Right-size EFS throughput mode

Most people assume a file storage bill scales with how much you store — more data, more cost. With Amazon EFS that's only half the picture. EFS charges separately for a "throughput mode" that controls how fast data moves in and out, and one of those modes, Provisioned Throughput, is a fixed monthly reservation of bandwidth. You commit to a level of speed and pay for it every hour whether the workload uses it or not, the same way you'd pay for a leased line you barely send traffic over.

This finding flags file systems on that reserved mode where the actual usage is a fraction of what's been reserved. In practice these are file systems that hit a speed limit once, had a big number set to make the symptom disappear, and were never revisited. A 200 MiB/s reservation runs to roughly $1,200 a month — and that's before counting the data stored. If the workload only ever drives a small share of that bandwidth, most of the charge is buying nothing. AWS offers a pay-for-what-you-use mode (Elastic) and a free mode that scales with stored size (Bursting); the waste is the gap between the fixed reservation and the two cheaper alternatives.

From a budgeting standpoint this category behaves like a fixed cost masquerading as a variable one. It doesn't move with usage, so it won't shrink when activity drops — it just sits on the invoice until someone changes the setting. That makes it a clean, low-risk saving when you find it, and a useful ownership signal: a large reservation against tiny measured usage almost always means a setting nobody owns anymore. The number to ask for at the cost review is reserved throughput versus actually-used throughput per file system; a wide, persistent gap is the whole story.

Priya is the finance partner embedded with the platform team at a genomics startup. At the monthly cost review the EFS line jumps out — it's larger than she'd expect for the amount of data the team says they store. She asks one question that's now standard on the agenda: "For our biggest file system, how much throughput have we reserved, and how much are we actually using?" The answer comes back as 250 MiB/s reserved against an 18 MiB/s peak — a fourteen-to-one gap, costing about $1,500 a month.

The conversation isn't technical. Priya doesn't ask about metrics or modes. She asks three things: why was the reservation set, does anyone still own that decision, and is there a pay-for-use alternative. The engineering lead confirms it was set two years ago to clear a one-off bottleneck, the original owner has moved teams, and yes — AWS now has an auto-scaling mode that bills only for what's used. That's enough to act. Engineering commits to switching it within the week; Priya adds reserved-versus-used throughput as a recurring line on the cost pack so the same gap can't reappear unnoticed.

A month later the throughput charge on that file system is under $50. Priya knows that's the right floor — genuine metered usage with no idle reservation — and she also knows that if a new large fixed reservation appears, it means someone set a number without checking the alternatives, and that's the conversation. The dollar amount is a leading indicator of a settings-ownership gap; the switch itself is almost incidental.

The direct impact is a fixed monthly charge that's larger than it looks and doesn't respond to usage. A single oversized file system can carry $1,000–$3,000 a month of reserved throughput on top of trivial storage. It's rarely enough to move the quarterly total alone, but it's exactly the kind of charge that lands in "unexplained EFS spend" and sends finance chasing a storage number that isn't actually about storage.

The more important impact is forecasting integrity. Because Provisioned Throughput is a fixed reservation, it behaves like a commitment but rarely gets tracked like one — it doesn't show up in your Savings Plan or Reserved Instance utilisation reports, so it escapes the usual commitment-coverage review. That makes it a blind spot: a recurring fixed cost with no utilisation metric attached to it on the standard reports. The fix is to ask for reserved-throughput-versus-used per file system as its own line, the same way you'd track commitment utilisation.

The third impact is chargeback accuracy. When the EFS line is reported as a lump, the cost can't be fairly assigned — a team storing very little data appears to have a large storage bill, which breaks the chargeback conversation. Splitting the reservation out and attributing it to whoever owns the file system makes the chargeback defensible and usually motivates the owning team to fix it themselves once they see the number.

Finally, it's a leading indicator. A large gap between reserved and used throughput that persists month over month means a pay-for-reserved setting has no active owner. That same governance gap predicts other fixed-reservation waste — provisioned IOPS, reserved concurrency, stranded commitments — trending the same way. Watch the reserved-versus-used ratio as a signal, not just a number to minimise.

Amazon's shared file storage lets teams reserve a fixed amount of bandwidth and bill for it around the clock. When a workload's real demand is a fraction of what was reserved, the business pays full price for capacity that sits idle — a recurring charge that's mostly air.

This is a config-hygiene issue more than a technical one. AWS now offers a pay-for-what-you-use option that makes the fixed reservation unnecessary for almost every workload. Fixing it is a one-setting change with no downtime and immediate saving; the more durable win is the discipline that every reservation-style commitment gets reviewed against actual usage rather than set once and forgotten.

At one company, the cloud-cost review kept surfacing a storage line that was far bigger than the amount of data behind it. The first instinct was to ask the team to "reduce storage spend," which went nowhere because storage wasn't the problem — a forgotten bandwidth reservation was. The exec sponsor changed the question from "why is storage so expensive?" to "are we paying for reserved capacity we don't use anywhere in the estate?"

That reframing surfaced not just one oversized EFS reservation but a pattern: several fixed commitments — throughput, provisioned IOPS, reserved capacity — set once and never reviewed against real usage. Within a quarter the team adopted a simple norm: any pay-for-reserved setting carries an owner and a review date, and defaults to the pay-for-use option unless there's a documented reason. The oversized EFS charge dropped by 95% and never came back.

That's the right outcome state. The goal isn't "never use reserved capacity" — sometimes it's exactly right. The goal is that every reservation is owned, justified, and checked against actual usage. The cost report stops being a place to hunt for surprises and becomes a confidence signal.

The dollar amount per file system is usually modest, but the reason it's tracked is what it reveals about discipline. A reservation sized many times larger than real usage means someone committed the business to a fixed cost and no one has revisited it. That's the same failure mode behind larger stranded commitments, and a cloud estate that does it on EFS throughput is very likely doing it elsewhere on bigger numbers.

There's a strategic angle too. AWS now offers a pay-for-what-you-use option that makes most of these reservations unnecessary — so an oversized reservation isn't just waste, it's evidence the team isn't adopting the cheaper, more flexible defaults the provider already ships. That sits at the intersection of cost efficiency and operational maturity, and both are fair things for leadership to expect the team to get right by default.