Amazon EBS Deployment and Volume Types – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon Elastic Block Store (Amazon EBS) provides persistent block storage for Amazon EC2 instances. This lesson focuses on how EBS volumes are deployed, which instances can attach to them, how volume types differ, and which configuration details commonly appear in SAP-C02 scenarios.

The central design rule is simple: an EBS volume is tied to one Availability Zone (AZ), and an attached EC2 instance must be in the same AZ.

Key Concepts

EBS is Availability Zone scoped

An EBS volume exists in a single AZ. AWS replicates the volume within that AZ to protect against hardware failure, but this does not make the volume automatically available in another AZ.

Consequences:

An EC2 instance and its EBS volume must be in the same AZ.
You cannot directly attach one EBS volume to an instance in another AZ.
To use the data in another AZ, create a snapshot and restore a new volume in the target AZ, or otherwise copy and migrate the data.
EBS is not a cross-AZ shared-storage solution.

For multi-AZ application designs, deploy independent EBS volumes with application-level replication, database replication, or another suitable storage architecture.

An EBS volume can exist independently of an EC2 instance

An EBS volume persists separately from the lifecycle of an EC2 instance. It can be:

Created without being attached to an instance
Detached from one instance
Attached to another compatible instance in the same AZ
Preserved after instance termination, depending on the delete-on-termination setting

An EC2 instance can have multiple EBS volumes attached, allowing separate volumes for the operating system, application data, logs, databases, or temporary working data.

Standard attachment model

The normal EBS model is one volume attached to one EC2 instance. The instance and volume must share an AZ.

EBS Multi-Attach is an exception. It allows a supported Provisioned IOPS SSD volume to be attached to multiple EC2 instances simultaneously. The instances must use Nitro-based systems, remain in the same AZ, and the maximum attachment count is 16 instances. Multi-Attach does not provide a cluster file system or automatic write coordination; the application and file system must be designed for concurrent access.

For current AWS configurations, Multi-Attach is associated with io1 and io2 volumes. Always verify the current regional and service documentation when an exam question depends on a recently introduced capability.

EBS volume categories

EBS volume types fall into three practical groups:

General Purpose SSD: balanced price and performance for most workloads.
Provisioned IOPS SSD: predictable, high IOPS and low latency for demanding transactional workloads.
Throughput-oriented HDD: lower-cost storage for large, sequential data sets where throughput matters more than random IOPS.

#### General Purpose SSD

Volume type	Typical use	Important characteristics
`gp3`	Default choice for most general-purpose workloads	IOPS and throughput can be provisioned independently of capacity; commonly preferred over `gp2` when supported
`gp2`	Legacy general-purpose SSD workloads	Performance is tied to volume size, with burst behavior for smaller volumes; no Multi-Attach

gp3 is often the best starting point when the workload needs configurable performance without increasing capacity just to obtain more IOPS. gp2 remains important for exam questions involving older deployments or size-dependent performance.

#### Provisioned IOPS SSD

Volume type	Typical use	Important characteristics
`io1`	High-performance transactional workloads and legacy Multi-Attach scenarios	Provisioned IOPS, predictable performance, supports Multi-Attach under its constraints
`io2`	High durability and sustained high-performance workloads	Newer generation Provisioned IOPS SSD option; supports Multi-Attach where supported
`io2 Block Express`	Very large, high-IOPS, low-latency workloads	Designed for the highest EBS performance levels on supported Nitro-based instances

Provisioned IOPS volumes are appropriate when the workload requires a defined IOPS level rather than the performance profile of a general-purpose volume. Examples include high-transaction databases and latency-sensitive enterprise applications.

#### HDD volumes

Volume type	Typical use	Important characteristics
`st1` Throughput Optimized HDD	Frequently accessed, large sequential workloads such as big-data processing and log processing	Low-cost, throughput-oriented, not suitable as a boot volume, no Multi-Attach
`sc1` Cold HDD	Infrequently accessed large data sets	Lowest-cost HDD option, lower throughput than `st1`, not suitable as a boot volume, no Multi-Attach

HDD-backed EBS volumes are optimized for sequential access. They are poor choices for workloads dominated by small random reads and writes, even when the capacity price is attractive.

Boot-volume restrictions

EBS-backed EC2 instances require a boot-capable volume. The SSD-backed EBS types can be used as boot volumes, while st1 and sc1 cannot.

A scenario asking for the cheapest EBS option for an operating-system volume should not select a throughput-optimized or cold HDD volume. Choose a suitable SSD-backed type instead.

Delete on termination

The root EBS volume is configured to be deleted when the EC2 instance is terminated by default in common launch configurations. Additional data volumes are generally preserved by default.

