Yeah, we use EC2. We are trying to move towards your model, which is, I think, better.

But when we started no one really knew what the "right way" was, so we went with custom AMIs.

This is a little off topic, but can you elaborate on your reasons for preferring scripted installation? It's what I use too, but hearing someone else's justification would be helpful.

I'll tell you why I'd like to get there. It makes updating the master image easier. If you need a new package, you just update on the server side, and then all the new images get that new package. No rebundling required.

It also helps when you want to upgrade your OS. As long as the packages are mostly the same, you can just run your update script from the new OS and make a few changes.

The way I have to do it now, I have to build a whole new master image from scratch, because I can't upgrade Ubuntu in place on EC2 due to the way they handle the kernel and kernel modules.

Doesn't this increase the time it takes to boot up a new instance, though?

Boot, update and apply patches, copy over source & data, start running services...everytime you start a new instance

Yes, it does. But you probably aren't starting instances that often, and it only adds a few minutes. If you really need a fast boot, then you can still use an image.

However keep in mind, on EC2 at least, that the images are actually downloaded from S3 when you boot, so if you have a huge image, it will take almost as much time.

We do this too. Another nice advantage is changes to the production machine state are all in source control. We deploy on EC2 + our own .deb. The entire .deb recipe is checked into source, right next to the rest of our source code. There's no wondering about when a specific change got added to the AMI.

I'm sure that it's just your friend that sits around manually configuring servers, taking EC2 at face value as just virtual hardware -- what some are calling the "Meat Cloud".

Source Code > Documentation > Artifacts