Cloud / Amazon EBS (Elastic Block Storage) Interview questions

Amazon Elastic Block Store (EBS) is a block-level storage service that gives EC2 instances persistent volumes. A volume shows up in the operating system as a raw disk, so you format it with a file system (ext4, XFS, NTFS) or hand it directly to a database.

Data lives independently of the instance. If you stop or even terminate the instance, a non-root volume keeps its data unless you delete it.

• Volumes are tied to a single Availability Zone and attach to instances in that same AZ.
• You choose size and volume type (SSD or HDD) based on your IOPS and throughput needs.
• You can back volumes up with snapshots stored durably in S3-managed storage.
• Volumes can be resized and retuned while in use with Elastic Volumes.

Typical uses are boot disks, relational and NoSQL databases, and big-data or log-processing workloads that need disk-like access.

EBS volumes fall into three groups: SSD-backed, HDD-backed, and the legacy magnetic type.

SSD volumes are optimized for IOPS (small random I/O). HDD volumes are optimized for MiB/s throughput on large sequential I/O, and st1/sc1 cannot be used as boot volumes.

gp3 is the current default EBS volume type. It balances price and performance for a wide range of workloads such as boot volumes, dev/test environments, and small to mid-sized databases.

Every gp3 volume includes a baseline of 3,000 IOPS and 125 MiB/s no matter how large it is. You can provision more of either independently of capacity, up to 80,000 IOPS and 2,000 MiB/s, and sizes now reach 64 TiB (the limits were raised in September 2025).

Because IOPS and throughput are decoupled from size, you no longer have to buy extra gigabytes just to get more performance, which was the gp2 pain point. Per-GB price is also about 20% lower than gp2.

Provisioned IOPS SSD volumes (io2 Block Express and the older io1) are the highest-performance EBS volumes. You specify the exact IOPS you need and EBS delivers it consistently with low latency.

io2 Block Express supports up to 256,000 IOPS, 4,000 MiB/s, and 64 TiB per volume, with sub-millisecond average latency on Nitro instances. It also offers 99.999% durability, versus 99.8-99.9% for other types. Since April 30, 2025, every io2 volume runs on Block Express.

They suit mission-critical databases such as SAP HANA, Oracle, and SQL Server. They are also the only types that support Multi-Attach. Expect to pay noticeably more than gp3.

Both are HDD-backed volumes built for large, sequential I/O where MiB/s matters more than IOPS. They use a burst-bucket model tied to volume size.

Size range is 125 GiB to 16 TiB. Neither can be a boot volume, and both perform poorly for small random reads, so do not put databases on them.

An EBS snapshot is a point-in-time backup of a volume, stored in Amazon S3 (managed by AWS, so you will not see it in your buckets). Snapshots are incremental: the first one copies all used blocks, and later ones store only blocks that changed.

Snapshots are regional, not tied to an AZ, which makes them the standard way to restore a volume in a different AZ, copy data to another Region, or share it with another account. You can also register a snapshot of a root volume as an AMI.

aws ec2 create-snapshot \
  --volume-id vol-0abc1234def567890 \
  --description "nightly backup"

EBS-optimized instances have dedicated bandwidth between the EC2 instance and EBS, so storage traffic does not compete with normal network traffic. That gives more consistent I/O performance.

Almost all current-generation instances are EBS-optimized by default at no extra charge, and Nitro-based types get this through the Nitro card. Older types needed the option turned on and sometimes cost extra.

Each instance type also has its own maximum EBS bandwidth and IOPS. If those are lower than what your volumes can deliver, the instance becomes the bottleneck.

The volume and the instance must be in the same Availability Zone, and the volume must be in the available state. Then attach it from the console (Actions > Attach volume) or the CLI, and pick a device name.

aws ec2 attach-volume \
  --volume-id vol-0abc1234def567890 \
  --instance-id i-0123456789abcdef0 \
  --device /dev/sdf

Attaching is not the last step. Inside the OS you still need to find the device (lsblk), create a file system if it is new (mkfs), and mount it. On Nitro instances the device appears as /dev/nvme1n1 rather than /dev/sdf.

EBS volumes are replicated automatically across multiple servers within one Availability Zone, so a single hardware failure does not lose data.

