CLOUD SERVICE · AWS

EC2 Image Builder - EC2 Image Builder is an AWS service for automating the creation, testing, and distribution of Linux and Windows Server machine images and container images.

EC2 Image Builder helps engineers maintain standardized images by applying operating system updates, installing software, and validating the results through configurable pipelines. It produces Amazon Machine Images (AMIs) for EC2 and container images for registries, with support for scheduled builds, cross-account and cross-Region distribution, and image lifecycle management.

Cloud Services Hub →

What is EC2 Image Builder

Read the extensive description

EC2 Image Builder automates the process of turning a base operating system image into a tested, deployable artifact. Its primary outputs are Amazon Machine Images (AMIs) and container images. For AMIs, teams typically start with a supported Linux or Windows Server image, install required applications and agents, apply configuration, and publish the resulting image for downstream deployments. Container pipelines build container images and publish them to configured repositories.

An image pipeline combines a recipe, infrastructure configuration, and distribution configuration. An image recipe identifies a parent image, build components, and storage settings. A container recipe defines the information needed to build a container image, including its parent image and Dockerfile template. Components contain the installation, configuration, and validation logic. AWS provides managed components for common tasks, while custom components let teams encode their own requirements using the AWS Task Orchestrator and Executor component document format.

Infrastructure configuration determines where the temporary build and test instances run. Engineers choose instance types, an instance profile, network settings, logging destinations, and related execution settings. Private subnet builds require connectivity to the services and package repositories used by the pipeline. Depending on the configuration, that connectivity can come from VPC endpoints, a NAT gateway, or another controlled network path. Security groups, IAM permissions, and access to software sources must be configured before builds can succeed.

Pipelines can run on demand or on a schedule. Scheduled execution can be configured to build every time or only when selected dependencies have updates. Build steps should avoid uncontrolled package versions when strict reproducibility is required. Pinning parent images, component versions, and application packages helps engineers explain changes between image releases. Logs and execution details should be retained long enough to investigate failures and support audit requirements.

Testing verifies that an image is usable before it is distributed. Practical checks include confirming that required services start, application dependencies are installed, security settings are present, and unwanted packages are absent. Passing these tests does not prove that an image is free of vulnerabilities or compliant with every policy. Teams should combine functional tests with vulnerability assessment and their own release approval process.

Distribution configuration controls where completed artifacts are delivered. AMIs can be distributed to additional AWS Regions and accounts, subject to the necessary IAM and encryption permissions. Container images can be delivered to Amazon ECR repositories. Publishing a new artifact does not automatically replace running instances or containers; deployment systems must consume the new image and perform a controlled rollout.

Image lifecycle policies help retire eligible Image Builder resources and associated artifacts according to configured rules. Retention settings should preserve rollback images and account for consumers that still reference older AMIs. EC2 Image Builder has no additional service charge, but build instances, storage, logging, image distribution, and other supporting services incur their normal AWS charges.

Key EC2 Image Builder Features

AMI and container image pipelines

Create automated pipelines for Linux and Windows Server AMIs or container images. Each pipeline brings together the recipe, execution infrastructure, and artifact distribution settings.

Reusable build and test components

Use AWS-managed components or write custom component documents to install packages, configure services, and validate images. Version components so changes can be reviewed and associated with specific image releases.

Scheduled and dependency-aware builds

Run pipelines manually or on a recurring schedule. Configure scheduled execution to run unconditionally or only when applicable dependencies, such as parent images or components, have updates.

Configurable build infrastructure

Select EC2 instance types, instance profiles, subnets, and security groups for temporary build and test resources. Use private networking when required, while providing access to AWS APIs and package repositories.

Image validation

Execute build-time validation and image tests to check application readiness and configuration requirements. For example, verify that a monitoring agent is installed and that required services start successfully.

Cross-account and cross-Region distribution

Distribute AMIs to designated AWS accounts and Regions using distribution configuration. Prepare destination permissions and KMS key policies when distributing encrypted images.

Workflow customization

Use image workflows to control supported build, test, and distribution execution steps. Customize workflow behavior when the default execution process does not meet operational requirements.

Image lifecycle management

