Articles

AWS EBS Interview Questions: IOPS, Throughput, Snapshots, and Recovery

Calculate EBS IOPS and throughput limits, diagnose instance bottlenecks, and explain snapshot consistency, initialization, and measurable recovery tests.

An AWS EBS interview question may offer a volume with 3,000 IOPS and ask why the application achieves only 500 operations per second. That can be entirely consistent with the configuration: at 256 KiB per operation, a 125 MiB/s throughput ceiling permits only 500 such operations each second. Buying more IOPS alone does not remove that ceiling.

A strong answer connects two contracts. First, calculate what the workload can demand from the volume and EC2 instance. Second, explain how you would recover usable application data after a failure. Provisioned performance and a completed snapshot are useful evidence, but neither proves that the service meets its latency or recovery objective. Practice the durability part with Design a cloud database write path and recovery.

Evidence boundary: Official EBS and EC2 facts come from AWS documentation checked October 1, 2026. The calculations, incident, and restore acceptance record are original exercises and engineering inference. No AWS benchmark, account configuration, or candidate report is claimed. Validate current limits for the Region, location, volume type, size, and instance you actually use.

How do IOPS and throughput constrain the same workload?

IOPS measures operations per second; throughput measures transferred bytes per second. For a simplified workload with a fixed counted I/O size, multiply the operation rate by that size. Use binary units consistently: one MiB is 1,024 KiB.

This original calculation assumes a volume provisioned at 3,000 IOPS and 125 MiB/s, an instance with sufficient headroom, and no other limiting factor:

Counted I/O size	Bytes implied by 3,000 IOPS	Effective rate under both ceilings
16 KiB	46.875 MiB/s	At most 3,000 IOPS and 46.875 MiB/s
256 KiB	750 MiB/s	At most 500 IOPS and 125 MiB/s

The second row uses 125 × 1024 / 256 = 500. The requested 3,000 IOPS would require six times the available throughput. Raising the IOPS setting without raising throughput does not change this particular bound.

These are upper-bound calculations, not performance promises. Real workloads have varied operation sizes, reads and writes, queueing, caches, and latency. AWS also documents how EBS counts operations, including splitting larger I/O and combining eligible smaller sequential I/O. Therefore application call counts may differ from the volume's counted operations. EBS I/O characteristics.

A good interview answer asks where the reported metric was measured. Database transactions per second, filesystem operations, and EBS IOPS are not interchangeable denominators. A transaction can require several I/O operations or be served partly from memory.

What are the current gp3 limits, and why qualify them?

AWS's current General Purpose SSD guide documents gp3 baseline performance of 3,000 IOPS and 125 MiB/s. It lists maxima of 80,000 IOPS and 2,000 MiB/s, subject to size and provisioning ratios. Those maxima are not the baseline or an entitlement of every small volume. Outposts has separate lower limits: 16,000 IOPS and 1,000 MiB/s. General Purpose SSD volumes.

This matters because older preparation notes often give the former regional maxima as if they were universal current limits. In an interview, say which location and documentation you are using. Then return to the workload, rather than turning the answer into a catalog of every volume type.

For an original planning case, a service requires 8,000 counted operations per second at 16 KiB each. That implies 125 MiB/s before any headroom. A provisioned 125 MiB/s ceiling is exactly the arithmetic requirement; it leaves no allowance for a changed I/O mix or simultaneous maintenance workload.

Our recommendation is to estimate the observed size distribution and peak concurrency, choose explicit headroom, and verify the effective path under a representative test. The appropriate margin depends on the latency objective and workload variation. Do not invent a universal percentage and present it as an AWS recommendation.

Choosing gp3 or a provisioned-IOPS volume also requires the latency and durability requirements. The AWS volume-type comparison provides different designs and capabilities; price and nominal maximum IOPS are insufficient on their own. EBS volume types.

Can the EC2 instance bottleneck several healthy volumes?

Yes. EBS-optimized EC2 instances have their own bandwidth and IOPS characteristics, including baseline and maximum behavior for relevant instance types. Multiple attached volumes share the instance's available EBS path. Summing their individual provisioned ceilings does not prove that the instance can deliver the total. EBS-optimized instance documentation.

Suppose an original exercise assigns two volumes 125 MiB/s each but gives the instance only 200 MiB/s of sustained EBS bandwidth for the scenario. A simultaneous workload requesting 250 MiB/s exceeds the aggregate path, even though neither volume is individually overprovisioned relative to its own limit.

The response should identify the shared ceiling and the measurement window. A brief burst can make a configuration look adequate for a sustained ingestion job. Check whether the stated number is baseline, burst maximum, or a tested steady-state result. Those terms change the capacity argument.

Also examine application concurrency. A synchronous request loop may keep too few operations in flight to use the available performance. In an illustrative steady-state calculation, 3,000 completed operations per second with mean residence time of 2 milliseconds implies about six outstanding operations by Little's law. That is a relationship under stated conditions, not a guarantee that setting queue depth to six will produce 3,000 IOPS.

Increasing queue depth can also increase latency when a downstream ceiling is already saturated. Explain the throughput and tail-latency objectives together. A configuration that maximizes bulk throughput might be inappropriate for a transactional request path.

