Picking An AWS Support Plan

The situation

A recently-merged company has three divisions on AWS under one master payer account, and the procurement team is renegotiating support plans at renewal. The numbers on the table:

• Division A, internal tools: small team, monthly AWS spend around $8,000, mostly S3, Lambda, and a handful of EC2. Support tickets this year: fourteen, all “how do I” or “why did my quota not increase”. Nothing has ever been down in production; there isn’t much production to be down.
• Division B, payments platform: the business. Monthly AWS spend around $180,000 across EC2, RDS, ElastiCache, MSK, and ECS. Customer-facing SLA of 99.95% uptime with financial penalties for breach. On-call runs 24/7 across two time zones. Last year: three Sev-1 incidents that touched AWS infrastructure, each resolved inside an hour with vendor help.
• Division C, the new acquisition: a bank-backed lender, monthly AWS spend around $420,000 and growing. Regulated industry with formal vendor-management requirements. The CIO’s red-line at procurement was “a named senior engineer we can call during an incident, a named account person we can call during business hours, and a formal quarterly architecture review.” They’ve been on a competitor’s cloud until now; the migration starts in six weeks.

All three are currently on Business Support, which was what the master payer bought by default. The renewal question: is that correct for each division, or should we be paying less on A and more on C?

What actually matters

Before pricing anything, it’s worth asking what “support” actually buys.

The first thing support buys is someone to answer the phone when something is broken. The AWS Service Health Dashboard tells us whether AWS thinks there’s an issue; a support case tells us whether AWS thinks our specific account’s specific issue is AWS’s fault, ours, or a shared problem. Without support, we’re on our own to diagnose whether a 500 response from S3 is a bug we introduced, a regional issue AWS hasn’t posted yet, or a throttling condition we can fix with a quota increase. With support, somebody on their side reads our case and tells us. How fast they read it is what the tiers are selling.

The second thing support buys is expertise during the incident. A Sev-1 at 2am is a bad time to be reading the DynamoDB partition-key documentation for the first time. Higher support tiers get access to engineers who have seen this failure mode before, can tell us whether the workaround we’re contemplating is safe, and can pull in an internal AWS team if the issue turns out to be in their code. The lower tiers get us a well-written article and a polite suggestion to try the forums.

The third thing support buys is proactive guidance before the incident. Trusted Advisor is the most visible piece: an automated set of checks that flag idle load balancers, over-permissive security groups, expiring Reserved Instances, and a few dozen other things that tend to matter. The free tier of Trusted Advisor is limited; the paid tiers unlock the full check set. The highest tier adds a Technical Account Manager (TAM) who looks at the account shape, runs quarterly architecture reviews, coordinates Well-Architected Framework Reviews (WAFRs), and generally acts as an inside track into AWS.

The fourth thing worth asking is what response time we need when the pager fires. AWS publishes response targets by severity level and plan; they range from “business hours, one business day” at the free tier to “15 minutes, 24/7, for business-critical outages” at the top. The question isn’t abstract, if our SLA to our own customers says “we commit to a one-hour incident response,” our support plan had better let us get an AWS engineer on the line inside that hour when the cause lives on AWS’s side of the fence.

The fifth thing is pricing shape. Support isn’t flat-rate; it’s a percentage of the monthly AWS usage, with tiered floors and ceilings. The floor and the percentage matter at different points on the spend curve, at low usage the floor dominates, at high usage the percentage does. The percentage tiers also drop as spend grows, which is why a higher-floor plan can be cheaper as a fraction of the bill once spend crosses a certain threshold.

And finally, one softer thing: the relationship. Large regulated customers increasingly need audit trails that show their vendor is a partner, not a black box. Enterprise Support’s named TAM and account-team involvement is sometimes less about the incident response and more about having a documented, named relationship the auditor can inspect. That’s not something the other tiers really sell.

What we’ll filter on

Six filters worth naming before we start scoring plans against divisions.

