Optimize your costs with AWS spot instances and Terraform in just a few steps
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:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet-allocation-strategy.html https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group#instance_requirements
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.
