The AWS free tier is designed for learning and small experiments, and it traps organisations at scale because it is treated as a permanent pricing model rather than a temporary allowance. It comes in three forms: a twelve month allowance for new accounts, always free limits that persist within a monthly threshold, and short term product trials. The expensive mistakes come from confusing the expiring twelve month allowance with always free, from assuming per account limits aggregate across a large estate when they do not, and from forgetting that data transfer and request charges sit outside many allowances and accrue from day one. The rule that prevents all of this is to design production as though the free tier does not exist, so crossing a threshold changes only the expected marginal cost and never the architecture.
Here is how the tiers work, where they break at scale, and how to govern them across many accounts.
What are the three kinds of AWS free tier?
Free tier is not one thing, and the differences are where the surprises hide.
- Twelve month free. A starter allowance on new accounts covering a small compute instance, a block of storage, and similar, which expires twelve months after the account is opened. The expiry is silent: usage that was free in month eleven is billed in full in month thirteen.
- Always free. Limits that persist within a monthly threshold, such as a quota of Lambda invocations or a volume of certain requests. These do not expire, but they are capped, and crossing the cap moves the entire usage to the standard rate.
- Short term trials. Time boxed trials on specific services that end on a date regardless of account age.
An architecture that quietly depends on any of these will see its bill step up the moment the allowance ends or the threshold is crossed, with no change in what the application is doing.
Why does the free tier break at enterprise scale?
At scale the free allowance is a rounding error against real consumption, so anything built around it is fragile. Three failure modes recur. First, expiry: a fleet of accounts opened at different times crosses the twelve month line on a rolling basis, producing a creeping bill that no single change explains. Second, aggregation: teams assume the always free limits combine across a large organisation, but the thresholds apply per account, so a hundred accounts each near a cap produce far more billed usage than a single account would suggest. Third, the lines outside the tier: data transfer between availability zones and regions, NAT gateway processing, and many request charges sit outside the free allowances and accrue from the first day, which is exactly where AWS bills quietly grow regardless of free tier status.
A worked example
A scaling fintech spun up dozens of AWS accounts for teams and environments over its first two years, many built on patterns that assumed free tier resources stayed free. As accounts crossed their twelve month mark on a rolling basis, the bill climbed steadily with no obvious cause, and per account always free limits that everyone assumed pooled were in fact billing on each account near its cap. The fix was structural: production was redesigned to assume standard pricing throughout, free tier usage was tracked against thresholds in the Cost and Usage Report, and per account budgets and alerts caught accounts approaching a limit before the charge landed. Removing the dependency on free allowances eliminated a recurring source of surprise and was part of the broader work that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.
How do you govern the free tier across many accounts?
Govern it as a development convenience with hard guardrails, never as a production pricing assumption. The practical controls are few and effective: track free tier usage against its thresholds in the Cost and Usage Report so you see an account approaching a cap or an expiry; set budgets and alerts per account so a crossing triggers a notification rather than a month end shock; and review new account creation so each one inherits the same monitoring rather than starting unmanaged. Most importantly, design production architecture as though the free tier does not exist, so the only effect of crossing a threshold is the expected marginal cost, applied to capacity you already planned to pay for. This sits inside the wider AWS cost discipline, where the Cost and Usage Report is the source of truth and commitments cover the steady base.
Frequently asked questions
What are the types of AWS free tier?
Why does the AWS free tier cause surprise bills at scale?
How do you govern the free tier across many accounts?
Stop free tier surprises before they scale
Our AWS savings kit covers the free tier traps, the data transfer and NAT gateway lines that grow quietly, and the commitment coverage that sets the effective rate on AWS. We take zero provider commissions and answer only to you. Download the kit, and read the AWS cost optimization guide for the full method.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.