4.2.1. Hardened AMIs and Container Images
First Principle: Compute security starts at the image. Every EC2 instance and container inherits the security posture of its base image — a hardened golden AMI with no unnecessary packages eliminates entire categories of vulnerabilities before a single line of application code runs.
EC2 Image Builder automates secure AMI creation:
- Define image pipelines that build, test, and distribute AMIs on a schedule
- Start from AWS base AMIs, then apply hardening components (CIS benchmarks, STIG compliance)
- Run automated tests before distributing (e.g., verify no open ports, no default credentials)
- Distribute approved AMIs across accounts and Regions
Systems Manager for fleet-wide image compliance:
- State Manager: Enforce configuration baselines (ensure required agents are installed)
- Patch Manager: Apply OS and application patches to running instances
- Inventory: Track installed software and configurations across all managed instances
Container Image Security:
- Use minimal base images (Alpine, distroless) to reduce attack surface
- Scan images with Amazon Inspector during build (CI/CD integration)
- Sign images with Docker Content Trust or AWS Signer to verify integrity
- Store in Amazon ECR with image scanning enabled and immutable tags
⚠️ Exam Trap: Image Builder creates AMIs. Inspector scans them for vulnerabilities. These are complementary — Image Builder doesn't scan for CVEs, and Inspector doesn't create AMIs. Know which does what.
Scenario: A security team creates a hardened AMI pipeline using Image Builder that starts from the latest Amazon Linux 2023 AMI, applies CIS Level 2 hardening, removes unnecessary packages, and runs Inspector to verify zero critical/high CVEs before distribution.
Reflection Question: Why is building security into the image (shift-left) more effective than patching running instances (shift-right)?
