A launch template is a convenient form that stores EC2 launch options.

A launch template is a versioned machine creation contract used by fleets, Auto Scaling Groups, EC2 Fleet, Spot Fleet, and deployment automation.

same AMI lineage
same bootstrap contract
same IAM boundary
same metadata posture
same storage mapping
same tagging contract
same security group shape
same observability baseline
same termination semantics
same rollback path

How do we build the machine artifact?

How do we repeatedly launch that artifact as a safe production fleet?

Can we launch an EC2 instance?

Can we launch, replace, scale, roll back, audit, and debug every instance in this fleet using an explicit immutable contract?

What is inside the machine?

How should the machine be launched?

How many machines should exist, where, and when should they be replaced?

MetadataOptions.HttpTokens = required

BlockDeviceMappings.Ebs.DeleteOnTermination = true

TagSpecifications includes owner, service, environment, data-classification

Given this template version,
AWS can create an instance that belongs to this workload,
in this environment,
with this image,
with this identity,
with this storage layout,
with this metadata posture,
and with tags that make it governable.

Using $Latest or mutable default version casually.

Production fleets should generally consume an explicitly selected template version, not an accidental moving pointer.

service: payment-api
environment: production
ami_id: ami-0abc123...
launch_template_id: lt-012345...
launch_template_version: 42
asg_name: payment-api-prod-a
release_id: payment-api-2026-07-06-001

rollback = set ASG to previous launch_template_version and run controlled instance refresh

open console, guess old AMI, edit random settings

AMI is produced by image pipeline.
AMI is tagged with source commit/build/kernel/package baseline.
AMI is promoted from dev -> staging -> prod.
Launch Template version references a concrete AMI ID.

AMI copied from an old instance.
AMI name pattern is used loosely.
Launch Template uses whichever AMI looks newest.

Stable capacity shape? specify instance type directly.
Need Spot/capacity diversification? use Launch Template + mixed instance overrides.

One giant EC2 role for all instances.

One role per workload boundary.

Separate platform bootstrap permissions from application permissions where possible.

HttpTokens = required
HttpEndpoint = enabled
HttpPutResponseHopLimit = 1 or carefully justified higher value
InstanceMetadataTags = disabled unless explicitly needed

small
idempotent
observable
bounded in time
safe to retry
free of long-lived secrets
used to start controlled bootstrap, not contain the whole platform

#!/bin/bash
set -euo pipefail

exec > >(tee -a /var/log/bootstrap.log | logger -t user-data -s 2>/dev/console) 2>&1

echo "bootstrap started at $(date -Is)"
/opt/platform/bin/bootstrap-node --environment prod --service payment-api
echo "bootstrap finished at $(date -Is)"

What disks exist when the instance starts?
What type are they?
Are they encrypted?
Are they deleted on termination?
What size and performance do they have?

Service: payment-api
Environment: prod
Owner: payments-platform
CostCenter: fintech-core
DataClassification: internal
ManagedBy: terraform
Runbook: https://internal/runbooks/payment-api
BackupPolicy: none-or-policy-name

Only tagging the instance.

If you over-specify network interfaces, you may accidentally constrain subnet/AZ placement.

security posture
metadata posture
ENI behavior if required

which subnets/AZs the fleet spans

Image Contract
  AMI, OS, packages, runtime

Launch Contract
  launch template version, metadata, identity, storage, tags

Placement Contract
  ASG subnets, AZ spread, placement group if needed

Capacity Contract
  min, max, desired, scaling policy, mixed instance policy

Traffic Contract
  target group registration, readiness, deregistration delay

Termination Contract
  lifecycle hook, drain, log flush, volume handling

AMI is good.
Launch Template is good.
ASG uses only one subnet.
AZ outage takes down the fleet.

ASG spans three AZs.
Launch Template uses EBS data volume pattern that assumes fixed AZ-local state.
Replacement cannot recover state in another AZ.

payment-api-prod-lt
payment-api-staging-lt
ledger-worker-prod-lt
ledger-worker-staging-lt

