Your AWS Credits Just Ran Out. Now What?
There is a specific kind of email that changes how a founder thinks about infrastructure overnight. It doesn’t come from a customer or an investor. It comes from AWS, and it says your credits are expiring in 30 days.
For the first year or two of a startup’s life, the cloud bill is background noise. AWS Activate, Google Cloud for Startups, Microsoft for Startups, and accelerator-linked programs like the ones from Y Combinator or Stripe Atlas hand out anywhere from $1,000 to $100,000 or more in credits, and teams build on top of that without ever really seeing what any of it costs. That’s the point of the programs. They’re designed to remove cost as a variable while a company figures out if it has a product worth scaling.
Then the credits run out, and cost stops being someone else’s problem.
The cliff is real, and AWS has gotten stricter about it
Credits typically expire 12 to 24 months after issuance, and the newer generation of program tiers are less forgiving about extensions than they used to be. Founders program credits usually last 12 months. Portfolio-tier credits, the larger allocations tied to accelerators or VC backing, generally run 12 to 24 months. Once the expiration date passes, unused credits are gone, and any ongoing usage is billed at standard rates starting immediately.
The practical effect is a genuine cliff, not a slope. A team that has been paying nothing, or close to nothing, wakes up one month to a bill that reflects the actual cost of everything they’ve been running. It’s common for that number to land somewhere between a few thousand and tens of thousands of dollars a month, depending on how much infrastructure accumulated during the free period.
That gap between “the bill was basically zero” and “the bill is real” is where most of the panic happens. It’s also completely avoidable, because the infrastructure didn’t change overnight. Only the invoice did.
Why the bill is often bigger than it should be
Free credits change behavior in a specific, predictable way: they remove the incentive to ask whether something is actually needed. When compute is free, there’s no cost signal telling a team that a staging environment left running 24/7, an oversized database instance, or three redundant test environments are burning money. Engineers make individually reasonable decisions, spin up an environment here, add a monitoring tool there, and none of it gets revisited because nothing forced a revisit.
This is the same pattern behind why non-production environments quietly become a large share of a cloud bill. Industry analysis puts development, test, and staging environments at roughly a quarter of total cloud infrastructure spend on average, and a meaningful share of that spend is pure idle time: environments running nights and weekends when nobody is using them. When credits are covering the bill, nobody notices. When credits stop, that idle spend becomes visible for the first time, often the same week the real invoice arrives.
So the first useful thing a founder can do when the credits are about to run out isn’t comparing providers. It’s finding out what’s actually running.
Step one: audit before you migrate anything
Before any migration conversation, get a clear answer to three questions:
What is actually serving production traffic, versus what exists for convenience? Pull up the billing console and sort resources by cost. In most early-stage accounts, a small number of resources account for most of the spend, usually compute instances, managed databases, and data transfer. Everything else is usually smaller than people assume.
What’s running that nobody remembers turning on? This is the single most common source of unnecessary spend in a credits-subsidized account. Old staging environments, abandoned proof-of-concepts, forgotten load balancers, and snapshot backups that were never pruned all keep billing quietly. A short audit at this stage routinely finds resources nobody on the current team can explain.
What’s oversized for what it actually does? Instances picked “to be safe” during the free period, especially for staging or test databases, are frequently two or three sizes larger than the workload needs.
Doing this audit before comparing providers matters because it changes the real question. Instead of “how do we replicate what we’re running somewhere cheaper,” the better question is “what should we actually be running, now that it costs something.”
Step two: decide what’s worth moving, not just where to move it
Once the audit is done, most early-stage accounts fall into one of two situations.
Situation one: the spend is small and mostly justified. If a team is spending a few hundred dollars a month on infrastructure that’s genuinely lean, the priority isn’t migration. It’s picking a provider with transparent, predictable pricing so the next twelve months don’t repeat the same surprise.
Situation two: the spend reflects habits formed during the free period. This is more common than founders expect. The fix here isn’t a wholesale migration project. It’s right-sizing first, on whatever infrastructure the team is already running, and only then deciding whether a different provider makes sense. Migrating an oversized, under-audited environment to a new provider just moves the same waste somewhere else with extra migration risk attached.
What actually matters when picking where to land
Once the audit is done and the real footprint is clear, the provider decision comes down to a short list of things that matter more than a features page:
Pricing that doesn’t require a calculator to predict. Hyperscaler pricing is famously hard to forecast because compute, storage, IOPS, data transfer, and backups are billed as separate line items that compound in ways that aren’t obvious until the invoice arrives. A provider with flat, predictable pricing removes an entire category of monthly surprise, which matters most in the first year after credits end, when a team is watching runway closely.
No exit tax. Egress fees, the cost of moving data out of a cloud, are one of the most common sources of “wait, why is this so expensive” moments for early-stage teams. Before committing anywhere, it’s worth confirming what it costs to leave, not just what it costs to arrive.
Support that responds like your business depends on it, because it does. At this stage, a five or ten person engineering team doesn’t have the bandwidth to spend a day chasing a support ticket. Response time and quality of support matter more here than they do for larger, better-staffed teams.
Room to grow without a second migration in eighteen months. The goal isn’t to pick the cheapest possible option today. It’s to pick infrastructure that fits the business at its current stage and has a believable path for the next one, without forcing another full migration the moment traffic or team size doubles.
The mindset shift that actually matters
The end of a credits period isn’t really a cost problem. It’s the first moment a startup’s infrastructure decisions get evaluated against real constraints instead of free money. Teams that treat it as a forced audit, not just a provider swap, usually come out the other side with a smaller, more predictable, better-understood infrastructure footprint than they had going in.
The goal was never to spend as little as technically possible. It’s to spend on infrastructure that matches what the business actually needs right now, and to actually know what that number is before deciding what comes next.