AWS Auto Scaling groups provide a mechanism to scale and manage a collection of EC2 instances that share the same instance configuration. The resource exists to enable both manual and dynamic control over the number of running instances with the explicit goal of lowering operating costs. Terraform interacts with this resource in a specific way because the underlying instances are not managed directly by Terraform state. Every scaling action performed by the Auto Scaling service would otherwise introduce state drift in Terraform, which is why the configuration pattern for Auto Scaling groups relies on lifecycle arguments and declarative capacity targets rather than direct instance management.
The tutorial workflow described assumes familiarity with the standard Terraform workflow. The workflow moves from provider configuration through launch artifact definition to autoscaling group declaration, and then to policy attachment. Traffic management is tied to the group through a load balancer, and a scaling policy is defined to automatically modify the number of instances running in the group. The lifecycle arguments are used specifically to avoid unwanted scaling operations that would be interpreted as drift by Terraform.
The dynamic nature of Auto Scaling groups is a core constraint for infrastructure as code. Because AWS can add or remove instances outside of Terraform apply cycles, Terraform does not attempt to track each EC2 instance created under the group. The state file records the desiredcapacity, minsize, max_size, launch template reference, and other group attributes, not the individual instances. This design choice prevents constant state conflicts, but it requires operators to understand that scaling events will not be reflected as resource changes in Terraform unless the group configuration itself is changed.
Dynamic Nature and State Drift Management
AWS Auto Scaling groups let you easily scale and manage a collection of EC2 instances that run the same instance configuration.
The impact of this capability is that teams can maintain a homogeneous fleet with a single definition, reducing the operational burden of launching instances individually. The real world consequence is cost elasticity: the number of running instances can be increased during demand spikes and decreased during idle periods, directly translating to lower compute spend.
You can then manage the number of running instances manually or dynamically, allowing you to lower operating costs.
Manual management is useful for planned events such as batch processing windows. Dynamic management is useful for reactive workloads where CloudWatch metrics drive scaling decisions. The cost impact is realized because unused capacity is removed automatically rather than remaining provisioned.
Since ASGs are dynamic, Terraform does not manage the underlying instances directly because every scaling action would introduce state drift.
This means Terraform plan will not show additions or removals of individual EC2 instances as changes. If an operator manually scales the group via the console or CLI, Terraform will not detect those instances as resources under its control. This prevents perpetual diffs but also means instance-level tagging, security group changes, or user data updates must be handled via the launch template or launch configuration, not via individual instance resources.
You can use Terraform lifecycle arguments to avoid drift or accidental changes.
Lifecycle arguments such as ignore_changes on desired_capacity or create_before_destroy allow the Terraform configuration to coexist with external scaling actions. The contextual layer connects this to the broader pattern of separating desired state for the group from the actual runtime count.
In this tutorial, you will use Terraform to provision and manage an Auto Scaling group and learn how Terraform configuration supports the dynamic aspects of the resource.
You will launch an ASG with traffic managed by a load balancer and define a scaling policy to automatically modify the number of instances running in the group.
The load balancer provides the integration point between incoming traffic and instance health. The autoscaling group registers healthy instances with the load balancer target group, ensuring traffic only reaches instances that passed health checks. The scaling policy ties metrics from the load balancer or EC2 to capacity adjustments.
You will learn how to use lifecycle arguments to avoid unwanted scaling of your ASG.
This reinforces the drift prevention theme and provides operators with a predictable workflow where Terraform governs the template and boundaries, while AWS governs the instance count within those boundaries.
This tutorial assumes that you are familiar with the standard Terraform workflow
The standard workflow includes terraform init, terraform plan, terraform apply, and state management. The assumption allows the tutorial to focus on resource-specific arguments rather than basic Terraform mechanics.
Scaling Policy Types and Terraform Support
An Auto Scaling Group without scaling policies is just a fixed-size group of instances.
Without policies, the group will maintain the desired_capacity but will not react to load. The operational consequence is that the application may become overloaded during traffic spikes or waste resources during troughs.
The real power comes from policies that automatically adjust capacity based on metrics, schedules, or predictions.
Metrics-based policies react to CloudWatch data such as CPU utilization, network traffic, or custom application metrics. Scheduled policies align capacity with known business patterns. Predictive policies use machine learning forecasts. The combination determines responsiveness.
Terraform supports all the scaling policy types AWS offers, and getting the right combination can make the difference between a responsive application and one that crumbles under load.
The contextual layer ties policy selection to business risk. An application that crumbles under load experiences latency spikes, error rates, and revenue loss. Proper policy configuration aligns infrastructure behavior with service level objectives.
This guide covers the main scaling policy types you can configure with Terraform.
The coverage includes simple scaling, step scaling, target tracking, scheduled scaling, and predictive scaling. Each type maps to a distinct AWS resource or block in Terraform.
Simple scaling is the oldest and most straightforward type.
Simple scaling policies add or remove a fixed number of instances when a CloudWatch alarm fires.
The impact is deterministic: an alarm breach triggers a fixed adjustment, for example +2 instances. This simplicity makes troubleshooting easier but can cause overreaction to transient spikes.
Terraform configuration for simple scaling typically involves an aws_autoscaling_policy resource with scaling_adjustment and an aws_cloudwatch_metric_alarm resource that references the autoscaling group name. The policy type is ChangeInCapacity.
The guide emphasizes that Terraform supports all scaling policy types AWS offers.
This support means the same Terraform code can express simple, step, and target tracking policies by changing arguments, allowing policy evolution without changing tooling.
Launch Template Definition and Autoscaling Group Composition
Determine the scaling policies you want to apply to the Auto Scaling group.
Policy determination must precede group definition because the group attributes such as min_size and max_size must accommodate the policy's adjustment range. The impact is that a policy that adds three instances will fail if max_size is below current capacity plus three.
How to create an AWS Auto Scaling Group in Terraform
- Define a launch configuration block and autoscaling group block
The example below defines a launch template and then uses this in the autoscaling group resource block (you should use these instead of launch configurations).
The launch template is the recommended approach over launch configurations because it supports versioning and more granular parameter control. The impact is improved deployment safety and rollback capability.
hcl
provider "aws" {
region = "us-west-2"
}
The provider sets the AWS region for all resources in this configuration. The region choice affects AMI availability, subnet IDs, and latency to users.
hcl
resource "aws_launch_template" "template" {
name_prefix = "test"
image_id = "ami-1a2b3c"
instance_type = "t2.micro"
security_groups = ["sg-12345678"]
}
The launch template specifies a name prefix to use for all versions of this launch configuration. Terraform will append a unique identifier to the prefix for each launch configuration created.
An Amazon Linux AMI is specified by a data source in the reference material, but the example uses a hard-coded image id ami-1a2b3c. The AMI determines the operating system and base software. The instance type t2.micro defines compute and memory capacity. The security group sg-12345678 controls inbound and outbound traffic.
The contextual layer is that changes to the launch template create new versions, and the autoscaling group can reference $Latest to automatically use the newest version.
hcl
resource "aws_autoscaling_group" "autoscale" {
name = "test-autoscaling-group"
availability_zones = ["us-west-2"]
desired_capacity = 3
max_size = 6
min_size = 3
health_check_type = "EC2"
termination_policies = ["OldestInstance"]
vpc_zone_identifier = ["subnet-12345678"]
launch_template {
id = aws_launch_template.template.id
version = "$Latest"
}
}
The autoscaling group block specifies the minimum and maximum number of instances allowed in the group. min_size = 3 ensures at least three instances remain, protecting against scale-to-zero scenarios. max_size = 6 caps cost and resource usage.
The desired count to launch is desired_capacity = 3. This is the target the group will maintain.
A launch template is used for each instance in the group via the nested launch_template block. The id references the template, and version = "$Latest" ensures new instances use the newest template version.
A list of subnets where the ASGs will launch new instances is provided via vpc_zone_identifier = ["subnet-12345678"]. This restricts placement to specific subnets, often across availability zones for fault tolerance.
Health check type is defined as EC2. This means AWS checks instance status via EC2 health, not via Elastic Load Balancing health checks.
Termination policy is set to OldestInstance. This is a list of policies to decide how instances in the Auto Scaling Group should be terminated. The oldest instance is terminated first during scale-in, preserving newer instances that may have updated software.
The impact of OldestInstance is even distribution of instance age and predictable scale-in behavior. The context connects to rolling deployments where newer instances should be preferred.
Module Based Provisioning with Instance Refresh and Lifecycle Hooks
Terraform module which creates Auto Scaling resources on AWS.
The module approach abstracts common patterns and reduces repetition. The impact is faster adoption and consistent defaults across teams.
Autoscaling group with launch template - either created by the module or utilizing an existing launch template
This flexibility allows reuse of an existing launch template in production environments where template ownership is separate.
Autoscaling group utilizing mixed instances policy
Mixed instances policy enables use of multiple instance types or purchase options within the same group, improving cost and availability.
Ability to configure autoscaling groups to set instance refresh configuration and add lifecycle hooks
Instance refresh provides controlled replacement of instances when launch template changes. Lifecycle hooks allow custom actions before or after instance launch or termination.
Ability to create an autoscaling group that respects desired_capacity or one that ignores to allow for scaling without conflicting Terraform diffs
The ignore_changes behavior for desired_capacity prevents Terraform from reverting manual scaling actions.
IAM role and instance profile creation
The module can create the IAM role required for the autoscaling group to interact with AWS services.
hcl
module "asg" {
source = "terraform-aws-modules/autoscaling/aws"
name = "example-asg"
min_size = 0
max_size = 1
desired_capacity = 1
wait_for_capacity_timeout = 0
health_check_type = "EC2"
vpc_zone_identifier = ["subnet-1235678", "subnet-87654321"]
initial_lifecycle_hooks = [
{
name = "ExampleStartupLifeCycleHook"
default_result = "CONTINUE"
heartbeat_timeout = 60
lifecycle_transition = "autoscaling:EC2_INSTANCE_LAUNCHING"
notification_metadata = jsonencode({ "hello" = "world" })
},
{
name = "ExampleTerminationLifeCycleHook"
default_result = "CONTINUE"
heartbeat_timeout = 180
lifecycle_transition = "autoscaling:EC2_INSTANCE_TERMINATING"
notification_metadata = jsonencode({ "goodbye" = "world" })
}
]
instance_refresh = {
strategy = "Rolling"
preferences = {
checkpoint_delay = 600
checkpoint_percentages = [35, 70, 100]
instance_warmup = 300
min_healthy_percentage = 50
max_healthy_percentage = 100
}
triggers = ["tag"]
}
}
min_size = 0 and max_size = 1 define a very small fleet. wait_for_capacity_timeout = 0 disables Terraform waiting for capacity, useful for fast applies.
vpc_zone_identifier lists two subnets, providing multi-AZ distribution.
Lifecycle hooks are defined with names, default results, heartbeat timeouts, and transitions. The startup hook triggers on autoscaling:EC2_INSTANCE_LAUNCHING with a 60 second heartbeat. The termination hook triggers on autoscaling:EC2_INSTANCE_TERMINATING with a 180 second heartbeat. Notification metadata is passed as JSON.
Instance refresh uses a Rolling strategy with preferences for checkpoint delay, checkpoint percentages, instance warmup, and healthy percentages. Triggers include tag, meaning a tag change initiates refresh.
The impact is zero-downtime updates. The contextual layer ties instance refresh to CI/CD pipelines where new application versions are rolled out.
Legacy Launch Configuration Approach
We will cover what is an AWS Auto Scaling Group? AWS Auto Scaling Groups (ASGs) let you quickly scale and manage a collection of EC2 instances that run the same instance configuration. ASGs automatically scale the number of instances in response to changes in demand or other scaling policies. They ensure that the desired number of instances are always running, helping to maintain application availability and handle fluctuating workloads.
The definition reinforces the core purpose: availability and handling fluctuating workloads.
Scaling policies define the conditions under which the group scales up or down, such as CPU utilization, network traffic, or other custom metrics.
CPU utilization is a common metric for compute-bound workloads. Network traffic is useful for I/O bound services. Custom metrics allow application-specific signals.
To utilize an auto-scaling group, you need to have a clear understanding of your application’s scaling requirements to be able to define appropriate policies
Understanding requirements prevents over-provisioning and ensures scaling thresholds align with business capacity.
Configure the AWS Provider
hcl
provider "aws" {
region = "ap-south-1"
}
The region is ap-south-1, Mumbai. Region choice affects data residency and latency.
Launch Configuration
hcl
resource "aws_launch_configuration" "terraform_autoscale" {
name_prefix = "example-config-"
image_id = "ami-05a5bb48beb785bf1"
instance_type = "t2.micro"
}
The launch configuration uses a name prefix example-config-. Terraform will append a unique identifier. The image id ami-05a5bb48beb785bf1 is the AMI. Instance type is t2.micro.
Auto Scaling Group
hcl
resource "aws_autoscaling_group" "terraform_autoscale" {
name = "terraform-asg"
launch_configuration = aws_launch_configuration.terraform_autoscale.name
min_size = 2
max_size = 5
desired_capacity = 2
vpc_zone_identifier = ["subnet-0c5af440c5754fee0", "subnet-0efc610622152af6c"]
}
min_size = 2 ensures baseline capacity. max_size = 5 caps scaling. desired_capacity = 2 sets initial target. The launch configuration name is referenced. Subnets are specified for placement.
Step 6: Save the file by pressing ESC button and entering :wq
The reference material notes the Vim save sequence. The impact is that the configuration becomes persistent for subsequent Terraform commands.
Forcing Scaling Operations via CLI
Force a scaling operation using the AWS CLI
Once you have your autoscaling group applied, you can force a scaling operation using the AWS CLI.
The example below will scale the group to 10 instances.
bash
aws autoscaling set-desired-capacity --auto-scaling-group-name "test-autoscaling-group" --desired-capacity 10
The command directly changes the desired capacity outside Terraform. The impact is immediate scaling. The contextual layer is that if Terraform is configured to ignore changes to desired_capacity, the next plan will not revert this change. If Terraform is not ignoring changes, the next apply will revert to the value in code, causing state drift.
The command demonstrates operational override capability for emergencies.
Autoscaling Group Attributes and Operational Considerations
AWS Auto Scaling Groups ensure that the desired number of instances are always running.
This guarantee is maintained by the Auto Scaling service monitoring instance health and launching replacements.
ASGs automatically scale the number of instances in response to changes in demand or other scaling policies.
The automatic scaling removes manual intervention for routine load changes.
Health check type can be EC2 or ELB. EC2 checks the instance status. ELB checks the load balancer health check. The choice affects how quickly unhealthy instances are replaced.
Termination policies decide which instances are removed during scale-in. Options include OldestInstance, NewestInstance, ClosestToNextConnection, etc. The policy affects cost and stability.
VPC zone identifiers define where new instances launch. Using multiple subnets across AZs improves fault tolerance.
Launch template version pinning via $Latest versus a specific version number determines stability versus immediate update adoption.
Conclusion
Terraform AWS Auto Scaling Group configuration is built around a separation of concerns where Terraform defines the template, boundaries, and policies, while AWS manages the dynamic instance count within those boundaries. The dynamic nature of Auto Scaling groups requires lifecycle management to prevent state drift, and the use of launch templates with versioning provides a safe path for updates. Scaling policies transform a fixed-size group into a responsive system that reacts to metrics, schedules, or predictions, and the choice of simple, step, target tracking, or scheduled policies determines responsiveness and cost efficiency. Module-based provisioning adds instance refresh and lifecycle hooks for controlled updates and integration with operational workflows. Legacy launch configurations remain viable but are superseded by launch templates for flexibility. Operational overrides via the AWS CLI are possible, and their interaction with Terraform depends on lifecycle ignore rules. Together these patterns allow infrastructure teams to maintain availability, handle fluctuating workloads, and lower operating costs through declarative, automated capacity management.