Amazon has always said “expect failure” with regards to their services. S3/SQS *will* (and does) return 500/503 errors at times. And EC2 instances *will* go away at some point. If people ignore this and assume their EC2 instances will be up for ever and ever, then they will experience data loss.

> Thirdly is unexpected restarts. What event based actions can I automate? I don’t know and this is possibly just because I’ve not dug into it deep enough yet. When they restart, EC2 servers are blank again. Can I set them to be automatically loaded with a script which reverts their state back to what it was pre-reboot?

So, one way is to use a system configuration tool like puppet. Simpler option is to write a startup script that is passed to the instance as part of the user-data and executed. This is how the Ubuntu & Debian AMIs are set up. Such a script can install packages, download other scripts or do other more exciting and complicated things too. And if you get an “installed” image set up, its pretty easy to save it back to S3 as a new AMI - this leaves you only to do minimal node configuration on boot, since the OS and related packages are already installed. EBS makes some of this easier, but if you want to scale using EC2 you’ll need to deal with it at some point.

> Forthly, permanent ip addresses - I know they have them but again that’s about the limit of my knowledge. Can I have more than one ip address per server? Can I have a floating one if I want to roll my own my high availability configuration?

Each EC2 instance has a private IP, a public IP, and optionally one or more “elastic IPs”. These are static addresses that can be mapped onto one running EC2 instance, and you can remap it via the “ec2-associate-address” command. They’re free as long as they’re assigned to instances - if you have unassigned IP addresses they’re charged at 1c/hour.