How much does AWS Business Support+ cost?

Business Support+ is 9% of monthly AWS charges up to $10,000, 7% from $10,000 to $80,000, 5% from $80,000 to $250,000, and 3% above $250,000, with a $29 per month per account minimum. The minimum only binds below about $322 of monthly spend.

What happened in the AWS billing bug of July 2026?

Between 16 and 17 July 2026, incorrect unit pricing in AWS billing estimation caused wildly inflated cost estimates, including one over $2.4 billion and another at $7.1 trillion. Actual charges were unaffected, but automated budget alerts fired on the bad estimates and some customers took destructive action on production accounts.

How much do you save by shutting down non-production EC2 out of hours?

It depends entirely on the schedule. A 12-hour, 5-day week uses 60 of 168 weekly hours, so stopping the rest removes 108 hours or 64.3% of runtime. A 24/5 fleet that only stops at weekends idles 48 of 168 hours, or 28.6%. Both are arithmetic on an assumed schedule, not measured savings, and EBS volumes and Elastic IPs keep billing through the stop.

When Your AWS Bill Looks Wrong

Q: Can I still buy AWS Developer or Business Support?

No. As of 2 December 2025, Developer Support and Business Support are no longer available for new subscriptions. Both, along with Enterprise On-Ramp, will be discontinued on 1 January 2027. The replacement for new customers is Business Support+.

Q: Is an Elastic IP charged while the EC2 instance is stopped?

Yes. An Elastic IP associated with an instance persists through a stop and is charged while the instance is stopped, at $0.005 per hour or about $3.65 per month. Stopped instances also continue to bill for their EBS volumes.

Three things happened to AWS billing in the last eight months that have nothing to do with each other and everything in common. A forecasting system produced numbers off by twelve orders of magnitude. A standard savings tactic turned out to return a fraction of its advertised percentage. And the price of support became a straight percentage of your bill, which quietly changed what a dollar of waste costs.

What links them is that in each case there is a number that looks like a measurement and is not one.

1. The forecast that said $7.1 trillion

Over 16 and 17 July 2026, and persisting more than 24 hours, AWS customers opened Cost Explorer and found estimates that made no sense. One customer's estimate showed over $2.4 billion for the month. Another hit $7.1 trillion, which is more than twice Amazon's own market capitalisation.

The root cause was incorrect unit pricing in AWS's estimated billing computation system. Actual charges were fine throughout, and AWS was clear that the displayed figures did not reflect actual usage and charges.

That should have been the end of it. It was not, because of what sits downstream of those estimates.

The alerts fired

Some organisations received automated budget alerts indicating projected bills in the billions or trillions of dollars. The alerting worked exactly as designed. It was watching a number, the number moved, it told somebody.

One documented user response: I panicked and destroyed everything on this account.

That is the part worth sitting with. Nobody in that story ignored their monitoring. Somebody had set up budget alerts, which is the responsible thing to do, and the monitoring told them their account was generating billions of dollars in charges, and they acted decisively on it.

A guardrail inside the system it watches

This is the structural lesson, and it generalises well past AWS billing. A guardrail that lives inside the system it monitors does not fail silent. It fails loud, and its false alarms are indistinguishable from real ones.

Budget alerts fired on estimates, not on verified invoices. Cost Explorer is a forecast interface, not an invoice. Most people using it day to day do not hold that distinction clearly, because for years the forecast has been close enough to the invoice that the difference did not matter.

I am not suggesting anyone turn off budgets or anomaly alerts. They catch real problems and you should keep them. What changes is the step between the alert and the action: before an alert makes you touch production, confirm what is actually running and what it actually costs. An estimate is a claim about the future, and a claim about the future can be wrong by a factor of a trillion.

2. The savings percentage that is not a measurement

Shutting non-production instances down outside business hours is close to universally recommended, and it is genuinely good advice. The number attached to it deserves more scrutiny than it usually gets.

A 12-hour, 5-day business week is 60 of 168 weekly hours. The other 108 are idle and still billed. Stop them outside those hours and you remove 108 of 168 hours, which is 64.3%.

That 64.3% is arithmetic on a schedule you assumed. It is not a measured saving, and it is not what will land on your bill. Two things eat into it.

The address moves, and fixing that costs money

AWS releases the auto-assigned public IPv4 address when an instance stops, and assigns a new one on start. So the box comes back on Monday with a different IP, and anything pinned to the old one is now pointing at nothing: partner allowlists, VPN rules, a hardcoded DNS record, a webhook registered with a third party.

The standard fix is an Elastic IP, which survives the stop. So does its charge. An Elastic IP associated with an instance persists through a stop and is charged while the instance is stopped, at $0.005 per hour, or about $3.65 a month, at the same rate whether in use or idle.

So part of what you just saved goes straight back onto the bill, and it goes back on for the hours the instance is off, which are precisely the hours you were trying to stop paying for.

Storage bills through the stop

A stopped EC2 instance still bills its EBS volumes. Compute stops, storage does not. On instances with large attached volumes the storage can be a meaningful share of the total, and none of it is affected by the schedule.

This is why the realised saving on a scheduling project is reliably below the headline percentage. The percentage describes instance-hours. The bill contains more than instance-hours.

Run the division on your own schedule

