EC2 Auto Scaling Purchasing Options

In the “Architecting on AWS” course there is a slide on Autoscaling Purchasing Options.

From the course notes:

Amazon EC2 Auto Scaling supports multiple purchasing options within the same Auto Scaling group (ASG). You can include Spot, On-Demand, and Reserved Instances (RIs) within a single ASG, allowing you to save up to 90% on compute costs.

The following walk through only takes a few minutes to try.

I keep it minimal to demonstrate the basic features and get started quickly, leaving you to try out the many further options.

In order to demonstrate using a mixture of On-Demand and Spot pricing, I will use a steady state Auto Scaling Group of 4:4:4, that is Minimum, Maximum and Desired all of 4. I aim to have a 50%/50% mix of On-Demand and Spot, that is 2 of each.

Another options is to have always have a certain number of On-Demand Base instances as part of the mix, but I will leave that Base number at zero.

When configuring Launch Templates and Auto Scaling Groups there is no reference to Reserved Instances. That part is automatically dealt with by matching your Reserved Instance choices, if any, with your actual running instances across the account, and then billing at the Reserved Instance price.

Everything that follows is done from the EC2 console.

This use case requires the use of a Launch Template.

Create a Launch Template. Give it a name. At a minimum, when the Launch Template will be used by an ASG, you must supply and AMI and Instance Type. I choose an AMZ Linux 2 AMI and t2.micro Instance Type.

Leave all rest as defaults. Note that expanding Advanced Details shows that you can request Spot instances here, but you must not tick this if the use case is to have a mix of On-Demand and Spot within and ASG.

Create an Auto Scaling Group and select the Launch Template. Select “Combine purchase options and instances”.

For Instance Distribution, clear “Use the default” and then choose “On-Demand Percentage” above base=50%, leaving everything else at default.

Choose to  Start with 4 instances. This is the desired number to start with. If you use Auto Scaling policies, then when scaling in and out, this the staring desired number and then it changes dynamically.

Select a subnet. In production it would be recommended to use more than one.

On the next screen, choose “No scaling policies”. To keep it simple, and to avoid needing to run some kind of simulated stress, we will keep it to a steady state group of 4 instances.

After a few seconds, you should see 4 instances launching.

We will want to verify the mix of On-Demand and Spot.

It is not possible to see the purchasing options from the instance details. Instead, you can go to EC2, Spot Requests to see 2 active spot requests, both fulfilled.

Alternatively, using CLI, the following will show details of the 2 Spot Instances.

aws ec2 describe-spot-instance-requests

If you select EC2, Spot Requests and click “Savings Summary” you can see A high-level summary of your savings across all of your running and recently terminated Spot Instances

To clean up:

Delete the ASG and Launch Configuration. The instances will be terminated, and in a few minutes you will see that the spot requests are closed.

The docs are here

Auto Scaling Groups with Multiple Instance Types and Purchase Options

and here

Introducing the capacity-optimized allocation strategy for Amazon EC2 Spot Instances

and for information about how the spot pricing model has changed recently

New Amazon EC2 Spot pricing model: Simplified purchasing without bidding and fewer interruptions


Low Cost WordPress

It seems there are many approaches to deploying WordPress on AWS

For example, there are cloud formation templates available. When I used these, they didn’t quite work out of the box, and I had to change some permissions on the Linux file system when it came to doing things like uploading media.

Given that I was going to have to mess around with Linux, my next approach was to follow a walkthough on the AWS site. You install a LAMP stack manually, then install and configure WordPress manually. Its a good learning exercise.

Another option is using LightSail, if it fits your needs.

In the end, I went for a Bitnami WordPress AMI from the Marketplace

For a low cost, low volume site, at the time of writing this site is running on a t2.nano, at less than $5 a month. You could use a t2.micro to be free-tier eligible if your account is still in its first year.

Later I might go for a t2.micro spot instance:

Relatively stable at $0.0038 for 3 months, that works out at $2.73 a month.


Incremental Snapshots

Snapshots are a way to backup  your volumes.

There are no labs specifically on taking snapshots in the course. In my opinion it would be a reasonable lab for an introductory course.

A good way of understanding snapshots is to try it.

  • Take snapshot1
  • Make a change
  • Take snapshot2  (this is incremental i.e. only changed blocks)
  • Delete snapshot1
  • Restore using the second snapshot.

Behind the scenes, when you deleted the first snapshot, AWS will ensure that the second snapshot contains all the blocks required for it to be fully usable.

To try it:

Launch an instance. I used Windows.

Navigate to Volumes>Snapshots

Take a snapshot

Make a change. I made a new folder on the desktop.

Take another snapshot. The snapshot will be incremental i.e. it will only contain the changed blocks since the first snapshot.

Now for the magic bit. Delete the first snapshot. Behind the scenes, AWS will ensure that the second snapshot contains all the blocks required for the second snapshot to be fully usable.

Stop the instance and detach the volume from it.

Create a volume from the second snapshot and attach it to the instance.

Ignore the instructions about the recommended device names in the window below, and use /dev/sda1. This makes it the root volume.

Start the instance.

It will be restored to the point at which you took the first snapshot.

As you know, snapshots are stored in S3, but not in any bucket you can see. It is also difficult to know exactly how much space is being used by snapshots. People are concerned that if they take frequent snapshot this will result in a large bill. One approach to this is to script the creation of snapshots, for example to take a daily snapshot and then delete all the older snapshots.

Scalable WordPress on AWS

There is an interesting document Reference Architecture for Scalable WordPress-Powered Websites

CloudFront is used to cache static content from an S3 bucket (plugins are available to integrate with S3), and dynamic content from an Application Load Balancer in front of the web instances, which are in an Auto Scaling group.  Compute optimized instances might be a good choice for the web servers.  An ElastiCache cluster caches frequently queried data. An Aurora MySQL instance hosts the WordPress database. As discussed in the Architecting course, for Autoscaling the web tier should be stateless. WordPress uses cookies for session storage. The DB layer holds persistent data. However, WordPress does also store some data including configuration data on the local hard disk on the instances, so instead the entire WordPress installation directory can be moved onto an EFS shared file system.