This behavior is controlled per volume by the DeleteOnTermination attribute. It can be changed when launching or modifying an instance.

Before terminating an instance, determine whether the volume contains:

Re-creatable operating-system data
Persistent application or database data
Logs required for compliance or investigation
A volume that should be detached and reused

Changing the setting does not create a backup. Use EBS snapshots or another backup mechanism when data must be recoverable.

Architecture Decision Guide

Requirement	Recommended direction	Reasoning or constraint
Standard EC2 operating system or application volume	`gp3`	General-purpose SSD with independently configurable IOPS and throughput
Existing legacy workload using size-based SSD performance	`gp2`	Performance scales with capacity and includes burst behavior
Predictable high IOPS and low latency	`io1` or `io2`	Provisioned IOPS is selected explicitly
Highest supported EBS performance for a very demanding workload	`io2 Block Express`	Requires supported Nitro-based infrastructure and compatible configuration
Large sequential analytics or log-processing workload	`st1`	Throughput-oriented HDD is less expensive than SSD for suitable access patterns
Infrequently accessed large data set	`sc1`	Lower-cost cold HDD option
Boot volume	SSD-backed EBS type	`st1` and `sc1` cannot be boot volumes
Multiple EC2 instances accessing one block volume	Supported `io1` or `io2` Multi-Attach configuration	Nitro-based instances, same AZ, attachment limit, and cluster-aware software are required
Access from instances in different AZs	Snapshot/restore, replication, or a different storage service	Direct cross-AZ EBS attachment is not supported
Preserve data after instance termination	Disable `DeleteOnTermination` or detach the volume	Root and data-volume defaults differ; verify the attribute explicitly

Exam-Relevant Takeaways

EBS volumes are scoped to one AZ.
The EC2 instance and EBS volume must be in the same AZ for attachment.
EBS replication within an AZ does not provide cross-AZ disaster recovery.
Snapshots are the standard mechanism for creating a volume in another AZ or Region.
An EBS volume can remain unattached and outlive its EC2 instance.
gp3 separates provisioned IOPS and throughput from volume capacity.
gp2 performance is linked to volume size and includes burst characteristics.
io1, io2, and io2 Block Express are designed for provisioned, predictable performance.
st1 and sc1 are throughput-oriented HDD types and cannot be used as boot volumes.
Multi-Attach is not a general shared-disk feature. It has volume, instance, AZ, attachment-count, and application-coordination requirements.
Check DeleteOnTermination before terminating an instance that owns important data.

Common Exam Traps

Confusing EBS with a multi-AZ storage service

An EBS volume is not automatically attachable from another AZ. If a question requires cross-AZ access, consider snapshots, replication, Amazon EFS, Amazon FSx, Amazon S3, or another service based on the access protocol and workload.

Choosing HDD because it is cheaper

Cost alone is not enough. st1 and sc1 are appropriate for large sequential workloads, not low-latency random I/O or operating-system boot disks.

Treating Multi-Attach as a shared file system

Multi-Attach exposes the same block device to multiple instances. It does not provide file locking, distributed coordination, or protection against simultaneous conflicting writes. The workload must use a cluster-aware file system or application design.

Assuming all EBS volumes support Multi-Attach

General-purpose SSD and HDD volume types do not support Multi-Attach. The feature is limited to supported Provisioned IOPS SSD types and compatible EC2 infrastructure.

Assuming every volume is deleted with the instance

The root volume and additional volumes commonly have different default deletion behavior. The actual answer depends on DeleteOnTermination, not merely on whether the volume is attached.

Using capacity as a substitute for performance without checking the type

With gp2, increasing capacity also increases baseline performance. With gp3, IOPS and throughput can be configured separately. With Provisioned IOPS types, performance is explicitly provisioned. These distinctions can change both the architecture and the cost.

Real-World Engineer Notes

Treat AZ placement as part of the deployment topology. Automated provisioning should create the volume in the same AZ selected for the instance.
Use tags and lifecycle policies to identify owners, environments, retention requirements, and whether a volume contains recoverable data.
Protect important EBS data with scheduled snapshots, cross-Region snapshot copies where required, and tested restore procedures.
Do not rely on EBS’s within-AZ replication for application-level backup or regional disaster recovery.
Monitor workload behavior before selecting a volume type. Random I/O, sequential throughput, latency, burst usage, and sustained IOPS lead to different choices.
Avoid overprovisioning gp2 capacity solely to gain IOPS when moving to gp3 can provide the required performance more directly.
For databases, validate the database engine’s storage and Multi-Attach behavior rather than assuming that a supported EBS feature is automatically safe.
Confirm current volume limits, maximum IOPS, throughput, and supported instance combinations in AWS documentation because EBS capabilities and quotas evolve.

