4.1.1. AMI Management and EC2 Image Builder
💡 First Principle: An AMI (Amazon Machine Image) is a snapshot of an EC2 instance's root volume plus metadata about the instance configuration. Every EC2 instance launches from an AMI — it's the DNA of your fleet. The quality and freshness of your AMI determines the consistency and security posture of every instance that launches from it.
Without a disciplined AMI management process, you end up with a "pets vs. cattle" problem: instances configured individually over time, each with slightly different software versions and patches, impossible to reproduce reliably. The solution is a golden AMI pipeline — an automated process that builds a fresh, patched, tested AMI on a schedule.
AMI Types:
| Type | Root Storage | Characteristics |
|---|---|---|
| EBS-backed | EBS volume | Instance can be stopped and restarted; root volume persists; can be encrypted |
| Instance store-backed | Instance store (ephemeral) | Instance cannot be stopped; data lost on termination; faster launch |
EBS-backed AMIs are the standard for almost all use cases. Instance store-backed AMIs are rare and mostly relevant for legacy or specialized high-I/O workloads.
EC2 Image Builder automates the golden AMI pipeline:
Key Image Builder Concepts:
| Concept | Description |
|---|---|
| Image Recipe | Defines the base AMI + ordered list of components (install Apache, harden OS, etc.) |
| Component | A build or test script (AWS-managed or custom) |
| Infrastructure Configuration | The instance type and IAM role used during the build |
| Distribution Configuration | Which regions and accounts receive the output AMI |
| Image Pipeline | Orchestrates the build on a schedule or on demand |
AMI Lifecycle: AMIs should be deprecated and deregistered after a defined period. Best practices:
- Tag AMIs with creation date and pipeline version
- Use lifecycle policies to deprecate AMIs older than 90 days
- Retain the N most recent AMIs as rollback options
- Deregister deprecated AMIs and delete their associated EBS snapshots
AMI Sharing: AMIs can be shared with specific AWS account IDs or made public. For organizational sharing, use AWS RAM (Resource Access Manager) to share AMIs with all accounts in your organization without making them public.
⚠️ Exam Trap: When you deregister an AMI, the underlying EBS snapshots are not automatically deleted. You must separately delete the snapshots to stop being charged for them. Image Builder can manage this automatically when configured with a lifecycle policy — but the default behavior is to leave snapshots intact.
Reflection Question: Your security team requires all EC2 instances to launch from a patched AMI built within the last 30 days. Manually running AMI builds is unreliable. What EC2 Image Builder configuration automates this, and how do you enforce that Auto Scaling Groups only use approved AMIs?
