Can additional web servers be used in an AWS Auto-Scaling group?

jbiggley

I'm throwing this into the SAM forum because SAM is going to be the platform that allows for AWS monitoring at some point in the not-to-distant future (I hope!).  One of the highly anticipated features is the ability to monitor auto-scaling groups which is, in and of itself, pretty awesome.  That made me think -- "Where could I use an auto-scaling group?"  The recent deployment of PerfStack in the (as of today) release candidates for NPM and SRM has forced me to finally get around to deploying the 3 additional web servers I bought last year.  Like any good admin, I am going to put all 4 of my web servers into a pool and load-balance to them (easy, right?) but then the Cloud engineers started talking about AWS vs On-prem and I though "I wonder if I can auto-scale additional web servers?" 

It seems like a perfect fit from a use-case perspective.  Most of my load will happen during North American business hours (even though I work for a global company) and it doesn't really make sense for me to run 4 web servers where 1 could easily handle the load.  The question is how to do it?

Auto-scaling groups (Auto Scaling Groups - Auto Scaling ) are more than just stopping and starting services, they actually kill and spawn new instances based on the metrics you pre-define in the group.  Additional web servers don't behave like that today.  Spawning a new instance is more than just a couple of clicks and a fancy PowerShell script (or is it?!?)

Anyway, before I spent a whole lot of time on it I thought I'd crowd-source some feedback on whether it could actually be done for an IIS-based web server.

jmeredith

Web servers are actually a pretty typical use case for autoscaling.  There are a few considerations though.

Traffic coming into the web server - You've got to use something to get the requests into the servers.  Probably a virtual load balancer.  The autoscaling has to be able to put the new server into the load balancer's pool and remove it when you terminate the server.  This is actually the easy part.

Getting that syncing feeling - You've got to make sure that all the web servers are identical and serve up the same content.  FIrst you should start with the same image when building the instances and usually continued syncing involves something like rsync or varnish keeping the data synced as users access the servers.  That's where it can get tricky to add web servers to the pool and set up the syncing automatically.  Some people will use a file system sharing application like Gluster or NFS.  Another option is to keep your data in S3 so it can be shared.  Here are a couple of links that discusses some of these options.  https://forums.aws.amazon.com/message.jspa?messageID=181768  How To Share Files Between EC2 Instances | ObjectiveFS

Scaling down - Scaling down can be tricky since you typically don't want to just drop connections on the server you are terminating.  This is called connection draining and fortunately AWS allows you to select that option on your ELB.  ELB Connection Draining – Remove Instances From Service With Care | AWS Blog