Quick Reference Summary

Scope: One EBS volume, one AZ.
Normal attachment: One volume to one instance in the same AZ.
Multi-Attach: Supported Provisioned IOPS SSD configuration, Nitro-based instances, same AZ, up to 16 instances, and application-level coordination.
General purpose: gp3 and gp2.
Provisioned IOPS: io1, io2, and io2 Block Express.
Throughput-oriented HDD: st1 and sc1.
Boot restriction: st1 and sc1 cannot be boot volumes.
Persistence: Volumes can exist independently of instances.
Termination behavior: Verify DeleteOnTermination; do not assume it.
Cross-AZ use: Snapshot, restore, replicate, or choose a storage service designed for cross-AZ access.

Flashcards

Q: What is the placement scope of an EBS volume?

A: A single Availability Zone.

Q: What placement rule applies when attaching EBS to EC2?

A: The EC2 instance and volume must be in the same AZ.

Q: How can an EBS volume be used in another AZ?

A: Create a snapshot and restore a new volume in the target AZ, or use an appropriate replication or migration process.

Q: Can an EBS volume exist without an EC2 instance attached?

A: Yes. It can remain unattached until it is needed.

Q: Which general-purpose SSD type allows IOPS and throughput to be configured independently of capacity?

A: gp3.

Q: What is the main performance characteristic of gp2?

A: Baseline performance is tied to volume size, with burst behavior for smaller volumes.

Q: Which EBS types are intended for provisioned IOPS workloads?

A: io1, io2, and io2 Block Express.

Q: Can st1 or sc1 be used as an EC2 boot volume?

A: No.

Q: What does EBS Multi-Attach enable?

A: Attaching one supported EBS Provisioned IOPS SSD volume to multiple compatible EC2 instances in the same AZ.

Q: Does Multi-Attach turn EBS into a shared file system?

A: No. Concurrent access requires suitable cluster-aware software or application coordination.

Q: What happens to a root EBS volume on instance termination by default?

A: It is commonly deleted, subject to the volume’s DeleteOnTermination setting.

Q: What is the typical use case for st1?

A: Large, frequently accessed sequential workloads where throughput matters more than random IOPS.

Practice Questions

Question 1

A company runs an EC2 instance in us-east-1a with an EBS data volume. A new instance in us-east-1b must access the same data. Which approach satisfies the EBS placement constraint?

A. Attach the existing volume directly to the new instance
B. Enable Multi-Attach and attach the volume across AZs
C. Create an EBS snapshot and restore a new volume in us-east-1b
D. Change the volume type to gp3

Correct answer: C

Explanation: EBS volumes cannot be directly attached across AZs. A snapshot can be restored as a new volume in the target AZ. Multi-Attach does not remove the same-AZ requirement.

Question 2

A workload requires a boot volume with low cost and high sequential throughput. Which option is valid for the boot volume?

A. sc1
B. st1
C. gp3
D. Any EBS type, because all EBS volumes support booting

Correct answer: C

Explanation: st1 and sc1 are HDD-backed throughput-oriented volumes and cannot be used as boot volumes. gp3 is an SSD-backed general-purpose choice.

Question 3

A database requires predictable IOPS and low latency. The team wants to specify storage performance independently from capacity. Which EBS category is most appropriate?

A. Provisioned IOPS SSD
B. Cold HDD
C. Throughput Optimized HDD
D. Magnetic archive storage

Correct answer: A

Explanation: Provisioned IOPS SSD volumes such as io1 and io2 are designed for predictable, high-performance transactional workloads. HDD choices prioritize sequential throughput and lower cost.

Question 4

An engineer plans to attach one EBS volume to 10 EC2 instances. The instances are Nitro-based and located in the same AZ. The application uses ordinary file-system access with no cluster-aware locking. What is the primary concern?

A. EBS volumes cannot be attached to more than one instance under any circumstances
B. Multi-Attach requires application or file-system coordination for concurrent writes
C. The instances must be in different AZs for Multi-Attach
D. Only sc1 volumes support Multi-Attach

Correct answer: B

Explanation: A supported Multi-Attach configuration can expose a volume to multiple compatible instances in one AZ, but EBS does not provide general shared-file-system coordination. Unsafe concurrent writes can corrupt data.

Question 5

A data volume contains records that must survive EC2 instance termination. Which action is the most direct configuration change?

A. Set the volume type to st1
B. Enable DeleteOnTermination
C. Disable DeleteOnTermination for the volume
D. Move the instance to another AZ

Correct answer: C

Explanation: Disabling DeleteOnTermination preserves the EBS volume when the instance is terminated. Snapshots should still be used for backup and recovery protection.