Can a cloud platform really be free? That’s the question thousands of developers, students, and startup founders ask every month when they type “AWS free tier” into a search bar. The short answer is yes, but with a catch that has burned plenty of people: free has limits, and those limits are measured in hours, requests, and gigabytes that reset on a schedule you need to understand. (Cloud) (Cloud computing)
This guide walks through how the AWS Free Tier is structured, what the most useful allowances look like, where people commonly slip up, and the practical habits that keep a bill at zero. It sticks to what the platform’s own documentation says and flags the areas where terms change often enough that you should double-check before you build.
What the AWS Free Tier Actually Is
The AWS Free Tier is a set of usage allowances that let new and existing customers try cloud services without paying, up to certain monthly caps. It is not a free trial in the traditional sense, and it is not a separate account type. It is a billing arrangement layered on top of a normal AWS account. (AWS Overview: Introduction to AWS)
AWS organizes these allowances into three buckets, and knowing which bucket a service falls into changes how you plan around it:
| Category | How it works | Example services |
|---|---|---|
| 12-month free tier | Free for 12 months from the date you create your account | EC2 (750 hours/month of a small instance), S3 Standard storage, RDS |
| Always free | Free indefinitely, within monthly limits, for all accounts | Lambda, DynamoDB, CloudWatch |
| Short-term trials | Free for a limited window or a one-time credit, then billed normally | Various specialty services |
The clock on the 12-month tier starts the moment the account is created, not when you first launch a resource. That detail matters. Someone who signs up, pokes around for six months, and then starts a real project has only half their window left.
AWS has also revised how new accounts are onboarded over the years, and the exact mix of credits and time-limited plans has shifted. Because these terms change, the safest move is to read the current terms on the official AWS Free Tier documentation before you commit a project to it.
The 12-Month Tier: The Classic Allowances
The 12-month tier is what most people mean when they talk about the AWS Free Tier. Historically it has included:
- 750 hours per month of a small EC2 instance (the t2.micro family, and in some regions t3.micro), which is enough to run one instance continuously for a month
- 5 GB of S3 Standard storage plus a modest allowance of requests and data transfer
- 750 hours of a small RDS database instance, covering common engines
- A slice of EBS storage and snapshots to go with the compute
Two things trip people up here. First, 750 hours is a monthly total, not a per-instance allowance. Run two instances around the clock and you burn through 1,440 hours, well past the cap. Second, the free instance type is small. It is fine for a hobby project, a test environment, or a learning exercise, but it will not carry a production workload.
The S3 allowance is similarly easy to misread. Storage is cheap, but requests and data transfer out are separate line items. A static site with light traffic stays comfortably inside the free limits. A site serving large files to thousands of visitors will not.
Always-Free Services: The Long Game
The always-free category is where the platform gets genuinely interesting for people building small applications. These allowances do not expire with the 12-month clock.
AWS Lambda is the standout. The always-free allowance covers a substantial number of requests and compute-seconds per month, which is more than enough for a personal API, a webhook handler, or a scheduled job. Because Lambda bills per invocation and per unit of compute time, an idle function costs nothing at all. That property, paying only when code actually runs, is the reason serverless architecture caught on so widely. If you want the deeper concept behind it, the general idea of serverless computing is worth reading up on separately.
DynamoDB offers a storage allowance plus a capacity allowance in its on-demand mode, enough for small datasets and low-traffic apps. CloudWatch includes a set of free metrics and alarms, which is convenient because you will want those alarms to watch your own spending.
The pattern across all of these: the free allowance is generous for small workloads and meaningless for large ones. That is by design. The platform wants you to prototype cheaply and pay when you scale.
Where the Surprise Bills Come From
Search any developer forum and you will find the same story: someone set up a “free” project, forgot about it, and got a bill for a few hundred dollars months later. The causes are predictable.
Leaving resources running. A stopped EC2 instance still incurs charges for its attached storage. A forgotten database keeps billing hourly. A load balancer with no traffic still costs money. The free tier covers usage, not existence, and idle resources are not always free.
Exceeding a cap without a hard stop. By default, going over a free allowance does not shut anything down. It simply starts billing at the standard on-demand rate. There is no automatic spending ceiling unless you configure one.
Data transfer out. Moving data into the platform is generally free. Moving it out is not. A project that serves images or video to the public can rack up transfer charges fast, and this line item is the one people most often overlook.
Multi-region sprawl. Free allowances are tracked per service and often per region. Deploy the same stack in three regions for testing and you may triple your consumption against a single allowance.
Forgetting the 12-month expiry. The most painful version: a project runs happily for a year, the free window closes, and the next invoice reflects full pricing for everything at once.
The fix for all of these is the same, and it is unglamorous: set a billing alarm and a budget before you launch anything. A budget that emails you at 50 percent of a five-dollar threshold costs nothing and catches almost every mistake early. Cost management discipline is a skill worth building deliberately, and cloud cost management as a field has a whole body of practice around exactly this problem.
A Practical Setup Checklist
If the goal is to learn or prototype without spending money, the order of operations matters. Here is a sequence that works: (Blog)
- Create the account and immediately set a zero-dollar budget with alerts. Do this before launching a single resource.
- Pick one region and stay there. Note it down. Resist the urge to spin up copies elsewhere.
- Start with always-free services. Lambda, DynamoDB, and a static site on S3 cover a surprising range of projects without touching the 12-month clock.
- If you need a server, use one small instance. One, not two. Tag it with a name and a purpose so future-you knows what it is.
- Turn on detailed billing reports. They show usage per service, which is how you find the line item that is quietly growing.
- Set a calendar reminder for month eleven. That is when you decide whether to keep paying or tear the project down.
- Delete rather than stop. When a project ends, terminate the instance and delete the volume, the snapshot, the database, and the elastic IP. Stopping is not enough.
The single most common mistake is skipping step one. People launch first and configure monitoring later, and by then the meter is already running. The second most common is trusting memory. Nobody remembers how many instances they launched six weeks ago, which is why the billing dashboard exists.
What the Free Tier Is Good For, and What It Is Not
Honest assessment: the AWS Free Tier is excellent for learning the platform’s primitives, running a small personal project, testing an idea before committing budget, and getting comfortable with infrastructure concepts without financial risk. It is genuinely useful, and the always-free serverless allowances in particular let a hobbyist run a real application for years at zero cost.
It is not a free hosting plan for a growing product. The moment traffic, storage, or compute crosses a modest threshold, standard pricing applies, and standard pricing on the platform is competitive but not trivial. It is also not a substitute for understanding how cloud billing works. The free tier rewards people who read the terms and punishes people who assume “free” means “no bill possible.”
A balanced way to think about it: the free tier is a generous on-ramp, not a destination. Treat it as a learning environment with a safety net you install yourself, and it will serve you well.
How the Free Tier Fits Into a Broader Cloud Strategy
For teams, the free tier is best understood as a sandbox attached to a paid account. The value is in letting engineers experiment without procurement friction, not in hosting anything that matters. That framing keeps expectations honest on both sides.
It also helps to place the offering in context. Cloud platforms compete on free allowances precisely because the switching cost of learning one platform’s primitives is high. Once a team knows how the compute, storage, and identity services fit together, staying is easier than moving. The free tier is a customer acquisition tool as much as a public service, and there is nothing wrong with that as long as you know which role you are playing.
For readers tracking how these offerings evolve, following cloud industry news is a reasonable habit, since allowance structures and onboarding models do change, and the details matter more than the headline. (News)
Conclusion
The AWS Free Tier is real, useful, and more limited than the marketing implies. It gives newcomers a genuine path to learn cloud infrastructure at no cost, especially through the always-free serverless services. It also has no automatic brake, which is why the people who get burned are almost always the ones who never set a budget alert.
The practical formula is simple: read the current terms, set spending alarms before you launch, keep your footprint small and in one region, and delete resources the moment a project ends. Do that, and the free tier does exactly what it promises. Skip it, and you join a long line of developers refreshing their billing dashboard with a sinking feeling.
FAQ
Is the AWS Free Tier really free forever?
Partly. The always-free category, which includes services like Lambda and DynamoDB within monthly caps, does not expire. The 12-month category does expire, twelve months after account creation, and pricing switches to standard rates afterward. Short-term trials expire even sooner. Check which category each service falls into before you build on it.
What happens if I go over the free tier limits?
Nothing shuts off. Usage beyond the allowance is billed at standard on-demand rates, and the charges appear on your normal invoice. There is no hard spending cap by default, which is why setting a budget with alerts is the single most important setup step.
Does a stopped EC2 instance still cost money?
Usually yes, for the attached storage. A stopped instance does not incur compute charges, but its EBS volumes keep billing, and any elastic IP associated with it may also cost money if it is not attached to a running instance. To stop all charges, terminate the instance and delete the leftover volumes and snapshots.
Can I use the free tier with an existing AWS account?
The 12-month allowances are tied to the account creation date, so an older account has likely used up its window. Always-free services remain available to any account within their monthly limits. If you are unsure what remains, the billing console shows current usage against each allowance.
How many EC2 instances can I run for free?
The allowance is measured in hours, not instances. A single small instance running continuously uses roughly 730 hours in a 31-day month, which fits inside a 750-hour allowance. Two instances running continuously use about 1,460 hours, so you would pay for the overage. Run one, or run several only part-time.
Is the free tier enough to host a real website?
For a small static site with light traffic, yes, comfortably. For anything with meaningful traffic, large media files, or a database under load, no. The data transfer and request allowances are modest, and the free compute is deliberately small. Use it to build and test, then plan a paid budget before you launch publicly.
