CloudFront flat-rate plans become manageable through the API and IaC
On September 3, 2026, AWS opened programmatic management of CloudFront flat-rate plans through the new PricingPlanManager API, the CLI, CloudFormation and the CDK. Teams can now codify subscribing, changing tiers and cancelling a no-overage monthly price, with a two-phase approval that prevents unintended billing.
November 2025. AWS launches CloudFront flat-rate plans, promising one monthly price with no overage charges. September 3, 2026. Managing those plans leaves the console and becomes scriptable through the API, the CLI, CloudFormation and the CDK. Hundreds of thousands of customers. That is the order of magnitude AWS claims for adoption of the grid in four months. Why it matters: for the first time, a CDN cost — historically the hardest to predict during a spike — can be pinned to a monthly figure written in a repository, reviewed in a pull request and deployed like any other infrastructure resource.
A fixed price that still escaped the code
The paradox of flat-rate plans could be summed up in one sentence: AWS was selling predictability, but only through clicks. Since November 2025, subscribing to a plan, changing its tier or cancelling it meant going through the CloudFront console — a manual action, impossible to reproduce across environments, to audit in a repository or to run through code review. A team provisioning its CDN with IaC was left with a blind spot: the whole perimeter was declarative except the billing.
The September 3, 2026 announcement closes exactly that gap. CloudFront now exposes its plans through the PricingPlanManager service, reachable via the CLI, the SDKs, CloudFormation and the CDK. Concretely, you can subscribe, change tiers and cancel a plan programmatically, with the same lifecycle as the rest of the stack. The pricing grid becomes a configuration object like any other.
What a plan covers
A flat-rate plan bundles the services a website or application almost always consumes together. For a single monthly price it covers the CloudFront CDN, AWS WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch log ingestion, serverless edge compute and an S3 storage credit. Four tiers structure the offer:
| Tier | Monthly price | Positioning |
|---|---|---|
| Free | $0 | Exploration, small sites |
| Pro | $15 | Light production sites |
| Business | $200 | Sustained traffic, Bot Control |
| Premium | $1,000 | High traffic, viewer mTLS |
Each tier sets a usage allowance sized for a given traffic level, but the allowance is not a hard cap: AWS notifies at 50%, 80% and 100%, and absorbs overages without surcharging. You can also mix flat-rate plans and pay-as-you-go across distributions within one account, which avoids migrating everything at once.
PricingPlanManager, the new building block
The PricingPlanManager service is the technical heart of the announcement. Its endpoint lives in us-east-1, and CloudFront is currently the only supported plan family. Two design choices matter to an SRE: optimistic concurrency and two-phase approval.
Every mutation relies on an ETag. You read the subscription, capture its eTag, then pass that value back through the --if-match parameter of the write. If the subscription changed in the meantime, the call fails with a ConflictException rather than overwriting a concurrent change:
# List the account's subscriptions
aws pricing-plan-manager list-subscriptions --region us-east-1
# Read a subscription's ETag before any mutation
SUBSCRIPTION_ARN="arn:aws:pricingplanmanager:us-east-1:111122223333:subscription/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
ETAG=$(aws pricing-plan-manager get-subscription \
--arn "$SUBSCRIPTION_ARN" \
--query 'eTag' \
--output text)
# Move a subscription to Premium, passing the ETag back
aws pricing-plan-manager update-subscription \
--arn "$SUBSCRIPTION_ARN" \
--if-match "$ETAG" \
--plan-tier PREMIUMA subscription’s lifecycle moves through explicit statuses — ACTIVE, PENDING_APPROVAL, SYNC_IN_PROGRESS and FAILED — and applying a change takes 2 to 5 minutes. A failure leaves a readable statusReason explaining the cause, instead of a silent billing gap.
Two-phase approval, the financial safety net
The most useful decision in PricingPlanManager is the approval mode chosen when creating a paid plan. IMMEDIATE mode activates billing in a single step. MANUAL mode creates the subscription in PENDING_APPROVAL and requires a second call, ApprovePaidSubscription, to start billing. An active paid subscription cannot be cancelled during the current month, and the Premium tier reaches $1,000 per month: accidentally switching on billing from a pipeline is not harmless.
AWS therefore recommends MANUAL mode for any programmatic workflow, and offers an IAM permission split to enforce it technically: the automation role gets pricingplanmanager:CreateSubscription, while pricingplanmanager:ApprovePaidSubscription stays reserved for a role that requires human authorization.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "pricingplanmanager:CreateSubscription",
"Resource": "*"
}
]
}With that split, an agent or pipeline can prepare a tier change without ever starting billing: precisely the guardrail that was missing to fold CDN cost into GitOps.
What the grid gained since November
The offer also matured on the feature front. At launch, some distributions could not switch to a plan because they used features the plans did not yet support. AWS closed those holes in four months. Lambda@Edge and AWS WAF CAPTCHA are now included — Lambda@Edge invocations remain billed pay-as-you-go on top of the plan. mTLS arrived in two flavors: origin mTLS from the Business tier, viewer mTLS on Premium.
The AI activity dashboard, included from the Pro tier, adds visibility into the AI bot and agent traffic hitting the application — trends, the most active bots, the most requested paths. Blocking controls, through WAF Bot Control, stay at Business and above. The intent is clear: a plan must never be a compromise that degrades the security of an existing distribution.
How a plan absorbs a spike
The “no overage” promise deserves a precise reading. The monthly allowance is not a cap: the first spike, up to three times the allowance, is fully accommodated that month. Beyond that, excess usage is evaluated over several months, and only significant, prolonged overages would lead AWS to adjust how your traffic is delivered — without ever charging extra. The exit is always the same: move up a tier.
This mechanism changes the equation for a team dreading the viral moment. The worst case is no longer a surprise bill but an invitation to revisit the tier. For budget predictability that is progress; for finops it is a shift of attention — from “how much will this cost” to “which tier do I actually live in”.
What this changes for FinOps
Switching from a variable to a fixed cost moves the nature of financial vigilance. On pay-as-you-go, the question is “how much did this spike cost me” — an answer that arrives after the fact, on the bill. With a plan, the question becomes “which tier do I actually live in”, and the answer reads in real time: the console shows historical usage against each tier’s allowance when you convert or change tier.
For a FinOps team, the plan is not an automatic saving: it is a risk transfer. You trade bill volatility against the cost of a tier that may be oversized during quiet periods. The right reflex is to size the tier on the median of traffic, not the peak, and to re-evaluate the distribution every quarter — now possible through code, and therefore automatable.
Verdict
If you already provision CloudFront with IaC and your traffic is stable or predictable, move your distributions to a flat-rate plan and manage it through PricingPlanManager in MANUAL mode: you pin the monthly cost, keep the audit trail in the repo, and avoid accidental billing through the IAM permission split.
If your traffic is highly variable but prone to viral spikes, the plan still makes sense precisely because it absorbs peaks without surcharges: size the tier on your median, not on your peak.
In every case, start in the console to read your historical usage against each allowance, then move the decision into code. A CDN cost written in a repository is a cost you can discuss, audit and optimize — something no console click will ever give you.