The AWS Free Tier 2026 is a different program from the one most guides describe. For accounts created after 15 July 2025, it is built on credits and a time-limited Free plan rather than twelve months of free hours. That is better in some ways, worse in others, and it has one catch that matters a lot if you set projects up properly.
This post explains what changed, how the Free and Paid plans differ, which always-free allowances actually matter for a small project, and why you should plan around those allowances rather than the credits.
What changed in the AWS Free Tier
The twelve-month free tier was replaced with a credits-based program for new accounts, and the always-free allowances stayed. If you created your account before 15 July 2025, you are on the old program and nothing here applies until it expires.
The old program gave new accounts fixed monthly amounts of specific services for twelve months: 750 hours of a small EC2 instance, 750 hours of a small RDS database, and so on. It was generous but narrow, and it was the source of a lot of surprise bills when the twelve months quietly ran out.
The new program replaces that with money. A new account gets $100 in credits at sign-up and can earn up to $100 more by completing a set of getting-started activities. The credits can be spent on any eligible service, so you are no longer steered towards EC2 and RDS just because they were the free ones.
Alongside the credits, you choose a plan when you sign up: Free or Paid. That choice is the part most people skim past. AWS documents the current program at aws.amazon.com/free, and it is worth reading the plan section twice.
Free plan versus Paid plan
The Free plan cannot bill you but will close your account; the Paid plan bills you but never closes. Pick based on which of those you would rather explain later.
| Free plan | Paid plan | |
|---|---|---|
| Sign-up credits | $100, plus up to $100 earned | $100, plus up to $100 earned |
| Charges beyond credits | None. Usage stops instead | Standard pay-as-you-go |
| Duration | Six months, or until credits run out | No limit |
| What happens at the end | Account closes unless you upgrade | Nothing |
| Data after closure | Kept 90 days for recovery | Not applicable |
| Always-free allowances | Yes | Yes |
| Can use AWS Organizations | No, this moves you to Paid | Yes |
The Free plan is a sandbox with a hard stop. It is a good fit for learning, and for an experiment you genuinely expect to throw away. The Paid plan is a normal account: no monthly fee, pay for what you use, and if you use nothing you pay nothing.
For a project you intend to keep, the Paid plan is the right answer, and not because AWS wants your money. It is because the Free plan’s end date is a cliff, and cliffs are exactly what a good setup avoids. You can upgrade from Free to Paid at any point, and unused credits come with you.
The always-free allowances that matter
For a small project, the always-free allowances are worth more than the credits, because they never expire and they cover exactly the services a small project should be using. Over 30 services include one.
The allowances are monthly, apply to every account old and new, and are listed on the official Free Tier page. The ones that matter most for a project that is still an idea:
- AWS Lambda: one million requests a month, plus a compute allowance, free every month. A small API or background job rarely gets anywhere near this.
- Amazon DynamoDB: a permanent allowance of storage and read/write capacity that comfortably covers a small application’s data.
- Amazon S3 and CloudFront: free monthly amounts of storage, requests and data transfer, enough to host a static site or small assets at no cost.
- Amazon CloudWatch, SNS, SQS and others: basic logging, notifications and queueing with free monthly amounts.
The pattern is clear. The services with always-free allowances are the ones that charge per request, per second or per gigabyte. The services without them, like a running EC2 instance or an RDS database, charge by the hour whether or not anyone is using them. Choose from the first group and an idle project costs nothing. That is the core of why AWS is a good place to start a project, independent of any credits.
The Organizations catch
Using AWS Organizations moves your account onto the Paid plan and ends credit earning. If you want one account per project, which you should, do not plan around the credits at all.
AWS Organizations is the feature that lets you create and manage multiple accounts under one umbrella. It is how you give each project its own AWS account with its own bill, its own permissions and its own blast radius. It is also the feature AWS considers a signal that you are running something real, and the Free plan is not for running something real.
So the two things a careful setup wants, account-per-project and the Free plan’s credits, are in tension. The resolution is simple once you see it: the credits were never the valuable part. $100 to $200 is nice, but it is a one-off. The always-free allowances are permanent, they apply on the Paid plan, and they cover a small project’s entire footprint.
The practical advice is: expect to be on the Paid plan, do not count on the sign-up credits, and build on services that cost $0 when idle. Your account will never shut down on you, and your bill will still be zero until you have real traffic.
How to run a project at or near $0 without credits
Pick per-request services, deploy only what the project needs, and set a budget alert before you deploy anything. Those three habits keep a small project at $0 regardless of plan.
Pick per-request services
Lambda, DynamoDB, S3, CloudFront, API Gateway and SQS all cost nothing when nobody is using them. A project built on them has no idle cost at all. If you later need a database with a running server, add it when the traffic justifies it, not on day one.
Deploy only what you need
The accounts, roles and deploy connections that a proper setup creates cost nothing on their own. An AWS account is free. An IAM role is free. An OIDC identity provider is free. What costs money is compute that runs around the clock, and a new project does not need any.
Set a budget alert first
In the AWS Billing console, create a budget with an email alert at a small number, say $5, before you deploy. It takes two minutes. If something does start costing money, you hear about it the same day. The post on avoiding a surprise AWS bill has the exact settings and the reasoning behind per-account budgets.
Know where the money goes if it goes
The common sources of unexpected cost in small projects are a NAT gateway left in a VPC, an RDS instance that was “just for testing”, a load balancer in front of nothing, and data transfer out at scale. None of these appear by accident in a serverless project. They appear when someone follows a tutorial written for a different architecture.
What this means for your next project
Treat the AWS Free Tier 2026 as a permanent set of always-free allowances with some optional one-off credits attached, not as a year of free hosting. Set up properly, on the Paid plan, with per-request services and a budget alert, and the project costs $0 while it is an idea and a few dollars a month once it is real.
That setup is what TigerSoup does for each new project: its own AWS account through Organizations, keyless deploys from GitHub, and a foundation built on services that cost nothing until you run something. It is free for Mac, with no subscription, and the only bills you could ever get are from AWS and GitHub, for what you actually use.