Replication stays inside the AZ. If the whole AZ fails, the volume is unavailable, so snapshots (regional) are your defense. For higher resilience, copy snapshots to another Region.

DeleteOnTermination controls whether an EBS volume is deleted automatically when its EC2 instance is terminated.

• Root volume: defaults to true, so it disappears with the instance.
• Additional volumes: default to false, so they survive termination.

Set it to false on a root volume if you need to keep the OS disk for forensics. The flag can be changed on a running instance:

aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'

Forgotten volumes that stay behind are a common source of silent EBS cost.

EBS encryption protects data at rest, data in transit between the instance and the volume, and the snapshots created from it. It uses AES-256 with keys managed in AWS KMS, either the AWS managed key (aws/ebs) or your own customer managed key.

You do not manage anything in the guest OS, and the performance impact is minimal on supported instance types. Snapshots of an encrypted volume are encrypted, and volumes made from them are too.

You can turn on EBS encryption by default per Region in an account, so every new volume is encrypted automatically.

The root volume is the EBS volume that holds the operating system an instance boots from. It is created from the AMI's root snapshot when you launch an EBS-backed instance.

Only SSD volume types (gp2, gp3, io1, io2) and legacy magnetic can be boot volumes. You can enlarge it, change its type, or snapshot it at any time. Because it is EBS-backed, the instance can be stopped and started without losing the OS state, unlike instance-store-backed instances.

By default the root volume is deleted when the instance terminates.

Multi-Attach lets a single io1 or io2 volume be attached to up to 16 Nitro-based instances in the same Availability Zone at once. Every instance gets full read and write access.

EBS does not coordinate the writes. You need a cluster-aware file system (or an application that manages concurrent access), because ordinary ext4 or XFS would corrupt when written from many hosts.

• Same AZ only.
• Not supported on the root volume.
• Supported on io1/io2, not gp3 or HDD types.

Typical use cases are clustered databases and high-availability designs that need fast failover.

Elastic Volumes is the feature that lets you change a volume's size, type, IOPS, and throughput while it is attached and in use, with no detach and no downtime for current-generation instances.

After you request a change, the volume moves through modifying and optimizing states before showing completed. It is usable during optimizing, though performance may be in between the old and new settings.

aws ec2 modify-volume \
  --volume-id vol-0abc1234def567890 \
  --volume-type gp3 --size 500 --iops 6000

Two rules to remember: you can only increase size, and you must wait about 6 hours (or until optimization ends) before modifying the same volume again. After growing, extend the partition and file system inside the OS.

IOPS is the number of read/write operations per second. Throughput is the amount of data moved per second, in MiB/s. They are linked by I/O size:

Throughput = IOPS x I/O size

A database doing many small 8-16 KiB reads is limited by IOPS. A backup job streaming 1 MiB blocks is limited by throughput. That is why SSD volumes are rated by IOPS (measured at 16 KiB) and HDD volumes by MiB/s (measured at 1 MiB).

Whichever limit you hit first, volume or instance, caps performance.

An EBS volume exists in exactly one Availability Zone, and it can be attached only to instances in that same AZ. You cannot attach it across AZs or Regions directly.

To move data, take a snapshot (a regional object), then create a new volume from it in the target AZ. For another Region, copy the snapshot first.

This also shapes HA design: an AZ outage makes its volumes unreachable. Spread instances across AZs and rely on snapshots, replication at the application layer, or a shared service like EFS.

Amazon Data Lifecycle Manager (DLM) automates creating, retaining, copying, and deleting EBS snapshots and EBS-backed AMIs through policies, so you do not need cron jobs or Lambda scripts.

A policy targets resources by tags (for example Backup=daily), sets a schedule such as every 12 or 24 hours, and defines retention by count or age. Policies can also copy snapshots to another Region or account, and move them to the archive tier.

For central backup across many AWS services with reporting and compliance, AWS Backup is the broader option. DLM is simpler when the need is EBS only.

Snapshot Archive is a low-cost storage tier for snapshots you rarely need, priced roughly 75% below the standard tier.

• Archived snapshots are stored as full copies, not incrementally.
• Minimum retention is 90 days, and early deletion is charged for the remainder.
• Restoring takes 24 to 72 hours, so it is not for quick recovery.