1. Case-severity response time, how fast does AWS commit to reading and replying to a new case at each severity level?
2. Twenty-four-seven access, can we raise a case at 3am on a Sunday and expect action, or are we waiting for Monday business hours?
3. Proactive guidance. Trusted Advisor check coverage, architecture reviews, Well-Architected reviews, concierge billing/account support.
4. Named contact, a Technical Account Manager (TAM) assigned to the account, with name, email, and Slack channel, versus a rotating pool.
5. Third-party software guidance. AWS will help diagnose issues with common third-party operating systems and software running on AWS (the “Third-party Software Support” offering included with Business and above).
6. Cost, both the floor and the percentage of spend above the floor. At high usage, the percentage matters more than the floor; at low usage, the floor is most of the bill.

The plan landscape

1. Basic (free). Comes with every AWS account. No case support beyond account and billing questions. Access to the Service Health Dashboard, documentation, whitepapers, and forums. Trusted Advisor is available but limited to seven core checks (a handful of security checks plus a few service-quota checks). No response-time commitment on technical issues because technical cases aren’t available. The floor for anyone experimenting; not a serious choice for anything with production responsibility.

2. Developer. Starts at $29/month (or 3% of monthly AWS usage if that’s higher, but in practice Developer’s target customers rarely spend enough for the percentage to bind). Unlimited technical cases via the web only. Response time targets: General guidance within 24 business hours; system impaired within 12 business hours. No 24/7; case handling is business-hours only. One “primary contact” can open cases, a single seat. Trusted Advisor stays on the core-checks subset. Right for dev and test accounts where a same-day answer to a quota question is fine and nothing is on fire at night.

3. Business. Starts at $100/month or a tiered percentage of monthly usage: 10% of the first $10k, 7% of the next $70k, 5% of the next $170k, 3% over $250k, whichever is greater. Unlimited cases, unlimited people able to open them, web, chat, and phone. Response targets: General guidance within 24 hours; system impaired within 12 hours; production system impaired within 4 hours; production system down within 1 hour, 24/7. Full Trusted Advisor check set, all categories, all checks, dynamic updates. Third-party Software Support for guidance on common OS and application stacks. AWS Infrastructure Event Management (IEM) available as a paid add-on. The workhorse plan for any team running production without a regulated compliance story.

4. Enterprise On-Ramp. Starts at $5,500/month or 10% of monthly usage (tiered similarly, with the percentage falling at higher usage). Everything in Business, plus: response target of 30 minutes for business-critical system down (instead of 15), access to a pool of Technical Account Managers (not a single named TAM; “pool-based” TAMs), one Well-Architected Framework Review per year, one IEM per year included, concierge support for billing and account issues. Designed for customers who need some of Enterprise but can’t justify its floor. The named-TAM-ness is weaker than Enterprise, the pool model means the TAM who answers this month may not be the one next month.

5. Enterprise. Starts at $15,000/month or a tiered percentage that caps lower than Business at high spend: 10% up to $150k/month, 7% next $350k, 5% next $500k, 3% over $1M. Everything in On-Ramp, plus: a designated Technical Account Manager (named, not pooled), response target of 15 minutes for business-critical system down (24/7), unlimited Well-Architected reviews, unlimited IEMs, training credits, Support API access for programmatic case and Trusted Advisor queries, operations reviews, game days. Designed for customers whose business runs on AWS, where downtime costs real money per minute, or who need the documented vendor-relationship evidence for regulators.

Side by side

Plan	Case response (business-critical)	24/7	Trusted Advisor	TAM	Floor / Monthly cost	Typical fit
Basic	N/A (no cases)	✗	Core checks only	✗	$0	Experimentation
Developer	12 h, business hours	✗	Core checks	✗	$29 / 3%	Dev & test
Business	1 h	✓	Full checks	✗	$100 / 10% → 3% tiered	Production without TAM
Enterprise On-Ramp	30 min	✓	Full checks	Pool	$5,500 / 10% tiered	Mid-size production
Enterprise	15 min	✓	Full checks	Designated	$15,000 / 10% → 3% tiered	Business-critical, regulated

