AWS Support Plan Migration: The January 1, 2027 Opt-In Most Accounts Will Miss

Three AWS Support plans stop existing on 1 January 2027, and for two of them nothing happens automatically. Developer Support and Business Support both require someone with console access to click an upgrade before the date, or the account drops to Basic. That is the part of this AWS support plan migration that catches teams out. A support plan is not something anyone looks at between renewals. We have opened client accounts in October and found the support tier last changed in 2019 by a person who left in 2021. The cost side of this change is mostly good news. The failure mode is an account that nobody opted in, losing its Health API access on a Monday morning.

What actually expires on 1 January 2027

Three plans retire on that date: Developer Support, Business Support, and Enterprise On-Ramp. AWS documents all three in Developer, Business, and Enterprise On-Ramp end of support. The lineup afterwards is Basic, Business Support+, Enterprise Support, and Unified Operations.

Two carve-outs matter before you plan anything. Developer Support, Business Support, and Enterprise On-Ramp all stay available in the AWS GovCloud (US) Region, so a GovCloud workload is not on this clock. And AWS's own pages do not agree on the On-Ramp date. The user guide says On-Ramp is discontinued on 1 January 2027, while the AWS Support FAQ says On-Ramp customers "will continue to be supported through December 31, 2026". Those describe the same cutover, but if you are writing a contract date into a runbook, use 31 December 2026 and give yourself the day.

Only one of the three transitions is automatic

Enterprise On-Ramp is the easy one. AWS moves On-Ramp customers to Enterprise Support through 2026, either at contract renewal or in periodic batches, and emails a month before the upgrade. No action is required. If you are on On-Ramp, your job is to make sure that email reaches a distribution list rather than one person's inbox.

Developer and Business are different. The FAQ is explicit that Developer and Business customers must actively opt in to Business Support+ before 1 January 2027, and that a Developer account which does not opt in accepts a downgrade to Basic Support. AWS's wording on what happens to an unattended Business account is less direct, which is not a gap we would plan around. Treat both as opt-in or lose it.

Here is our read on why this trips people. A plan retirement that bills you more gets noticed, because finance sees it. A plan retirement that silently reduces your tier does not show up anywhere until the first time someone needs a severity-1 case at 2am and finds the option greyed out.

The automation that stops working when an account lands on Basic

Cost is recoverable. An account that falls to Basic breaks code, and that is the part worth auditing first.

The AWS Health API requires a paid plan. The AWS Health API documentation states that you need Business Support+, Enterprise Support, or Unified Operations to use it, with a transitional allowance for Business, Enterprise On-Ramp, or Enterprise Support plans. Call it from an account without one and you get a SubscriptionRequiredException. Anything you have built on Health events is in scope: scheduled-change ingestion into Jira, EC2 retirement notifications routed to Slack, EventBridge rules that open a ticket when AWS announces maintenance on an RDS instance.

The AWS Support API and the full Trusted Advisor check set are in the same category. Business Support+ includes the full set of Trusted Advisor checks and the Support API for creating, updating and closing cases from code. Basic gets six security checks plus the service limit checks, and no Support API.

Find the exposed accounts before December, not after:

# Illustrative probe. Run it with credentials for each account you want to test.
# A clean exit means the account has a qualifying plan; a SubscriptionRequiredException
# means it will lose Health automation if it lands on Basic.

for ACCOUNT_ID in $(aws organizations list-accounts \
      --query 'Accounts[?Status==`ACTIVE`].Id' --output text); do

  CREDS=$(aws sts assume-role \
    --role-arn "arn:aws:iam::${ACCOUNT_ID}:role/OrganizationAccountAccessRole" \
    --role-session-name support-plan-audit \
    --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
    --output text 2>/dev/null) || { echo "${ACCOUNT_ID} assume-role failed"; continue; }

  read -r AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN <<<"$CREDS"
  export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

  if aws health describe-event-types --max-items 1 --region us-east-1 >/dev/null 2>&1; then
    echo "${ACCOUNT_ID} health-api-ok"
  else
    echo "${ACCOUNT_ID} health-api-blocked"
  fi
  unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
done

The role name in that snippet is the AWS Organizations default for accounts created through the console. Substitute whatever your account vending actually provisions.

Run the new tiers against your own bill

Business Support+ is billed as the greater of $29 per month or a tiered percentage of monthly AWS charges: 9% on the first $10,000, 7% from $10,000 to $80,000, 5% from $80,000 to $250,000, and 3% above $250,000. Enterprise Support is the greater of $5,000 per month or 10% on the first $150,000, 7% from $150,000 to $500,000, 5% from $500,000 to $1 million, and 3% above that. Both sets of tiers come from the AWS Support pricing page.

Applied to a few spend levels:

