Until elastic beanstalk supports time scheduled scaling, I will be sad. Every morning my app servers go from zero to a million miles an hour and it takes about 20 minutes to scale up. Does anyone actually use this at scale?
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!
I believe you could write code to do this, as long as you have amazon credentials on a server at that time in the morning. Did you write your own app, or do you need to hire a consultant to do this?
Autoscaling isn't really intended for bursting, it works better when you have predictable traffic patterns. But if I understand it correctly you can use EB with custom Cloudwatch metrics and that lets you do some pretty cool, predictive things that autoscale based on external factors such as: volume of Twitter mentions, Google Analytics data, number of active user sessions, etc. In theory you could write some app code that uses custom cloudwatch metrics to initiate scale-up during certain timeframes. right ?
