A surprising number of side projects and small business sites still start on AWS’s free tier, and just as many get a billing surprise a few months later because they signed up expecting the old 12-month free trial structure that AWS ran for years. That structure has changed. Understanding what AWS actually offers new accounts today, rather than what older blog posts still describe, is the difference between a genuinely free first project and an unexpected charge showing up on a card you forgot was linked to the account.

This isn’t a criticism of AWS for changing the offer; every major cloud provider adjusts its free tier over time as usage patterns and abuse patterns shift. It’s a practical warning that treating any cloud provider’s free tier as a fixed, permanent fact rather than a term that gets revisited is how side projects quietly turn into monthly bills nobody planned for.

What AWS Free Tier Actually Looks Like Now

For a long stretch, AWS ran a straightforward model: sign up, and for 12 months you’d get a fixed free allotment on popular services like EC2 (750 hours a month of a small instance), S3 storage, and RDS databases, on top of a separate set of “Always Free” services with permanent limits that never expired. That 12-month structure is no longer how AWS onboards new accounts. AWS shifted to a credit-based new-customer offer instead: new signups get an initial credit applied immediately, with the option to unlock additional credit by exploring specific services, and those credits carry an expiration window from account creation rather than being tied to a flat 12-month service-by-service allowance.

The “Always Free” category is still real and still the most durable part of the free tier. These are services AWS commits to keeping free indefinitely, within stated usage caps, regardless of how long you’ve had the account or whether your signup credits have expired. That’s the part of the free tier worth building a genuine understanding of, since it’s the only piece you can rely on for a long-running low-traffic project rather than a time-boxed trial.

Where the Confusion Comes From

AWS’s free tier has changed more than once, and a lot of the guidance still circulating online, including guides published as recently as a year or two ago, describes the older 12-month trial structure as if it’s still the default for a new signup. Because AWS documentation itself updates in place rather than preserving old versions, it’s easy for a reader to land on an outdated third-party summary and configure a project around assumptions that no longer hold. The safest approach for anyone starting a new AWS account today is to check the current terms directly on AWS’s own free tier page at signup time rather than relying on a cached number from a search result, since the exact credit amounts and expiration windows are the kind of detail AWS has adjusted before and will likely adjust again.

What’s Actually Free Long-Term

The always-free tier covers a real, useful set of services for a small project, though the specific caps are worth confirming on AWS’s pricing pages for each service since they’re managed independently and change on their own schedules. Historically, this category has included a meaningful monthly allotment of AWS Lambda invocations, a set amount of DynamoDB storage and read/write capacity, and small tiers of services like Amazon SNS and CloudWatch monitoring. None of these require the new-account credit to use, and none of them expire after a fixed period the way the old EC2 and RDS trial allotments did.

That distinction matters for how you architect a small project. Building a genuinely low-cost, long-running side project around the always-free services (serverless functions, a small managed database within its free cap, minimal storage) is far more sustainable than building around EC2 or RDS instances that were only free during an initial trial window and will start billing once that credit or trial period lapses.

Making the New-Account Credit Actually Count

If you’re signing up as a new AWS customer, the credit is real money you can spend on real infrastructure, and the biggest mistake is spending it on exploration rather than a plan. Before creating any resources, sketch out what you actually intend to build and estimate its cost using the AWS Pricing Calculator, so the credit gets applied against a project you’ll actually finish rather than burned down through trial-and-error while learning the console. The credit expires; a half-finished experiment doesn’t refund it.

It’s also worth setting up billing alerts before spending a single dollar of that credit, not after. AWS Budgets lets you configure an alert well before you approach your credit limit or before any pay-as-you-go charges begin, and that single setup step is the most reliable protection against the classic “I forgot I left an instance running” bill that catches new AWS users off guard.

The Mistakes That Turn a Free Project Into a Billed One

The single most common way a supposedly free AWS project starts costing money is a forgotten running resource: an EC2 instance left up after a test, an RDS database provisioned for a demo and never torn down, an Elastic IP address reserved but not attached to anything. AWS bills for allocated capacity whether or not you’re actively using it, and a small forgotten instance running for a full month adds up in ways that feel disproportionate to how little it was actually used.

