Amazon EBS Snapshots and Custom AMIs – SAP-C02 Study Guide

Purpose of This Lesson

Amazon Machine Images (AMIs) provide reusable templates for launching EC2 instances. An AMI can capture a customized server configuration—including its operating system, installed software, configuration files, and EBS-backed storage layout—so that additional instances can be launched consistently.

This lesson demonstrates a common workflow:

1. Launch and customize an EC2 instance.
2. Create an AMI from the configured instance.
3. Launch additional instances from that AMI.
4. Launch replicas in another Availability Zone within the same Region.
5. Clean up the AMI and its associated snapshots.

Key Concepts

Creating a custom AMI

A custom AMI is useful when a server has been configured with software or settings that should be reused. For example, an instance can run user data during its first boot to install a web server and create application content. An AMI can then capture the resulting instance state.

When an AMI is created from an EBS-backed EC2 instance, AWS creates snapshots of the EBS volumes referenced by the AMI’s block device mappings. The AMI also records information needed to launch instances, such as:

• Root device configuration
• Additional EBS volumes
• Snapshot references
• Instance architecture and virtualization details
• Boot and device-mapping information

An AMI is a launch template for an instance, not a live synchronization mechanism. Changes made to the source instance after AMI creation are not automatically propagated to instances launched from that AMI.

EBS snapshots and Availability Zones

EBS volumes are tied to a specific Availability Zone. An EBS snapshot is a Regional resource, allowing it to be used to create an EBS volume in any Availability Zone in the same AWS Region.

This means an AMI created from an instance in one Availability Zone can be used to launch another instance in a different Availability Zone within that Region. The new instance receives newly created EBS volumes in its selected Availability Zone.

A snapshot does not make an EBS volume directly attachable across Availability Zones. Instead, use the snapshot to create a new volume in the target Availability Zone, or launch an AMI that references the snapshot.

AMI Regional scope

An AMI is Region-specific. An AMI created in one Region cannot be used directly to launch an EC2 instance in another Region.

To use the same image in another Region, copy the AMI to the destination Region. The copied AMI has its own associated snapshots in that Region. During the copy process, encryption can be configured where supported and permitted by the relevant KMS key policies.

Cross-Region AMI copies are useful for:

• Disaster recovery
• Regional failover
• Geographic expansion
• Data residency requirements
• Standardized deployment across Regions

AMI creation is not the same as application backup

An AMI captures the configured system and its EBS-backed disks at a particular point in time. It is useful for server replacement and repeatable instance deployment, but it should not automatically be treated as a complete backup strategy.

For production systems, consider whether the backup must also include:

• Application-consistent state
• Databases and transaction logs
• Data stored outside the instance
• Cross-Region copies
• Retention policies
• Recovery point and recovery time objectives

AMI and snapshot cleanup

Deregistering an AMI does not automatically delete the EBS snapshots associated with it. To remove all related resources:

1. Identify the snapshots referenced by the AMI.
2. Deregister the AMI.
3. Delete the no-longer-needed snapshots.

Deregister the AMI before deleting its backing snapshots. Retaining snapshots that are no longer referenced by an AMI can create unnecessary storage costs.

User data versus AMI contents

User data typically runs during the initial boot of an EC2 instance. If software is installed by user data before the AMI is created, that installed state can be captured in the AMI.

However, user data itself is not a substitute for image configuration management. A robust design should define which setup belongs in:

• The AMI, for stable base software and configuration
• User data, for instance-specific initialization
• AWS Systems Manager, for operational configuration and patching
• Configuration management or deployment tooling, for repeatable application changes

Exam-Relevant Takeaways

• EBS volumes are Availability Zone-scoped; EBS snapshots are Regional.
• An EBS-backed AMI can launch instances in any Availability Zone in the AMI’s Region.
• AMIs are Region-specific and must be copied before use in another Region.
• Creating an AMI from an EBS-backed instance creates or references snapshots for its EBS volumes.
• A custom AMI is appropriate for repeatable EC2 deployments with a known software baseline.
• A snapshot is not the same as an AMI: a snapshot represents volume data, while an AMI contains launch metadata plus references to required snapshots.
• Deregistering an AMI does not delete its associated snapshots.
• Encrypted AMI or snapshot copies require appropriate KMS permissions and key management decisions.
• Security groups are not embedded in the AMI. They must be selected or supplied when launching the new instance.
• Subnet and Availability Zone placement are launch-time decisions, not fixed by the AMI.
• An AMI does not automatically include external resources such as security groups, IAM roles, Elastic IP addresses, load balancer configuration, or databases.

