Skip to main content
In this lesson we walk through AWS EC2 Image Builder and show how it helps you create and maintain secure, tested, versioned images (AMIs or container images). EC2 Image Builder is a managed AWS service that provides a repeatable, auditable pipeline for building golden images — similar in purpose to HashiCorp Packer but tightly integrated with the AWS ecosystem.
A screenshot of the AWS EC2 Image Builder web page showing the heading "EC2 Image Builder — Build and maintain secure images." On the right is a panel with a "Create image pipeline" button and pricing/information boxes.
Why use EC2 Image Builder?
  • Automates image creation and configuration with reusable components.
  • Provides built-in test and validation phases to reduce drift and configuration errors.
  • Enables versioned image pipelines and lifecycle rules for cleanup.
  • Supports cross-region and cross-account distribution with KMS encryption support.
A screenshot of the AWS EC2 Image Builder web page showing a "How it works" flowchart that outlines starting with a base image, customizing software, testing, and distributing images. The right side shows "More resources" links and the page header and browser tabs are visible.
Image Builder is commonly used to implement the golden AMI pattern for immutable infrastructure: build a fully configured and tested image, then launch instances from that image instead of bootstrapping at runtime.

Architecture — five main components

There are five core concepts to understand. The table below summarizes each component, its purpose, and an example.
  1. Image pipelines — the orchestration layer that ties a recipe, infrastructure configuration, distribution settings, and a schedule together. Pipelines run the build workflow when triggered (manually, scheduled, or via EventBridge).
A screenshot of the AWS EC2 Image Builder console showing the "devops-020-240-pipeline" summary, including creation time, ARN, and that the pipeline status is Enabled. The lower pane shows the Output images section (no items listed).
  1. Image recipes — define the base image and the components (both build and test components) to run during the build.
A screenshot of the AWS EC2 Image Builder console showing an image recipe named "devops-020-240-recipe" with metadata (creation time, platform, ARN, base image). The page also lists build components such as update-linux, devops-020-240-app-dependencies, amazon-cloudwatch-agent-linux, and reboot-linux.
  1. Components — reusable building blocks defined as small YAML documents. Components run actions such as installing packages, configuring files, running scripts, downloading/uploading artifacts, or running assertions. Use components in both build and test phases.
  2. Infrastructure configuration — specifies how the ephemeral build instance is launched (instance type, VPC/subnet, IAM role, key pair, security groups, logging, etc.). Image Builder launches a temporary EC2 instance to perform the build and then terminates it.
A screenshot of the AWS EC2 Image Builder console showing the "Infrastructure configurations" page with a list of four configurations (e.g., devops-020-240-infrastructure, kk-infra-config) and columns for description, instance types, and IAM role. The left sidebar shows Image Builder navigation items and saved resources, and there's a "Create infrastructure configuration" button at the top right.
  1. Distribution settings — define where built images are published (regions, accounts), any AWS KMS keys for encryption, launch templates, and other distribution options.
Screenshot of the AWS EC2 Image Builder console on the "Distribution settings" page, listing distribution configuration names, regions (us-east-1) and creation times. The left sidebar shows navigation items like Image pipelines, Saved resources and Security overview.
Typical build flow:
  • Pipeline triggers (manual, scheduled, or EventBridge).
  • Infrastructure configuration launches a temporary EC2 build instance (for example, t3.medium).
  • The recipe’s build components run in the defined order.
  • Test components run to validate the image. Tests must return success; otherwise the image is not published.
  • If tests pass, Image Builder creates and optionally distributes the AMI per your distribution settings.
  • The ephemeral build instance is terminated.
Image Builder uses ephemeral build instances per run — it does not maintain long-running build VMs. This contrasts with using AWS Systems Manager to manage ongoing instances.
A screenshot of the AWS EC2 Image Builder console showing an infrastructure configuration named "devops-020-240-infrastructure" with details like IAM role, ARN, VPC ID, instance type (t3.medium) and S3 logs. The Resource tags area is visible and shows no tags.
Make sure your execution and instance IAM roles include the required permissions to download components, write logs to S3, create AMIs, and perform KMS operations. Missing permissions cause builds to fail. Refer to the official docs for required policies.

Components — build and test examples

