Enterprise AWS bills keep climbing in 2026, even with list rates barely moving. This report reads where the overspend hides, why each category compounds, and how buyers recover a material share of the bill without rewriting the architecture.
AWS bills keep growing in 2026, and the rate card explains almost none of it. The overspend hides in five places. Each one is measurable, and most of it is recoverable at the next reconciliation.
About this report
The Redress Compliance AWS Cloud Overspending Report is a directional benchmark on where enterprises overpay on AWS in 2026. It draws on three inputs.
We report bands and directions, not precise discounts. Individual outcomes vary widely with workload mix, region footprint, and commitment structure. Where a single number appears, treat it as the middle of a range rather than a guarantee.
The overspend hides in five places. Over committed Savings Plans and Reserved Instances, idle or oversized compute and storage, untagged spend, egress, and on demand workloads running at scale without a commitment in place. Each one has a measurable signature on the bill, and each one has a defined recovery move.
None of these categories shows up as a new line. They all flow through the same per service meters that have run for years. That is why the bill climbs without a rate change to point at, and why the lever sits inside the buyer organization rather than at the supplier.
The first category is over committed capacity. A Savings Plan or Reserved Instance footprint sized to projected growth that did not arrive is the most common overspend on AWS, and it is paid every hour regardless of actual use.
The structural signature is simple. Realized eligible usage sits below the commit line. The hours below the line are paid at the commitment rate even when nothing ran on them. The effective rate on the workload that did run ends higher than a smaller, well sized commit would have produced.
The second category is idle and oversized compute and storage. EC2 instances kept running for workloads that retired months ago, EBS volumes attached to instances no one uses, and RDS instances sized for a peak that no longer arrives all carry steady state cost.
The amounts are rarely heroic on any single resource. They are heroic in aggregate, because they compound over thousands of resources and across years where no one looked. The right loop here is regular review against a baseline, not a one off audit.
The third category is untagged spend. Cost that cannot be attributed to an owner cannot be optimized, because nobody is accountable for it. In the estates we benchmark, this typically runs 25 to 45 percent of the bill at first read, which makes the cost allocation conversation directional at best.
The fix is process before tooling. A tagging policy with a small number of mandatory dimensions, enforced at the account or service control policy level, gives every other optimization a hook to pull on.
The fourth category is egress. Cross availability zone, cross region, and internet egress are all paid at published rates that look small per gigabyte and large at terabyte scale. Buyers underbudget egress because it does not appear in any commitment vehicle and does not show up on the EDP discount sheet in the same shape as compute.
Architecture decisions make most of the difference. A workload that crosses regions on every call carries a cost line that the same workload running in one region would not. The honest unit here is dollars per million calls, not the headline rate per gigabyte.
The fifth category is on demand workloads running at scale without a commitment vehicle in place. Each hour costs more than it had to. The pattern is most common in environments where the FinOps function arrived late, or where a recent migration left compute on demand by default.
The fix is not always more commitment. It is the right commitment shape, sized to the defensible baseline rather than to an aspirational target. The wrong commit creates over commitment, which is the first category on the list.
It becomes a tax the moment realized eligible usage drifts below the commitment line. Every hour below the line is paid at the commitment rate even though no workload ran on it. The effective rate ends above the rate of a smaller well sized commit, and the headroom that was meant to absorb growth funds the gap instead.
The trap is that the math looks clean on day one. A larger commit pulls a higher published discount on AWS Savings Plans, which makes the bigger number look cheaper per unit. Then usage drifts, and the commit becomes the floor on the bill rather than a ceiling on the discount.
Underuse is the clearest signal. The Cost Explorer commitment utilization view shows where eligible usage sits against the commit line, hour by hour. Any sustained gap below the line is paid for at the commit rate, regardless of the workload.
The pattern is usually structural, not transient. A team sized the commit to projections that did not land, or to a workload that moved to a different family. The fix begins with treating those gaps as the first thing the next reconciliation has to attack.
When underuse is large enough, the effective rate on the running workload ends above the equivalent on demand rate net of a smaller commit. The discount on the slide deck and the discount on the bill diverge, and the bigger commit ends as the more expensive choice.
This is counterintuitive enough that procurement teams routinely miss it. The instinct is to push the commit higher at renewal to chase a larger headline discount. The honest move is often to push it lower, and route growth to a separate vehicle.
The shape of the commit decides whether it ages well. A compute Savings Plan that floats across regions and instance families is more forgiving of workload change than an EC2 RI bound to a single family in a single region.
The trade off is the discount. The more flexible the vehicle, the smaller the headline rate. The right answer is rarely the maximum discount. It is the largest commit that the workload can actually fill across the term.
The defensible baseline is the trough of realized eligible usage over the last twelve to eighteen months, adjusted for known retirement events. That is the largest commit that can be filled with a high confidence floor, and it is the right number to start the next reconciliation with.
Growth headroom goes outside the commitment. The new workload pays on demand until its own usage line is high enough to support its own commit. This separation keeps the over commitment trap from rebuilding itself each year.
The Enterprise Discount Program is a discount layer on top of usage, not a commitment vehicle that replaces sizing. The EDP commit aggregates spend across the estate and earns a tier discount. It does not absolve the team of sizing Savings Plans and Reserved Instances inside that envelope.
The buyers who treat EDP and Savings Plan sizing as the same conversation end up paying twice. EDP is the corporate floor on spend. Savings Plans and Reserved Instances are the per workload sizing exercise. Both have to be defensible against the underlying usage.
A material share. In the estates we benchmark, idle and oversized compute and storage together typically account for 10 to 20 percent of the steady state run rate. None of it is heroic on any single resource. It is heroic in aggregate, because it compounds across thousands of resources and many years of no one looking.
The honest unit here is utilization, not headcount of resources. A thousand right sized instances cost less than three hundred oversized ones, and the difference is usually the result of process rather than skill. The fix is a regular review loop with a clear owner, not a one off audit.
EC2 carries two distinct flavors of waste. Idle instances run with no real workload on them, often left over from a project or a test that never retired. Oversized instances run with too much capacity for the workload they actually serve.
The signatures differ. Idle shows up as flat near zero CPU and memory utilization. Oversized shows up as a high commit fraction at low utilization. Both should be picked up by a weekly review that asks one question per instance. Is the resource still needed, and is it sized for what it does today.
EBS volumes outlive the instances they were attached to more often than any other resource. The volume continues to bill at the gp3 or io2 rate while sitting unattached and unused. The recovery is usually a quick win at low risk.
Oversized volumes are the harder pattern. A volume provisioned at high IOPS for a workload that no longer needs them carries a premium on every gigabyte. The fix is migrating to a lower performance tier, often with no measurable change in user experience.
RDS is the database equivalent of EC2 waste, with the same two patterns. Instances kept running for workloads that retired months ago, and instances sized for a peak that no longer arrives. The cost is paid hourly, and the storage is paid on top.
Aurora reservations and RDS reservations behave like other Reserved Instances and have to be sized to the realized baseline rather than to the projection that drove the original sizing. Storage tiers, automated backups, and snapshot retention all add lines that compound.
ElastiCache clusters and EMR clusters carry the same idle risk as compute, plus a steeper hourly rate. A cluster kept running between batch windows or during a paused project line is one of the most expensive forms of idle on the bill.
The fix is a regular schedule on non production environments and an explicit owner on production. Both work. The first removes the cost from the calendar. The second puts the cost in front of someone who has to defend it each month.
The single audit pattern almost never lands. A list of idle resources is generated, a one off cleanup happens, and the next year produces the same list against fresh resources. The audit has not changed the process that created the waste.
The loop pattern lands. A weekly or monthly review by service owners against the same utilization metric, the same ownership tags, and the same playbook for retirement. The first cycle finds the obvious cases. The fifth cycle has changed the way the estate operates.
Egress costs more than most budgets assume, and a meaningful share is recoverable through architecture and contract together. Cross availability zone, cross region, and internet egress are all paid at published rates on the AWS EC2 pricing page and the wider AWS pricing catalog. The published rates look small per gigabyte, and they end large at terabyte scale.
The trap is that egress is invisible in commitments. The EDP commitment vehicle and Savings Plans do not absorb data movement. The buyer pays full rate even after a large discount conversation on compute.
Cross availability zone traffic is the line buyers underbudget the most, because it sits inside the same region and feels like local. The meter does not see it that way. A workload that calls a service in another availability zone on every request pays the cross zone rate on every payload.
The architecture move is colocation. Services that talk to each other on the hot path should be deployed inside the same zone where the architecture permits. Where it does not, the cross zone footprint should be sized into the capacity plan rather than discovered on the invoice.
Cross region transfers carry a higher rate and often a larger payload. Backups copied to another region, multi region active configurations, and analytics jobs that pull from a regional data lake all run on the cross region meter.
The discipline is the same as for cross zone. Map the cross region edges of the architecture, size the expected gigabytes, and check the line against the meter quarterly. Surprises here are large because the rate is large.
Internet egress is the most visible part of the bill and the one that public benchmarks fixate on. It is the rate that drops into the headline. It is rarely the largest egress line in a mature enterprise estate, because internal traffic dwarfs it.
That said, internet egress is the line where contract negotiation moves the most absolute dollars at the largest estates. The EDP framework can carry custom egress reductions for the largest spenders, and the published AWS Cost Management blog documents the standard waivers available at lower volume.
CloudFront and VPC endpoints reshape the egress bill rather than removing it. CloudFront routes internet egress through a different meter that can be cheaper at scale and lands inside a separate commitment vehicle. VPC endpoints can remove cross zone traffic for specific service calls.
Both work as part of an architecture, not as a sticker fix. The teams that benefit most started the design with cost in mind. The teams that bolted them on later see a real but smaller saving, because the workload was not built for the new path.
Contract levers on egress exist, and they are not always offered by default. Custom egress reductions, marketplace transfer credits, and committed transfer pricing are all possible at the right scale. The framework conversation belongs in the EDP renewal, not in a separate procurement cycle.
The honest expectation is a meaningful improvement at the largest estates, and a smaller one elsewhere. Egress is not where a small buyer wins. It is where a large buyer can keep the discount sheet from quietly eroding.
The rate card barely moved. The bill did, because commit sizing, sprawl, and egress drifted faster than budgets.
Most public advice on the AWS EDP says the same thing. Push the commit higher to earn the deepest tier discount, and treat the headroom as future flexibility. That advice was already weak in 2023. It is the wrong default in 2026.
Three pieces of standard advice do not survive contact with the meter. Maximize the commit. Use the commit to fund growth. Renegotiate the EDP rather than the workload. Each one made sense in a specific year. None of them is the strongest play for the buyer right now.
The standard pitch is to maximize the EDP commit and earn the deepest cloud discount headline. We disagree. In the cloud estates we benchmark, over committing locks in spend the business cannot fill, the effective rate ends higher than a smaller well sized commit, and the headroom that should have absorbed growth becomes a tax instead. The buyer side move is to size the commit to defensible baseline usage, keep growth headroom out of the commitment, and treat egress and untagged spend as first class budget lines rather than as the annual surprises they have been. The discount on the slide is not the discount on the bill, and the bill is the only number a buyer pays.
The argument for funding growth inside the commit is that headroom is cheap insurance. The math does not support it. Headroom paid at the commit rate every hour is more expensive than headroom paid on demand on the few hours it ran, unless the growth materialized exactly on plan.
The honest pattern is to keep new workloads on demand until they have a defensible baseline, then commit against that baseline. New workloads forecast worst on adoption, and the over commitment trap on them is the most expensive single error on the AWS bill.
The third piece of standard advice says the EDP renewal is where the cost conversation happens. The EDP is where the corporate floor is set. The cost conversation belongs at the workload level, every reconciliation, every renewal.
The biggest absolute dollars move through right sizing, routing, and commitment shape on individual workloads. The EDP frames the discount layer on top of all of that. Buyers who renegotiate only the EDP leave the deeper savings on the table.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Cost that cannot be attributed cannot be defended, and defense is the work that recovers overspend. Untagged spend hides ownership, which hides accountability, which hides the lever every other optimization needs to pull on.
The typical first read shows 25 to 45 percent of the bill untagged or inconsistently tagged. Cost allocation reports built on that are directional at best. Owner teams cannot get the data they need to defend their own line, and the cost stays at the corporate level where no one owns it.
Untagged spend by what it blocks
| Blocked move | Why it depends on tagging | Typical share at risk |
|---|---|---|
| Showback and chargeback | Owners cannot defend cost they cannot see | 25 to 45% of bill |
| Right sizing program | No owner to approve resize or retirement | 8 to 14% of compute |
| Commitment sizing | Forecast is built on guesses, not on owner baselines | 10 to 20% of commit |
| Anomaly detection | Alerts route to nobody and get muted | Single incidents |
| Architecture review | Egress and storage choices have no ownership trail | 4 to 9% of bill |
Tagging policy beats tagging tooling on every estate we have benchmarked. A small number of mandatory dimensions, defined once and enforced at the account or service control policy level, recovers more value than a complex governance layer with optional fields.
The right starter set is small. Owner, environment, cost center, and workload. Four dimensions, enforced at creation, generate enough signal to attack the rest of the overspend list. More dimensions can be added once the four mandatory ones are clean.
Enforcement at the boundary, meaning the account or service control policy layer, beats enforcement after the fact. A service that cannot launch without a tag is a service that arrives tagged. Cleanup scripts that retag thousands of resources after launch are an expensive substitute for enforcement at creation.
The boundary also makes the conversation simple. A team that cannot launch a resource without naming an owner has no opportunity to leave the question open. The cost belongs to the owner from the first hour.
Once the tags are clean, cost allocation becomes an internal currency. Teams see their own line each month, and they can defend it or change it. The decisions about right sizing, commitment, and architecture move from the platform team to the workload owner.
That shift is the single largest cultural change a FinOps program produces. It also produces the largest measurable savings, because the people closest to the workload are the people who can change it without breaking it.
The Cost and Usage Report is the source of truth, and it should be loaded into the analytical layer that the FinOps team and the finance team both query. Vendor dashboards are useful for monitoring. They are not the system of record.
The CUR carries the per resource line, the tag set, the commitment attribution, and the discount applied. Once those four columns are joined to the ownership model, the conversation about overspend stops being directional. It becomes per resource, per owner, and per dollar.
Tagging quality is the gating constraint on every other lever. A right sizing program with 50 percent untagged spend is half a program. A commitment renewal with 30 percent untagged compute is a guess. The order of operations puts tagging first, not because it is the most valuable lever in isolation, but because it unlocks every other one.
The fastest path to the rest of the savings is the boring path. Get the tags right, then attack the run rate. The teams that skip this step keep finding the same overspend on the next cycle.
The shape of overspend changes with what the workload does. Steady state compute carries commitment risk. Spiky batch carries scheduling risk. Data heavy workloads carry egress risk. Each shape has a different first move, and the cap on overspend is set workload by workload, not at the platform level.
Steady state compute is the most predictable line on the bill. It moves with deployment cadence and traffic patterns, both of which are forecastable inside a quarter. The dominant overspend pattern is commitment sizing, and the dominant fix is right sized Savings Plans against a defensible baseline.
The teams running steady state well treat the commitment exercise as a quarterly process rather than an annual one. The trough of usage is updated each quarter, the commit is adjusted, and the headroom is paid on demand until it becomes a new baseline.
Spiky workloads carry scheduling risk. A batch job that ran every night at midnight last year may run every two hours this year, and the cost grew with it. The pattern is rarely intentional. It accreted, and no one revisited the schedule.
The fix is a regular schedule review with the workload owner. Queue limits, parallelism caps, and a clear off books policy on weekends and overnight windows recover a meaningful share of batch spend without breaking the workload.
Data heavy workloads carry egress risk. Cross zone calls, cross region replication, and analytics queries that pull from a remote data lake all run on the egress meter. The bill grows with the architecture, not with the rate card.
The fix is colocation and selective replication. Data and compute should live in the same zone where the architecture permits, and the cross zone edges should be deliberate. The teams that built the architecture for this carry materially smaller egress bills than the teams that did not.
Greenfield AI workloads are the most explosive line on the modern AWS bill. GPU and inference instance footprints scale with experimentation, and the commit shape that fit a CPU world rarely fits this one. The overspend pattern is on demand at scale plus uncommitted growth.
The honest move is to put the accelerated compute on its own commit conversation, not to fold it into the EDP envelope at last year's shape. The workload is different enough that the same vehicle does not fit, and the rate card on accelerated instances does not behave like the rate card on general purpose ones.
Multi account sprawl is a workload class in itself. An organization that grew through acquisition or autonomous teams tends to carry many accounts, each with its own commitment posture, its own tag set, and its own gaps. The aggregate bill carries the sum of every gap.
The fix is consolidation at the right level. AWS Organizations and the EDP framework let the consolidated entity carry a single commit envelope while leaving operational autonomy intact at the account level. The bill responds quickly when the envelope is drawn in the right place.
Measure the run rate against utilization, route accountability to workload owners, and treat egress and untagged spend as first class budget lines rather than as the surprises they have been. The combination recovers a material share of the bill at the next reconciliation, and the work is operational rather than procurement.
The right unit is utilization, not the dashboard number for spend. Commit utilization, instance utilization, and egress per call all carry more signal than the headline run rate. A spend number tells you the bill grew. A utilization number tells you where to look.
Once the team measures utilization at the workload level, the optimization candidates fall out by themselves. The lines that are paid for and not used are visible in the same view as the lines that are paid for and used hard.
Accountability has to sit with the owner, not with the platform team. The platform team can build the tools and run the program. They cannot defend every workload to every owner each month. That work has to belong to the workload owner who built the resource.
This is the practical purpose of tagging. The tag set carries the ownership trail, and the cost report routes the conversation. The discipline only holds if the owner sees their line every month and is asked to defend it.
Egress and untagged spend should be budget lines, not surprises. A run rate plan that does not include egress in its top level structure will overshoot in any environment with meaningful data movement. A plan that does not measure untagged spend will accumulate it.
The structure forces the right conversation. A team with a published egress budget will defend its architecture. A team without one will discover the line at the end of the year and ask for more budget instead.
The cost loop is the missing operating model in most cloud programs. It is the regular cadence where workload owners review their utilization, their commitment coverage, their egress lines, and their tag quality, and report up to a finance partner.
Without the loop, AWS cost looks like a forecast problem that finance owns and a quality problem that engineering owns. With it, the two questions are joined, and the right trade offs become visible at the time they need to be made.
The EDP conversation is downstream of the workload work, not upstream. A team that walks into renewal with a clean baseline, a defensible commitment shape, and a published egress posture wins a better discount sheet than a team that walks in with a guess.
The buyers who treat the EDP as the cost lever rather than the discount layer leave most of the savings on the table. The bill responds to the workload work first, and the renewal frames the result.
In five places. Over committed Savings Plans and Reserved Instances, idle or oversized compute and storage, untagged spend, egress, and on demand workloads running at scale without a commitment vehicle. Each has a measurable signature on the bill, and each has a defined recovery move.
They become a tax when realized eligible usage drifts below the commitment line. Every hour below the line is paid at the commit rate even though no workload ran on it. The effective rate ends above a smaller well sized commit, and the headroom that was meant to absorb growth funds the gap instead.
Idle and oversized compute and storage together typically account for 10 to 20 percent of the steady state run rate. The footprint is small per resource and large in aggregate, because it compounds across thousands of resources and many years where no one looked. A regular loop, not a one off audit, is the fix that holds.
Cross availability zone, cross region, and internet egress are all paid at published rates that look small per gigabyte and large at terabyte scale. In environments where data movement is not engineered as a first class cost line, egress moves the monthly bill by 4 to 9 percent. Cross zone is the line buyers underbudget most.
Usually no. Over committing locks in spend the business cannot fill, the effective rate ends higher than a smaller well sized commit, and the headroom that was meant to absorb growth becomes a tax. Size the commit to the defensible baseline, keep growth headroom outside the commitment, and treat egress and untagged spend as first class budget lines.
Cost that cannot be attributed cannot be defended. Untagged spend typically runs 25 to 45 percent of the bill at first read, which makes cost allocation directional at best. The fix is process before tooling. A tagging policy with four mandatory dimensions, enforced at the account or service control policy level, gives every other optimization a hook to pull on.
Measure utilization at the workload level, route accountability to owners through a clean tag trail, budget egress and untagged spend as first class lines, size commitments to the defensible baseline, and run a quarterly cost loop joining finance and engineering. The combination recovers a material share of the bill at the next reconciliation, with no architecture rewrite required.
Steady state compute carries commitment risk. Spiky batch carries scheduling risk. Data heavy workloads carry egress risk. Greenfield AI carries on demand at scale plus uncommitted growth risk. Multi account sprawl carries every risk in aggregate. The cap is set workload by workload, not at the platform level.
Provider choice is rarely the question on AWS. The lever sits inside the buyer organization, in commit sizing, tagging, egress engineering, and EDP sequencing. Migrating to another hyperscaler usually moves a small percentage of the bill. The internal disciplines move multiples of that.
Without discipline, expect the AWS run rate in 2027 to climb materially again on the same workload base. The drivers are accelerated compute growth, larger data movement, and commitment drift. The buyers who hold cost close to plan run a tagging policy, a quarterly cost loop, and a defensible baseline. The work is operational.
The five overspend categories with bands, the commit sizing method, the tagging policy, the egress posture, and the EDP sequencing that holds the line.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement, finance, and platform leaders running the next reconciliation.
The list rate barely moved. The bill did, because commit sizing, sprawl, and egress drifted faster than budgets.