Data transfer is the second common trap. Compute and storage costs get most of the attention, but outbound data transfer, especially from S3 or EC2 to the public internet, is billed separately and isn’t always covered by the same free allotments as the underlying storage or compute. A project that stores files cheaply but serves them to a lot of visitors can rack up transfer charges even while the storage itself stays within free limits. Checking a service’s data transfer pricing separately from its storage or compute pricing, rather than assuming one free tier covers the whole pipeline, avoids this specific surprise.

The third trap is one most new users don’t think about until it happens: exceeding an “Always Free” cap doesn’t cut off the service, it starts billing you for the overage at standard rates, silently, unless you’ve set up monitoring to catch it. A Lambda function that suddenly gets more traffic than expected, or a DynamoDB table that grows past its free storage allotment, keeps running exactly as before, just with charges accumulating in the background. Budget alerts are the only real defense against this pattern, since AWS won’t proactively warn you that you’ve crossed a threshold unless you’ve configured it to.

Tools Worth Setting Up From Day One

AWS Cost Explorer gives a visual breakdown of where spending is actually coming from, broken out by service, which is the fastest way to catch a resource that’s quietly billing more than expected before it becomes a large surprise at the end of a billing cycle. It’s free to use and worth checking weekly during any period when you’re actively provisioning new resources, not just glancing at once a month when the bill arrives.

AWS Budgets, mentioned above for its alerting function, also supports action-based automation in some configurations, letting you trigger a notification or, with more setup, a corrective action when spending crosses a defined threshold. For a hobby project or learning environment where the goal genuinely is to stay at zero cost, setting a budget threshold at a small dollar amount above zero and alerting on it catches problems within days rather than discovering them at the next billing statement.

When AWS Isn’t the Right Free Tier for the Project

AWS’s free tier structure, credit-based for new accounts plus a permanent always-free layer, isn’t the only option, and it isn’t always the simplest one for a small project. Other cloud providers run their own free tiers with different tradeoffs: some offer a small set of permanently free compute instances rather than a time-limited credit, others focus their free allotment on specific services like databases or static hosting rather than general-purpose compute. None of these are drop-in replacements for AWS’s broader service catalog, but for a project that only needs one or two specific capabilities, comparing the free tier of a more specialized provider against AWS’s general-purpose one is worth the ten minutes it takes, rather than defaulting to AWS out of habit.

The right choice usually comes down to what the project actually needs. A static site or a small serverless API can often run entirely within a permanently free tier somewhere without ever touching a credit that expires. A project that genuinely needs EC2-style general compute, a real relational database, or AWS-specific services like Rekognition or specialized machine learning tools has fewer alternatives and is where AWS’s broader catalog, even with its credit-based new-account structure, still makes the most sense.

Learning AWS Versus Running a Free Project: Different Goals, Different Plans

It’s worth separating two different reasons people sign up for AWS’s free tier, because they call for different strategies. Someone learning AWS for a certification or a career move benefits from spending the new-account credit deliberately on services they wouldn’t otherwise touch, provisioning an EC2 instance, standing up an RDS database, experimenting with IAM policies, because the point is hands-on exposure to services they’ll be asked about in an interview or an exam, not keeping the bill at exactly zero forever.

Someone trying to run an actual small project indefinitely at no cost has the opposite priority: staying inside the always-free category as much as possible and treating the new-account credit as a one-time bonus for occasional experimentation rather than the foundation the project depends on. Conflating these two goals, learning broadly versus running cheaply, is a common reason people either waste credit on services they never revisit or under-explore AWS out of an overly cautious fear of any charge at all. Deciding which goal you’re actually optimizing for before opening the console saves both money and frustration.

What Happens When the Credit or Trial Period Ends

AWS doesn’t shut off resources automatically when a new-account credit runs out or an old-style trial window expires; it simply starts billing at standard rates for anything still running. That’s the scenario billing alerts exist to prevent, but it’s worth understanding explicitly rather than assuming AWS will pause or warn you by default. A project built entirely on always-free services sails through this transition unaffected, since those limits were never tied to the credit or trial period in the first place. A project that leaned on EC2, RDS, or other services covered only by the credit needs an explicit decision at that point: either accept the ongoing charge, migrate the workload to an always-free alternative, or shut the resources down deliberately rather than letting them keep running on autopilot.

