Migrate EBS volumes from io1 to io2

io1 is the premium storage tier on the cloud bill — the disk type teams choose for databases and other systems where slow or unreliable storage would directly hurt the business. It carries two charges: one for how much data you store and one for the performance you reserve. io2 is the newer version of that same premium tier, and in most regions it costs exactly the same per gigabyte and per unit of reserved performance.

The reason this lands on a cost report at all is that io2 is, in plain terms, a free upgrade. For the identical monthly charge, an io2 disk is about a hundred times less likely to fail in a given year than the io1 disk it replaces. That reliability isn't an abstraction: a storage failure on a production database means an incident, a restore, potential data loss, and the people-hours that follow. Paying the same price for a far lower chance of that event is value the bill doesn't capture but the business absolutely feels.

There's a second, narrower angle for the heaviest workloads. When a disk reserves a very large amount of performance, io2's pricing actually steps down in the higher bands, so the highest-IOPS volumes can come out cheaper on io2 than on io1 — never more expensive, sometimes meaningfully less. So this is a category where the right question at the monthly review isn't "how much will this save?" but "is there any reason we're still on the older, riskier tier when the newer one costs the same or less?"

Sam is the finance partner embedded with the platform team. At the monthly cost review she sees $6,200 in the provisioned-IOPS storage category and asks the question that's now standard on the agenda: "How much of our premium storage is still on the older io1 type, and is there any cost reason not to be on io2?" The engineering lead confirms there is none — io2 is the same price per gigabyte and per unit of performance, and for the two biggest volumes it's actually cheaper.

The conversation isn't technical. Sam doesn't ask about IOPS tiers or Block Express. She frames it as risk-for-free: the same spend buys storage that's a hundred times less likely to fail under the systems where a failure becomes an incident. That framing makes the migration trivially easy to approve — there's no trade-off to weigh, no downtime to schedule against a release calendar, no commitment to unwind. She adds "io1 GB remaining" as a one-line metric on the cost pack so it can be tracked to zero.

A month later the line reads $0 of io1 and the provisioned-IOPS category is ~$1,500 lower overall, partly from the high-IOPS tiering and partly from mirrors the team could retire once a single io2 volume met the durability bar. Sam's takeaway for the next free-upgrade case: when AWS ships a same-price successor to a tier you're already paying for, the only thing standing between you and the saving is whether anyone asks the question.

The unusual thing about this category is that the upgrade is free or cheaper, so the budget conversation isn't about cost reduction in the normal sense. At the low end nothing on the bill changes — you pay the same per gigabyte and per unit of performance — so a straight io1 → io2 swap is cost-neutral on most volumes. The value is risk that the invoice never prices: a hundredfold lower chance of a failure on the storage under your most important systems.

Where it does move the number is the heaviest workloads. io2's per-IOPS rate steps down in the higher bands, so any volume reserving more than 32,000 units of performance comes out cheaper on io2 than io1 — never more expensive, sometimes materially less. If your provisioned-IOPS line is dominated by a few large database or analytics volumes, that tiering can be a quiet four-figure monthly saving for a configuration change with no downtime and no commitment.

The third effect is on redundancy spend. Where teams doubled up io1 volumes in a mirror to chase reliability, a single io2 volume can now meet the bar — so the migration can retire that second volume entirely and halve the spend on those workloads. This is the kind of saving that never appears as a recommendation because it requires knowing the mirror existed; it surfaces only when someone asks why the durability tier hasn't been modernised.

Finally, treat io1 spend as a generation-currency signal. A persistent io1 line means the org is still running storage on a tier AWS superseded years ago — which usually predicts other lingering old-generation choices (older instance families, older volume types, older managed-service versions) carrying the same same-price-or-cheaper upgrade waiting unclaimed. Track "io1 GB remaining" to zero, then ask what other tiers haven't been modernised.

io2 is a newer version of the premium storage tier that sits under databases and other business-critical systems. It costs the same per gigabyte as the version it replaces, but is roughly a hundred times less likely to fail in a given year — and on the very largest workloads it can even be cheaper. There is no contract to renegotiate and no downtime to schedule.

This is one of the few cloud decisions with no trade-off: the same spend buys materially lower operational and data-loss risk on the systems where an outage hurts most. The only reason any io1 volume is still running is inertia. The leadership signal is simple — if the migration hasn't happened, it's a hygiene gap, not a budget call.

At one company the cloud review used to carry a premium-storage line that nobody questioned — it was "the database disks," assumed to be as cheap and as reliable as they could be. When the exec sponsor started asking whether the org was on the current generation of each service rather than whatever was provisioned years ago, this category surfaced: a meaningful chunk still ran on the older io1 type.

The migration took an afternoon, cost nothing extra, removed downtime risk rather than adding it, and on the largest workloads actually lowered the bill while improving reliability a hundredfold. The lasting outcome wasn't the dollar saving — it was the habit: a standing question of "are we on the current generation?" applied to every major service line, so free upgrades get taken routinely instead of being discovered years late by a scanner.

This category is on the report because it's a no-trade-off upgrade that hasn't been taken. The same money buys storage a hundred times less likely to fail under the systems where failure becomes an incident, and on the largest workloads it costs less. A non-zero io1 line on the cost pack isn't a budget problem to debate — it's a hygiene gap that should simply be closed.

The second-order signal is what it says about how the org adopts AWS improvements. When a vendor ships a same-price, strictly-better successor to a tier you already pay for, taking it should be routine. A lingering io1 line means free upgrades are being discovered late by scanners rather than adopted as a habit — and the same pattern almost certainly applies to other modernisation opportunities that don't surface as cleanly. The leadership question is whether "are we on the current generation?" is a standing review item, not a once-a-year surprise.