Machine and Container Images
Golden AMIs with EC2 Image Builder and container images in Amazon ECR: what to bake, how to build and test images automatically, and how to scan, share, and retire them.
Before anything is deployed, something has to be packaged. This topic covers the two packaging units the SOA-C03 exam expects you to manage: the Amazon Machine Image that defines a server, and the container image that defines an application. Both start as a definition in a file and end as a versioned artifact you can rebuild, test, distribute, and retire on a schedule.
What This Topic Covers
- What an AMI actually contains, why it is Regional, and why the storage cost lives in its snapshots rather than the image record
- The bake-versus-bootstrap decision: which configuration belongs in the image and which belongs in user data at launch
- The five EC2 Image Builder resources (image recipe, components, infrastructure configuration, distribution settings, image pipeline) and how one pipeline run moves through the build stage, the snapshot, the test stage, and distribution
- Pipeline scheduling, including the dependency-update setting that skips a build when nothing upstream changed
- Sharing and distributing AMIs across Regions, accounts, and OUs, and the KMS key requirement for images backed by encrypted snapshots
- The difference between deprecating, disabling, and deregistering an AMI, and the snapshots left behind by each
- How container image layers, manifests, tags, and digests relate, and why tag immutability exists
- Amazon ECR authentication, the three permission layers (IAM, repository policy, registry policy), and where each decision is made
- Basic scanning against enhanced scanning with Amazon Inspector, and which requirements force the move to enhanced
- Lifecycle policies for automatic cleanup, plus registry replication and pull through cache rules
Why It Matters
Skill 3.1.1 of the exam guide is "create and manage AMIs and container images", and the questions built on it are operational rather than definitional. You get an Auto Scaling group still launching from an image a security review rejected, a new AMI that never appeared in the DR Region, a cross-account replication that silently copies nothing, or a repository whose storage bill grew for a year. Answering those means knowing exactly what each action does and what it leaves untouched.
The habit matters more than the services. A server built by hand cannot be rebuilt, audited, or handed to anyone else. An image built by a pipeline has a version, a test suite, and an expiry date, and every later topic in this domain assumes you already work that way.
