The AWS Free Tier gets pitched as a no-risk way to learn cloud computing, and mostly that’s true, right up until the month someone spins up an EC2 instance, forgets about it, and comes back three weeks later to a bill that shouldn’t exist on a “free” account. That gap between the promise and the actual experience is almost always a monitoring problem, not a pricing problem. This guide covers what the Free Tier actually includes, the specific limits that trip people up, and the habits that keep an account genuinely free for the full twelve months instead of turning into a surprise invoice.
What the AWS Free Tier Actually Is
AWS Free Tier isn’t a single offer, it’s three different types of free usage bundled under one name, and confusing the three is where a lot of unexpected charges originate.
- 12-months-free tier: Available only to new AWS accounts, starting from the date of sign-up. This covers specific usage limits on core services like EC2, S3, and RDS, and expires exactly one year after account creation regardless of how much of the allowance was actually used.
- Always-free tier: A smaller set of services with permanently free usage limits that don’t expire after twelve months, AWS Lambda’s free monthly invocations are the most commonly used example.
- Short-term trials: Time-limited free access to specific services (often 30 to 60 days) that starts from first use of that particular service, independent of the account’s overall 12-month clock.
The critical distinction: only the first category has a hard expiration tied to account age. Mixing it up with the always-free tier is exactly how people end up surprised when charges start appearing on month 13, having assumed everything they’d been using was permanently free.
It helps to think of these three categories as answering three different questions rather than one. “What’s free for my first year” is the 12-months-free tier. “What stays free no matter how old my account gets” is the always-free tier. “What’s free to try right now, regardless of account age” is the short-term trial category. Keeping those three questions separate in your head, rather than treating “Free Tier” as one undifferentiated pool of free stuff, is most of what it takes to avoid the account-age surprise that catches so many first-year AWS users off guard.
Who the Free Tier Actually Fits
The Free Tier is genuinely well-suited to a specific set of use cases: someone learning AWS fundamentals through hands-on practice, a developer prototyping a small application before deciding whether it’s worth a real budget, a student working through cloud certification material, or a hobbyist running a low-traffic personal project. It’s less well-suited, despite how it’s sometimes marketed in beginner tutorials, to anything resembling a production workload with real users, since the compute and storage allowances are deliberately modest, sized for learning and experimentation, not for hosting something that needs to reliably serve traffic.
Recognizing which category a given project falls into early avoids a specific kind of frustration: building something on Free Tier resources, having it start to get real usage, and then discovering the free allowance was never intended to support that usage in the first place. Planning for a transition to paid resources once a project shows real traction is a healthier mental model than treating the Free Tier as a permanent home for anything that succeeds.
What’s Actually Covered, And What Isn’t
The specific services and limits change periodically, so treating any fixed number as permanent is a mistake, always verify current limits on AWS’s own Free Tier page before relying on a specific figure. That said, the categories that consistently show up in the 12-months-free tier include:
- Amazon EC2, a monthly allowance of hours on specific instance types, intended for one small virtual server running continuously, not multiple instances or larger instance sizes.
- Amazon S3, a fixed amount of standard storage plus a monthly allowance of GET and PUT requests.
- Amazon RDS, free hours on specific database instance types plus a storage allowance, again scoped to specific instance classes rather than any database size.
- Amazon DynamoDB, a specific read/write capacity allowance under the always-free tier, making it one of the few genuinely permanent free options for a small application’s data layer.
- AWS Lambda, a monthly allowance of free requests and compute time under the always-free tier, generous enough that many small serverless projects never leave the free allowance at all.
What’s easy to miss: these limits are per-service and often per-instance-type, not a general “AWS is free” allowance. Launching a larger EC2 instance type than the one covered by the free tier, or running a second database instance alongside the free one, generates charges immediately, there’s no soft warning before the meter starts running on anything outside the specific covered configuration.
The Mistakes That Turn “Free” Into a Bill
Forgetting to Shut Down Resources
The single most common cause of unexpected AWS charges on a Free Tier account isn’t exceeding a limit, it’s simply forgetting a resource is running. An EC2 instance launched for a weekend project and never terminated keeps consuming free-tier hours (and then billed hours, once the monthly allowance is exhausted) whether or not anyone is using it. The fix is procedural, not technical: treat “did I shut this down” as a mandatory last step of every session working with AWS resources, the same way closing a laptop lid is a habit rather than a decision made fresh each time.
Mismatched Instance or Storage Types
Free Tier coverage is usually scoped to a specific instance size (commonly the smallest general-purpose type) and a specific storage class. Selecting a larger or different-tier option during setup, sometimes just one dropdown menu away from the free option, and not always obviously flagged in the interface, starts billing immediately even while the account otherwise still shows Free Tier eligibility.
Multiple Regions, Multiple Meters
Free Tier limits typically apply per account, aggregated globally in AWS’s usage tracking, but resources launched in different regions can behave unpredictably if a user assumes each region gets its own separate free allowance, it generally doesn’t. Spinning up test resources in several regions “just to compare” is a common way to blow through a shared monthly allowance faster than expected.
Data Transfer Charges
Inbound data transfer to AWS is typically free, but outbound data transfer (serving content to end users, for example) is billed past a modest free allowance, and this is one of the most commonly missed cost categories by people focused only on compute and storage limits. A small personal project rarely hits this ceiling, but anything with real traffic can cross it faster than expected.
Setting Up Guardrails Before You Need Them
Billing Alerts
AWS Billing preferences include an option to receive alerts at specified spending thresholds. Setting this up during initial account setup, not after the first surprise bill, is the single highest-leverage five-minute task on this entire list. A $1 or $5 alert threshold catches a runaway resource within a day or two rather than a full billing cycle later.
AWS Budgets
Beyond simple billing alerts, AWS Budgets lets an account holder set a specific dollar target and receive notifications at percentage thresholds of that target (50%, 80%, 100%), giving earlier warning than a single fixed-dollar alert. For anyone actively experimenting with multiple services, a budget covering the whole account is worth the few minutes of setup.
CloudWatch for Usage Monitoring
Amazon CloudWatch provides visibility into resource usage patterns, not just final billing, useful for catching a resource that’s running but not actually being used, before it accumulates enough hours to matter financially. It’s a heavier tool than a billing alert, and probably not necessary for a first small project, but worth adopting once usage gets complex enough that manual tracking becomes unreliable.
Tagging Resources
Applying consistent tags (project name, purpose, “temporary” vs. “keep”) to every resource created makes a monthly cleanup pass dramatically faster. Without tags, figuring out which of a dozen resources are safe to delete requires reconstructing context that’s easy to forget within a few weeks of creating something.
Services That Quietly Aren’t Free Even on a Free Tier Account
Beyond the well-known limits on EC2 and S3, a handful of AWS services and configurations catch Free Tier users off guard specifically because nothing about the interface signals they’re outside the free allowance:
- Elastic IP addresses left unattached. AWS provides a small number of Elastic IPs at no charge while they’re attached to a running instance, but an Elastic IP reserved and then left unattached (after an instance is stopped or terminated, for example) starts accumulating hourly charges. This is one of the most common sources of small, confusing charges on accounts that otherwise stayed within free-tier limits everywhere else.
- NAT Gateways. Unlike most core compute and storage services, NAT Gateways are not covered by the Free Tier at all and bill by the hour plus data processed from the moment they’re created, regardless of account age or usage level.
- Load balancers. Application and Network Load Balancers carry their own hourly charges outside the Free Tier’s EC2 allowance, a detail that’s easy to miss when following a tutorial that adds a load balancer in front of a “free” EC2 instance without flagging the extra cost.
- Snapshot and backup storage. EBS snapshots and RDS automated backups accumulate storage charges of their own, separate from the primary volume or database storage allowance, and can quietly grow over months of automatic backups nobody’s actively reviewing.
None of these are hidden fees in any deceptive sense, they’re documented, just easy to miss when a tutorial or getting-started guide focuses attention on the headline free services and glosses over the supporting infrastructure around them.
Free Tier vs. Reserved Instances and Savings Plans: Don’t Confuse the Timelines
Once the 12-month Free Tier period is approaching its end, or for workloads that will clearly outgrow free-tier limits, AWS offers Reserved Instances and Savings Plans, mechanisms for committing to usage in exchange for a discounted rate, unrelated to the Free Tier program itself. These are worth understanding as the natural next step for anyone whose project graduates past free-tier limits, but they require an upfront or ongoing commitment and shouldn’t be confused with anything “free.” Evaluating them makes sense once actual usage patterns are established, committing to a reserved instance before knowing real usage needs risks locking into a size or type that turns out to be wrong.
A Quick Pre-Launch Checklist
Before spinning up anything new on a Free Tier account, running through a short checklist catches most of the common mistakes before they cost anything:
- Confirm the exact instance type or storage class selected matches what’s documented as free-tier eligible, not just “the smallest option shown.”
- Set or confirm a billing alert is active before creating any new resource, not after.
- Tag the resource with its purpose and an expected teardown date, even for a “quick test.”
- Note the resource in whatever tracking system (spreadsheet, calendar reminder, sticky note) actually gets checked regularly, the point is a system that gets used, not a sophisticated one that gets ignored.
- If the resource involves a load balancer, NAT Gateway, or Elastic IP, budget for it as a paid item from the start rather than assuming Free Tier coverage.
A Simple Monthly Routine
Rather than relying purely on automated alerts, a short monthly check tends to catch things automation misses, resources that are technically within free-tier limits but no longer needed, storage that’s accumulated past what a project actually requires, or an instance type selected months ago that no longer matches current needs. Reviewing the AWS Billing Dashboard’s usage breakdown once a month, cross-referencing it against what’s actually still in active use, takes a few minutes and catches drift that a threshold alert alone won’t flag, since drift within the free allowance doesn’t trigger any alert at all.
What Happens When the 12 Months Run Out
The 12-months-free tier expires on a fixed date tied to account creation, not usage, there’s no way to extend it by using less, and AWS does send advance notification as the expiration approaches, but relying solely on that email rather than tracking the date independently is a common oversight. After expiration, any resources still running that were previously covered under the 12-month allowance begin billing at standard rates immediately. Marking the expiration date in a personal calendar at account creation, with a reminder a few weeks ahead, avoids the scramble of realizing mid-billing-cycle that free coverage has quietly ended.
Common Questions About the Free Tier
- Does a new AWS account automatically get the 12-months-free tier, or does it need to be requested? It applies automatically to new accounts at sign-up, there’s no separate enrollment step, though a valid payment method is still required to create the account in the first place, since usage beyond free limits bills automatically.
- Can the 12-month clock be reset by creating a new account? AWS’s terms restrict Free Tier eligibility to genuinely new customers, and creating a second account specifically to reset the clock is against the terms of service, with enforcement mechanisms tied to payment details and other account signals.
- Will AWS shut down a resource automatically once a free limit is exceeded? No. Exceeding a free-tier limit doesn’t stop the resource, it simply starts billing for the usage beyond the free allowance, which is exactly why monitoring matters more than assuming a hard cap exists.
- Is there a way to set an absolute spending cap that AWS enforces automatically? AWS Budgets can trigger automated actions (like stopping specific resources) when configured with that intent, but this requires deliberate setup, it isn’t the default behavior of a billing alert, which only notifies rather than intervenes.
The Bottom Line
The AWS Free Tier genuinely delivers on its promise for the use cases it’s designed for, learning cloud fundamentals, running a small side project, prototyping something before committing real budget to it. The account holders who get burned aren’t usually victims of hidden fees; they’re victims of resources they forgot were running, instance types one click away from the free option, or a 12-month clock they lost track of. Setting up billing alerts on day one, tagging resources as they’re created, and doing a short monthly review turns the Free Tier from a source of anxiety into exactly what it’s supposed to be: a genuinely free way to get comfortable with AWS before spending real money on it.
None of the safeguards described here take more than a few minutes to set up, and all of them are one-time or low-effort recurring tasks rather than ongoing overhead. The return on that small investment is disproportionate: the difference between a Free Tier year that stays genuinely free and one that ends in an unpleasant billing surprise usually comes down to exactly these habits, not to anything more sophisticated than remembering to check.