Hyperscalers will encourage you to migrate workloads onto your platform with credits, but what happens when they run out? Your bill goes from “basically zero” to more than your office rent. The CFO is in the CTO’s office asking hard questions.
This isn’t an unusual scenario. A migrated customer can burn £200k of credits over 18 months, blissfully unaware that their real monthly run rate is £14k. Then the invoice lands and nobody knows what has an answer for the increased spend.
The credit illusion
Cloud credits are a brilliant acquisition strategy — for the cloud providers. They get you building on their platform, often accumulating technical debt and vendor lock-in, pushing back your concerns about increasing cloud spend.
Credits don’t just defer cost, in many organisations they effectively 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’re running six RDS instances when two would do. Any effort put into optimisation feels like waste, why bother when you have the credits?
The credit period creates a culture of waste. That culture doesn’t disappear when the credits do, and by then it is too late to effect serious change quickly.
What actually happens
Month 1 after credits expire: The bill arrives and it’s 2–3x what anyone expected. Engineering says “we’ll 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’re shipping product and so the cloud line item grows faster than revenue.
Month 12: Cloud spend is now a board-level concern. If you are really unlucky someone asks if you should be migrating to another hyperscaler, to start this whole process over again.
The unit economics problem
The real issue isn’t the total bill — it’s that you’ve 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 hidden behind a credit balance that just ticks down.
The first step is establishing what things actually cost:
- 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’re badly provisioned
Most founders are shocked when they see these numbers for the first time. Not because they’re catastrophically bad, but because they’ve literally never seen them before.
Five things to do before credits expire
If you’re still in your credit period:
1. Enable cost allocation tags. This is a simple fundamental task you should be getting in the habit of doing: Tag every resource with team, environment, and service. You can’t optimise what you can’t 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, and to hopefully spot problems before they become a serious issue.
3. Right-size before you have to. Run AWS Compute Optimizer. It’ll tell you which instances are over-provisioned. During the credit period, downsizing saves you nothing financially, but it reduces the shock later.
4. Audit your data transfer. The silent killer. Most teams don’t realise they’re paying for cross-AZ traffic, NAT Gateway processing fees, or CloudFront bandwidth until the credits stop absorbing it.
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. Act like your credits don’t exist, and if that number makes you uncomfortable you have time to fix it before it hits your budget.
When the bill is already here
If you’re reading this because the credits already expired and the bill is painful there are usually inital savings to be made by cleaning up, but to avoid things getting worse you will need systemic change.
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’s meaningful, but it’s not the 70% reduction you’re hoping for.
For that kind of reduction, you need to rethink architecture — and that means engineering time, which means opportunity cost. Is a pound spent on cloud optimisation worth more than a pound spent on product development?
Sometimes yes. If your cloud bill is growing faster than your revenue, optimisation isn’t optional — it’s survival. But if your unit economics are reasonable and you’re growing fast, a 30% reduction through right-sizing and commitments might be the right level of effort.
The bigger question
Credits expiring are an important milestone. It’s the first time many startups and migration customers have to confront whether the issue of ongoing cost optimisation on public cloud and whether it is a good long term fit for them.
For some workloads, the answer is clearly yes — bursty traffic, global distribution, rapid experimentation. For others — steady-state compute, predictable traffic, data-heavy processing then the case for dedicated servers at a fraction of the cost might make more sense.
You don’t need to answer that in the panic of your first real cloud bill. But it’s worth asking once you understand the economics of the infrastructure you are running.
If your credit expiry is approaching — or already behind you — a Platform Fit Verdict will map your real unit economics and show which workloads are worth rearchitecting.