I wrote recently about testing AWS auto scaling policies. Before you can test auto scaling policies however, you need an auto scaling configuration to test! This post will look at building a simple auto scaling configuration, to provide a scale-able and highly available web site. Before starting on the configuration, there are a bunch of services that need to be in place for the auto scaling group to function. These include:
- A VPC to launch our instances into
- A ELB to attach our auto-scaled instances to
- An AMI to launch. Either a custom AMI or one provided by Amazon, depending on the use case
- CloudWatch – used to monitor the performance of the AS group, and to trigger auto-scaling activities
The autoscaling configuration itself is composed of two parts. Firstly there is the launch configuration, which is the config template that the Auto Scaling group will use to launch instances. Then there is the Auto Scaling group itself, which defines how many instances you want to run and how the group will scale under certain conditions:
We’ll start by creating a launch configuration.
Creating a Launch Configuration
To get started, click the ‘Create launch configuration’ button. The steps to go through here are similar to those when you spin up a new EC2 instance. You’ll first be prompted to select and AMI and instance type you wish to use with the auto scaling group. For this demo, I selected the Amazon linux AMI running on a t2.micro instance. Once you’ve selected the AMI and instance type, you’ll be presented with a form to complete, which details the remaining launch configuration settings. These include:
- The name of the new launch configuration
- Purchasing option – whether you want to use spot instances
- IAM role (whether to attach a role to the instance. In my example I have attached a role which allows the instance access to an S3 bucket, from which it can download my static website files)
- Monitoring – Whether to enable detailed Cloud Watch monitoring
- Advanced Settings – These include User Data, IP Address Type and Kernel and Ram Disk ID
I’ve added user data to my launch configuration which installs a web server, then pulls over the website files from an S3 bucket, before starting the web server service:
#!/bin/bash sudo yum install httpd -y aws s3 sync s3://test-1-bucket/web /var/www/html sudo service httpd start
On the next pages, select the appropriate storage and security group settings to apply to the instances launched by this configuration. For this demo I created a new security group allowing port 80/http inbound, whilst keeping the default storage settings, which was to create a single root volume. Once done, review the chosen settings, then click ‘Create launch configuration’. At this point you’ll be prompted to select a keypair, which will be used when connecting to the instances launched from this configuration. We can now move on to creating the auto scaling group.
Creating an Auto Scaling Group
When creating an auto scaling group we need to provide the following basic detail:
- The launch configuration to be used (see above)
- Group Name
- Group size (the desired number of instances to start the group with)
- Network (The VPC that the instances will be launched into)
- Subnet (The subnet(s) that the instances can be created in)
For example:
In this example I will start with a single instance. This will allow me to test that the instance provisioned is behaving as expected, before I start building in scaling policies (which I’ll take a look at in my next post).
There are also a number of advanced settings. These are:
- Load balancing (Whether the instances will be automatically registered with a load balancer, and which target group or classic load balancer)
- Health Check type (Either EC2 or ELB)
- Health Check Grace Period. The grace period is the number of seconds that AWS will wait between triggering auto scaling events.
- Monitoring and Instance Protection
For example:
On the next page we’re prompted to configure auto scaling policies:
For now I will leave the default option selected, which is to keep the group at it’s initial size. I’ll do a follow up post to this to cover creating auto scaling policies. On the next pages, you can configure notification settings (auto scaling can send to an SNS topic when an event occurs), and you can configure tags for the instances created. As a minimum it’s a good idea to use a Name tag for the instances created by the group. On the final page, review the overall configuration then click ‘Create Auto Scaling Group’. In this example a single instance will be provisioned almost immediately, due to me setting the desired number of instances to 1. In my next post I’ll build in some auto scaling policies to this configuration, which is where the magic happens – with new instances added or removed from the group dependent on triggers set on cloudwatch metrics. More on this next time…