top of page

Optimize your costs with AWS spot instances and Terraform in just a few steps

Updated: Jul 11


When looking to reduce your cloud expenses, spot instances are definitely one of the best alternatives, today I’ll show you how you can leverage this for your non-production environments with Terraform. Spot instances can prove to be an excellent approach for reducing cloud expenses in non-production settings. But don’t forget it’s essential to consider the spot allocation strategy, instance types, and potential hazards while configuring spot instances.

Let’s have a look.


Step# 1: Configure AWS launch_template and autoscaling_group

First, we need to configure our aws_launch_template and aws_autoscaling_group resources:


resource "aws_launch_template" "Lt" {


name_prefix = "asg-testLT-"

image_id = var.ami_id

ebs_optimized = "false"

instance_type = var.instance_type

key_name = var.key_name

security_groups = var.security_groups

user_data = var.user_data

metadata_options {

http_endpoint = "enabled"

http_tokens = "required"

http_put_response_hop_limit = 2

}

network_interfaces {

associate_public_ip_address = var.public_ip

security_groups = var.security_group

}

iam_instance_profile {

arn = var.instance_profile_arn

}

block_device_mappings {

device_name = "/dev/xvda"

ebs {

volume_size = var.root_vol_size

volume_type = "gp2"

delete_on_termination = true

}

}

}


And our autoscaling group:


resource "aws_autoscaling_group" "asg" {

vpc_zone_identifier = data.aws_subnet_ids.private.ids

name = var.asgName

max_size = var.maxSize

min_size = var.minSize

health_check_grace_period = 100

default_cooldown = var.cooldown

health_check_type = var.healthCheckType

desired_capacity = var.desiredSize

capacity_rebalance = true

force_delete = true

mixed_instances_policy {

instances_distribution {

spot_allocation_strategy = "capacity-optimized-prioritized"

}

launch_template {

launch_template_specification {

launch_template_id = aws_launch_template.Lt.id

version = "$Latest"

}

override {

instance_type = "t3.large"

}

override {

instance_type = "t3a.large"

}

override {

instance_type ="t2.large"

}

}

}

termination_policies = [

"OldestInstance",

"OldestLaunchConfiguration",

"Default",

]

}



Step # 2: Define a mixed_instance_policy

To use Spot instances in our EC2 auto scaling group resource, we need to define a mixed_instances_policy block, that is conformed by the instances_distribution block, and the launch_template block.


The instances_distribution block defines how we want to mix on-demand and spot instances, in our case we want to use 100% spot instances, but there can be business cases when we want a percentage of on-demand instances (critical workflows). The spot allocation block strategy defines how we want AWS to choose spot instances for our workflows (price, instance type, etc) . We can also define strategies for on-demand allocation and spot pooling.


The launch_template block references the launch template needed for the autoscaling group, in this case, we override the instances that we want for our workflow.


Step # 3: Choose your spot allocation strategy

There are many important factors to consider when we are implementing spot instances:

  • The spot allocation strategy is very important and it depends on the nature of the workflow, the most common strategies are the following:

  • priceCapacityOptimized: This means that AWS will request Spot Instances from the pools that it believes have the lowest chance of interruption in the near term. Spot Fleet then requests Spot Instances from the lowest priced of these pools.

  • capacityOptimized: With Spot Instances, pricing changes slowly over time based on long-term trends in supply and demand, but capacity fluctuates in real-time. The capacityOptimized strategy automatically launches Spot Instances into the most available pools by looking at real-time capacity data and predicting which are the most available.

  • lowestPrice: The Spot Instances come from the lowest priced pool that has available capacity. This is the default strategy. However, we recommend that you override the default by specifying the priceCapacityOptimized allocation strategy.


In this case, the capacityOptimized strategy was chosen over the other strategies, because the specific workloads depend on certain types of instances to work properly, that is why we override the instance types in the launch template block.


The fear of using spot instances is how they can interfere with the work of developers for non-production environments and how this can affect productivity, that is why we have to choose carefully the type of instances for our spot pool, we can do so using the AWS Spot advisor: https://aws.amazon.com/ec2/spot/instance-advisor/.


Step # 4: Select instance type

To choose an instance type for our workloads it is important to take into account the following:

  • vCPU

  • Memory

  • Region

Let’s say, that for this example an instance in the us-east-2 region was needed, with 2 vCPUs and 8GB of memory and with a tiny percentage of interruption possibilities, in the spot instance advisor we can find the t3.large instance, for this instance we have 70% of savings over on-demand instances, and the disruption frequency is less than 5%, so with this, we can ensure that our workloads are more protected from being terminated all the time.


It is important to review and analyze instances that can fulfill our workload needs, so it is recommended to at least define more than 4 instances to ensure spot’s availability.



Final thoughts


To sum it up, spot instances can be a fantastic solution for lowering cloud costs in non-production environments. However, it's crucial to take into account the spot allocation strategy, instance types, and potential risks when setting up spot instances. By using helpful tools like the AWS Spot advisor, you can make well-informed choices and ensure that your workloads are both cost-effective and dependable. Remember, spot instances might not be the right fit for every situation, so it's important to assess your specific requirements and workloads before implementing them.


Happy coding and see you in the Cloud!



References:


photo-of-juan-bermudez




Juan Bermudez

Cloud Engineer

Teracloud






If you want to know more about Terraform, we suggest going check How to Restore a Previous Version of Terraform State

 

If you are interested in learning more about our #TeraTips or our blog's content, we invite you to see all the content entries that we have created for you and your needs.





Buscar por tags
bottom of page