Architecture Decision Guide

Requirement	Recommended approach	Important consideration
Launch many identical EC2 servers	Create a custom AMI and launch instances from it	Keep the image versioned and patched
Launch in another Availability Zone in the same Region	Use the same AMI or create a volume from the snapshot in the target AZ	EBS volumes themselves cannot be moved directly between AZs
Launch in another Region	Copy the AMI to the destination Region	The copied AMI and snapshots are separate Regional resources
Preserve a server’s disk state	Create an EBS snapshot or AMI	Choose an AMI when repeatable instance launches are required
Build a standard operating system baseline	Use a hardened, versioned custom AMI	Combine with patch management and image lifecycle processes
Recover from a Regional failure	Maintain copied AMIs and required data backups in another Region	AMIs alone may not protect databases or external state
Reduce manual cleanup	Track AMI-to-snapshot relationships and use lifecycle automation	Deregister AMIs and delete obsolete snapshots deliberately
Protect image data	Use encrypted EBS volumes and encrypted snapshots or AMI copies	Validate KMS key access for the launch and copy operations

Common Exam Traps

Confusing Availability Zone and Region scope

An EBS volume is tied to one Availability Zone, but a snapshot and an AMI are Regional. A snapshot can create a volume in another AZ in the same Region. Neither the original snapshot nor the original AMI can be used directly in a different Region.

Assuming AMIs include networking configuration

An AMI does not preserve the source instance’s security group, subnet, private IP address, public IP address, or Elastic IP association. These are controlled when the new instance is launched.

Assuming an AMI is automatically a full-system backup

An AMI generally covers the instance’s configured EBS-backed volumes, but it does not automatically protect dependent services, databases hosted elsewhere, or data in services such as Amazon S3, Amazon DynamoDB, or Amazon EFS.

Deleting the AMI and expecting snapshots to disappear

Deregistering an AMI removes the AMI registration, not the underlying snapshots. Orphaned snapshots may continue incurring storage charges.

Treating an AMI as a replication mechanism

An AMI is a point-in-time image. It does not keep multiple running servers synchronized, and it does not provide continuous replication of application data.

Ignoring permissions during cross-Region encrypted copies

Encrypted snapshots and AMIs involve AWS KMS. The principal performing the copy or launch must have the necessary KMS permissions, and the destination key policy must allow the required operations.

Real-World Engineer Notes

• Prefer immutable image-based deployments for predictable server fleets. Build a new AMI version rather than modifying production instances manually.
• Record image ownership, build date, operating system version, application version, patch level, and intended environment using tags or an image catalog.
• Use EC2 Image Builder or an equivalent automated pipeline for repeatable AMI creation, testing, and distribution.
• Test that instances launched from the AMI actually start the application, pass health checks, and can be placed behind the intended load balancer.
• Remove secrets, temporary files, credentials, and environment-specific configuration before creating a reusable image.
• Use launch templates with the AMI ID, instance type, security groups, IAM role, subnet strategy, and user data required for deployment.
• For fleets that scale automatically, combine a versioned AMI with an Auto Scaling group and health checks.
• Use EBS snapshot lifecycle policies or AWS Backup where appropriate, but confirm retention requirements before deleting snapshots referenced by recovery processes.
• An AMI can reduce bootstrapping time, but it increases the need for image patching and version governance.

Quick Reference Summary

• EBS volume: Availability Zone-scoped block storage.
• EBS snapshot: Regional point-in-time copy of an EBS volume.
• AMI: Region-specific EC2 launch template that references one or more snapshots and records launch metadata.
• Same Region, different AZ: Use the AMI or snapshot to create new EBS volumes in the target AZ.
• Different Region: Copy the AMI.
• Cleanup: Deregister the AMI, then delete unneeded associated snapshots.
• Security groups: Selected at launch; not included in the AMI.
• User data: Initial bootstrapping mechanism; it may be unnecessary for software already captured in the AMI.

