Hello Timescale, first of all thank you a lot for that very detailed explanation on bandwidth/data transfer for our case. I was doing some research yesterday and got to similar conclusions, but anyway it's pretty clear the way you're detailing all the process behind.
Indeed, I just noticed BANDWITH and DATA TRANSFER are not the same although they're interchanged very frequently, in conclusion I could state that the first one sets a limit to simultaneous users and the second limits monthly visits.
find 350MB for 8 minutes of a static photo panorama experience quite a lot actually. Are you sure this is the bandwidth you need per viewer?
We're using this neat Mac program "Surplusmeter" which allows to track live the actual data transfer, recently we did some tests and indeed it's a bit high, right now the calculated average is 200MB/10min, which is like 0.33MBps and in a standard 100Mbps uplink connection (12.5MBps) would allow around 37 users simultaneously on the server which is not much really, this is a critical point to check on hosting.
The CPU and ram are not going to be the big issue...
This is the part which we really have no experience about, I guess there's not much demand on the server as virtual tour calculations are user side but, ¿have you experience on this? one of our current options has 4GB RAM, it's the lowest of them all but if it works it may be a nice option.
But really, instead of trying to figure out how to server that amount of data I'd have a look at where all that bulk is going.. Are the pano images properly multi-res and compresses sensibly? Are the hotspot media elements of a suitable size and hosted correctly?
All tour is multires, interface images are all .png and less than 5MB, from the Surplusmeter measures it seems image transfer for VT is what is consuming all that bandwidth.