My friend Dan and I enjoy playing first-person shooters, where it’s just the two of us going head-to-head in a game. It’s something we’ve been doing off and on since the days of serial cables connecting two Commodore Amiga’s in one room. Dan has since moved across the country from me, but the growth of the Internet and gaming technology has allowed us to keep the gaming going, even if it involves a bit more complexity now. A few years ago, I was looking for an inexpensive way to host a game server that would have a reasonably low and equivalent latency for both of us. At the time, the virtual hosting services I looked at were running about $25/mo, which isn’t bad but seemed like overkill, given that we’d only be using the server once a week or so (late-night Friday sessions are the norm for us).
As luck would have it, about this time Amazon introduced their virtual hosting/cloud computing service called the Elastic Compute Cloud (EC2). It allows users to create an image for a virtual server that can be activated and shut down easily, with service charges at $0.10/hour for a running instance plus a bit for data transmission. When the instance is not running, the user is only charged for data storage of the image on Amazon’s Simple Storage Service (S3), at $0.15/GB per month (charges listed here may vary in the future or over different configurations). So with several gigs of storage and running a few hours each week, this is a much better deal than paying for an always-running virtual server.
One annoying thing when EC2 first became available was that you couldn’t make changes to data stored with the instance. Building and provisioning an instance would take a few hours. After that, it could be started and stopped within minutes, but any changes would be lost between boots. If you wanted to upload a new map for your game, you’d have to rebuild the instance. Within the last year or so, Amazon introduced Elastic Block Storage (EBS). This allows a user to create a volume within S3 that can be mounted by an instance at boot time. Any changes on that volume are permanent. Snapshots of the volume state can also be made, allowing for recovery if the volume data becomes corrupted or you need to return to a previous state of the volume. Of course, you do have to pay for the data space used by these volumes and snapshots, but the pricing, as I indicated above, is pretty reasonable. Even when Dan and I have done quite a few hours a month of gaming, I seldom go over $3/mo in total charges.
If you do the math, using EC2 for a game server that is up and running constantly is no bargain. If this is your need, it’s definitely better to look at a virtual hosting service rather than EC2. But, if you only need the game server running a few times a month, EC2 is pretty hard to beat.
Half-Life 2 Deathmatch (HL2DM) is the game of choice for me and my friend right now. It’s been ideal under EC2, since the standalone Steam server runs under Linux and is easily configured and controlled using the command line and scripts. At some point, I’d like to post more details on my installation. I have some cool features going—including using a Linux service that communicates the dynamic IP of the EC2 instance to DynDNS.org and associates it with a hostname so that when we fire up Half-Life 2, we don’t have to point the game to a new IP each time and instead just reference a static hostname.
Here are a couple handy URL’s if you’re interested in giving EC2 and a Half-Life 2 game server a try:
Amazon Web Services (AWS) Management Console
Source Dedicated Server (srcds)