Reading across: Developer fails on 24/7; Business is the first plan that answers the pager at 3am; On-Ramp and Enterprise are distinguished mostly by whether the TAM is named or pooled and by the response-time target (30 minutes vs 15). Cost scales with usage, but the percentage drops at each tier at higher spend, which is why Enterprise becomes cheaper per-dollar than Business once the monthly bill crosses a certain threshold (roughly the $150k/month mark, depending on mix).

Matching divisions to plans

The picks in depth

Division A. Developer. Fourteen tickets in a year, all during business hours, all “how do I” or “please increase my quota”. At Business’s tier pricing, 10% of the first $10k of monthly spend, the company is currently paying roughly $800 per month for a plan whose 24/7 phone support nobody has used. Dropping to Developer at $29/month saves about $770/month against the current bill while still giving the developer unlimited web cases with a 12-hour business-hours response. The one place to be careful: Developer is a single-primary-contact plan. If the division grows a second engineer who needs to open cases, that forces a move to Business regardless of usage. Worth putting a note in the annual renewal diary to revisit if the team doubles.

Division B. Business. Business is the sweet spot for production workloads without a regulatory named-contact requirement. At $180k/month of AWS spend, the tiered percentage works out to $10k on the first $10k (capped at 10%), $4.9k on the next $70k (7%), and $5k on the remaining $100k (5%), roughly $10,400/month for the support relationship. For that, the platform team gets: unlimited cases from any engineer; phone and chat on top of web; a 1-hour response target for production-down issues, 24/7; full Trusted Advisor covering cost, performance, security, fault-tolerance, service-limits, and operational-excellence checks; AWS Infrastructure Event Management available as an add-on for the product launches where it matters.

The gap to On-Ramp is the 30-minute response target and the pool TAM. For a platform with a 99.95% SLA, an extra 30 minutes of response time on a Sev-1 is about 0.05% of uptime in a single month, meaningful if it happens twice, less meaningful if Business’s 1-hour target is hit in practice at 20-30 minutes most of the time (which, by the platform team’s incident history, it is). The pool TAM at On-Ramp is less useful than Business’s full Trusted Advisor plus a reasonable in-house SRE practice. If Division B’s incidents start involving multi-hour AWS root causes, the calculus changes; until then, Business is the correct answer.

Division C. Enterprise. The explicit requirements from the CIO map cleanly: “a named senior engineer we can call during an incident”, a designated TAM, which only Enterprise provides (On-Ramp gives a pool); “a named account person we can call during business hours”, included via account-team access; “a formal quarterly architecture review”. Enterprise’s unlimited Well-Architected Framework Reviews satisfy this. The 15-minute critical-response target (vs 30 for On-Ramp, 60 for Business) is non-negotiable for a regulated lender running on a six-week migration timeline where AWS infrastructure will be the single largest vendor risk.

At $420k/month of AWS spend, the tiered percentage: $15k on the first $150k (10%), $6.1k on the next $270k (at 7% over $150k…). Running that properly: $15k on the first $150k at 10%, then the remaining $270k falls in the 7% band, so $18.9k, for a total of about $33,900. Wait, let me recheck: Enterprise’s tier thresholds are different from Business. Enterprise: 10% up to $150k/mo, 7% next $350k (so $150k to $500k), 5% next $500k (so $500k to $1M), 3% over $1M. So $420k falls entirely within the first two bands: $15k at 10% on the first $150k, $18.9k at 7% on the $270k above $150k = about $33,900/month. Roughly. The exact figure depends on current published tier boundaries; the order of magnitude is $30-35k/month for Enterprise at this usage level.

The floor ($15,000) never binds at Division C’s spend; the percentage does. As the business grows, the percentage tiers down, at $1.5M/month the effective rate is closer to 6%, which is one of the few places where growth makes a support bill cheaper per dollar. For a regulated lender whose vendor-management policy will need documented evidence of the support relationship, the named TAM, the quarterly WAFRs, the game days, and the Support API (which lets Security Hub integrate cases into the company’s own SIEM) all make the price line-itemisable in a way the board will understand.

A worked scenario: the 2am page

