| We use CloudFormation to do this, but I thought beanstalk had similar cloudwatch metrics to scale with. We don't use chef/puppet/ansible/salt in production or any code deploy stuff. Basically use your provisioning tool of choice to setup an instance like you would a local vm, deploy your code, then package that all up as an AMI. When the server spins up there is some minor config that gets set depending on the zone it is in and we are off to the races. Takes about 2 minutes to fully register with ELB and start serving traffic. Each step you remove from a new instance to become 'ready' decreases your load time and lets you run at higher margins so you arent stuck with a Cloudwatch alert of 30% cpu -> scale up because it takes 20 minutes for chef to config the server, git to deploy code, run whatever compilation of assets/configs, then finally register with ELB Downside of course is you are always making AMIs to do a new push. If you follow semver, you could add a small step to handle a pull of your latest .PATCH version so you are only creating AMIs for MAJOR.MINOR. Or if you prefer only doing MAJOR ami creations tldr: reduce # of steps a new instance has to take in order to start handling traffic = higher cloudwatch thresholds = more server utilization = cheaper bill and faster scaling! |