Launch Template defines common contract.
ASG mixed instance policy overrides instance types.

Base: m7i.large
Overrides: m7i.large, m7a.large, m6i.large, m6a.large

Every release creates a new Launch Template version.
ASG points to explicit version.
Instance refresh rolls it out.
Rollback points to previous version.

platform owns OS, agents, metadata, base IAM, storage defaults
workload owns app artifact and runtime config

platform template becomes too generic and over-permissive

AMI boots
cloud-init/user-data succeeds
SSM available
metrics/logging available
app reaches readiness
EBS mounts are correct
metadata posture is correct
tags are present on instance and volumes
health check passes after warmup
termination behavior is safe

resource "aws_launch_template" "payment_api" {
  name_prefix   = "payment-api-prod-"
  image_id      = var.ami_id
  instance_type = "m7i.large"

  iam_instance_profile {
    name = aws_iam_instance_profile.payment_api.name
  }

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    instance_metadata_tags      = "disabled"
  }

  monitoring {
    enabled = true
  }

  user_data = base64encode(templatefile("${path.module}/user-data.sh", {
    service     = "payment-api"
    environment = "prod"
  }))

  block_device_mappings {
    device_name = "/dev/xvda"

    ebs {
      volume_size           = 30
      volume_type           = "gp3"
      encrypted             = true
      delete_on_termination = true
    }
  }

  tag_specifications {
    resource_type = "instance"

    tags = {
      Service            = "payment-api"
      Environment        = "prod"
      Owner              = "payments-platform"
      ManagedBy          = "terraform"
      DataClassification = "internal"
    }
  }

  tag_specifications {
    resource_type = "volume"

    tags = {
      Service            = "payment-api"
      Environment        = "prod"
      Owner              = "payments-platform"
      ManagedBy          = "terraform"
      DataClassification = "internal"
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

AMI is passed as an explicit variable from image pipeline.
IMDSv2 is required.
Root volume is encrypted and deleted on termination.
Tags are applied to both instance and volume.
User data is rendered from a small template.

resource "aws_autoscaling_group" "payment_api" {
  name                = "payment-api-prod"
  min_size            = 6
  max_size            = 30
  desired_capacity    = 9
  vpc_zone_identifier = var.private_subnet_ids

  health_check_type         = "ELB"
  health_check_grace_period = 300

  launch_template {
    id      = aws_launch_template.payment_api.id
    version = aws_launch_template.payment_api.latest_version
  }

  target_group_arns = [aws_lb_target_group.payment_api.arn]

  instance_refresh {
    strategy = "Rolling"

    preferences {
      min_healthy_percentage = 90
      instance_warmup        = 300
    }
  }

  tag {
    key                 = "Service"
    value               = "payment-api"
    propagate_at_launch = true
  }

  tag {
    key                 = "Environment"
    value               = "prod"
    propagate_at_launch = true
  }
}

version = aws_launch_template.payment_api.latest_version

version = var.launch_template_version

common launch contract
from
capacity diversification

resource "aws_autoscaling_group" "worker" {
  name                = "ledger-worker-prod"
  min_size            = 20
  max_size            = 200
  desired_capacity    = 40
  vpc_zone_identifier = var.private_subnet_ids

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 10
      on_demand_percentage_above_base_capacity = 30
      spot_allocation_strategy                 = "price-capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.worker.id
        version            = var.launch_template_version
      }

      override {
        instance_type = "m7i.large"
      }

      override {
        instance_type = "m7a.large"
      }

      override {
        instance_type = "m6i.large"
      }

      override {
        instance_type = "m6a.large"
      }
    }
  }
}

metadata_options {
  http_endpoint               = "enabled"
  http_tokens                 = "required"
  http_put_response_hop_limit = 1
  instance_metadata_tags      = "disabled"
}

required = IMDSv2 token required
optional = IMDSv1 still allowed

tags do not contain sensitive information
bootstrap truly needs them
access boundary is understood

block_device_mappings {
  device_name = "/dev/xvda"

  ebs {
    volume_size           = 30
    volume_type           = "gp3"
    encrypted             = true
    delete_on_termination = true
  }
}

