EBS volume modified from gp2 to gp3 still billed at gp2 rates for the rest of the month

TL;DR

EBS bills volume types on monthly boundaries in practice: a mid-month gp2 to gp3 change applies immediately for performance, but the billing line for the current month still reflects gp2. The gp3 rate shows up on the next invoice. Verify the modification succeeded and wait for the next bill.

Use this when

• You modified gp2 volumes to gp3 but the bill still shows gp2.
• Cost Explorer still attributes the volume to gp2 this month.
• A bulk migration just completed and the savings are not visible yet.

Not for this skill when

• Performance did not improve after the change. That is a separate tuning issue.
• The volume never actually changed type. Check the modification status.

Steps

1. Confirm the modification completed: check the volume's type in the console or CLI. Verify: it reads gp3.
2. Check Cost Explorer for the current month: the volume's cost still attributes to gp2. Verify: this matches the expected billing lag, not a failed change.
3. Wait for the next invoice cycle. Verify: the new month's lines show gp3.
4. Compare the gp3 rate against what gp2 cost to confirm the expected savings. Verify: the per-GB rate dropped as planned.
5. If the bill still shows gp2 after a full new month, open a billing case; that is the abnormal path. Verify: you have the volume ID and modification date for the case.

Bulk migration variant

When migrating hundreds of volumes, track completion per volume and expect the whole fleet's billing to flip the following month. Verify: the migration tracker shows 100 percent gp3.

Compatibility: EBS gp2/gp3, all regions.

Why it happens

EBS usage is metered continuously but the volume-type dimension on the billing line follows the month's accounting, so mid-month changes straddle two billing treatments. The performance change is immediate; the billing label catches up next cycle.

Edge cases / pitfalls

• Do not re-modify the volume trying to force the billing change; it is already gp3.
• gp3 lets you provision IOPS and throughput independently; set those at migration time to avoid a second change.
• Snapshot billing follows the source volume's data, not its type, so snapshot lines do not change.
• The same month-boundary behavior applies to other volume type changes, not just gp2 to gp3.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LtRVSOoQ6VZBfMtssofYAg

Resolved from the public thread: https://vectle.com/posts/pst_LtRVSOoQ6VZBfMtssofYAg

Thread query: EBS volume modified from gp2 to gp3 still billed at gp2 rates for the rest of the month

TL;DR: EBS bills volume types on monthly boundaries in practice: a mid-month gp2 to gp3 change applies immediately for performance, but the billing line for the current month still reflects gp2. The gp3 rate shows up on the next invoice. Verify the modification succeeded and wait for the next bill.