gp2 vs gp3 cost: how to choose (EBS)

gp2 and gp3 are general-purpose EBS volume types. Cost comparisons often go wrong when you compare only the $/GB number and ignore that performance knobs and baselines can force you to over-provision.

gp2 vs gp3 breakpoints

• IOPS needs: sustained IOPS requirement.
• Throughput: sequential MB/s requirement.
• Size: gp2 scales IOPS with size; gp3 does not.

How the cost model differs

• gp2: performance is more tightly coupled to volume size; you may grow GB just to get IOPS.
• gp3: you can provision size, IOPS, and throughput more independently (within limits).

When gp3 tends to win

• You have many moderately sized volumes and want predictable performance without over-sizing.
• You want to set explicit IOPS/throughput targets based on measured utilization.
• You want to separate “capacity growth” decisions from “performance” decisions.

When gp2 can still be fine

• Your volumes are already sized primarily for capacity and meet performance needs without tuning.
• You have low to moderate IOPS needs and do not need tight performance controls.

Simple decision heuristic

• If you are increasing volume size mainly to "get more IOPS", gp3 is usually worth modeling.
• If you rarely touch performance settings and your workload is not I/O sensitive, gp2 may be sufficient.
• If you need predictable performance targets per volume, gp3 is generally easier to reason about.

Worked workflow: compare with measured utilization

1. Measure current IOPS and throughput utilization (average and p95) for a representative week.
2. Identify which volumes are “oversized for performance” (large GB but low usage).
3. Model gp3 with explicit IOPS/throughput targets and compare monthly cost.
4. Validate performance in a canary or staging environment before migrating a fleet.

Common pitfalls

• Comparing only $/GB and ignoring IOPS/throughput needs.
• Using peak metrics as a baseline (over-provisioning performance).
• Changing volume type without a validation window and rollback plan.
• Forgetting snapshots: volume changes do not reduce snapshot retention unless policies change too.

Migration checklist (safe switching)

• Pick a representative set of volumes (different workloads and sizes).
• Capture baseline latency, IOPS, throughput, and error rates for a week.
• Switch in canary and validate p95 latency under the same workload.
• Roll out gradually, and keep a rollback path for the workloads that are sensitive.

Sources

• EBS pricing: aws.amazon.com/ebs/pricing
• EBS volume types: docs.aws.amazon.com

Related guides

Related calculators

FAQ