It fits compliance backups, end-of-project data, and old monthly or yearly copies. Keep your recent snapshots in the standard tier for fast restores. The switch can be done manually or by a DLM policy.

Both give an EC2 instance block storage, but persistence and location differ.

Use instance store for caches, scratch data, and replicated systems that can rebuild themselves. Use EBS for anything you cannot afford to lose.

The main difference is how performance is tied to size. gp2 links IOPS to capacity, while gp3 lets you set them independently.

With gp2, a 100 GiB volume gets only 300 baseline IOPS. To reach 3,000 you had to allocate 1,000 GiB. gp3 gives 3,000 at any size, so most gp2 volumes can be migrated with Elastic Volumes for lower cost and better performance.

Each gp2 volume earns I/O credits at its baseline rate of 3 IOPS per GiB. Volumes smaller than 1,000 GiB can spend credits to burst up to 3,000 IOPS. The bucket holds up to 5.4 million credits and starts full.

Example: a 100 GiB volume has a baseline of 300 IOPS. Bursting at 3,000 drains credits at 2,700 per second, so a full bucket lasts about 2,000 seconds (roughly 33 minutes). After that, it drops to 300 IOPS until credits refill.

Volumes at 1,000 GiB or larger have a baseline of 3,000 or more, so they never need bursting. Watch the BurstBalance CloudWatch metric. A steady fall to 0% explains sudden database slowdowns, and moving to gp3 removes the issue.

gp3 is cheaper per GB and gives more predictable performance, so there is rarely a reason to choose gp2 for new volumes.

1. Lower cost: about 20% less per GB than gp2.
2. No burst cliff: 3,000 IOPS and 125 MiB/s are always available, not credit-based.
3. Independent tuning: pay for extra IOPS or throughput without buying unused capacity.
4. Higher ceilings: up to 80,000 IOPS and 2,000 MiB/s.

One caveat: a very large gp2 volume (say 5 TiB) already has 15,000 IOPS baseline, so compare costs, since matching that on gp3 needs paid extra IOPS. Even then the migration is a no-downtime modify-volume call.

The first snapshot of a volume stores all blocks in use. Each later snapshot stores only blocks that changed since the previous snapshot and points to older snapshots for everything unchanged.

flowchart LR
 V["Volume blocks A B C D"] --> S1["Snapshot 1: A B C D"]
 V2["B changed to B2"] --> S2["Snapshot 2: only B2, refs A C D"]
 V3["E added"] --> S3["Snapshot 3: only E, refs earlier blocks"]
 S1 --> S2 --> S3

Each snapshot is still independently restorable: EBS reconstructs the full volume from the chain of references. That means you pay for unique changed data, not for the volume size each time. Deleting an older snapshot never breaks a newer one, because EBS keeps the blocks that newer snapshots still need.

Only the blocks that no other snapshot references are removed. Blocks needed by later snapshots are moved to remain available, so every remaining snapshot still restores in full.

This means deleting one snapshot may free little storage, especially if data changes slowly. Expect the cost drop to match the unique data that snapshot held.

• You cannot delete a snapshot that backs a registered AMI. Deregister the AMI first.
• Deleted snapshots can be recovered if a Recycle Bin rule covers them.
• Snapshot deletion is safe for the chain but is permanent otherwise.

EBS has no direct move. You go through a snapshot, because snapshots are regional.

1. Snapshot the volume (pause writes or unmount for a clean copy).
2. Create a new volume from that snapshot, choosing the target AZ.
3. Attach the new volume to an instance in that AZ and mount it.

aws ec2 create-volume \
  --snapshot-id snap-0123456789abcdef0 \
  --availability-zone us-east-1b \
  --volume-type gp3

For a whole instance, create an AMI and launch it in the other AZ. Changes made after the snapshot are not included, so plan a final cutover snapshot.

Use the copy operation, run against the destination Region, naming the source Region and snapshot ID.

aws ec2 copy-snapshot \
  --region eu-west-1 \
  --source-region us-east-1 \
  --source-snapshot-id snap-0123456789abcdef0 \
  --encrypted --kms-key-id alias/dr-key

The first copy transfers all blocks, later copies to the same destination are incremental. You can encrypt an unencrypted snapshot during the copy, or re-encrypt it with a different KMS key. Encrypted snapshots need a key that exists in the destination Region.

