This chapter covers the Golden AMI strategy and AWS EC2 Image Builder, a critical topic for the SOA-C02 exam under Domain 3: Deployment, Objective 3.3. Golden AMIs are pre-configured, hardened machine images that serve as a baseline for EC2 instances, ensuring consistency, security, and rapid scaling. EC2 Image Builder automates the creation, testing, and distribution of Golden AMIs. Approximately 5-10% of exam questions touch this area, focusing on best practices for AMI lifecycle management, automation, and integration with other AWS services. Mastering this topic is essential for SysOps administrators responsible for maintaining a standardized and compliant EC2 fleet.
Jump to a section
Imagine a bakery that produces thousands of custom cakes daily. Each cake must be consistent, but every order has unique toppings. The bakery's solution: a master recipe (Golden AMI) that specifies exact ingredients, mixing times, and baking temperature. This recipe is stored in a secure vault (AMI library). When a new order comes in, the baker doesn't reinvent the cake from scratch. Instead, they photocopy the master recipe (create an AMI), then adjust only the frosting and decorations (user data and post-deployment configuration). The bakery also uses a recipe automation machine (EC2 Image Builder) that can take a basic recipe, add common improvements (like a secret icing ingredient), and test-bake a small cake (build and test instance) to ensure quality before storing the updated recipe back in the vault. If every baker tried to create cakes from scratch, some would add too much sugar or underbake. The Golden AMI eliminates that variability, ensuring every cake meets the brand standard. The automation machine also keeps a log of all recipe versions (Image Builder pipeline versions), so the bakery can roll back if a new variant fails. This is exactly how Golden AMIs and Image Builder work in AWS: a standardized, pre-hardened machine image that can be customized for specific workloads, built and tested through automated pipelines, and versioned for compliance and rollback.
What is a Golden AMI and Why Does It Exist?
A Golden AMI (Amazon Machine Image) is a pre-configured, hardened, and approved image that serves as the standard base for launching EC2 instances within an organization. It includes the operating system, security patches, required software packages, agents (e.g., SSM Agent, CloudWatch Agent), and configuration settings (e.g., time zone, firewall rules). The purpose is to eliminate configuration drift, reduce deployment time, and enforce security baselines.
Without Golden AMIs, teams might launch instances from public AMIs or standard OS images and then apply manual configurations, leading to inconsistencies, missing patches, or misconfigurations. Golden AMIs ensure every instance starts from a known, compliant state.
How Golden AMIs Work Internally
A Golden AMI is created from a source EC2 instance that has been fully configured. The process involves:
Launch a reference instance from a base AMI (e.g., Amazon Linux 2).
Apply configurations – install software, apply patches, set security policies, install agents.
Sysprep (Windows) or clean-up (Linux) – remove unique identifiers, logs, temporary files, and prepare the OS for cloning.
Create an AMI from the instance – AWS takes a snapshot of each EBS volume attached to the instance and registers the AMI.
Terminate the reference instance (optional but recommended to avoid costs).
The AMI is stored in the region where it was created. It can be copied to other regions or shared with other AWS accounts. When you launch an instance from the AMI, AWS uses the snapshots to create EBS volumes, attaches them, and boots the instance.
Key Components of a Golden AMI Strategy
AMI ID: Unique identifier for the image.
Root Volume Snapshot: The snapshot of the root EBS volume (contains OS and applications).
Block Device Mapping: Defines which snapshots map to which device names (e.g., /dev/xvda).
Permissions: Controls which accounts can launch instances from the AMI (public, specific accounts, or implicit).
Tags: Metadata to track version, environment, owner, etc.
EC2 Image Builder: Automating Golden AMI Creation
EC2 Image Builder is a managed service that automates the creation, testing, and distribution of Golden AMIs. It eliminates the need for manual scripts or third-party tools. Key components:
Pipeline: Defines the end-to-end workflow: source image, recipe, infrastructure configuration, distribution settings, and schedule.
Recipe: A document that specifies the base image, components (software packages, scripts), and block device mappings.
Component: A YAML document that defines steps to install software, configure settings, or run tests. Components can be reused across recipes.
Infrastructure Configuration: Defines the instance type, IAM role, security groups, and subnet for the build and test instances.
Distribution Settings: Specifies which regions and accounts to distribute the resulting AMI to.
Image: The output AMI generated by the pipeline.
How Image Builder Works Step-by-Step
Pipeline Execution: Triggered on a schedule or manually.
Launch Build Instance: Image Builder launches an EC2 instance using the infrastructure configuration.
Apply Recipe: The recipe's components are executed in order (e.g., install patches, install software, run tests).
Create Image: After successful build, Image Builder creates an AMI from the instance.
Test Image: Optionally, Image Builder launches a test instance from the new AMI and runs test components.
Distribute: The AMI is copied to specified regions and shared with specified accounts.
Clean Up: Build and test instances are terminated.
Configuration and Verification Commands
#### Creating a Golden AMI Manually (AWS CLI)
# Create an AMI from an instance
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyGoldenAMI-v1" --no-reboot--no-reboot: Avoids rebooting the instance before creating the image (ensures filesystem consistency is not guaranteed; use with caution).
#### Using Image Builder (AWS CLI)
# Create a component
aws imagebuilder create-component --name my-component --version 1.0.0 --platform Linux --data file://component.yaml
# Create a recipe
aws imagebuilder create-image-recipe --name my-recipe --version 1.0.0 --parent-image arn:aws:imagebuilder:us-east-1:123456789012:image/amazon-linux-2-x86/x.x.x --components componentArn=arn:aws:imagebuilder:us-east-1:123456789012:component/my-component/1.0.0
# Create an infrastructure configuration
aws imagebuilder create-infrastructure-configuration --name my-infra --instance-types t3.medium --security-group-ids sg-12345678 --subnet-id subnet-12345678 --iam-role arn:aws:iam::123456789012:role/EC2ImageBuilderRole
# Create a distribution configuration
aws imagebuilder create-distribution-configuration --name my-dist --distributions Region=us-east-1,Region=eu-west-1
# Create a pipeline
aws imagebuilder create-image-pipeline --name my-pipeline --image-recipe-arn arn:aws:imagebuilder:us-east-1:123456789012:image-recipe/my-recipe/1.0.0 --infrastructure-configuration-arn arn:aws:imagebuilder:us-east-1:123456789012:infrastructure-configuration/my-infra --distribution-configuration-arn arn:aws:imagebuilder:us-east-1:123456789012:distribution-configuration/my-dist --schedule scheduleExpression="cron(0 0 * * ? *)"
# List images
aws imagebuilder list-imagesVerification: Check AMI details
aws ec2 describe-images --image-ids ami-12345678Integration with Other AWS Services
AWS Systems Manager: Use SSM documents to apply additional configuration at launch (e.g., join domain, install agents).
AWS CloudFormation: Launch stacks using Golden AMI IDs as parameters.
AWS Auto Scaling: Use Golden AMIs in launch templates or configurations to ensure consistent instances.
AWS KMS: Encrypt AMI snapshots with customer-managed keys for compliance.
AWS Organizations: Share AMIs with specific accounts via RAM (Resource Access Manager).
Best Practices
Versioning: Use a naming convention like ami-golden-YYYYMMDD-v1 to track versions.
Automate: Use Image Builder or CI/CD pipelines (e.g., Jenkins) to create AMIs.
Test: Include test components in Image Builder pipelines to validate that applications start and security checks pass.
Deprecation: Use AMI deprecation to mark old AMIs as deprecated after a certain period.
Lifecycle Policy: Use AWS Backup or manual scripts to deregister old AMIs and delete associated snapshots.
Security: Scan AMIs for vulnerabilities using Amazon Inspector or third-party tools.
Exam-Relevant Details
Default AMI retention: AWS does not automatically delete AMIs; you must manage lifecycle.
AMI copying: Cross-region copying takes time; the AMI must be in the available state.
AMI sharing: You can share AMIs with specific AWS accounts; you cannot share with an entire organization unless using RAM.
Image Builder pricing: You pay for underlying resources (EC2 instances, EBS snapshots) and no additional fee for the service itself.
Component document format: YAML with name, description, schemaVersion, phases (build, validate, test).
Common Pitfalls
Reboot vs no-reboot: Using --no-reboot when creating an AMI manually can result in an inconsistent filesystem; always reboot or use Image Builder which handles this.
Missing EBS snapshots: If you create an AMI from an instance with additional EBS volumes, those snapshots are included; ensure they are not deleted before the AMI is deprecated.
Permissions: If an AMI is private, only the owner can launch instances; sharing requires explicit permissions.
Image Builder failures: Check the build logs in CloudWatch Logs; common issues include missing IAM permissions (e.g., ec2:DescribeInstances, iam:PassRole).
Define the Base Image
Choose a source AMI that serves as the foundation for your Golden AMI. This could be an official Amazon Linux 2, Windows Server, or a third-party image. Consider the OS version, architecture (x86 vs ARM), and any licensing requirements. In Image Builder, you specify the parent image ARN. For manual creation, launch an instance from the chosen AMI. Ensure the base image is up-to-date with the latest patches at the time of selection. The exam often tests that you should use a minimal base image to reduce attack surface and size.
Configure the Reference Instance
Connect to the running instance (via SSH or RDP) and apply all desired configurations. This includes installing software packages (e.g., Apache, Python, SSM Agent), applying security patches, setting firewall rules (iptables or Windows Firewall), configuring logging, and setting time zones. Use configuration management tools like Ansible or Chef if needed. For Windows, run sysprep with generalize option to remove unique identifiers. For Linux, clean up temporary files, logs, and SSH host keys. This step is critical: any mistake here propagates to all instances launched from the AMI.
Create the AMI
Once the instance is fully configured and cleaned, create the AMI. In the AWS Management Console, select the instance and choose 'Create Image'. In the CLI, use `aws ec2 create-image` with `--no-reboot` only if you are confident the filesystem is consistent; otherwise, reboot first. The process takes several minutes as AWS takes snapshots of attached EBS volumes and registers the AMI. The AMI ID is returned. For Image Builder, this step is automatic after the build phase. The AMI enters the 'pending' state and becomes 'available' when ready.
Test the AMI
Launch a test instance from the new AMI to verify that everything works as expected. Check that services start, applications respond, and security settings are applied. For Image Builder, you can define test components that automatically run tests (e.g., check that a web server returns HTTP 200). Testing prevents deploying a broken AMI to production. Also test that the instance can be managed via Systems Manager and that CloudWatch logs are flowing. If issues are found, fix the source instance and create a new version.
Distribute and Version
Copy the AMI to other regions where you need it using the console or `aws ec2 copy-image`. Share the AMI with other AWS accounts if necessary. Use a consistent naming convention (e.g., `MyApp-Golden-2025-03-01-v1`). Tag the AMI with metadata like environment, version, and creation date. In Image Builder, distribution settings handle cross-region and cross-account sharing automatically. Set AMI deprecation time to automatically mark old AMIs as deprecated after a certain period (e.g., 90 days). This helps with governance and cleanup.
Scenario 1: Enterprise Security Compliance
A financial services company must ensure all EC2 instances comply with PCI DSS. They create a Golden AMI that includes hardened OS settings (e.g., disabled root login, enforced password policies), installed security agents (e.g., CrowdStrike, CloudWatch Agent), and configured logging to CloudWatch Logs. They use EC2 Image Builder with a pipeline that runs weekly. The pipeline uses a base Amazon Linux 2 image, applies a component that installs the latest security patches, and runs a test component that verifies the instance passes a CIS benchmark scan. The resulting AMI is distributed to all accounts in the organization via AWS RAM. If a security patch is critical, they trigger the pipeline manually. This ensures all new instances are compliant within minutes of launch.
Scenario 2: Rapid Scaling for a SaaS Application
A SaaS startup experiences unpredictable traffic spikes. They use Auto Scaling groups with a Golden AMI that contains the application code, web server (Nginx), and caching layer (Redis). The AMI is built daily using a CI/CD pipeline that integrates with Image Builder. Each build includes the latest application version from their Git repository. The pipeline runs integration tests against a staging environment before creating the AMI. When traffic spikes, the Auto Scaling group launches new instances from the latest Golden AMI, ensuring zero configuration drift. The startup also tags AMIs with the Git commit hash for traceability. If a rollback is needed, they simply update the Auto Scaling group to use a previous AMI ID.
Scenario 3: Multi-Region Disaster Recovery
A global e-commerce company needs to maintain identical environments in three AWS regions (us-east-1, eu-west-1, ap-southeast-1). They create a Golden AMI in the primary region (us-east-1) using Image Builder. The distribution configuration copies the AMI to the other two regions automatically. They also schedule the pipeline to run weekly on Sundays. In the event of a regional failure, they can launch instances in another region using the same AMI ID (after mapping to the copied AMI ID). They use CloudFormation templates that reference the AMI by a parameter, which is updated via Lambda after each build. This ensures fast failover with consistent configuration. Common misconfigurations include forgetting to update the AMI parameter in CloudFormation, leading to old AMIs being used.
The SOA-C02 exam tests your understanding of Golden AMI strategy and EC2 Image Builder under Objective 3.3 (Deployment and Provisioning). Expect questions that require you to choose the most efficient and automated way to maintain consistent AMIs. Key areas:
Image Builder vs. Manual Creation: The exam favors Image Builder because it is automated, repeatable, and includes testing. A common wrong answer is to suggest manually creating AMIs with scripts (e.g., using Packer) because it's free, but the exam expects managed services.
AMI Lifecycle Management: Questions often ask how to deprecate old AMIs. The correct answer is to set a deprecation time on the AMI (using --deprecation-time in CLI or via console). Wrong answer: deleting the AMI immediately, which breaks instances launched from it (they still run but can't be used for new launches).
Cross-Region Distribution: Image Builder distribution settings allow automatic copying to multiple regions. A trap is to suggest using AWS Backup or S3 cross-region replication; those are for data, not AMIs.
IAM Permissions: Questions test that Image Builder requires an IAM role with permissions to launch instances, create images, and copy images. Wrong answer: using the default EC2 instance profile without custom policies.
Component Documents: You may be asked to identify the correct YAML structure for a component. Remember the phases key with build, validate, and test. The exam might show a snippet with schemaVersion: 1.0 which is correct.
Edge Cases: What if an AMI is shared with your account but you cannot launch? Check that the AMI is in the same region and that you have permissions. Another: if you create an AMI from an instance with encrypted volumes, you need to specify the KMS key when copying.
Numbers: Default AMI deprecation time is none (must be set). Image Builder pipeline schedule uses cron expressions. AMI copy time depends on snapshot size.
To eliminate wrong answers, think about automation, security, and compliance. If an answer involves manual steps (e.g., SSH into an instance to run commands), it's usually wrong. Look for terms like 'Image Builder', 'component', 'pipeline', 'distribution'.
A Golden AMI is a pre-configured, hardened image used as a standard base for EC2 instances.
EC2 Image Builder automates the creation, testing, and distribution of Golden AMIs.
Image Builder consists of pipelines, recipes, components, infrastructure, and distribution configurations.
Use Image Builder over manual creation for automation, testing, and compliance.
AMI lifecycle management includes versioning, deprecation, and cleanup of old AMIs and snapshots.
Cross-region AMI distribution is handled automatically by Image Builder distribution settings.
IAM roles for Image Builder must include permissions for EC2, IAM, and KMS actions.
AMI deprecation time can be set to automatically mark old AMIs as deprecated.
These come up on the exam all the time. Here's how to tell them apart.
Manual AMI Creation
Requires manual configuration of an EC2 instance.
No built-in testing; must manually launch and verify.
No automated scheduling; must trigger manually or via scripts.
Difficult to integrate with CI/CD pipelines.
No built-in cross-region distribution; must use CLI scripts.
EC2 Image Builder
Fully automated pipeline from source to AMI.
Supports test components to automatically validate AMI.
Supports cron-based scheduling for regular builds.
Integrates with AWS services like CodePipeline and Systems Manager.
Built-in distribution settings for cross-region and cross-account sharing.
Mistake
Golden AMIs must be created manually for each new application version.
Correct
EC2 Image Builder automates the entire process. You define a pipeline with a recipe that includes components to install your application. The pipeline runs on a schedule or trigger, automatically creating a new AMI each time. Manual creation is error-prone and not scalable.
Mistake
Once an AMI is created, it cannot be updated; you must create a new one.
Correct
You cannot modify an existing AMI; you must create a new version. However, you can deprecate old AMIs and keep multiple versions. Image Builder creates a new AMI each time the pipeline runs, so versioning is inherent.
Mistake
AMI sharing with an entire AWS Organization requires sharing with each account individually.
Correct
You can use AWS Resource Access Manager (RAM) to share an AMI with an entire AWS Organization or Organizational Unit. This simplifies management. Previously, you had to share with each account one by one.
Mistake
Using --no-reboot when creating an AMI is always safe and faster.
Correct
`--no-reboot` skips the shutdown of the instance before snapshotting, which can result in an inconsistent filesystem (e.g., open files, pending writes). It is recommended to allow reboot (default) to ensure data integrity. Image Builder handles this properly.
Mistake
EC2 Image Builder incurs additional service charges beyond the underlying resources.
Correct
EC2 Image Builder is a free service. You only pay for the EC2 instances, EBS snapshots, and other resources consumed during the build and test processes. There is no per-pipeline or per-image fee.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Golden AMI is a standard AMI that has been customized and hardened to meet organizational standards. It includes pre-installed software, security patches, and configuration settings. A standard AMI is typically a base OS image from AWS or the community without additional customization. The term 'Golden' implies it is the approved, compliant image for production use.
Use EC2 Image Builder to create a pipeline that runs on a schedule (e.g., weekly). The pipeline uses a recipe that includes components to install updates and software. Each pipeline execution produces a new AMI version. You can also trigger the pipeline via AWS CodePipeline or Lambda for event-driven updates.
Yes, you can share an AMI with specific AWS accounts using the `--launch-permission` parameter or via the AWS Management Console. However, to share with an entire AWS Organization or Organizational Unit, you should use AWS Resource Access Manager (RAM). RAM allows you to share the AMI with all accounts in the organization without listing each one individually.
Deprecating or deleting an AMI does not affect running instances that were launched from that AMI. They continue to run normally. However, you cannot launch new instances from a deprecated or deleted AMI. It is best practice to deprecate AMIs before deleting them to allow a transition period.
Image Builder allows you to define test components in the recipe. After the build phase, Image Builder launches a test instance from the newly created AMI and runs the test components. These components can include scripts to verify that services are running, ports are open, or security checks pass. If any test fails, the pipeline fails and the AMI is not distributed.
The IAM role used by Image Builder (specified in the infrastructure configuration) needs permissions to launch EC2 instances, create images, describe images, and pass roles. Specifically, it requires actions like `ec2:RunInstances`, `ec2:CreateImage`, `ec2:DescribeInstances`, `iam:PassRole`, and `kms:CreateGrant` (if using encrypted volumes). The managed policy `EC2InstanceProfileForImageBuilder` provides many of these permissions.
Yes, EC2 Image Builder supports both Linux and Windows platforms. For Windows, you can include components that run PowerShell scripts, install MSI packages, and run Sysprep. The pipeline handles the generalization process automatically if you include the appropriate component.
You've just covered Golden AMI Strategy and Image Builder — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?