An Economy of Scale
ready-room.net vs rolling your own
I still get surprised reactions when I explain how ready-room.net works or where those 10min of startup is spent, so I thought I'd take a moment to revisit it. I think the automation is great as it makes on demand DCS hosting easy, but I'd also like to point out it can actually cost less than rolling your own as well, which I think is pretty neat. I'll explain it, but the long and short of it is there is an economy of scale.
Hosting Cost - 16 GB / i3.large equivalent
The difficulty with hosting DCS in AWS, or any other cloud platform is just it's sheer size on disk when installed. Close to 150GB at last count. The issue is that unlike a compute instance - disks can't be temporarily provisioned, unless you're prepared to start from scratch every time you start your server. Standard disk in AWS is ~.1 USD per GB/month, so if we budget for 200GB (to allow for the OS and DCS updates) than that's 20 USD per month before any compute time.
A strategy that you might think would reduce the cost of disks is to use disk snapshots. The idea is you create a snapshot of your disk, then you can delete your disk and restore it from the snapshot the next time you want to use it. AWS snapshots are ~.05 USD per GB/month so it's absolutely more cost effective, but not without its tradeoffs. The way snapshots are actually implemented is by saving the disk data to s3, and when the disks are restored from snapshots that data needs to be retrived from s3 which takes time. Given a snapshot AWS will produce a disk fairly quickly, but with the tradeoff that the disk itself is lazily initialised - i.e. the first read from a position on the disk may take longer than normal as it will need to wait for the data from s3, in fact AWS documents a process known as disk warming which is a way of waiting for the disk to be ready to operate at full speed. DCS as it turns out will need to read the disk upon certian events when running a mission, and a disk that is still warming up can result in a less than ideal in-game experience.
ED recommends running DCS on SSDs, which suggests DCS is sensitive to disk performance. In the cloud the hands down best performing disks are those directly connected to the CPU and housed in the same chassis as the CPU. The tradeoff with these disks though is that becuase they are directly connected, they are only available in conjunction with the compute instance - we have to start from scratch with every newly provisioned compute instance. This isn't so bad though becuase another strategy of reducing the cost of disks is just to maintain the data directly in s3, which at ~.025 USD per GB/month is more cost effective again, and the process of copying the data into a new compute instance is effectively equivalent to the process of restoring a snapshot with disk warming.
An Economy of Scale
So one way of looking at rr is that it's fundamentally a caching service for quickly staging DCS server onto EC2 instances to avoid the cost of a long lived disk. Both disk snapshots and s3 staging have the property of being able to service all the instances in a region, so there is definitely an economy of scale here and where a decent chunk of the value of rr is as a service.