Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon Elastic Block Store (Amazon EBS) provides persistent block storage for Amazon EC2. This lesson focuses on how EBS volumes, snapshots, and Amazon Machine Images (AMIs) relate to one another, especially when copying data across Availability Zones or Regions, sharing resources between AWS accounts, and changing encryption states.
These operations are common in migration, disaster recovery, account separation, golden-image management, and cross-Region deployment scenarios.
Key Concepts
EBS volumes are Regional-service-backed block storage
An EBS volume is a block device attached to an EC2 instance. Although the data is accessed over the AWS network, EBS is not a shared file system such as Amazon EFS or FSx. A volume is normally attached to an EC2 instance in the same Availability Zone.
To use the data in another Availability Zone, create a snapshot and then create a new volume from that snapshot in the target Availability Zone.
EBS snapshots
An EBS snapshot is a point-in-time backup of a volume. Snapshots are stored in Amazon S3 and are associated with a Region rather than a specific Availability Zone.
Important characteristics:
- Later snapshots are incremental: they record blocks changed since the previous snapshot.
- Each snapshot can be used to restore a complete volume because AWS maintains the required snapshot chain behind the scenes.
- A snapshot can be copied to another Region.
- A volume created from a snapshot can be placed in a different Availability Zone within the same Region.
- Snapshot storage is based on the data required by the snapshots, not simply the apparent size of each snapshot.
Deleting snapshots can reduce storage usage, but retain the recovery points required by your backup and compliance policies. AWS manages the underlying dependencies when snapshots are deleted.
Creating volumes from snapshots
A snapshot can be used to create an EBS volume:
- In another Availability Zone in the same Region.
- As an encrypted volume, even when the source snapshot is unencrypted.
- With a selected KMS key when encryption is enabled.
Creating a volume from a snapshot does not move the volume directly. It creates a new volume populated from the snapshot data.
AMIs and EBS snapshots
An EBS-backed AMI references one or more snapshots that contain the root and additional EBS volumes needed to launch an EC2 instance. Consequently, the encryption characteristics of the snapshots affect the AMI and the instances launched from it.
An AMI can be copied to another Region. Copying an AMI creates a new AMI and backing snapshots in the destination Region; it is not merely a metadata operation.
Encryption transitions
AWS supports several useful encryption workflows:
- An unencrypted snapshot can be copied to create an encrypted snapshot.
- An unencrypted snapshot can be used to create an encrypted volume.
- An unencrypted snapshot can be used to create an unencrypted AMI, but it cannot directly produce an encrypted AMI through that relationship.
- An encrypted snapshot can be copied while changing the KMS key and, optionally, the Region.
- An encrypted snapshot can be used to create an encrypted volume in another Availability Zone.
- An unencrypted AMI can launch an encrypted EC2 instance by enabling EBS encryption during launch and selecting an appropriate key.
- An encrypted AMI can be copied as an encrypted AMI, with the destination Region and KMS key changed.
Always distinguish between encrypting the source artifact and enabling encryption on the newly created artifact. The operation and destination determine which choices are available.
Sharing encrypted AMIs
An unencrypted AMI can be shared with specific AWS accounts and can also be made public, subject to AWS sharing controls and security considerations.
An encrypted AMI cannot be made public. To share an encrypted AMI with another account:
- Use a customer managed KMS key rather than relying on a key the recipient cannot use.
- Update the KMS key policy or grant the receiving account permission to use the key.
- Share the AMI with the target account.
- Ensure the recipient has the required permissions to describe, copy, or launch the AMI and use the backing snapshots.
Sharing an AMI does not automatically grant access to the KMS key that encrypts its snapshots. KMS permissions are a separate control plane concern.
A common remediation is to copy the encrypted AMI using a customer managed key, then share the copied AMI and grant the recipient access to that key.
Architecture Decision Guide
| Requirement | Recommended approach | Important consideration |
|---|---|---|
| Move EBS data to another Availability Zone | Create a snapshot, then create a volume in the target AZ | EBS volumes are AZ-scoped; the snapshot is Regional |
| Back up an EBS volume | Create scheduled EBS snapshots | Define retention, recovery point, and recovery time objectives |
| Reduce snapshot storage | Remove snapshots no longer needed | Validate retention and compliance requirements first |
| Copy data to another Region | Copy the snapshot to the destination Region | Cross-Region copying incurs transfer and storage costs |
| Encrypt an existing unencrypted snapshot copy | Copy the snapshot and enable encryption | Select the destination KMS key where appropriate |
| Create an encrypted volume from unencrypted data | Create the volume from the snapshot with encryption enabled | The source snapshot remains unencrypted |
| Distribute an EC2 golden image across Regions | Copy the AMI to each target Region | The copy creates destination-region AMI and snapshot resources |
| Share an encrypted AMI with another account | Use a customer managed KMS key and grant cross-account key access | AMI sharing alone is insufficient |
| Publish an image publicly | Use an unencrypted AMI only when public distribution is acceptable | Never expose sensitive data through a public AMI |
| Change the encryption key | Copy the encrypted snapshot or AMI using the destination KMS key | KMS key permissions must be valid in the relevant account and Region |
Exam-Relevant Takeaways
- EBS volumes are tied to an Availability Zone; snapshots are Regional.
- A snapshot is incremental, but every snapshot remains a usable restore point.
- Cross-AZ EBS movement uses a snapshot and a new volume.
- Cross-Region movement requires copying the snapshot or AMI to the destination Region.
- An unencrypted snapshot can be copied into an encrypted snapshot.
- An unencrypted snapshot can create an encrypted EBS volume.
- An encrypted AMI cannot be shared publicly.
- Cross-account use of encrypted AMIs requires access to the customer managed KMS key used for encryption.
- Copying an encrypted snapshot or AMI can provide a mechanism to change the KMS key.
- Encryption settings apply to the newly created resource; they do not retroactively encrypt the original snapshot or volume.
- AMI copies are Region-specific resources with their own backing snapshots.
Common Exam Traps
- Confusing EBS with EFS: EBS is block storage for an instance, while EFS is a shared file system designed for concurrent access from multiple instances.
- Treating snapshots as Availability Zone resources: Snapshots are Regional and can be used to create volumes in another AZ in that Region.
- Assuming incremental snapshots cannot stand alone: Although storage is incremental, each snapshot can restore the volume state represented by that point in time.
- Assuming AMI sharing includes KMS permissions: An encrypted AMI’s recipient also needs permission to use the customer managed KMS key.
- Assuming encrypted AMIs can be public: Encrypted AMIs cannot be publicly shared.
- Assuming a snapshot copy changes the source: Copying creates a separate snapshot; encryption and KMS-key changes apply to the copy.
- Forgetting the Region boundary: A volume cannot be directly moved to another Region. Copy the snapshot or AMI first, then create the destination resource.
- Deleting snapshots solely based on their apparent age: Snapshot deletion must align with backup retention, legal, and recovery requirements.
Real-World Engineer Notes
- Automate snapshot and AMI creation with Amazon Data Lifecycle Manager, AWS Backup, or an equivalent operational process where appropriate.
- Use customer managed KMS keys when encrypted artifacts must be shared across accounts or when key ownership and rotation policies matter.
- Plan KMS key policies, IAM permissions, and organization-level controls together. A valid AMI share without valid KMS access still fails at launch or copy time.
- For disaster recovery, copy snapshots or AMIs to the recovery Region and test restoration. A copied backup is not proof of recoverability until the launch and data-validation process succeeds.
- Cross-Region copies incur data transfer and destination storage costs and may take time to complete. Account for this in recovery time objectives.
- Snapshot and AMI operations may require additional permissions beyond basic EC2 permissions, including snapshot, AMI, and KMS actions.
- Avoid public AMIs unless the image is intentionally designed for public distribution and contains no confidential data, credentials, proprietary software, or environment-specific configuration.
Quick Reference Summary
- Volume scope: Availability Zone.
- Snapshot scope: Region.
- Cross-AZ volume move: Snapshot, then create a volume in the target AZ.
- Cross-Region data move: Copy the snapshot, then create the destination volume.
- Snapshot model: Incremental storage with independently usable recovery points.
- Unencrypted snapshot to encrypted snapshot: Supported through snapshot copy.
- Unencrypted snapshot to encrypted volume: Supported at volume creation.
- Encrypted AMI sharing: Supported with customer managed KMS-key access; public sharing is not supported.
- Encryption-key change: Copy the encrypted snapshot or AMI and select another KMS key.
Flashcards
- What is the Availability Zone scope of an EBS volume?
An EBS volume is tied to a specific Availability Zone.
- What is the Region scope of an EBS snapshot?
An EBS snapshot is stored as a Regional resource and is not tied to one AZ.
- How do you move EBS data to another AZ in the same Region?
Create a snapshot and create a new EBS volume from it in the target AZ.
- Are EBS snapshots full copies every time?
No. Later snapshots are incremental, although each snapshot can restore a complete volume state.
- Can an unencrypted snapshot produce an encrypted snapshot?
Yes. Copy the snapshot and enable encryption on the copy.
- Can an unencrypted snapshot produce an encrypted EBS volume?
Yes. Enable encryption when creating the volume.
- Can an encrypted AMI be shared publicly?
No. Encrypted AMIs cannot be made public.
- What is required to share an encrypted AMI cross-account?
Share the AMI and grant the recipient access to the customer managed KMS key used to encrypt its backing snapshots.
- Can an encrypted snapshot copy use a different KMS key?
Yes. The copy operation can change the encryption key.
- Can an EBS volume be directly moved to another Region?
No. Copy its snapshot or AMI to the destination Region and create a new resource there.
- Does deleting an old snapshot necessarily make newer snapshots unusable?
No. AWS manages snapshot dependencies, but deletion should still follow the required retention policy.
- What does an EBS-backed AMI contain conceptually?
AMI metadata plus references to snapshots used for the root and other EBS-backed volumes.
Practice Questions
Question 1
A company has an unencrypted EBS snapshot in us-east-1. It must create an encrypted EBS volume in another Availability Zone in us-east-1, leaving the original snapshot unchanged. Which solution meets the requirement?
A. Copy the volume directly to the target AZ and enable encryption
B. Create a volume from the snapshot in the target AZ and enable encryption during creation
C. Copy the snapshot to another Region, then create the volume
D. Encrypt the original snapshot in place and create the volume
Correct answer: B
Explanation: A snapshot can create a volume in another AZ in the same Region, and encryption can be enabled for the new volume. The original snapshot is not modified. EBS volumes cannot be directly copied between AZs without using a snapshot workflow.
Question 2
A security team needs to share an encrypted EC2 AMI with a separate AWS account. The AMI is encrypted with a key that the receiving account cannot use. What should the architect do?
A. Make the encrypted AMI public
B. Share the AMI only; KMS access is inherited automatically
C. Copy the AMI using a customer managed KMS key and grant the receiving account permission to use that key
D. Convert the AMI to an unencrypted AMI by changing its metadata
Correct answer: C
Explanation: Encrypted AMI sharing requires both AMI sharing and access to the KMS key used by the backing snapshots. A customer managed key can be configured for cross-account use. Encrypted AMIs cannot be public, and encryption cannot be removed by changing AMI metadata.
Question 3
An organization needs to deploy the same EBS-backed golden image in eu-west-1, although the source AMI exists in us-east-1. Which operation is required before launching instances in the destination Region?
A. Attach the source AMI to an EC2 instance in eu-west-1
B. Copy the AMI to eu-west-1
C. Create a volume in eu-west-1 from the source Region’s snapshot without copying it
D. Change the AMI’s Availability Zone attribute
Correct answer: B
Explanation: AMIs are Region-specific. Copying the AMI creates a destination-Region AMI and copies its backing snapshots, after which instances can be launched in that Region.
Question 4
A team believes that deleting an earlier EBS snapshot will always make all later snapshots unusable because later snapshots are incremental. Which statement is most accurate?
A. The team is correct; every snapshot depends directly on all older snapshots
B. Snapshots are incremental, but each snapshot remains a usable recovery point; AWS manages the underlying data dependencies
C. Snapshots are always complete copies, so incrementality is irrelevant
D. Only the oldest snapshot can be restored
Correct answer: B
Explanation: EBS snapshots use incremental storage, but each snapshot represents a restorable point in time. AWS maintains the underlying snapshot data when snapshots are deleted. Retention decisions should still preserve the recovery points required by the organization.
Question 5
A disaster-recovery design copies encrypted EBS snapshots to another Region. The organization wants the destination snapshots encrypted with a different customer managed KMS key. Which approach should be used?
A. Copy the snapshots and select the destination KMS key during the copy
B. Change the source snapshot’s key after copying
C. Create an unencrypted volume first, then attach it to the destination instance
D. Change the Availability Zone of the source snapshot
Correct answer: A
Explanation: Encrypted snapshot copies can be placed in another Region and can use a different KMS key. The source snapshot remains unchanged; the destination copy receives the selected encryption configuration.