Home Development Agile Same-day Terraform support for EC2 Predictive Scaling Policy

Same-day Terraform support for EC2 Predictive Scaling Policy


AWS is always bringing out new services, enhancing current ones; they are released at a pace that would be considered impossible even a couple of years ago. While this is awesome for AWS users, uses who only deploy new services by code using providers supplied by their preferred IaC can have issues. These new features will not be exposed to the relevant Terraform provider; this disconnect can cause problems with users who wish to consume these new features and developers who will circumvent (sorry workaround) and Operations attempting to keep the lights on in a high-performance culture. This lag is only to be expected. A considerable amount of development hours has gone into building out new features. AWS needs to start gaining value from their code investment by releasing the product to market as quickly as possible. This means that things like 3rd party providers such as the HashiCorp AWS provider are always behind the curve with features. However, today there appears to be a little bit of synchronicity, the AWS announcing the general availability of Predictive Scaling Policy in EC2 and at the same time HashiCorp announcing that Terraform also supports the feature in the latest AWS provider.

Terraform adds Predictive Scaling with Infrastructure as code

What is Predictive Scaling Policy?

We already understand what an AWS scaling policy is. It is the ability to trigger a change in a resource set based on a predetermined trigger. The trigger will either increase the number of instances in a cluster at a set time or then decrease the number during the evening, thereby potentially reducing your overall bill. Traditional Auto-Scaling is a blunt instrument, often based on nothing more than an arbitrary figure based on nothing more sensible than when everybody enters or leaves the office:

  • People enter at 9 am, so let’s start the extra servers for your application at 8:30 am,
  • 90% of the office leaves at 5 pm, so let’s scale back down at 6 pm.

But what is Predictive Scaling policy? Predictive scaling is AWS’s newest addition to its armory to manage elasticity in your environment. Using data collected from your actual EC2 usage and other data points obtained from AWS observations, AWS pushes this through some secret sauce (ML modeling) to effectively predict your usage over set periods, usually a day or a time weekly cadence. What is clever about this is that the service can start to anticipate your hot spots with as little as 24 hours of historical data. What is even better is as the algorithm behind this service uses Machine learning, AWS will re-evaluate its predictions every 24 hours to create a forecast for the next 48 hours.

“Predictive Scaling Policy” sounds fantastic! but I bet I won’t be able to use this in my Infrastructure as Code deployments yet. Not so. Remember I mentioned synchronicity at the beginning of this post. Yes, that is correct. You can start using this feature to control your EC2 clusters today.

How do I use this feature?

As with most new things, there are some pre-requisites, not too demanding. You need to be using Terraform 0.12 or later; this should not be an issue because you are using version 0.12 or later. Nobody wants to be using 0.11 or earlier with all those issues 😊. And the need for the latest AWS provider is a given.

To use this new feature in your code will require the use of a single new resource:


together with some changes to your existing autoscaling resource policy contained within the resource block:


The configuration below demonstrates how the Terraform AWS provider can configure Predictive Scaling within an EC2 Auto Scaling group.

The code below is used to obtain the registered AMI for use later. This section is as per a normal auto-scaling group.

data "aws_ami" "amzn" {
   most_recent = true
   owners      = ["amazon"]
   filter {
      name   = "name"
      values = ["amzn2-ami-hvm-*-x86_64-gp2"]

This data block provides information on the list of available zones. Again there is no need to change anything in this block.

data "aws_availability_zones" "available" {
   state = "available"
   filter {
      name   = "opt-in-status"
      values = ["opt-in-not-required"]

The following resource block takes the name of the image defined in the aws_ami data definition and defines the size of the instance to be deployed when the resource auto-scales. Once again there is no requirement to change anything in this block.

resource "aws_launch_configuration" "test" {
   name          = "launch_configuration"
   image_id      = data.aws_ami.amzn.id
   instance_type = "t2.micro"

The autoscaling group resource block had a change, the min and max size have been set to 0. This is important as your policy decisions are now set by a predictive policy.

resource "aws_autoscaling_group" "test" {
   availability_zones   = slice(data.aws_availability_zones.available.names, 0, 2)
   name                 = "autoscaling_group"
   max_size             = 0
   min_size             = 0
   force_delete         = true
   launch_configuration = aws_launch_configuration.test.name

This is where the majority of differences are contained.

resource "aws_autoscaling_policy" "policy_predictive" {
   name                   = "policy_predictive"
   policy_type            = "PredictiveScaling"
   autoscaling_group_name = aws_autoscaling_group.test.name
   predictive_scaling_config {
      metric_specification {
         target_value = 32
         predefined_scaling_metric_specification {
            predefined_metric_type = "ASGAverageCPUUtilization"
            resource_label         = "myTestLabel"
         predefined_load_metric_specification {
            predefined_metric_type = "ASGTotalCPUUtilization"
            resource_label         = "myTestLabel"
   mode                          = "ForecastAndScale"
   scheduling_buffer_time        = 10
   max_capacity_breach_behavior  = "IncreaseMaxCapacity"
   max_capacity_buffer           = 10



Predictive scaling is an interesting feature. This feature will scale your EC2 environments much more efficiently than traditional scaling methods, which if the hype is true will result in lower AWS bills for customers as elasticity will be better managed and much more granular than a blunt instrument scaling method. But what I find more interesting is that this feature was released into the HashiCorp AWS Provider on the same day as its release to general availability within AWS. This seems to show that AWS sees Terraform as one of the main methods of deploying infrastructure to their environment.


Sign up to receive our top stories directly in your inbox