| Monthly AWS spend | Business Support+ | Enterprise Support | Enterprise premium | |---|---|---|---| | $5,000 | $450 | $5,000 (floor) | $4,550 | | $20,000 | $1,600 | $5,000 (floor) | $3,400 | | $50,000 | $3,700 | $5,000 | $1,300 | | $120,000 | $7,800 | $12,000 | $4,200 | | $300,000 | $15,800 | $25,500 | $9,700 |

Working the $120,000 row, because the arithmetic should reproduce: Business Support+ charges 9% of the first $10,000 ($900), 7% of the next $70,000 ($4,900), and 5% of the remaining $40,000 ($2,000), for $7,800. Enterprise sits entirely inside its first band, so 10% of $120,000 gives $12,000.

Two things fall out of that table. Business Support+ is cheaper than the old Business Support at the bottom of the range, since the minimum dropped from $100 per month to $29. And AWS says existing Business and Enterprise customers will not see a cost increase, which matches the tier rates being flat or slightly lower than the plans they replace.

Enterprise Support got cheaper to enter, and that changes the answer

The Enterprise minimum fell from $15,000 per month to $5,000. That sounds like a pricing footnote and is actually the most consequential number in the announcement.

The floor binds until your tiered amount catches up with it. At 10% on the first band, the old $15,000 floor meant you paid a flat $15,000 until monthly AWS spend reached $150,000. The new $5,000 floor binds only until $50,000 of monthly spend. The band of companies for whom Enterprise Support was priced like a punishment shrank by $100,000 of monthly spend.

So who should move up? We would recommend Enterprise over Business Support+ when any of three things is true. You have a contractual recovery-time commitment tighter than your ability to escalate, and you need the 15-minute production-critical response. You run a regulated workload where AWS Security Incident Response at no extra cost offsets a chunk of the premium. Or you are spending above roughly $120,000 a month and the premium has become a small fraction of the bill while the designated TAM is doing real work on your architecture reviews.

Below $50,000 a month, stay on Business Support+ and spend the $1,300 difference on something that moves. That advice is the opposite of what your account team will suggest, and we have yet to see the Enterprise floor pay for itself at that spend level.

The per-account mechanics that account vending will surprise you with

The console gives you two ways to enrol, and the difference matters more than the price. From Change AWS Support Plans, an organization in all-features mode can subscribe its entire organization to Business Support+, and only the management account can do it. The alternative is enrolling account by account.

Two behaviours follow from organization-level enrolment. Any new account created within or invited to the organization is automatically subscribed to Business Support+. And an account previously subscribed at the organization level is downgraded to Basic when it leaves the organization.

Both are sharp edges for anyone running automated account vending. The first means your sandbox factory now attaches a paid support plan to every throwaway account it mints, and the pricing page states the $29 minimum per account. The second means an account migration between organizations, which teams do during acquisitions and reorganisations, silently strips the support plan off the account mid-move.

We would do two things before enrolling an organization. Put your account count and your consolidated spend into the pricing calculator in the Support Plans console and read the number it gives back. Then get your account team to confirm in writing how the per-account minimum interacts with consolidated billing for your organization, because that single answer decides whether organization-level enrolment is a rounding error or a line item. Ambiguity in a pricing page is not a reason to guess.

What we are doing on client accounts before December

A ten-week plan, in the order we run it.

Weeks one and two are inventory. List every account and its current support plan, flag the ones on Developer or Business, and note which ones are GovCloud and therefore out of scope. Run the Health API probe above and record which accounts have working automation to lose.

Weeks three and four are the automation audit. Grep your infrastructure and tooling repositories for health.describe_event_types, DescribeEvents, Support API calls, and Trusted Advisor checks consumed by anything other than a human. Every hit is a dependency on a paid plan.

Weeks five and six are the decision. Run the table above against your own consolidated spend, decide Business Support+ or Enterprise per payer, and get the per-account minimum answered in writing.

Weeks seven and eight are execution. Opt in. Organization-level if the answer on minimums came back clean, account-level if it did not.

Weeks nine and ten are verification. Re-run the probe, confirm no account reports health-api-blocked, and set a calendar reminder for mid-December to check again. Account vending runs between now and then.

Teams that already went through our Amazon DevOps Guru end of support work will recognise the shape of this, and there is a direct connection: AWS DevOps Agent, one of the replacements in that post, is included with Business Support+. If this migration is the first time anyone has looked at AWS spend commitments in a while, the ownership problem underneath it is the one we describe in Building a FinOps practice.

When to Get Help

Most teams can run this themselves in an afternoon of inventory and a week of waiting on the account team. Bring in help when the account count is large enough that the per-account minimum question has a real answer, when you have Health API automation feeding incident response and cannot afford a gap, or when the Enterprise decision is tied to a customer commitment you have already signed.

We do this work as a fixed-scope engagement: account inventory, automation dependency audit, a costed recommendation per payer account, and the cutover. If the 1 January date is closer than your change freeze allows, get in touch and we will start with the accounts that have automation to lose.