Some time saving tips when setting up an Amazon EC2 network

I ran into several hiccups with my first foray into Amazon's EC2 and AMIs setting up a tiered server environment. As I hate making the same mistake twice (and love learning from others experiences) I put together a short list of "my" "lessons learned" when setting up an Amazon EC2 network for the first time. Which in retrospect seem somewhat obvious (but isn't that software development in general).



- Use EBS based AMI images otherwise you will lose everything if this instance isn't cloned (not necessarily a bad thing). This is analogous to booting an ISO image or a harddrive install--the thing is that the AMIs are built with this distinction and as far as I know it can't be changed, so you need to select an appropriate AMI.

- Search for an appropriate AMI and try first. Make sure you can do the basics. i.e. set up the network, and access the system as you expect before investing a load of configuration time into the system to make sure you have what you want.

- Initially set up with different security zones for each system (or different tier) as the policy cannot be changed after startup. The reason for this is that each system will probably have different needs. Once configured you can look at your firewall needs and consolidate the security zones when/if you set up v2.

- Do download the firefox ec2 manager. Seems to expose just about everything you could want access to via the browser.

- Watch your account, to get an idea of the billing you are running up. It wasn't that much for me but it made me realize that I should shutdown the systems when no in use (since this was a simple demostration and didn't need to be up 24/7).

- Use a windows machine that generates a default password (which apparently doesn't happen, or is a bug with the grab of the log file)

- Nail down the ip addresses of the machines on the lan 'cause they are dynamic. The right way to do this is to assign an elastic IP, which is an external fixed IP address. However, if you use the hostname equivalent, the internal DNS will return the internal IP, and will allow you to avoid sending the data outside (thereby reducing costs, and increasing performance). Seems to be the only way without setting up a virtual network.

- And you will probably want to install the ec2 tool set on the local image. For instance if you want to bind an elastic IP on boot automatically. This involves installing Java, the ec2 toolkit, and then invoking your script in the appropriate boot location.

- Permanent assignment of elastic IPs across reboots requires installation (on target image) of Amazon EC2 tools to set the assignment on boot up.

- Which leads to the final one: don't forget to clone image instances on a regular basis. Particularly if you are building up systems. It's just too easy to terminate an instance and lose everything.

Pretty neat though to see things up and running though with minimal upfront cost. Although I'm not convinced it's that much cheaper than lining up real hardware.