The 64.3% figure also assumes a 12-hour day. Plenty of non-production fleets run 24/5 and only stop at weekends. That idles 48 of 168 hours, which is 28.6%, less than half what the 12-hour schedule yields.

Same tactic, same tooling, less than half the return, and the difference is entirely in an assumption nobody wrote down. Before you build a business case on 64.3%, run the division on the schedule your teams actually keep.

For what it is worth, this is a rule in my own scanner: CostPatrol's EC2-O004 flags non-production EC2 running 24/7 with no off-hours schedule. It only pays off on instances that are genuinely non-production and that someone will actually stop.

3. Support is now a percentage of your bill

This is the biggest of the three and the least discussed, which is strange given it has been in effect since December.

As of 2 December 2025, Developer Support and Business Support are no longer available for new subscriptions. Both, along with Enterprise On-Ramp, are discontinued on 1 January 2027. This was announced on 2 December 2025, and the announcement does not tie it to re:Invent.

The live pricing page now lists only Basic (free), Business Support+, Enterprise Support with a $5,000 minimum, and Unified Operations with a $50,000 minimum. Developer and Business appear nowhere on it.

The Business Support+ rate card

9% of monthly AWS charges up to $10,000
7% from $10,000 to $80,000
5% from $80,000 to $250,000
3% above $250,000
Minimum $29 per month per account

That $29 minimum was widely reported as good news, and it is lower than the $100 minimum Business Support carried previously. But look at where it stops binding: $29 divided by 0.09 is about $322 of monthly spend. Above roughly $322 a month, 9% of your spend already exceeds $29, so the minimum is irrelevant.

Which means no account in the $5,000 to $60,000 band ever pays the minimum. They pay the percentage. Worked through, and this is my arithmetic on AWS's published rates:

$5,000 monthly spend: 0.09 x 5,000 = $450/month
$30,000 monthly spend: (0.09 x 10,000) + (0.07 x 20,000) = $2,300/month
$60,000 monthly spend: (0.09 x 10,000) + (0.07 x 50,000) = $4,400/month

What actually went away

If you are already on Developer Support, AWS frames the move as your call: you can continue using your existing plan, or upgrade to Business Support+ any time before 1 January 2027. AWS's own word for the move is upgrade, and on the features that is fair. Business Support+ includes 24/7 access to AWS experts and a 30-minute expert response for critical issues. It is a bigger product.

The thing that disappeared is not a discount. It is the option to buy less.

A small team that wanted the ability to open a technical case and nothing more used to have a cheap tier for exactly that. Now the tier below Business Support+ is Basic, and customers on the Basic Support plan cannot open technical support cases at all. So the choice is a percentage of your bill, or no technical support channel. The 30-minute critical response is included whether or not you would ever have paid for it.

Enterprise On-Ramp customers do not get a choice

Throughout 2026, Enterprise On-Ramp customers are being automatically upgraded to AWS Enterprise Support during contract renewal or in periodic batches, with no further action required.

The softening here is real: Enterprise Support's monthly minimum is now $5,000, down from $15,000. AWS does not date that change. Its rate card is 10% of monthly charges up to $150,000, 7% from $150,000 to $500,000, 5% from $500,000 to $1 million, and 3% above that.

The lower floor matters most at the bottom of the Enterprise band. Take a $60,000 per month account:

Enterprise Support today: 0.10 x 60,000 = $6,000. The percentage binds, not the floor.
Business Support+: $4,400. Gap of $1,600.
Under the old $15,000 floor: that same account paid $15,000, because the floor bound above the percentage. Gap of $10,600.

That last comparison holds regardless of what the old percentage rate was: the $15,000 floor binds for any rate at or below 25%, and no AWS support rate exceeds 10%. So the reduction genuinely moved Enterprise Support from unthinkable to arguable for accounts in this range, and that is worth knowing if you were priced out of it before.

The second-order effect

Support priced as a percentage of spend changes the value of cost work, because it changes what waste costs.

In the first Business Support+ tier, a dollar of waste attracts nine cents of support charge. So it is not a dollar. It is $1.09. Every idle instance, every orphaned volume, every forgotten NAT gateway now carries a surcharge on top of itself.

I should be straight about my position here: I sell a cost scanner, so that arithmetic flatters me. Take it as a reason to check your own numbers rather than as a reason to buy anything. The rate card is public and the multiplication is not hard.

The through-line

Each of these is a case where a number that looks authoritative is not the thing it appears to be:

A forecast is not an invoice. It can be wrong by any amount, and the alerting built on top of it will report the error with total confidence.
A savings percentage derived from an assumed schedule is not a measured saving. It excludes storage, it excludes the address charges the change itself creates, and it silently encodes a working week nobody verified.
A support minimum that never binds is not a price. The percentage is the price, and it makes your waste more expensive than its face value.

None of these are exotic edge cases. They are the ordinary numbers people run cloud budgets on. The useful habit is small: when a number is about to drive a decision, ask whether it was measured or derived, and if derived, from what assumption. On the July billing bug that question was the difference between a strange afternoon and a destroyed account.

Sources

AWS statements come from AWS documentation and pricing pages. Incident details come from contemporaneous press reporting, cited below. Dollar figures for support tiers and scheduling percentages are my arithmetic on published rates and assumed schedules, labelled as such in the text.