Compute and Auto Scaling

Running compute on AWS through Terraform means launch templates, auto scaling groups, and load balancers — not a fleet of hand-managed aws_instance resources. The launch template is the blueprint (AMI, instance type, user-data, IAM profile), the ASG is the thing that keeps the right number of instances alive across AZs, and the load balancer spreads traffic over whatever the ASG currently has running.

This is also where Terraform's model meets AWS's and has to give ground. An ASG manages its own instance count through scaling policies, so the live desired_capacity belongs to the autoscaler, not to your config. If Terraform owns that number, every apply drags it back to whatever you wrote — undoing the scale-out that just happened to absorb traffic. The fix is to let Terraform set the floor and ceiling and stop watching the middle.

Launch Templates

An aws_launch_template captures how to build one instance: which AMI, which instance type, the user-data run at boot, the security groups, and the IAM instance profile that grants the instance its permissions. It is versioned — each change creates a new version — and the ASG points at a version, which is the seam that makes rolling updates possible. Read the AMI from a data source so the latest patched image resolves at plan time rather than rotting as a hardcoded ID.

resource "aws_launch_template" "web" {
  name_prefix   = "web-"
  image_id      = data.aws_ami.al2023.id
  instance_type = "t3.micro"
  user_data     = base64encode(file("${path.module}/cloud-init.yaml"))

  iam_instance_profile { arn = aws_iam_instance_profile.web.arn }
  vpc_security_group_ids = [aws_security_group.web.id]

  lifecycle { create_before_destroy = true }
}

The user_data is base64-encoded cloud-init, not a provisioner — boot-time configuration that the instance applies to itself declaratively. create_before_destroy on the template means a replacement is built before the old one is torn down, which the ASG needs for a clean rollout.

Auto Scaling Groups and Who Owns desired_capacity

The aws_autoscaling_group ties the launch template to a set of subnets and a target group, and declares the bounds: min_size and max_size are yours to set, but desired_capacity is the live number the autoscaler moves up and down. Set it once to seed the group, then hand it over with ignore_changes so Terraform stops reconciling it. Without that, an apply run an hour after a traffic spike scaled the group to 9 instances will quietly plan it back to 3.

resource "aws_autoscaling_group" "web" {
  name_prefix         = "web-"
  min_size            = 3
  max_size            = 12
  desired_capacity    = 3
  vpc_zone_identifier = [for s in aws_subnet.private : s.id]
  target_group_arns   = [aws_lb_target_group.web.arn]
  health_check_type   = "ELB"

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }

  instance_refresh {
    strategy = "Rolling"
    preferences { min_healthy_percentage = 90 }
  }

  lifecycle {
    create_before_destroy = true
    # the autoscaler owns the live count; don't let apply revert it
    ignore_changes        = [desired_capacity]
  }
}

ignore_changes = [desired_capacity] is scoped to exactly the one attribute that legitimately changes out of band — never all, which would also hide real drift in min_size, the template, or the subnets. health_check_type = "ELB" tells the ASG to trust the load balancer's health checks, so an instance that fails HTTP checks gets replaced even though the EC2 status check passes.

The Load Balancer in Front

An Application Load Balancer sits across the public subnets, a target group holds the registered instances, and a listener forwards traffic. The ASG never lists instances directly — it registers them into the target group by ARN as it launches them, and deregisters them as it terminates them. That indirection is what lets the count change underneath without rewiring anything: traffic always flows to whatever is currently healthy in the target group.

resource "aws_lb_target_group" "web" {
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id
  health_check { path = "/healthz" }
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.web.arn
  port              = 80
  protocol          = "HTTP"
  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web.arn
  }
}

Zero-Downtime Instance Refresh

When you change the launch template — a new AMI, a different instance type — existing instances do not roll automatically. Two mechanisms make the replacement graceful. create_before_destroy ensures the ASG and template aren't destroyed before their replacements exist, and the instance_refresh block tells AWS to replace running instances in batches, keeping min_healthy_percentage of capacity serving traffic throughout. Set that to 90% and the refresh swaps roughly one instance at a time on a 10-instance group, never dropping below 9 healthy.

Why ASGs Beat Individual Instances

Managing a workload as separate aws_instance resources throws away the two things that make a fleet survivable: self-healing and scaling. An ASG replaces an instance that fails its health check without a human or a plan; it adds and removes instances as load moves; and it spreads them across AZs so a zone outage costs you a fraction, not the whole tier. Reach for individual instances only for genuine pets — a bastion host, a one-off — and for everything that scales, use the launch-template-plus-ASG shape.