What should you measure before changing the volume?

Start with a bounded incident description: which request slowed, when it started, whether reads or writes changed, and which volumes carry the relevant data and logs. Our recommended diagnostic sequence compares application latency with volume operations, transferred bytes, queueing, and instance aggregate limits over the same interval.

Consider this original incident. A report export doubles its read size while keeping the same requested operation rate. The application latency rises, CPU remains moderate, and transferred bytes approach the configured throughput ceiling. That evidence supports a throughput hypothesis more strongly than a demand for more IOPS.

Now change the evidence: the volume is well below both configured ceilings, but database lock waits increase. A storage upgrade is no longer the first justified intervention. The symptom “slow database” does not uniquely identify EBS as the bottleneck.

A useful before-and-after record includes workload parameters, operation-size distribution, concurrency, cache state, elapsed interval, throughput, and percentile latency. Keep the test representative. A benchmark using large sequential reads cannot establish small random write performance for a database.

Avoid destructive probes against a mounted production device. For interview purposes, describe an isolated benchmark volume or a controlled application-level workload with bounded traffic. The goal is evidence that discriminates between hypotheses, not a command that happens to produce an impressive number.

Does an incremental snapshot need every earlier snapshot to restore?

EBS snapshots are incremental in how changed blocks are stored, but each snapshot represents a restorable volume state. AWS manages the necessary shared blocks; deleting an earlier snapshot does not remove blocks still needed by another retained snapshot. This is different from manually assembling a chain of application backup files. How EBS snapshots work.

For an original explanation, imagine a volume with three logical blocks. Snapshot S1 represents A, B, C. Later S2 represents A, B2, C. The logical recovery target for S2 includes all three blocks, even though only the changed block needs new snapshot storage. The user does not restore S1 and then manually patch B2 to create the EBS volume.

Do not extend that explanation into “snapshots make application logs unnecessary.” A database may still need its logs to recover transactions or meet an RPO between snapshot times. Block-level backup semantics and application-level recovery are separate contracts.

Retention also needs a business policy. Retaining a technically restorable snapshot from before a schema migration may be insufficient if the matching application version, configuration, or encryption-key access is missing. Our recommendation is to record those dependencies with the recovery point and verify them in a restore exercise.

Is a snapshot automatically application-consistent?

No. AWS states that a snapshot captures data written to the volume when requested; it does not include data still cached by the application or operating system. Snapshot creation is asynchronous. The official guidance recommends pausing writes to obtain a consistent and complete snapshot, with additional considerations for root devices and multi-volume snapshots. Create EBS snapshots.

In an original database scenario, a successful response to a write may depend on the database's durability settings. If essential state remains only in memory when the snapshot is requested, the snapshot cannot preserve it. A snapshot reaching completed later does not change what had been written at the selected point.

Ask what consistency the application requires. A crash-consistent image may allow a database's recovery mechanism to replay a valid log. An application-consistent recovery point may require a supported flush, checkpoint, or quiescing procedure. Use the database's documented backup contract rather than guessing that filesystem capture guarantees transaction consistency.

For data and logs on separate volumes, define how their recovery points are coordinated. Taking two unrelated snapshots at different times can produce a pair the application cannot reconcile. A multi-volume capability still needs to be assessed against the application's own consistency requirements.

Why can a restored volume be slow on first access?

A snapshot-restored volume may need initialization as blocks are fetched. AWS documents manual initialization, fast snapshot restore, and a provisioned initialization rate of 100–300 MiB/s for supported locations. Specifying an initialization rate and using fast snapshot restore are distinct choices; the current guide explains their interaction and restrictions. Initialize EBS volumes.

Our original restore plan separates three milestones: volume created, required data initialized or ready at the chosen performance level, and application validated. Returning a volume identifier proves only the first milestone.

For a simple estimate, 100 GiB of snapshot data at an illustrative 200 MiB/s is about 512 seconds of data initialization. That arithmetic does not include instance launch, attachment, database recovery, validation, or traffic cutover. Use snapshot data size, rather than automatically substituting the provisioned capacity of a sparsely used volume.

Do not promise that every restored volume must be fully read manually. Choose the supported initialization approach according to recovery time, cost, location, and workload. Then measure the restored application's behavior rather than treating initialization progress as the final acceptance test.

What belongs in a restore acceptance record?

Use this original record for a ledger service: recovery-point identifier and timestamp, matching data/log volumes, expected last durable transaction, restored transaction count, checksum or reconciliation result, application version, encryption access, initialization method, and measured time to serve validated requests.

Define RPO as the allowed data-loss interval and RTO as the allowed recovery interval. Start and stop the clocks explicitly. A rehearsal that stops timing when the volume becomes available understates recovery if the database takes another ten minutes to replay and validate.

Restore into an isolated target first. Verify a known committed transaction, reconcile aggregate totals, and confirm that the application can both read and write. Preserve the original evidence while deciding whether to cut traffic over. That is a proposed engineering procedure, not proof that a restore has been executed here.

Sources and Further Reading

Sources checked October 1, 2026. Calculations are illustrative bounds, not AWS performance guarantees; recheck limits and recovery dependencies for the actual environment.