How the AWS Free Tier actually works

The AWS Free Tier is one of the most misunderstood things in cloud computing, and the confusion is structural rather than accidental. It is not a single offer. It is a bundle of separate allowances with different rules, different clocks and different failure modes, all presented under one label. People sign up expecting a sandbox that cannot charge them, and then discover a bill for something they thought was covered.

This guide separates the parts, explains what happens at the boundaries, and shows how to set up an account so that a mistake costs you a notification rather than money.

The three kinds of free

The first thing to internalise is that “free tier” covers three genuinely different mechanisms.

Trial offers are short-term. They start when you first use a particular service and run for a fixed window, commonly thirty or ninety days. They apply per service, not per account, so activating one does not start the clock on the others.

Twelve-month offers begin when the account is created, not when you first use the service. This is the category most people mean when they say “free tier”, and it is where the classic allowances live: a modest amount of general-purpose compute, a small block of object storage, some database hours. The clock is the account’s age. If you create an account, forget about it for eleven months, then start building, you have four weeks of allowance left rather than a year.

Always Free offers never expire. They are usually small but genuinely permanent: a certain number of function invocations per month, a quantity of NoSQL storage, a monitoring allowance. For a hobby project that stays small, these can carry real workloads indefinitely.

AWS has also been reshaping the signup experience, offering new accounts a choice between a plan that gives a credit allowance and a plan with full pay-as-you-go permissions. The details of these signup plans have shifted more than once, so treat the specifics you read anywhere, including here, as something to confirm in the console rather than assume.

Where the allowance actually stops

The allowances are metered per month, per region, and per usage type. Each of those three words hides a way to spend money you did not mean to spend.

Per month means the counter resets, but it does not roll over. Using half your compute allowance in January does not give you 150% in February.

Per region is the one that catches people. Many free tier allowances are aggregated across regions, but not all of them are, and the resources you create are absolutely region-specific. Spinning up a test instance in a region you rarely open is the classic way to leave something running for six weeks without noticing, because your dashboard defaults to a different region and the orphan never appears in front of you.

Per usage type is the subtlest. A free tier allowance for compute covers specific instance sizes. Choosing a slightly larger size does not give you a discounted rate against the allowance. It bills at full price from the first second. The same applies to storage classes and database engine types.

The costs that sit next to free things

Even when the headline resource is inside its allowance, adjacent charges often are not. These are the ones worth memorising.

• Public IPv4 addresses. AWS now charges for public IPv4 addresses, including ones attached to running instances. A small instance that is itself inside the allowance can still generate a steady monthly charge simply for being reachable.
• Data transfer out. Traffic leaving the cloud to the internet is billed beyond a modest monthly allowance. Serving files, running a busy API, or syncing large datasets to your laptop all count.
• Storage attached to stopped instances. Stopping an instance stops the compute charge. The disk attached to it keeps existing and keeps billing.
• Snapshots. Easy to create, easy to forget, billed by the gigabyte-month until deleted.
• Load balancers, NAT gateways and managed endpoints. These bill per hour whether or not any traffic passes through them, and they are not in the free tier.

None of this is hidden. It is simply spread across a large pricing surface, and the mental model of “I am on the free tier” does not naturally include it.

Setting the account up so mistakes are cheap

The practical answer is not to be more careful. It is to build a tripwire, because attention fails and automation does not.

Turn on billing alerts before you create anything. AWS Budgets lets you set a monthly cost budget with alerts at thresholds you choose. Set one at a genuinely small figure. The point is not to cap spending, it is to be told early.

Set an alert on forecasted spend, not just actual spend. Actual-spend alerts fire after the money is committed. Forecast alerts fire while there is still time to act.

Use the Billing console’s free tier usage view. It shows how much of each allowance you have consumed and flags the ones you are on track to exceed. Checking it weekly during an active build takes under a minute.

Tag everything from the start. A simple tag such as a project name on every resource makes it possible to answer “what is this charge” later. Untagged resources are how orphans survive.

Do a region sweep before you stop working on something. Open the billing view rather than the service console, because billing is global and will show you resources in regions you forgot you used.

Reading your own usage

When a charge does appear, the useful tool is Cost Explorer with the grouping set to usage type rather than service. Service-level grouping tells you the charge came from compute, which you already suspected. Usage-type grouping tells you it came from a specific instance-hour category or a specific data transfer path, which is actionable.

If a line item makes no sense, the pricing pages for that individual service are more reliable than the summary pages, because the summary pages describe the common case and the surprises are almost always in the uncommon case.

What the free tier is genuinely good for

Having spent this long on the caveats, it is worth being clear that the free tier is useful. It is well suited to learning the console and the CLI, to running through certification labs, to building a proof of concept that you will tear down, and to hosting genuinely small always-free workloads such as an occasional scheduled function.

It is poorly suited to anything with unpredictable traffic, anything that needs to stay up, and anything where an unexpected charge would be a real problem rather than an annoyance. For those, a deliberate small paid setup with a hard budget is calmer than a free tier you are constantly checking.

Before you build

Decide in advance what you are testing and roughly how long it will take. Write down the resources you create. Set the budget alert first. Delete things when you are finished with them rather than when you remember.

That sequence costs about ten minutes at the start and removes almost every way the free tier surprises people.

For the vendor’s own reference on the services involved here, see the AWS documentation.

Questions people ask