Components are defined using a compact YAML schema. Build components perform installation and configuration tasks; test components assert that the image satisfies expected conditions. Common actions include ExecuteBash, ExecutePowerShell, S3Download, S3Upload, and FileCopy. Below is a consolidated build component example that installs Python, Node.js, Docker, the CodeDeploy agent, and creates an application directory. This single component contains multiple steps in the build phase:
And a matching test component that validates the above installations. Test steps should exit 1 on failure so Image Builder marks the test as failed:
You can also author very small components — for example, a single-step test that prints Hello World:
Screenshot of the AWS EC2 Image Builder console showing the Components page with two Linux components listed (devops-020-240-app-dependencies/1.0.0 as BUILD and devops-020-240-validation/1.0.0 as TEST). The left sidebar shows navigation items like Saved resources and Security overview.
Actions are not limited to ExecuteBash. Windows components can use PowerShell; use S3Download/S3Upload for artifacts stored in S3. Always include clear and deterministic tests to catch regressions early.
Always include test components. Testing ensures the resulting AMI or container image meets the expected configuration and prevents publishing broken images.

Image recipes and component versioning

An image recipe selects a base image and lists build and test components in the exact order you want them executed. You can use Amazon-managed components or provide your own custom components. Best practice: pin component versions to avoid unexpected behavior when managed components change. When creating a recipe you typically choose:
  • Base image (AWS-managed AMI, Marketplace, shared AMI, or a custom AMI).
  • Build components and their specific versions.
  • Test components for validation.
  • Additional storage volumes, working directory, and metadata tags.
  • Reboot behavior (many components include a reboot component when required).
A screenshot of the AWS EC2 Image Builder console displaying an image recipe titled "devops-020-240-recipe | 1.0.0" with summary details (creation time, ARN, base image) and a list of build components. The left sidebar shows navigation items such as Image recipes, Components, and Security overview.
Screenshot of the AWS EC2 Image Builder "Create image recipe" console showing the Working directory set to /tmp and empty Components, Build components, and Test components sections. On the right is the Amazon managed components panel with a search for "reboot-linux" and options to add a component.

Distribution settings and sharing

Distribution settings control where and how images are published:
  • Publish AMIs to multiple regions and accounts.
  • Encrypt AMIs with an AWS KMS key for secure sharing.
  • Attach launch templates or specify launch permissions (private, shared accounts/organizational units, or public).
  • Integrate with license management and Systems Manager (SSM) for instance inventory and run commands.
A screenshot of the AWS EC2 Image Builder "Create distribution settings" page showing output type options (Amazon Machine Image selected or Docker image) and form fields for Name and Description. The top navigation and AWS console header are also visible.
Sharing can be scoped to specific AWS account IDs, Organization units, or made public (exercise caution when sharing publicly). Use IAM and KMS controls to manage access.

Pipelines — scheduling, triggers, and security scanning

Image pipelines tie recipes, infrastructure configs, and distribution settings into a runnable workflow. Pipeline options include:
  • Manual runs, scheduled runs (cron-like), or EventBridge-triggered runs.
  • Vulnerability scanning and security snapshots during the build.
  • Enhanced metadata collection and logging to Amazon S3 or Amazon CloudWatch.
Pipelines commonly take 15–45 minutes depending on package installs and complexity. Use EventBridge for automated triggers when, for example, a base image is updated.
Screenshot of the AWS EC2 Image Builder "Image pipelines" page showing a single pipeline named "devops-020-240-pipeline" with status Enabled and type AMI. The pipeline's creation time is listed as March 17, 2026.
A screenshot of the AWS EC2 Image Builder "Create pipeline" console showing options like enabling enhanced metadata collection, security scanning, and build schedule settings (Schedule builder/CRON/Manual). The page includes fields for description, vulnerability snapshot options, and frequency/time schedule controls.

Lifecycle policies and versioning

Image Builder supports lifecycle policies for recipes and images to automate versioning and cleanup. Use lifecycle rules to:
  • Auto-version recipes on updates.
  • Retain a fixed number of image versions.
  • Delete images older than a specified age to control image sprawl.
Screenshot of the AWS EC2 Image Builder "Create lifecycle policy" console. It shows the Activate policy toggle, IAM roles set to "Use service defaults" with an IAM execution role, and the Rule scope set to "Recipes" with a "Browse recipes" button.
Lifecycle policies are essential for cost control and reducing operational overhead.

Quick reference — key features

Summary

EC2 Image Builder helps formalize the golden image process by combining automation, testing, versioning, and distribution:
  • Author components (build and test) as YAML documents.
  • Create recipes that assemble base images and ordered components.
  • Configure ephemeral build infrastructure and pipelines to orchestrate builds.
  • Use distribution settings and KMS for secure publishing.
  • Apply lifecycle policies to manage image retention and cleanup.
For more information and examples, see:

Watch Video