AWS Free Tier Changed in 2025: What Happens When Credits Expire

If you opened an AWS account after July 15, 2025, you are on the new free tier, and your credits are on a clock: new accounts get up to $200 in credits ($100 on sign-up plus $100 earned by completing activities), and they expire after 12 months or when you exhaust them — whichever comes first. The old always-free and 12-month-free model that bootstrapped founders relied on for years is gone for new accounts. The practical takeaway: if you spun up a side project or a seed-stage app in late 2025, budget for a real AWS bill landing sometime in 2026, and know exactly which line items start charging the moment the credits run dry.

What actually changed #

AWS replaced the legacy free tier with a credit-based plan for accounts created on or after July 15, 2025. Instead of a grab-bag of per-service 12-month allowances (750 hours of a t2.micro, 5 GB of S3, and so on), you now get a flat credit balance to spend across services. You can run in a free plan that caps you at the credits and shuts down paid usage, or switch to a paid plan at any time. The credits expire at the earlier of 12 months or zero balance. That timing matters more than the dollar amount: a lightly used demo might coast for the full year, while an app with a managed database and a load balancer can burn $200 in six to eight weeks.

The reason this feels abrupt is that the old free tier was effectively a subsidy for architecture mistakes. You could leave an idle NAT gateway or an oversized RDS instance running and not notice because the hours were free. Under the credit model, every one of those choices has a visible price from day one. We wrote about the specific charges that catch people off guard in the five line items that ambush startups — NAT gateways, inter-AZ data transfer, and per-GB CloudWatch ingestion are the usual suspects, and none of them were ever meaningfully covered by the free tier anyway.

The line items that start billing first #

When the credits run out, the bill is rarely dominated by compute. The typical first-month surprise for a small web app is a managed database and the networking around it. A single db.t4g.micro RDS Postgres instance runs roughly $12–$15/month on-demand; an Application Load Balancer has a baseline of about $16/month before you send a single request through it; and a NAT gateway adds around $32/month plus data-processing fees. Add those up and a modest stack sits near $60–$80/month before any traffic. That is the cliff a lot of 2026 founders are about to walk off, and it is why pinning your sizing before the credits expire matters more than optimizing after the bill arrives.

The honest framing is that infrastructure cost should grow with the product, not leap on a calendar date. We lay out that progression in the honest stages of AWS infrastructure: a real but small app can live comfortably around $180/month, and should not be pushed toward a $680/month architecture until it genuinely needs it. The free tier ending does not change those numbers — it just removes the camouflage that hid them.

Where Vylara fits the migration #

Vylara connects to your GitHub repo, analyzes the codebase, and provisions the infrastructure your app actually needs — in your own AWS account. Because the resources live in your account, billing flows straight from AWS to you, and whatever credits you still have apply exactly as they would for anything else you deploy. Vylara charges for the orchestration and AI layer, not for your compute, so moving onto it does not add a second compute bill on top of AWS.

The part that helps with the free-tier cliff is the "Your app needs" review. After the Vylara agent scans your repo, it detects dependencies like prisma or ioredis and shows you each required resource with a plain monthly estimate — roughly ~$15/mo for a managed Postgres database, ~$8/mo for a Redis cache, ~$1/mo for a storage bucket — before anything is created. You choose "Create for me" or point at a database you already run. Nothing touches your account until you approve the plan and trigger the first deploy, which is the step that actually provisions the environment. Connecting the repo and merging config PRs from vylara-ai[bot] only updates your code; the cloud environment is created when you deploy.

That estimate-first screen is the difference between finding out your run rate in a dashboard and finding out in a surprise invoice. If you are moving off a free-tier account that is about to expire, or off a hosted platform entirely, it is the same flow — our walkthrough of migrating from Render to your own AWS account covers the stateless-versus-stateful trade-offs, which are the genuinely hard part of any move. Stateless services cut over cleanly; databases with real data need a planned migration, and no agent makes that risk-free.

What to do before the clock runs out #

The useful move is to treat the credit expiry as a forcing function to understand your true run rate while you still have runway. Deploy the real shape of your production stack now, read the per-resource estimates, and right-size before the bill becomes real rather than after. After launch, Vylara’s infrastructure chat can read your service status and logs and propose scaling changes — scaling a database down to save money, or up under load — with your approval required for any write action. That means you can validate the estimate against actual usage and tighten it inside the credit window instead of discovering the gap on your first paid invoice.

None of this is magic. AI-generated infrastructure still needs a human reading the diff, sizing is a best guess until real traffic pins it down, and credit balances expire whether or not you have planned for them. But knowing the exact services that start charging — a database, a load balancer, a NAT gateway — and seeing a dollar figure next to each one before you deploy turns the 2026 free-tier cliff from an ambush into a line item you chose on purpose. For a fuller picture of running lean on AWS as a small team, start with our guide for startups.