This chapter covers Amazon Machine Image (AMI) management and lifecycle, a core topic for the SOA-C02 exam. AMIs are the foundation for launching EC2 instances, and understanding how to create, maintain, share, and retire them is essential for operational efficiency and security. Expect 5-8% of exam questions to directly test AMI concepts, including creation from instances and snapshots, cross-region copying, sharing with other accounts, deregistration, and the relationship with EBS snapshots.
Jump to a section
Think of an Amazon Machine Image (AMI) as a recipe card in a restaurant kitchen. Each recipe card lists all the ingredients (operating system, software packages, configurations) and the exact steps to prepare a dish (boot sequence, initialization). When a chef wants to cook a meal, they grab a recipe card and follow it to create a plate of food (launch an EC2 instance). If they need to make the same dish again, they can reuse the same card. Over time, the chef might modify the recipe—add more spice, change the cooking time—and then photocopy the updated card to create a new version. This is exactly like creating an AMI from a running instance: you take a snapshot of the instance's state (including the root volume and attached data volumes) and register it as a new AMI. The original recipe card remains unchanged. In a busy restaurant, the chef might have hundreds of recipe cards, each with a unique ID and version number. They store them in a binder (the AMI catalog in the AWS account). If a recipe becomes outdated, the chef can deprecate it or deregister it, but the old cards (snapshots) remain in the file cabinet (S3 bucket backing EBS snapshots) for a while. The most important rule: never share your original recipe card; instead, make a copy (copy AMI) and share the copy. This prevents accidental modifications and ensures consistency. Just as a chef would never hand over their only copy of a signature dish’s recipe, a SysOps admin must carefully manage AMI permissions, lifecycle, and versions to avoid launching instances with wrong or insecure configurations.
What is an AMI and Why It Exists
An Amazon Machine Image (AMI) is a pre-configured template that contains the software configuration (operating system, application server, applications) required to launch an EC2 instance. Think of it as a snapshot of a virtual machine at a point in time. AMIs are regional resources; each AMI is tied to a specific AWS Region and can only be used to launch instances in that region. The AMI ID is unique per region.
Why do we need AMIs? They provide: - Standardization: Ensure every instance starts with the same base configuration. - Speed: Launch instances in minutes without manual installation. - Reusability: Use the same AMI across multiple instances, across accounts, and across regions (after copying). - Backup and Recovery: Create AMIs as golden images for disaster recovery.
How AMIs Work Internally
An AMI consists of: - Root Volume Template: One or more EBS snapshots (or instance store-backed root volume) that contain the operating system, applications, and data. - Launch Permissions: Controls which AWS accounts can use the AMI to launch instances. - Block Device Mapping: Specifies the volumes to attach to the instance when launched (e.g., /dev/sda1 for root, /dev/xvdf for data).
When you create an AMI from an existing EC2 instance, AWS performs the following steps: 1. Instance Preparation: AWS takes the instance to a consistent state. If the instance is running, AWS coordinates with the OS to flush file system buffers and freeze I/O (if using AWS Systems Manager or by manually stopping the instance). For EBS-backed instances, AWS can create a crash-consistent snapshot even without stopping the instance, but stopping ensures file system consistency. 2. Snapshot Creation: AWS creates EBS snapshots of the root volume and any attached EBS volumes that are included in the block device mapping. The snapshots are stored in Amazon S3 (though you don't directly access them). 3. Registration: The snapshots are registered as an AMI with a unique ID (ami-xxxxxxxx). The AMI metadata includes the architecture (e.g., x86_64), virtualization type (paravirtual or HVM), kernel ID, RAM disk ID, and block device mapping.
Key Components, Values, Defaults, and Timers
AMI ID: Format ami-0abcdef1234567890. Region-specific.
Root Device Type: ebs (default) or instance-store. EBS-backed AMIs have root volume size up to 16 TiB; instance-store backed AMIs have root volume size up to 10 GiB.
Virtualization Type: hvm (Hardware Virtual Machine) or paravirtual (PV). HVM is recommended for most modern instances.
Architecture: i386, x86_64, arm64.
Block Device Mapping: A JSON-like structure that defines:
- Device name (e.g., /dev/sda1)
- Snapshot ID (for EBS volumes)
- Volume size (GiB)
- Volume type (gp2, gp3, io1, etc.)
- Delete on termination flag (default true for root volume)
- Encrypted flag
- Launch Permissions: public, explicit (specific account IDs), or private (only owner).
- Tags: Can be applied to AMIs and underlying snapshots.
- Lifecycle: AMIs can be created, copied, shared, deprecated (marked as deprecated), and deregistered. Deregistration does not delete the underlying snapshots; they must be deleted manually.
- Deprecation Time: You can set a deprecation date for an AMI. After that date, the AMI is marked as deprecated but still usable until deregistered.
- Copying: Cross-region copying creates a new AMI in the target region with a new ID. Cross-account copying requires explicit permissions.
- Encryption: AMIs can be encrypted using EBS encryption. When copying an AMI, you can re-encrypt with a new KMS key.
Configuration and Verification Commands
Using AWS CLI: - Create an AMI from an instance:
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyAMI" --description "My AMI" --no-reboot The --no-reboot flag avoids a reboot; --reboot (default) performs a reboot.
- Register an AMI from a snapshot:
aws ec2 register-image --name "MyAMIFromSnapshot" --root-device-name /dev/xvda --block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-1234567890abcdef0}- Deregister an AMI:
aws ec2 deregister-image --image-id ami-0abcdef1234567890- Copy an AMI to another region:
aws ec2 copy-image --source-image-id ami-0abcdef1234567890 --source-region us-west-2 --region us-east-1 --name "MyCopiedAMI"- Modify launch permissions:
aws ec2 modify-image-attribute --image-id ami-0abcdef1234567890 --launch-permission "Add={UserId=[123456789012]}"- Describe AMIs:
aws ec2 describe-images --image-ids ami-0abcdef1234567890- Set deprecation time:
aws ec2 enable-image-deprecation --image-id ami-0abcdef1234567890 --deprecate-at 2025-12-31T23:59:59.000ZUsing AWS Management Console: - Navigate to EC2 > Images > AMIs. - Actions: Launch, Create image from instance, Copy, Share, Deregister, etc.
How AMIs Interact with Related Technologies
EBS Snapshots: AMIs are built from EBS snapshots. When you deregister an AMI, the snapshots remain. You must manually delete snapshots to save costs. The exam often tests that deregistration does not delete snapshots.
EC2 Auto Scaling: Auto Scaling groups use launch templates or launch configurations that reference an AMI. When you update the AMI, you must update the launch template and create a new version, or update the launch configuration (which is immutable, so you must create a new one).
AWS Systems Manager: You can use Systems Manager Automation to create AMIs, patch them, and update them in a pipeline.
AWS Backup: Can automate AMI creation and retention policies.
AWS Image Builder: A service to create, maintain, and share AMIs with a pipeline (source AMI, components, recipes, distribution).
VM Import/Export: Allows importing VM images from on-premises as AMIs.
Best Practices
Use tags to track AMI purpose, version, and owner.
Set deprecation dates to automate AMI retirement.
Limit public sharing to avoid security risks.
Copy AMIs to other regions for disaster recovery.
Use encrypted AMIs for sensitive workloads.
Automate AMI creation using AWS Backup or custom scripts to ensure regular backups of instances.
Common Pitfalls
Forgetting to delete underlying snapshots after deregistration leads to ongoing costs.
Sharing AMIs publicly accidentally exposes snapshots.
Using an AMI from a different region without copying fails.
Not stopping the instance before creating an AMI can result in inconsistent data if applications are writing to disk.
Cross-account copy requires explicit permission from the source account and acceptance from the target account.
Create AMI from Running Instance
First, ensure the instance is in a consistent state. For critical applications, stop the instance to guarantee file system consistency; otherwise, use --no-reboot (AWS will still attempt to flush caches). The create-image command initiates snapshot creation of the root and attached EBS volumes. During this process, the instance remains running if --no-reboot is used, but I/O performance may be impacted. The AMI creation can take several minutes depending on volume size. After completion, the AMI is registered automatically with a new ID. The underlying snapshots are created with a description referencing the AMI ID.
Register AMI from Existing Snapshot
If you have a pre-existing EBS snapshot (e.g., from a backup), you can register it as an AMI. Use the register-image CLI command with --block-device-mappings specifying the snapshot ID. You must also specify the root device name (e.g., /dev/xvda). The AMI will have the same architecture and virtualization type as the original instance. This is useful for restoring an instance from a snapshot without launching from the original AMI.
Copy AMI to Another Region
Copying an AMI to another region is a two-step process: the source AMI's snapshots are copied to the target region, then a new AMI is registered there. The copy-image command requires source-region and target region. You can also specify encryption options. The copy is asynchronous; you can check progress using describe-images or describe-snapshots. Cross-region copy incurs data transfer costs and snapshot storage costs in the target region.
Share AMI with Another Account
To share an AMI with another AWS account, modify the launch permissions to add the target account ID. Use modify-image-attribute with --launch-permission 'Add={UserId=[...]}'. The target account can then describe the AMI and launch instances from it. Sharing does not transfer ownership; the source account remains the owner. For cross-account copy, the target account must accept the shared AMI (if it is encrypted) by creating a copy in their account.
Deprecate and Deregister AMI
Deprecation marks an AMI as deprecated without deleting it. Use enable-image-deprecation with a future date. After that date, the AMI shows a deprecated status but can still be used to launch instances. To fully remove, use deregister-image. This removes the AMI from the account's AMI list. However, the underlying snapshots remain. To delete them, use delete-snapshot for each snapshot ID. Failure to delete snapshots leads to ongoing storage costs.
In a large enterprise with hundreds of EC2 instances, AMI management is critical for security and operational efficiency. Consider a financial services company that must maintain a golden AMI with hardened OS, antivirus, and monitoring agents. The SysOps team uses AWS Image Builder to create a pipeline that takes a base Amazon Linux 2 AMI, installs required packages, applies security patches, and then distributes the final AMI to multiple regions (us-east-1, eu-west-1, ap-southeast-1) for disaster recovery. The pipeline runs weekly, and the old AMIs are deprecated after 30 days. The team uses tags to track version numbers (e.g., 'golden-v1.2.3') and creation dates. They also share the AMI with a separate security audit account that scans it for vulnerabilities before approval. A common misconfiguration is forgetting to delete old snapshots after deregistration, which accrues costs. Another scenario is a SaaS provider that launches instances for each customer from a custom AMI. They use cross-account sharing to allow customers to launch instances in their own accounts. They must ensure that the AMI is not shared publicly to avoid data leaks. They also copy the AMI to the customer's preferred region. Performance-wise, copying large AMIs (e.g., 500 GB) across regions can take hours; they plan for this by scheduling copies during off-peak hours. When misconfigured, such as sharing with the wrong account or not setting deprecation dates, the company risks launching outdated instances or incurring unexpected costs. The SysOps admin must regularly audit AMIs using AWS Config rules that flag public AMIs or AMIs older than 90 days without deprecation.
The SOA-C02 exam tests AMI management under the Deployment domain (Objective 3.3). You should be prepared for questions that require you to know the difference between deregistering an AMI and deleting its snapshots. A common wrong answer is 'deregistering an AMI automatically deletes its snapshots' – this is false. Another trap: 'You can share an AMI with another account by copying it directly to that account' – actually, sharing is done via launch permissions; copying requires the target to have access and then they copy. The exam also tests that AMIs are regional; you cannot launch an instance in us-east-1 using an AMI from eu-west-1 without copying. Specific numbers: The default root volume size for instance-store AMIs is 10 GiB; for EBS-backed, up to 16 TiB. The deprecation date must be in ISO 8601 format. The exam loves to ask about the --no-reboot flag: it avoids a reboot but may result in inconsistent data if files are being written. Another edge case: when you copy an AMI with encryption, you must specify a new KMS key if you want re-encryption; otherwise, the copy uses the same key (if allowed cross-region). The exam also tests that you cannot change the root device type (EBS vs instance-store) after creation. To eliminate wrong answers, focus on the underlying mechanism: AMIs are just metadata pointing to snapshots. Any action that implies snapshots are automatically deleted is incorrect unless explicitly stated. Also remember that modifying launch permissions does not affect existing instances launched from that AMI. Finally, the exam may ask about the 'AMI lifecycle policy' using AWS Backup – know that you can create backup plans that automatically create AMIs and retain them for a specified period.
AMIs are regional resources; you must copy them across regions to use in another region.
Deregistering an AMI does not delete its underlying EBS snapshots.
You can set a deprecation date for an AMI using enable-image-deprecation.
Cross-account sharing is done via launch permissions, not by copying the AMI.
The --no-reboot flag in create-image avoids reboot but risks inconsistent snapshots.
EBS-backed AMIs support root volumes up to 16 TiB; instance-store up to 10 GiB.
Encryption can be added or changed when copying an AMI.
AWS Image Builder automates AMI creation and patching pipelines.
These come up on the exam all the time. Here's how to tell them apart.
EBS-backed AMI
Root volume is an EBS volume (persistent, up to 16 TiB).
Instance can be stopped and restarted without losing data.
Snapshots can be taken for backup.
Supports encryption and larger instance types.
Default for most modern AMIs.
Instance-store backed AMI
Root volume is an instance store (ephemeral, up to 10 GiB).
Instance cannot be stopped; termination loses data.
No snapshot support; backup requires copying to S3.
Limited to instance families that support instance store (e.g., m3.medium).
Less common; used for temporary or high-I/O workloads.
Mistake
Deregistering an AMI automatically deletes its underlying EBS snapshots.
Correct
Deregistration only removes the AMI metadata. The EBS snapshots remain in your account and continue to incur storage charges until you explicitly delete them using the delete-snapshot API.
Mistake
You can launch an instance in any region using an AMI from another region without copying.
Correct
AMIs are regional resources. To use an AMI in a different region, you must first copy it to that region using the copy-image API or console action. The copy creates a new AMI ID in the target region.
Mistake
Sharing an AMI with another account allows them to modify the original AMI.
Correct
Sharing only grants launch permissions. The recipient cannot modify or delete the original AMI. They can only launch instances from it. Ownership remains with the source account.
Mistake
Creating an AMI from a running instance without reboot always guarantees consistent data.
Correct
Using --no-reboot avoids a reboot but does not guarantee file system consistency. Applications writing to disk during snapshot creation may result in an inconsistent state. For critical workloads, stop the instance or use application-level consistency methods (e.g., freeze I/O).
Mistake
You can change the root device type of an AMI after it is created.
Correct
The root device type (EBS or instance-store) is fixed at AMI creation time. You cannot convert an EBS-backed AMI to instance-store or vice versa. You must create a new AMI from an instance with the desired root device type.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
When you deregister an AMI, the AMI metadata is removed, but the EBS snapshots that compose the AMI remain in your account. You must manually delete those snapshots using the EC2 console or AWS CLI (delete-snapshot) to avoid ongoing storage charges. The snapshots are not automatically deleted because they might be used by other AMIs or for independent backups.
Yes, you can share an AMI by modifying its launch permissions to include the target account ID. The target account can then launch instances directly from your AMI without needing to copy it. However, if the AMI is encrypted, the target account must have access to the KMS key. If you want the target account to own their own copy, they can use the copy-image action after you share the AMI.
You can create an AMI from a stopped instance just like from a running one. Use the AWS Console, CLI, or SDK. Since the instance is stopped, there is no risk of data inconsistency, and you do not need to specify the --no-reboot flag. The process creates snapshots of the root and attached EBS volumes and registers the AMI.
Deprecation marks an AMI as deprecated on a specified future date but does not delete it. The AMI remains usable. Deregistration removes the AMI from your account's AMI list, making it unavailable for launching new instances. However, instances already launched from that AMI continue to run. Deprecation is a softer retirement step, often used to notify users before full removal.
Yes, you can copy an encrypted AMI to another region. During the copy, you can specify a new KMS key for re-encryption in the target region. The source snapshots are decrypted and re-encrypted with the target key. If you do not specify a key, the copy uses the same KMS key, which must be available in the target region (cross-region KMS key access is possible but requires permissions).
You can use AWS Backup to create backup plans that automatically create AMIs on a schedule (e.g., daily) and retain them for a specified number of days. Alternatively, use AWS Systems Manager Automation with custom scripts or AWS Image Builder for more complex pipelines. AWS Backup provides lifecycle policies to automatically delete old AMIs and their snapshots.
If you already have a running instance launched from an AMI that was later deregistered, the instance continues to run normally. Deregistration only prevents new instances from being launched using that AMI. The underlying snapshots remain, so the instance's storage is unaffected. However, you cannot create new instances from that AMI ID.
You've just covered AMI Management and Lifecycle — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?