AMI Bake vs Launch-Time Configuration

Bake config into the AMI or apply at launch? The trade-offs and the patterns.

Bake

The AMI bake versus launch-time config decision is one of those infrastructure questions that has a different right answer for different services. Baking puts configuration into the AMI itself; launch-time config applies it as the instance boots. The trade-off is speed versus flexibility, and most mature teams end up running both patterns for different parts of the fleet.

What baking provides:

• Faster boots.: A baked AMI starts with everything already installed. Boot time is seconds to a few minutes, not the 10 to 30 minutes a launch-time configure can take. The fast boot matters for autoscaling that needs capacity quickly.
• Configuration is in the image.: The image is a known artifact. What runs on the instance is what was baked into the AMI. There is no possibility of drift between instances; they all started from the same image.
• Requires CI to produce AMIs.: Baking requires a CI pipeline that builds AMIs from a source recipe. Tools like Packer build the AMI from a configuration. The pipeline must be maintained; the AMI build cycle becomes part of the deploy cycle.
• Versioning is critical.: Baked AMIs proliferate. The team needs naming and lifecycle policies that prevent the AMI list from becoming an unintelligible mess. Old AMIs are deprovisioned; new ones replace; the active AMI is always known.
• Reproducibility benefits.: A given AMI version is reproducible: launch this AMI, you get this software stack. Debugging is easier because the environment is fixed. Rollback is fast because the previous AMI is still available.

Baking is the right pattern for services where boot speed matters and configuration is stable.

Launch-time

Launch-time configuration applies setup at boot. The base AMI is generic; the userdata or configuration agent specializes the instance. The pattern trades boot speed for flexibility.

• Slower boots.: Launch-time configure runs after boot. Package installation, configuration application, service registration all happen during this window. The total boot-to-ready time is minutes to tens of minutes.
• Userdata configures.: AWS userdata, cloud-init, or configuration agents run at boot. The configuration is read from a parameter store, fetched from a config repository, or generated dynamically. The instance becomes specific based on its launch context.
• Easier iteration.: Configuration changes apply on next boot without rebuilding an AMI. The iteration cycle is fast. For services with frequently changing configuration, the speed of iteration matters more than the cost of slower boots.
• Same AMI, different config per ASG.: One AMI can serve multiple roles when configured at launch time. Different Auto Scaling Groups apply different configurations to the same base. The AMI inventory stays small.
• Configuration drift risk.: If configuration is fetched at boot and the source changes between boots, instances drift. The team must decide whether drift is acceptable or whether the configuration source should be versioned.

Launch-time configuration is the right pattern for services where boot speed is not the bottleneck and configuration changes frequently.

Hybrid

Most mature teams end up with a hybrid approach. The slow, stable pieces are baked; the fast-changing, instance-specific pieces are configured at launch. The hybrid optimizes both axes.

• Bake the slow stuff.: Large packages, kernel modules, base operating system tuning, language runtimes go into the AMI. These rarely change and take significant time to install. Baking them eliminates that time from boot.
• Configure at launch.: Environment-specific values, secrets, dynamic discovery, ASG-specific role configuration happen at launch. These change frequently and depend on the launch context.
• Balances speed and flexibility.: The boot is fast (because the slow parts are baked) and the configuration is flexible (because the fast-changing parts are launch-time). The hybrid produces the best of both patterns.
• AMI rebuild on dependency change.: When a baked dependency changes (kernel patch, language runtime upgrade, package update), the AMI rebuilds. The rebuild is a tracked event with its own pipeline.
• Configuration in version-controlled source.: Launch-time configuration comes from a version-controlled source (Parameter Store with versioning, a Git-backed configuration repo, a versioned secret store). The drift risk is managed by versioning.

AMI bake versus launch-time config is a question of where on the trade-off curve each service belongs. Nova AI Ops integrates with the build and deployment pipelines, surfaces boot-time trends, and helps teams identify candidates for moving from launch-time to bake (or vice versa) based on observed behavior.