Does this instance need only root volume?
Does app write data locally?
Is local data recoverable?
Should the data volume survive termination?
Who snapshots it?
What is the filesystem mount path?
How is device naming handled on Nitro/NVMe?

root volume only
logs shipped out
delete root volume on termination
no data volume

root volume + scratch EBS or instance store
scratch is disposable
delete-on-termination true
job retry handles loss

root volume separate from data volume
data volume lifecycle explicit
snapshot policy explicit
restore path tested
AZ locality understood
termination protection considered

Launch Template user data starts bootstrap.
Bootstrap tool is versioned and tested.
Bootstrap emits status.
Systemd owns long-running process.
Health check waits for readiness.

#!/bin/bash
set -euo pipefail

LOG=/var/log/platform-bootstrap.log
exec > >(tee -a "$LOG" | logger -t platform-bootstrap -s 2>/dev/console) 2>&1

echo "starting bootstrap"

/opt/platform/bin/bootstrap \
  --service payment-api \
  --environment prod \
  --region "$(curl -sS -H "X-aws-ec2-metadata-token: $(curl -sS -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')" http://169.254.169.254/latest/meta-data/placement/region)"

systemctl enable payment-api
systemctl start payment-api

echo "bootstrap complete"

Tag the instance, volume, and network interface where possible.

Launch Template:
  security groups
  metadata options
  IAM profile
  storage mapping

ASG:
  subnet IDs
  AZ spread
  desired/min/max
  health checks

If the OS shuts down, should the instance stop or terminate?
Should root volume be deleted?
Should data volume survive?
Should lifecycle hook drain traffic first?
Should app flush buffers?
Should queue worker release leases?

termination is normal
root volume delete-on-termination true
node can be recreated from template

termination is data-sensitive
volume lifecycle must be explicit
snapshot/restore must be tested

New launches use the configured template version.
Existing instances remain until replaced or refreshed.

create new LT version
point ASG to new version
start instance refresh
respect min healthy percentage
wait for warmup
watch alarms
rollback if unhealthy

1. launch one instance from new template
2. validate bootstrap
3. route small traffic or run synthetic check
4. update ASG
5. instance refresh gradually

set ASG back to known-good launch template version
start new instance refresh

SSH into broken nodes and patch them manually

one instance type, one AZ, one capacity pool

capacity unavailable, hardware-specific failure, AZ blast radius

many instance families, architectures, AMI variants, disk layouts

unpredictable performance, hard debugging, hidden compatibility bugs

same launch contract
small set of compatible instance types
explicit architecture boundary
measured performance envelope
clear rollback path

If this instance type is unavailable, what compatible alternatives exist?
If this AZ has pressure, can the fleet launch elsewhere?
If Spot is interrupted, can On-Demand absorb baseline?
If AMI is architecture-specific, did we separate arm64 and x86 templates?

payment-api-prod-x86-lt
payment-api-prod-arm64-lt

architectures:
  x86_64:
    ami: ami-x86...
    instance_types:
      - m7i.large
      - m6i.large
  arm64:
    ami: ami-arm...
    instance_types:
      - m7g.large
      - m6g.large

[ ] AMI ID is explicit and produced by image pipeline
[ ] template version is explicit and auditable
[ ] user data is small and idempotent
[ ] IAM instance profile is least-privilege per workload
[ ] IMDSv2 is required
[ ] metadata hop limit is justified
[ ] root volume is encrypted
[ ] delete-on-termination is intentionally set
[ ] data volumes have explicit lifecycle policy
[ ] tags apply to instances and volumes
[ ] detailed monitoring decision is explicit
[ ] security groups are correct for workload boundary
[ ] subnet/AZ placement is controlled by ASG/fleet
[ ] SSM or break-glass access is available if needed
[ ] bootstrap logs are available
[ ] health check grace period matches startup time
[ ] rollback launch template version is known
[ ] instance refresh strategy is defined
[ ] capacity fallback is defined
[ ] quotas are checked for expected scale

new instances behave differently than expected

ASG uses $Latest or default pointer changed without rollout discipline

pin explicit version; use release manifest; require approval for promotion

instance refresh replaces healthy nodes with unhealthy nodes

Launch Template version points to AMI not validated in production-like environment

preflight launch, canary, staged refresh, alarm rollback

instance is running but app never becomes ready

user data not logged, script not idempotent, cloud-init failure ignored

log to /var/log/bootstrap.log and console; fail explicitly; expose readiness

bootstrap cannot fetch config/secrets or app cannot access required storage

wrong instance profile attached in Launch Template

role per workload; integration test bootstrap with production-like role

incident blast radius larger than expected

shared admin-like EC2 role

least privilege; split roles; monitor credential usage

EBS cost rises after instance replacement

delete_on_termination false accidentally or volume not tagged

explicit delete-on-termination; tag volumes; orphan cleanup report

app/agent cannot discover region, credentials, or instance identity

IMDSv2 enforced but legacy script still uses IMDSv1

update bootstrap helpers and agents; test IMDSv2 path before enforcing

scale-out requested but instances do not launch

instance type unavailable
subnet lacks IPs
quota exceeded
invalid AMI
bad launch template parameter
capacity reservation mismatch
security group or IAM issue

inspect ASG activity history; diversify instance types; monitor subnet IPs and quotas

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names payment-api-prod \
  --query 'AutoScalingGroups[0].LaunchTemplate'

LaunchTemplateId
Version

aws ec2 describe-launch-template-versions \
  --launch-template-id lt-0123456789abcdef0 \
  --versions 42

ImageId
InstanceType
IamInstanceProfile
MetadataOptions
BlockDeviceMappings
SecurityGroupIds
UserData

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name payment-api-prod \
  --max-items 20

failed launch
capacity errors
invalid AMI
security group issues
instance profile issues
subnet IP exhaustion

aws ec2 get-console-output \
  --instance-id i-0123456789abcdef0 \
  --latest

sudo journalctl -u cloud-init -n 200 --no-pager
sudo cat /var/log/cloud-init-output.log
sudo cat /var/log/platform-bootstrap.log
sudo systemctl status payment-api

point ASG to previous known-good launch template version
start instance refresh
monitor target group health and error rate

Launch some instances by hand.
Change settings until it works.
Create AMI from it.
Use it in prod.

No reproducibility. No provenance. No safe rollback.

User data installs everything, fetches app, migrates DB, edits config, starts service.

Boot is slow, fragile, hard to observe, hard to test.

ASG always uses the latest template version.

Creating a template version becomes an implicit production rollout.

Only instances are tagged.

Detached volumes become invisible cost and compliance risk.

All EC2 workloads use one generic template and a huge role.

Poor least privilege, hard audit, hidden coupling, broad blast radius.

ASG uses launch configuration
AMI changed manually
user data installs app from S3
root volumes not consistently encrypted
tags only on instances
rollback means editing ASG manually

new AMI has bad JVM flag
instance refresh replaces 50% fleet
latency spikes
rollback takes 45 minutes because old version is unclear

Image pipeline builds AMI.
Launch Template version created per release.
ASG pins explicit template version.
Instance Refresh uses min healthy 95%.
Synthetic canary validates one node first.
Root volume encrypted/delete-on-termination.
Tags applied to instance and volume.
IMDSv2 required.
Rollback version stored in release manifest.

bad JVM flag found during canary
ASG not refreshed
rollback is not needed because release never reached fleet

image
identity
metadata posture
storage mapping
bootstrap entrypoint
tagging contract
network/security posture
lifecycle defaults

AMI = what is inside the machine
Launch Template Version = how the machine is launched
ASG/Fleet = how machines are placed, scaled, refreshed, and terminated

Use explicit versioning.
Avoid accidental $Latest rollouts.
Keep user data small.
Require IMDSv2.
Tag instances and volumes.
Make storage lifecycle explicit.
Use canary and instance refresh.
Keep rollback version known.