One Wednesday in March, six weeks after the new support contracts take effect, Division B’s payments platform starts throwing 5xx errors from the checkout API. The on-call engineer, Ravi, gets paged at 02:14 local time.

First ten minutes. CloudWatch confirms a spike in 5XXError from the ALB. Internal dashboards point at Aurora Postgres, reader endpoint latency has tripled, and the primary’s CPU is at 94%. Ravi runs the usual triage: deploys aren’t in flight, no unusual traffic patterns, no new dashboards. The pattern doesn’t look like anything the runbook covers.

At 02:27. Ravi opens a support case: severity “Production system down”, describes the symptom set, attaches the RDS identifier and the affected time range. Per Business support’s 1-hour target for production-down, the case enters the priority queue.

At 02:41. Fourteen minutes after the case opens, an AWS Database Support engineer replies with an initial diagnostic suggestion: the Aurora cluster is showing a specific error pattern consistent with an internal AWS issue in eu-west-1 that has been under investigation for forty minutes. A service-impact bulletin is about to post on the Service Health Dashboard.

At 02:48. The bulletin posts. Ravi updates the internal incident channel: “AWS-side issue, active mitigation in progress, ETA ~30 min.” The support engineer stays on the case, updating every fifteen minutes. At 03:22 the cluster recovers; the incident closes at 03:40 with a total customer-visible window of 58 minutes, inside the 99.95% monthly budget.

The post-incident review. Three things stand out. First, Business support’s 1-hour target was hit in 14 minutes on this case, typical, not worst-case. Second, having a support engineer confirm the issue was AWS-side within half an hour shortened the customer-communication timeline by at least twenty minutes; without that confirmation the team would have spent more time trying to fix a problem that wasn’t theirs. Third, the incident is exactly the class of event where Enterprise Support’s 15-minute target might have shaved ten more minutes off, for Division B, a minute of downtime is expensive but not catastrophic, so the $10k/month Business plan is the correct balance; for Division C’s bank, where “system down” is in contract language, the 15-minute target is worth the extra $20k/month.

What’s worth remembering

1. Four paid plans (and Basic). Developer, Business, Enterprise On-Ramp, Enterprise. Basic is the free default that comes with every account and is not a real choice for production.
2. Developer is single-seat, business-hours, web-only. $29/month or 3% of spend. Right for dev/test and sandbox accounts where a same-day answer to a quota question is fine.
3. Business is the first 24/7 plan. $100/month floor or 10% tiered down to 3%. One-hour target for production-down. Full Trusted Advisor. Unlimited seats. Phone and chat on top of web. Right for production without regulatory named-contact requirements.
4. Enterprise On-Ramp sits between Business and Enterprise. $5,500/month floor, 30-min critical response, pool-based TAM, one WAFR per year. Designed for customers who need some of Enterprise but can’t justify Enterprise’s floor.
5. Enterprise is the named-relationship tier. $15,000/month floor, 15-min critical response, designated TAM, unlimited WAFRs, unlimited IEMs, Support API, game days, operations reviews. The vendor-relationship evidence a regulated customer’s auditor wants to see.
6. Pricing is tiered percentage of monthly AWS usage. Percentages drop as spend grows, at sufficient scale Enterprise costs a smaller fraction of the bill than Business would on the same account.
7. Trusted Advisor’s full check set is on Business and above. Basic and Developer get the core seven checks; everything else, full cost, performance, security, fault-tolerance, service-limit, operational-excellence coverage, requires Business or higher.
8. Pick the plan for the pager, not for the feature list. The question that matters is “at 2am on a Sunday, what response time do we need, from whom, to what escalation level?”, the answer prices the plan.

Three divisions, three pagers that fire differently, three plans. Division A’s pager almost never fires and doesn’t need to be answered at 3am. Developer. Division B’s pager fires occasionally and needs an answer inside the hour. Business. Division C’s pager fires for a regulator-watched business with named-contact requirements. Enterprise. The plan that’s cheapest is the one that matches how often the phone needs to be answered, by whom, and how fast.