Cross-Region copies underpin disaster recovery and moving workloads. Time-based copy can guarantee a completion window of 15 minutes to 48 hours.

You cannot flip encryption on for a volume in place. Instead, create an encrypted copy through a snapshot.

1. Snapshot the unencrypted volume.
2. Copy the snapshot and choose Encrypt, selecting a KMS key.
3. Create a new volume from the encrypted copy in the same AZ as the instance.
4. Stop the instance, detach the old volume, attach the new one under the same device name, and start it.

Alternatively, launch a new instance from an AMI copy made with encryption on. Once the volume is encrypted, it cannot be converted back to unencrypted. To avoid this chore for future volumes, enable EBS encryption by default in the Region.

EBS uses envelope encryption. When you create an encrypted volume, EBS asks KMS for a unique data key under your chosen KMS key. The data key is stored, encrypted, alongside the volume metadata.

On attach, EBS calls KMS to decrypt the data key using the caller's permissions and loads the plaintext key into the host that runs the instance. Data is then encrypted and decrypted transparently between the instance and the volume, and never leaves the volume unencrypted at rest.

• The IAM role or user needs kms:CreateGrant, kms:Decrypt, and kms:GenerateDataKeyWithoutPlaintext on the key.
• Disabling or deleting the key makes the volume unreadable.
• Snapshots inherit the volume's data key.

A common failure is an instance failing to launch because its role lacks permission on a customer managed key.

A volume created from a snapshot is available immediately, but its blocks are lazily loaded from S3 the first time each block is accessed. That first touch has higher latency than a normal read.

The effect is visible on databases or freshly launched fleets that scan many blocks right after restore. Newly written blocks are not affected, only blocks not yet fetched.

• Initialize manually: read every block, for example with fio or dd, before production use.
• Fast Snapshot Restore (FSR): enable on the snapshot for full performance from the first I/O.
• Volume initialization rate: set a target rate when creating the volume, for predictable warm-up.

Fast Snapshot Restore (FSR) pre-warms a snapshot in the AZs you pick, so volumes created from it deliver full provisioned performance immediately, with no lazy-loading delay.

You enable it per snapshot per AZ. It is billed for every hour it stays enabled in each AZ, and each Region has a limit on the number of FSR-enabled snapshots, so treat it as selective.

• Good fit: launching many instances from one golden AMI snapshot, disaster recovery drills, large database restores with tight RTO.
• Poor fit: rare restores or dev volumes, where the cost buys nothing.

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Use Elastic Volumes to grow the volume, then extend the partition and file system inside the OS. Neither step needs a reboot.

1. Modify the volume size in the console or with modify-volume.
2. Wait until the state is optimizing or completed.
3. Grow the partition, then the file system.

lsblk
sudo growpart /dev/nvme0n1 1
sudo xfs_growfs -d /        # XFS
# sudo resize2fs /dev/nvme0n1p1   # ext4

Take a snapshot first as a safety net. Remember that size can never be reduced, and the next modification on the same volume must wait about 6 hours.

EBS only supports growing a volume. The service cannot know which blocks the file system still uses, and shrinking would risk cutting data, so the API refuses a smaller size.

The workaround is to copy the data to a smaller volume:

1. Create a new, smaller volume and attach it to the instance.
2. Format it and copy the data, using rsync -aHAX for Linux.
3. Verify, then switch mount points (or swap the volume) and detach the old one.
4. Snapshot the old volume, then delete it after a safe waiting period.

The file system must fit the smaller size, so trim unused data first. Windows and some LVM setups can shrink the partition, but that does not reduce the EBS bill unless a new volume replaces the old one.

With Multi-Attach, the same io1/io2 volume is exposed as a block device to several Nitro instances in one AZ. The volume accepts I/O from all of them and does not arbitrate writes.

flowchart TD
 V[(io2 Multi-Attach volume)]
 A["Instance A"] --> V
 B["Instance B"] --> V
 C["Instance C"] --> V
 V --> F["Cluster-aware FS or app-level locking"]

io2 Block Express also supports I/O fencing (NVMe reservations) so a cluster manager can block a failed node from writing.

Pick io2 Block Express when a single volume must exceed what gp3 can give or when a stricter guarantee is required. Otherwise gp3 is cheaper and enough.

