Sometimes my posts are a bit wacky, and I don’t hit on things people really want to know. I’ve come to realise I like getting email questions because it is a nice format and I know I am helping at least one person.

This set of questions came in as a result of the EC2 and S3 videos I posted a while ago.

1. Is there a way to share a file system / volume across multiple EC2 instances? As in, if we have 2+ App servers running, it would be ideal if they shared a volume so that if files changed, they would be changed on all servers, instantly. If not, I suppose we could run NFS or something similar. Ideas?

It would be possible to have one of your EC2 instances be a master and share the files – just as one would do in any other “normal” situation (smb, nfs, whatever). If you’re only talking about code, you could also use something like rsync, or directly checkout from your source control to keep code in sync.

Another thing you can do for assets is write the data to S3 and share it via buckets. While this approach requires quite a bit of infrastructure and error handing on your part, it also gives you unlimited data storage and an “automatic” content delivery platform.

The last project we did we used the S3 approach. We used message queues to inform parts of the application about changes, and also to retry on failures. However, that project has massive data storage and delivery requirements.

2. Are we correct that making any configuration changes to an instance necesitates re-bundling that instance into a new AMI afterwards? Otherwise, all changes are lost the next time it’s shut down and fired back up.

Yes and no. You can build a custom AMI that has everything you want on it (or buy / rent a premade one), and then save all your configurations to a mounted EBS “Elastic Block Store”. An EBS basically equates to a hard dive you mount to the AMI. You can use the EBS just like any hard drive attached to a “normal” computer, and it’s storage persists.

It’s awesome on Linux because you an just mount the EBS anywhere (like in /var/www, /opt/coldfusion, or /etc/config), but you can achieve the same effect on Windows as well.

In other words, you’ll always lose changes to the C:\ when you bring the system down, but not lose the D:, E:\ etc.

(You’ll want to know how to build an AMI at some point though – system updates / upgrades and what not.)

3. We have some legacy windows only apps, so we are going to be running windows instances and linux instnaces, but we’re starting with the windows ones (assuming they will be more difficult)… Have you noticed any differences between the two that you want to mention? Have you worked with the windows instances much at all?

The windows ones are a bit more expensive, and they seem to take a really long time to start (3-4 minutes vs. 30-45 seconds on Linux), but once they get going they seem to be just like any other box. You can terminal service in to manage them – if you didn’t know it was an AMI you wouldn’t know it was an AMI :)

I’ve also never built a custom windows AMI, but I hear that it is easier (when it works). Building a Linux AMI can be completely scripted, and I don’t think a windows one can (though, again, I’ve never built a windows one)

4. We are a bit concerned with the complexity of making changes to instances and needing to take them down and re-bundle them for those changes not to be lost… I suppose we could do so to copies of the AMI so that we don’t need to take down production instances, but it still seems overly cumbersome. Do you know of a decent plan/flowchart/graph/play-by-play of how other companies/people have worked with EC2 servers as a production environment?

I can understand your concern, and the best remedy is to get in there and play. You’ll find that if you configure you infrastructure correctly, use EBSs correctly, you can bring up whole new production instances in 30 seconds (or so). Need a test deploy server? Bling. Done. You can do new releases by reassigning the IP to a new running instance… Anyway, I think you might want to read up on EBSs because it sounds like will alleviate a lot of your concerns.

As for the plan / flowchart … that’s the kind of stuff I get paid for :-D