Define lifecycle policies to deprecate, disable, or delete eligible AMIs and clean up associated resources. Configure retention and exclusion rules to avoid removing artifacts still needed for deployment or rollback.

EC2 Image Builder Use Cases

Standardized operating system images

Produce organization-approved Linux and Windows Server AMIs with common logging agents, access controls, and configuration. Application teams can use these images instead of independently maintaining baseline installation scripts.

Recurring patch refreshes

Schedule image rebuilds to incorporate operating system and application updates, then test the refreshed artifacts. Deploy the resulting AMIs through a separate rollout process rather than treating image creation as patching running instances.

Application-ready EC2 images

Preinstall application binaries, runtimes, and dependencies to reduce instance initialization work. Validate application startup during image testing and publish approved image identifiers for deployment automation.

Multi-account image governance

Build images in a dedicated account and distribute approved AMIs to workload accounts and Regions. Apply consistent release naming, encryption permissions, and retention rules across the distribution targets.

Container base image maintenance

Build container images containing approved operating system packages and shared runtime dependencies, then publish them to Amazon ECR. Downstream application builds can consume these maintained base images by version or digest.

Security baseline validation

Encode hardening steps and tests for required settings, services, and packages. Combine the results with vulnerability findings and approval gates before allowing an image into production deployments.

EC2 Image Builder pricing models

Artifact storage and supporting services

AMI backing snapshots, ECR image storage, S3 objects, CloudWatch logs, and applicable data transfer incur their usual charges. Optional services and infrastructure, such as Amazon Inspector, customer-managed KMS keys, NAT gateways, and VPC endpoints, can add costs; retaining images or distributing them to more Regions also increases resource consumption.

Build and test resource consumption

Temporary EC2 instances and their EBS volumes incur normal compute and storage charges while provisioned. Build frequency, instance size, execution duration, and failed runs affect the total cost.

No additional Image Builder service charge

EC2 Image Builder does not add a separate charge for using the service. Charges apply to the AWS resources and services used to build, test, store, assess, and distribute images.

Services EC2 Image Builder integrates with

A common architecture places EC2 Image Builder in a dedicated image-production account. Temporary EC2 instances run in controlled subnets, use narrowly scoped IAM instance profiles, and retrieve versioned installation assets from S3. Private builds need routes or endpoints for the AWS services they use, plus connectivity to any external package repositories. Build logs and execution records provide evidence for troubleshooting and release reviews.After validation, AMI distribution delivers approved artifacts to workload accounts and Regions. Encrypted distribution requires coordinated IAM permissions and KMS key policies, including destination-side access where needed. Container pipelines instead publish images to ECR repositories, where application build systems or deployment tools consume approved tags or digests.Security and deployment automation should remain explicit. Amazon Inspector findings can supplement functional image tests, while EventBridge state-change events can trigger release registration or downstream review. An AVAILABLE image is a completed artifact, not necessarily a production-approved release. Deployment tooling must select the approved AMI or container digest, update the relevant configuration, and roll out replacements. Retention policies should preserve images needed by active deployments and rollback procedures.

Amazon EventBridge

EventBridge can route Image Builder image state-change events to operational automation. For example, match an image reaching the AVAILABLE state and invoke a Lambda function that records the new AMI identifier in a release catalog. Event handlers should be idempotent and should confirm that an artifact meets release requirements before promoting it.

Open Amazon EventBridge →

Amazon EC2

Image Builder uses EC2 instances to execute image builds and tests and produces AMIs that EC2 can launch. For example, build an AMI with an application runtime and monitoring agent, then reference the approved AMI in an EC2 launch template. Updating an AMI or launch template does not itself replace existing instances; the deployment process must handle rollout.

Open Amazon EC2 →

Amazon Inspector

Image Builder can integrate with Amazon Inspector to provide vulnerability findings for supported image builds when scanning is configured. For example, review package vulnerability findings alongside functional test results before approving an AMI for production. Configure the required Inspector coverage and permissions, and implement a separate approval or automation process when findings must block deployment.

Open Amazon Inspector →

Amazon S3

S3 can hold component documents, installation assets, and build logs. For example, store a versioned application installer in S3 and have a custom component download it during the build. Private build instances need an appropriate network path to S3, and both identity and bucket policies must permit access.

Open Amazon S3 →