Typical choices for io2: SAP HANA, Oracle or SQL Server production databases where IOPS above 80,000, consistent latency, or Multi-Attach for clustering is required. If your workload stays under 80,000 IOPS with millisecond tolerance, start on gp3 and measure.

Choose st1 when data is large, read and written in big sequential chunks, and cost per GB matters more than IOPS.

• Log processing, Kafka brokers, MapReduce and Hadoop data nodes, ETL staging, data warehouse scans.
• You need up to 500 MiB/s per volume at a low price per GB.

Avoid st1 for boot volumes, small random I/O, or databases, since it caps at 500 IOPS (measured with 1 MiB I/O). For that pattern gp3 is far better even if it costs more per GB.

Also note that gp3 can now deliver up to 2,000 MiB/s, so for high throughput needs on smaller datasets gp3 may be both simpler and competitive. Compare price per GB against your actual throughput target before choosing.

Work from the volume outward and check each limit that could cap I/O:

1. Volume limits: compare VolumeReadOps + VolumeWriteOps and throughput against provisioned IOPS and MiB/s. For gp2, st1, and sc1, check BurstBalance.
2. Queue depth: a consistently high VolumeQueueLength means the volume cannot keep up.
3. Instance limits: confirm the instance type's EBS bandwidth and IOPS are not lower than the volume's.
4. Snapshot initialization: restored volumes may still be lazily loading blocks.
5. Modification in progress: an optimizing volume may be temporarily slower.
6. I/O pattern: small I/O hits IOPS limits, large I/O hits throughput limits.

Use iostat -x 1 in Linux to see latency and utilization. Often the cure is moving gp2 to gp3, raising provisioned IOPS, or picking a larger instance.

EBS publishes volume metrics to CloudWatch in the AWS/EBS namespace, at 1-minute periods for volumes on Nitro instances (5 minutes otherwise).

Alarm on BurstBalance, queue length, and idle time to catch slowdowns and waste.

EBS already replicates each volume inside its AZ, so RAID is used to change performance or capacity, not as your main safety net.

Use RAID 0 to exceed a single volume's limits, though gp3's 64 TiB, 80,000 IOPS ceiling and io2's 256,000 IOPS make it less common now. It is still limited by the instance's EBS bandwidth.

AWS discourages RAID 5 and 6, since parity writes eat a large share of the IOPS you pay for. Whatever you choose, keep snapshots, and note that stripes need coordinated snapshots (multi-volume snapshots) to stay consistent.

A snapshot captures data on disk, so it is crash-consistent by default, like a sudden power loss. Data still in memory or in-flight transactions may be missing. Applications like databases need extra steps for application consistency.

1. Quiesce the application: flush buffers, put the database in backup mode, or lock tables.
2. Freeze the file system with fsfreeze (Linux) or use VSS (Windows).
3. Start the snapshot. Once the API confirms it has begun, you can resume writes.
4. Unfreeze and resume normal operation.

sudo fsfreeze -f /data
aws ec2 create-snapshot --volume-id vol-0abc1234def567890
sudo fsfreeze -u /data

For automation, Data Lifecycle Manager supports pre and post scripts through Systems Manager, and create-snapshots with an instance target takes crash-consistent snapshots of all volumes at the same moment.

Modify the snapshot's createVolumePermission to add the target account ID, then the other account can create volumes from it or copy it.

aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission \
  --operation-type add --user-ids 123456789012

• Unencrypted snapshots can be shared with specific accounts or made public (avoid public).
• Encrypted snapshots can only be shared if encrypted with a customer managed KMS key, and that key must also be shared with the recipient. The default aws/ebs key cannot be shared.

The recipient should copy the snapshot into their own account (and re-encrypt with their own key), so they do not lose access if you revoke sharing. Turn on block public access for snapshots to prevent accidents.

It depends on the action and the volume's settings:

Instance store volumes, in contrast, are wiped on stop or terminate. A stopped instance costs nothing for compute but you still pay for provisioned EBS storage, so delete leftover volumes and snapshots you no longer need.

Attach the broken root volume to a healthy rescue instance in the same AZ, fix or copy files, then put it back.