Flashcards

1. Q: What is the primary purpose of a custom EC2 AMI?

A: To provide a reusable template for launching instances with a predefined operating system, software, configuration, and EBS volume layout.

1. Q: Are EBS snapshots Availability Zone-scoped or Regional?

A: Regional. A snapshot can be used to create an EBS volume in any Availability Zone in the same Region.

1. Q: Are EBS volumes Regional?

A: No. An EBS volume is associated with a specific Availability Zone.

1. Q: Can an AMI created in one Region launch an instance directly in another Region?

A: No. The AMI must first be copied to the destination Region.

1. Q: What does an EBS-backed AMI contain?

A: Launch metadata and block device mappings that reference the snapshots needed to create the instance’s EBS volumes.

1. Q: Does an AMI include the source instance’s security groups?

A: No. Security groups are selected during instance launch.

1. Q: What happens to associated snapshots when an AMI is deregistered?

A: They remain and must be deleted separately if they are no longer needed.

1. Q: Can an AMI be used to launch instances in another AZ in the same Region?

A: Yes. The AMI’s snapshots are Regional, and new EBS volumes are created in the selected AZ.

1. Q: Is an AMI continuous replication?

A: No. It is a point-in-time image used for repeatable launches.

1. Q: What AWS service can automate standardized AMI builds?

A: EC2 Image Builder.

Practice Questions

Question 1

A company has a customized EC2 web server in us-east-1c. The solutions architect must launch identical instances in us-east-1a and us-east-1b without rebuilding the operating system and application manually. What is the simplest solution?

A. Attach the existing EBS root volume to instances in the other Availability Zones.
B. Create an AMI from the web server and launch instances from that AMI in the target Availability Zones.
C. Copy the EBS volume to Amazon S3 and restore it in each Availability Zone.
D. Assign the source instance’s private IP address to instances in the other Availability Zones.

Correct answer: B

Explanation: EBS volumes are tied to an Availability Zone, so the original root volume cannot simply be attached elsewhere. An EBS-backed AMI uses snapshots to create new volumes in the selected Availability Zone within the same Region.

Question 2

A disaster recovery design requires an EC2 workload currently deployed in eu-west-1 to be restorable in eu-central-1. Which action is required for the AMI?

A. Change the AMI’s Availability Zone attribute.
B. Copy the AMI to eu-central-1.
C. Share the AMI with the destination subnet.
D. Create an Elastic IP in eu-central-1 and associate it with the original AMI.

Correct answer: B

Explanation: AMIs are Region-specific. The AMI must be copied to the destination Region before it can be used to launch an instance there. Other dependent resources, such as networking and application data, must also be prepared separately.

Question 3

An operations team deregisters an obsolete AMI but notices that EBS snapshot storage costs continue to increase. What is the most likely explanation?

A. Deregistering an AMI automatically converts its snapshots to cold storage.
B. AMI snapshots are retained and must be deleted separately.
C. Deregistering an AMI creates a new full snapshot.
D. Snapshots are charged only when an AMI is registered, so the charges must be from security groups.

Correct answer: B

Explanation: Deregistering an AMI removes its registration but does not delete the associated EBS snapshots. The snapshots must be identified and deleted separately after confirming that no backup or recovery process still requires them.

Question 4

A team launches an instance from a custom AMI and expects it to use the same security group and subnet as the source instance. The new instance instead launches with different networking settings. What explains this behavior?

A. AMIs store only the source instance’s public IP address.
B. Security groups and subnet placement are launch-time settings and are not embedded in the AMI.
C. AMIs can only launch in the default VPC.
D. EBS snapshots cannot be used with security groups.

Correct answer: B

Explanation: An AMI captures the operating system, installed software, EBS-backed storage layout, and launch metadata related to the image. Subnet, security group, IP addressing, and IAM role choices are supplied during launch or through a launch template.