Launch Templates and ASG Configuration

A Launch Template is a versioned blueprint that tells Auto Scaling Groups (and EC2 directly) how to launch instances. It captures the AMI ID, instance type, key pair, security groups, and optional user data in a single reusable document. Unlike the older Launch Configuration, a Launch Template supports multiple versions and can be updated without replacing the ASG.

You can create a Launch Template with the AWS CLI using create-launch-template. The --launch-template-data parameter accepts a JSON object that defines all instance settings. Versioning lets you iterate on the template without affecting running instances until you are ready to deploy.

Every Launch Template starts at version 1. When you create a new version you can override only the fields that changed—all other settings are inherited from the source version. The ASG can be told to use a $Latest version (always the newest) or a $Default version (explicitly designated). Using $Default gives you controlled rollouts, while $Latest is convenient in dev environments.

An Auto Scaling Group (ASG) maintains a fleet of EC2 instances within defined boundaries: minimum (floor), maximum (ceiling), and desired capacity (target count at any moment). When instances fail health checks or the scaling policy fires, ASG automatically launches or terminates instances to keep the fleet at the desired count between min and max.

When you create an ASG you reference a Launch Template (not a specific AMI directly). You also specify the VPC subnets where instances will be launched. Spreading across multiple subnets (one per AZ) gives you built-in multi-AZ redundancy—if one AZ fails, ASG launches replacement instances in the remaining AZs automatically.

By default an ASG uses EC2 health checks, which only flag an instance as unhealthy if it is stopped, terminated, or the hypervisor reports it failed. When you attach a load balancer you should switch to ELB health checks so the ASG replaces instances that are running but returning HTTP 5xx errors. This is a common exam question: always choose ELB health checks when there is a load balancer in the architecture.

Setting the correct capacity bounds is critical. The minimum ensures your application can always serve traffic (never go below this). The maximum prevents runaway scaling that could exhaust service limits or budget. The desired capacity is the initial target; scaling policies adjust it dynamically. If you set min=max=desired, the ASG acts as a fixed-size group, which is useful for launch template deployments or pinned capacity.

For web-tier applications, attach the ASG to an Application Load Balancer target group. Each new instance launched by the ASG is automatically registered with the target group, and terminated instances are automatically deregistered. This ensures traffic only flows to healthy, running instances. You must also set the health check type to ELB so the ASG is aware of load-balancer-level failures.

User data is a shell script (Base64-encoded) that runs once when an instance first boots. In a Launch Template it is the right place to install packages, configure agents (CloudWatch, SSM), and pull application code. Keep user data idempotent—scripts that can run safely more than once prevent issues during instance refresh. For complex setups, call out to AWS Systems Manager or a configuration management tool instead of embedding large scripts.

A Warm Pool pre-initialises a set of stopped (or running) EC2 instances in a ready state outside the ASG. When the ASG needs to scale out, it pulls from the warm pool instead of launching cold instances—dramatically reducing the time needed to add capacity. Instances in the warm pool incur stopped-state costs (EBS only, no CPU charges), making this much cheaper than keeping fully running spares.

When the ASG scales in it must decide which instances to terminate. The default termination policy selects the AZ with the most instances first (to rebalance), then the oldest launch template, then the instance closest to its billing hour. You can customise this order—for example, choose OldestLaunchTemplate to remove instances running outdated configurations first. ASG also performs AZ rebalancing automatically after a subnet becomes available or after manual changes.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Launch Templates provide a versioned, reusable instance blueprint that supports multiple versions and $Latest/$Default version pointers, ASG capacity bounds (min/max/desired) govern fleet size with automatic multi-AZ distribution across subnets, and ELB health checks must be enabled when an ASG is behind a load balancer so application-level failures trigger replacement. Next up we explore scaling policies including target tracking and step scaling.