1. Snapshot the root volume as a safety copy.
2. Stop the broken instance (not terminate).
3. Detach its root volume and attach it to the rescue instance as a secondary device, such as /dev/sdf.
4. Mount it, then repair /etc/fstab, SSH keys, or logs, or copy out the data.
5. Unmount, detach, reattach to the original instance using its root device name (e.g. /dev/xvda), and start it.

Common causes are a bad fstab entry, a full disk, broken SSH configuration, or a kernel issue. Newer options include EC2 Serial Console, Systems Manager Automation runbooks, and the replace root volume feature.

EBS bills for provisioned GB, IOPS, and throughput, plus stored snapshot data, whether or not you use them. Savings come from removing waste:

1. Migrate gp2 to gp3 for roughly 20% lower per-GB cost with better baseline performance.
2. Delete unattached volumes (state available) and volumes with near-zero VolumeIdleTime activity.
3. Right-size IOPS and throughput on gp3 and io2 using CloudWatch data or Compute Optimizer recommendations.
4. Expire old snapshots with Data Lifecycle Manager retention, and move long-term ones to the Snapshot Archive.
5. Use st1/sc1 for cold, sequential data.
6. Tag volumes so Cost Explorer can attribute spend to teams.

Since volumes cannot shrink, avoid oversizing at creation. Delete leftover snapshots after deregistering AMIs.

Recycle Bin holds deleted EBS snapshots and EBS-backed AMIs for a retention period you define, so you can restore them instead of losing them.

• Create retention rules for a Region or tag-matched resources.
• Retention runs from 1 day to 1 year.
• Restore a resource with a console click or restore-snapshot-from-recycle-bin.
• Items in the bin are billed at the normal rate and are purged after the period ends.

It covers snapshots and AMIs, not volumes, so keep snapshots current for volume protection. Use IAM policies and rule locks so nobody can shorten or delete the retention rule.

A volume moves through a small set of states as you create, use, and delete it.

stateDiagram-v2
 [*] --> creating
 creating --> available
 available --> in_use: attach
 in_use --> available: detach
 available --> deleting: delete
 deleting --> deleted
 creating --> error
 deleted --> [*]

• creating: being provisioned, possibly from a snapshot.
• available: ready but not attached, still billed.
• in-use: attached to an instance, even when the instance is stopped.
• deleting / deleted: being removed, then gone permanently.
• error: a failure during creation.

Detach cleanly by unmounting first. Snapshots taken while the volume is in any of these usable states remain after the volume is deleted.

After attaching, format the disk if it is new, mount it, and add an /etc/fstab entry so it mounts after a reboot.

lsblk
sudo file -s /dev/nvme1n1        # 'data' = no file system yet
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /data && sudo mount /dev/nvme1n1 /data
sudo blkid /dev/nvme1n1          # copy the UUID
echo &#x27;UUID=<uuid> /data xfs defaults,nofail 0 2&#x27; | sudo tee -a /etc/fstab
sudo mount -a                    # test fstab

Use the UUID, not the device name, because NVMe names can change between reboots. Add nofail so a missing volume does not stop the instance booting. Skip mkfs for a volume restored from a snapshot, or you erase its data.

EBS direct APIs let you read and write snapshot contents at the block level over the API, without creating a volume from the snapshot. Blocks are 512 KiB.

Useful for third-party backup tools doing efficient incremental copies, for reading diffs to speed up cross-account or on-premises backups, and for importing disk images as snapshots. Access needs the ebs: IAM actions.

They are three storage models for different access patterns.

Pick EBS for low-latency single-host storage, EFS when many Linux instances need the same file tree, and S3 for durable, cheap object storage accessed by applications.

Use EBS Snapshot Lock, which makes a snapshot immutable for a set duration so no one can delete it, including compromised admin credentials.

Lock durations run from 1 day up to about 100 years. Pair it with Recycle Bin rule locks, cross-account and cross-Region copies, and tight IAM policies on ec2:DeleteSnapshot. Store copies in a separate backup account so one breach cannot reach every copy.

Each type has a maximum IOPS-to-size ratio, so a target IOPS sets a minimum size.

For throughput on gp3, the ceiling is 0.25 MiB/s per provisioned IOPS, so reaching 1,000 MiB/s requires at least 4,000 IOPS. Then confirm the instance type can carry that load.

This is why gp3 replaced gp2: 10,000 IOPS on gp2 needs about 3,334 GiB, but only 20 GiB on gp3.