Launch Templates vs. Launch Configurations

The Blueprint Problem

Before an ASG can launch an instance, it needs a blueprint: which AMI to use, what instance type, which security groups, what startup script to run. AWS originally solved this with Launch Configurations. They work, but they have a fundamental flaw: they are completely immutable. To change a single field — even just the instance type — you must create an entirely new Launch Configuration and re-attach it to the ASG. There is no versioning, no rollback, no inheritance.

Launch Templates replace Launch Configurations entirely and are the only option you should use for new ASGs.

What Launch Templates Add

Versioning: A Launch Template is versioned. You create v1 with a t3.micro instance type. You update to v2 with t3.small. If v2 causes problems, you point the ASG back to v1 in seconds. No re-creation required.

Inheritance (Overrides): You can define a base template with shared settings — VPC, security groups, IAM role — and then create per-environment overrides that only change what differs. A production override might specify m5.xlarge; a staging override might specify t3.medium. Both inherit everything else from the base.

Mixed Instances Policy: This is the killer feature. Only Launch Templates support mixing Spot Instances and On-Demand Instances in the same ASG. A typical production configuration might say: "Keep 2 On-Demand instances as a baseline, and fulfill the rest of the capacity with Spot across m5.large, m5.xlarge, and m4.large instance families." This can cut compute costs by 60–80% while maintaining availability.

In practice, you create a Launch Template with the AMI, instance type, security groups, and IAM role baked in as its data. When something needs to change — say, bumping the instance type from t3.micro to t3.small — you publish a new numbered version of the same template rather than replacing it, and then point the ASG at that version number. The ASG picks up the new version on its next launch; nothing is re-created, and rolling back is just pointing back at the old version number.

The Mixed Instances Policy in Practice

Here is what a Mixed Instances Policy looks like in a CloudFormation or CLI context. The ASG will maintain 2 On-Demand instances and fill remaining capacity with Spot, trying m5.large first, then m5.xlarge, then m4.large:

{
  "MixedInstancesPolicy": {
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 2,
      "OnDemandPercentageAboveBaseCapacity": 0,
      "SpotAllocationStrategy": "capacity-optimized"
    },
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "web-server-base",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5.xlarge"},
        {"InstanceType": "m4.large"}
      ]
    }
  }
}