Your cloud credits expire. Your bill goes from “basically zero” to more than your office rent. The CFO is in the CTO’s office asking hard questions.
I have seen it dozens of times. A Series A company burns through £200k of credits over 18 months, blissfully unaware that their real monthly run rate is £14k. Then the invoice lands and nobody knows what hit them.
The Credit Illusion
Cloud credits are a brilliant acquisition strategy — for the cloud providers. They get you building on their platform, accumulating technical debt and vendor lock-in, while you think you are getting infrastructure for free.
Credits do not just defer cost. They hide it.
When your infrastructure is “free,” nobody optimises it. Nobody questions whether you really need that m6i.4xlarge for a staging environment that three people use. Nobody asks why you are running six RDS instances when two would do.
The credit period creates a culture of waste. That culture does not disappear when the credits do — but the free ride does.
What Actually Happens
Let me walk through what I typically see when I audit a post-credits startup:
Month 1 after credits expire: The bill arrives and it is 2–3x what anyone expected. Engineering says “we will optimise next sprint.” Finance adds a line item to the board deck.
Month 2: Some quick wins get shipped — a few instances get downsized, someone turns off the dev environment over weekends. The bill drops 15%. Everyone relaxes.
Month 3–6: The bill creeps back up. New features mean new services. The quick wins are exhausted. Nobody has time for deep optimisation because they are shipping product. The cloud line item grows faster than revenue.
Month 12: Cloud spend is now a board-level concern. The CTO is asked to present a “cloud cost reduction plan.” They have never had to think about this before.
This pattern is so common it is practically a template.
The Unit Economics Problem
The real issue is not the total bill — it is that you have never had to understand your unit economics on cloud. During the credit period, your cost per customer, cost per transaction, cost per API call — all of these are hidden behind a credit balance that just ticks down.
When I work with post-credits startups, the first thing I do is establish unit economics:
- Cost per customer per month — not just compute, but storage, data transfer, monitoring, everything
- Cost per environment — production vs staging vs dev vs the “temporary” environment someone spun up six months ago
- Cost per service — which microservices are actually expensive, and which just look expensive because they are badly provisioned
Most founders are shocked when they see these numbers for the first time. Not because the numbers are catastrophically bad, but because they have literally never seen them before.
The Five Things to Do Before Credits Expire
If you are still in your credit period, here is what to do right now:
1. Enable Cost Allocation Tags
This takes 30 minutes and is the single most effective thing you can do. Tag every resource with team, environment, and service. You cannot optimise what you cannot measure.
2. Set Up a Monthly Cost Review
Once a month, your engineering lead should look at the bill. Not to optimise — just to understand. Build the muscle of knowing what things cost before it becomes urgent.
3. Right-Size Before You Have To
Run AWS Compute Optimizer or a similar tool. It will tell you which instances are over-provisioned. During the credit period, downsizing saves you nothing financially, but it builds the habit and reduces the shock later.
4. Audit Your Data Transfer
Data transfer is the silent killer on cloud bills. Most teams do not realise they are paying for cross-AZ traffic, NAT Gateway processing fees, or CloudFront bandwidth until the credits stop absorbing it. Map your data flows now.
5. Model Your Post-Credits Bill
Take your current usage (not your current bill — your actual usage from Cost Explorer), remove the credit offset, and project forward. If that number makes you uncomfortable, you have time to fix it.
When the Bill Is Already Here
If you are reading this because the credits already expired and the bill is painful, here is the honest truth: there are no quick fixes that do not involve trade-offs.
You can right-size instances (saves 20–40% on compute), switch to Reserved Instances or Savings Plans (saves another 20–30%), and clean up unused resources (varies, but usually 5–15%). That is meaningful, but it is not the 70% reduction you are hoping for.
For that kind of reduction, you need to rethink architecture — and that means engineering time, which means opportunity cost. The question becomes: is a pound spent on cloud optimisation worth more than a pound spent on product development?
Sometimes the answer is yes. If your cloud bill is growing faster than your revenue, optimisation is not optional — it is survival. But if your unit economics are reasonable and you are growing fast, a 30% reduction through right-sizing and commitments might be the right level of effort.
The Bigger Question
Credits expiring is a useful forcing function. It is the first time many startups have to confront a fundamental question: is the public cloud the right platform for this workload at this scale?
For some workloads, the answer is clearly yes — bursty traffic, global distribution, rapid experimentation. For others — steady-state compute, predictable traffic, data-heavy processing — the answer might be dedicated servers at a fraction of the cost.
You do not need to answer that question in the panic of your first real cloud bill. But it is worth asking once you understand your actual unit economics.
The credits were always going to run out. The question is whether you are ready when they do.
Rochwall helps growth-stage companies audit their cloud spend and plan for life after credits. If your credit expiry date is approaching — or already passed — book a Platform Fit Verdict and we will show you exactly where you stand.