Support is billed as a percentage of your bill, so it grows automatically with usage - double the bill and support doubles too, while the support you receive does not. The tiers differ not only in response times but in Trusted Advisor coverage and whether the price is negotiable.
AWS Support is the easiest line on the bill to lose control of - not because it is expensive, but because of how it is priced: as a percentage of your bill.
That produces a counter-intuitive consequence: your spend rises, the support charge rises with it automatically, and the support you receive does not increase. Most teams notice the absolute number only after the bill has grown several times over.
This page covers what separates the five tiers, which differences actually matter, and how to judge whether it is worth paying. Prices and bands are on the official pricing page (published summaries differ slightly in how the bands are worded).
The property people overlook: it is a percentage of your bill
Apart from the free tier, every tier reduces to one sentence: "a percentage of usage, or a monthly minimum, whichever is greater."
Two words matter in that sentence: (1) "whichever is greater" - at low usage you pay the minimum, at high usage the percentage overtakes it; and (2) the percentages are banded and step down - not one flat rate on the whole bill, but cumulative bands, so the marginal rate falls as usage rises.
Why does that deserve its own section? Because "a percentage" means:
- It grows automatically, without anyone deciding anything. Every other cost item at least requires you to start a machine; this one rises on its own.
- It is inherently a large line item. The bigger the bill, the more prominent it becomes - and by then your attention is usually on compute and storage.
- It is a decision that can be revisited. Plenty of teams picked a tier early and never looked again, while the usage profile changed underneath them.
Five tiers, from free to a dedicated account manager
| Tier | Pricing | Key difference |
|---|---|---|
| Basic | Free with the account | No technical support channel - documentation, forums and billing support only |
| Developer | From $29/month, or 3% of monthly usage (greater) | Email only, business hours; aimed at development and testing |
| Business | From $100/month, or banded percentages (10% on the first $10K, stepping to 3%) | 24/7, production-down response as fast as 1 hour, full Trusted Advisor |
| Enterprise On-Ramp | From $5,500/month, or banded percentages | Business-critical response as fast as 30 minutes; a technical account manager (TAM) pool |
| Enterprise | From $15,000/month, or banded percentages (10% on the first $150K, stepping to 3%) | Dedicated TAM, 15-minute response, infrastructure event management, architecture reviews |
Do not read that table as a comparison of response times - the most visible difference is not always the one that matters. Three differences change your day-to-day:
- Whether there is a technical support channel at all (Basic has none - the most fundamental dividing line).
- Whether you can raise a production issue 24/7 (Developer is business hours and email only).
- How complete Trusted Advisor is - the full checks require Business or above, and they include cost optimisation findings.
The third point is routinely undervalued: if you are already doing cost optimisation, the full Trusted Advisor checks alone can justify Business - they are precisely a list of "which resources are being wasted". Conversely, if you never read those recommendations, that rationale does not apply to you.
Business: the starting point for most production
If you keep one sentence: teams running production where an outage costs money usually start at Business. Three practical differences justify it:
- 24/7 submission - production incidents do not schedule themselves into business hours.
- A defined response time for production impairment (as fast as 1 hour), which Developer does not have.
- Full Trusted Advisor.
But there is arithmetic to do first: Business is banded percentages, so its absolute cost rises with usage. Before deciding, work out what this tier would actually cost you at your current bill size - the official pricing page has the band table, and running the numbers beats an impression formed from a percentage.
⛔ Do not budget from the "from" price: "$100/month" only holds at very low usage. Once usage grows, the percentage overtakes the minimum. Compute your own figure first, then judge whether it is worth it.
The two enterprise tiers, and what separates them
The enterprise tiers differ mainly in the shape of your relationship with a technical account manager (TAM).
| Enterprise On-Ramp | Enterprise | |
|---|---|---|
| TAM | Shared pool (hours allocated as needed) | Dedicated |
| Business-critical response | As fast as 30 minutes | As fast as 15 minutes |
| From | $5,500/month | $15,000/month |
| Suits | Teams that need TAM access but not at dedicated scale | Large organisations with complex architecture and compliance needs |
The value of these tiers is not faster response (for most teams, the gap between 1 hour and 15 minutes matters far less than "is there anyone who actually understands our architecture"). It is someone participating in your architecture decisions: reviews, capacity planning, cover for major events. If your TAM has not held a real meeting in a year, what remains of this tier is mostly the price.
Judging it that way is more useful than reading a feature list. For the other enterprise-scale route - negotiating a cross-service discount with AWS - see the highest layer of the offers landscape in AWS discounts, the complete picture.
Is it worth it: three questions
There is no universal answer, but three questions converge the decision:
- "What does a four-hour production outage cost us?" If that figure dwarfs a year of support, the response time is worth the price. If the cost is small (internal systems, non-critical workloads), the higher tier is waste.
- "How much can our own team resolve?" Whether you have engineers who know the platform decides whether you need faster responses or proactive guidance. Many teams actually need documentation, runbooks and an on-call process - not a faster ticket.
- "When did we choose our current tier?" If nobody remembers, it is a default - and worth re-evaluating. Usage profile and team capability both move, so the tier should move with them.
A frequently overlooked direction: as your team matures, going back down from Business to Developer is legitimate - provided you accept "business hours, email only" for critical issues. The test is not "can we afford it", it is "is our own response capability sufficient".
Is it negotiable? Above a certain tier, yes
Something many people do not know: support pricing is not uniformly fixed.
- Business and below: list price, normally no separate negotiation.
- Enterprise On-Ramp and Enterprise: negotiable, and usually as part of an overall enterprise agreement - meaning it should not be treated as an isolated small item to shave, but as part of the whole commitment.
The practical implication: if your usage is already substantial, this is an underused negotiating lever. If you are still on Business, do not spend effort here - put it into optimising the usage structure instead (see AWS billing: six actions that actually work).
One clarification for bill tracing: support charges appear as their own line item, not inside the percentage base. So if you see this line jump, it is usually because your usage grew, not because support raised its prices - the tracing approach is in why your AWS bill jumped.
FAQ
Do I have to buy a support plan?
No. Basic comes with the account and is free, it just has no technical support channel (documentation, forums and billing-related support only). For personal projects and experiments that is usually enough; once you run production where an outage has business impact, evaluate the next tier seriously.
What separates Developer from Business?
Three practical differences: Business is 24/7, Developer is business hours only; Business uses phone, chat and email, Developer is email only; and Business carries a response time for production impairment (as fast as 1 hour) that Developer does not. Separately, the full Trusted Advisor checks require Business or above.
Does support cost rise automatically with my usage?
Yes - which is precisely why it is easy to overlook. Every tier except the free one is "monthly minimum or percentage of usage, whichever is greater", so it climbs automatically without anyone deciding anything. Re-run the numbers annually, or whenever your usage profile shifts materially, rather than choosing once and never revisiting.
Can I upgrade or downgrade at any time?
On the public information, upgrades generally take effect quickly, while downgrades typically take effect at the end of the current billing period. The exact rules and timings are on the official pages and terms. If you are downgrading to control cost, plan on the next tier’s expectation for the current period.
Does the support charge count towards cost optimisation?
It is part of your cost structure but it is not in the "discount" layer - it does not change your service unit prices. So the levers are "pick the right tier" and "negotiate when it is negotiable", not expecting a discount to cover it. The layering is in AWS discounts, the complete picture. If what you want is to lower what you actually pay for the same services, that is the channel layer - see AWS discounts and reseller pricing and the cross-provider comparison in cloud discount mechanisms compared.