Calendar reminders are a low-effort way to force that decision rather than discovering it retroactively on a bill. Setting a reminder for a date shortly before the credit’s known expiration, cross-checked against the actual balance in the AWS billing console rather than an assumed date, gives enough lead time to make a deliberate choice about what stays running and what gets torn down.

Securing a Free-Tier Account Matters More Than It Seems

A free-tier or credit-funded AWS account is, from an attacker’s perspective, a way to run compute for free on someone else’s card. Leaked access keys, whether accidentally committed to a public repository or lifted from an insecure local environment, are one of the most common ways a personal AWS account ends up with an unexpected five-figure bill from cryptocurrency mining or spam infrastructure run entirely by someone else. This isn’t a hypothetical edge case; it’s a well-documented pattern specific to AWS’s combination of programmatic access keys and pay-as-you-go billing.

The defense is straightforward and worth doing before any other setup step. Never commit access keys to a code repository, public or private. Enable multi-factor authentication on the root account immediately, since the root account has unrestricted billing and resource access by default. Create a separate IAM user with limited permissions for day-to-day work instead of using the root account credentials directly, and rotate any access key that’s ever been exposed, even briefly, rather than assuming it wasn’t noticed. AWS also offers a free service, GuardDuty, with its own limited free trial period, that flags unusual account activity, which is worth enabling specifically during the period when an account is most likely to be probed: right after signup, when it’s newly registered and its credit balance is at its highest.

The Always-Free Services Worth Actually Learning

Of the always-free category, a handful of services are worth learning in real depth because they cover a genuinely wide range of small-project needs without ever depending on the new-account credit. AWS Lambda, which runs code without provisioning a server, has historically included a substantial free monthly request allotment alongside a free tier of compute time measured in GB-seconds, enough for a real hobby project’s backend logic to run indefinitely without billing, as long as usage stays within the documented caps for the account’s region.

Amazon DynamoDB, a managed NoSQL database, has similarly offered a meaningful always-free storage and throughput allotment, which is enough for a small application’s data layer without needing to provision or pay for a traditional database server. Pairing Lambda with DynamoDB is one of the more reliable ways to build a genuinely free small backend on AWS, since both pieces come from the always-free category rather than a time-limited trial or credit-funded allotment. Amazon SNS and Amazon CloudWatch round out a workable free stack for notifications and basic monitoring, both with their own permanent free allotments.

None of these substitute for a general-purpose virtual machine the way EC2 does, and a project that genuinely needs to run a persistent server process, rather than short-lived serverless functions, will eventually need to either stay within EC2’s free trial window or accept ongoing charges once that window or credit balance runs out. Knowing that distinction upfront, serverless-friendly workloads can often stay free indefinitely, server-dependent workloads generally can’t, shapes which architecture makes sense for a project meant to stay free for longer than a few months.

Tagging and Tracking Spend as the Project Grows

Cost tracking becomes genuinely useful only once resources are tagged consistently, and it’s far easier to tag resources as you create them than to retrofit tags onto a sprawling set of untagged services months later. A simple tagging convention, project name and environment (test versus production, for instance) applied to every resource at creation time, turns AWS Cost Explorer from a vague total into a breakdown that actually explains where money is going. For a solo developer running one project, this might feel like overkill early on, but the habit costs nothing to build and pays off the moment a second project starts sharing the same account.

Cost allocation tags also matter if a free-tier project eventually needs to be handed off, whether to a co-founder, a client, or a future version of yourself trying to remember six months later why a particular database is still running. An untagged, unlabeled sprawl of resources is one of the more common reasons small AWS accounts accumulate forgotten, silently billing infrastructure that nobody remembers provisioning in the first place.

A Practical Way to Start

Before creating a single resource, read the current terms on AWS’s own free tier page rather than trusting any third-party summary, including this one, for exact dollar amounts and expiration windows, since those specific numbers are the part AWS changes most often. Set up a billing alert immediately after account creation, before provisioning anything. Build around the permanently free services where the project allows it, and treat the new-account credit as a bonus for testing something bigger rather than the foundation the whole project depends on staying free forever. That sequence, verify current terms, alert first, build conservatively, is the difference between a free tier project that stays free and one that quietly turns into a monthly bill nobody budgeted for.