Deploying site on Amazon Beanstalk and IIS settings

Question

I am interested in working with Amazon Elastic Beanstalk to deploy my new site. A few things that I need to know and can't get an answer to:

1) How can I maintain IIS settings of all deployed and future deployed machines? 2) If I can maintain, what happens if I change the settings on one server, will it automatically set it on other servers? 3) How can I backup the data. In other servers I usually make an AMI and deploy to a new server in case of a problem?

Answer 1

In constrast to @Christopher's comment:

1) deploying a custom AMI through EB is an anti-pattern. Every time EB updates the base platform, you will need to recreate your custom AMI.

2) Yes, manual configuration changes on the server is an anti-pattern. But specifying configuration as part of your deployment unit is recommended practice.

Have a look at the AWS EB documentation on Customizing Software on Windows Servers.

3) You should not have any state on your server that needs to be backed up. Everything you need to deploy the application is in your deployment package and EB configuration. EB uses health checks and auto-scaling to ensure your environment is always running.

Answer 2

Beanstalk is not much more than a collection of calls to various AWS services, such as autoscaling, S3, and EC2, among many others, and some scripts and routing that make deploying new application versions easy. If you approach it with that understanding, its structure makes more sense:

1. Beanstalk comes with stock AMIs, but you can deploy custom ones as well. Bake your IIS settings into an AMI (be sure to base it upon a stock Beanstalk AMI), and they will persist through all auto-scaling operations. This only applies to server configuration. New versions of your application shouldn't be baked into the AMI, and are propagated to your servers via beanstalk itself.
2. Making configuration changes on the servers once they're instantiated is an anti-pattern. Changing one will not propagate those changes to the others. Instead, you should cut an AMI for the new configuration, spin up a second environment, and change the domain routing to make a zero-downtime switch. This is quite counterintuitive the first time you do it, particularly if you're accustomed to datacenter deployments. It is possible to avoid the routing change by altering an environment's AMI after instantiation, but it will be interruptive.

I'm afraid I don't quite know what you mean by question 3. To what data are you referring? If you can let me know in comments and I'll be happy to edit this answer with anything I know.