Credits expire, and an unspent balance is a straight loss. Note the amount, the expiry date and the scope first; work out which usage does not draw on the credit at all; and there is an ordering point - lower the unit price with a discount first, and the same credit lasts longer.
Almost everything written about AWS credits covers how to get them: the 200 USD in the free tier, the startup tiers, the vouchers from limited-time campaigns. But there is a second half nobody covers - how to use them, and how not to waste them.
That second half matters because credits have one hard property: they expire, and the unused portion is not extended, cannot be withdrawn and cannot be transferred. An unspent balance is not "saved for later", it is a straight loss.
How to get them is in AWS Free Tier for new accounts, AWS startup credits and AWS limited-time campaigns. This page covers only what happens next.
Step one: write down three numbers
The usual reason credits go wrong is not that people cannot use them - it is that nobody recorded what they were. On receipt, put three numbers somewhere the team can see:
| Number | Why it matters | Consequence of skipping it |
|---|---|---|
| Amount | Determines how much usage you can cover | No idea how long it lasts |
| Expiry date | The only hard deadline | Discovering on expiry day that it went unused |
| Scope | Which services it covers, and which it does not | Assuming coverage, then seeing charges anyway |
⛔ Scope is the one people skip. A credit is not cash sitting in the account: it usually offsets eligible service usage only, and whether third-party Marketplace purchases qualify depends on the specific terms. The classic exclusion is data transfer - the official China Regions free tier page states it plainly: data transfer is not included in the free tier. That usage continues at standard rates, drawing on neither the free tier nor the credit.
First, work out which usage does not touch the credit
To make a credit last, the first move is not "spend less" - it is separating the usage that never draws on the credit anyway:
- Always-free allowances. The official wording says the free tier includes free usage of selected services - those services carry their own allowance, and usage within it does not consume the credit. Serverless compute, queues and notifications typically have always-free allowances that leave your credit untouched.
- Twelve-month allowances. Same logic: those services have their own allowance for their own period.
- Ingress. Data transferred into AWS is normally not charged, so it cannot consume a credit either.
What does consume it: usage beyond each service allowance, services with no allowance at all, and anything billed at standard rates. Aim your attention there rather than vaguely "spending less".
A useful inference: the credit and the selected-service allowances are two benefits that stack, so the right strategy is not "use as little as possible" - it is "use freely where no allowance covers you". That is where a credit has value. Spending it where an allowance already applies is giving it away.
The most common waste: running out without noticing
More common than "not using it all" is using it up without knowing, and then finding the bill jump from almost nothing to several hundred. The two wastes point in opposite directions from one root cause: nobody was watching the burn rate.
Three actions, about ten minutes together, address both:
- Watch the official usage view. The free tier pages provide current and forecast usage - they tell you both what is left and, at the current rate, when it runs out.
- Set a budget alert. A monetary threshold with tiered alerts (50% / 80% / 100%) turns "the credit is nearly gone" into a notification rather than a discovery.
- Tag your resources. The free period accumulates resources nobody owns. Without tags you cannot judge whether a given usage is worth your credit.
All three fall into the "find out early" category. None saves money directly, but they determine whether your later decisions have any evidence behind them. The full alert set-up is in why your AWS bill jumped.
Order matters: buy the discount first, then spend the credit
This is the most valuable point on the page and the easiest to miss: credits and discounts have an ordering, and the order changes how long the same credit lasts.
| Sequence | Result |
|---|---|
| Buy the commitment discount first (lower the unit price), then let the credit offset the bill | The same credit covers more usage → effectively a longer protection window |
| Burn the credit first, then think about discounts | The credit is consumed at full price; the moment it ends you start from list price |
Why the difference exists: a credit offsets a monetary amount. Lower unit prices mean less money per unit of usage, so the credit drains more slowly. Buying the commitment while the credit is still live is effectively using the discount to extend the credit. It is also an extension of "architecture first, then commitment" - make the structure cheaper first, then let the credit pay for it.
The two do not conflict: a discount lowers the unit price on the bill; a credit offsets the amount. Different layers, both apply. Which commitment and how much is in how to buy AWS Savings Plans.
There is a side benefit to this order: buying a discount requires judging which usage is steady-state, and the credit period is exactly the window for observing that (experimentation is free). So right-sizing, architecture decisions and buying the commitment are mutually reinforcing rather than three separate chores.
A checklist before expiry
Approaching the expiry date (or exhaustion), work through this in order:
- Confirm what is left and when it expires. Not from memory - from the usage view.
- Finish any experiments still running. The real value of a credit is free experimentation, and the run-up to expiry is the last window for it.
- Buy the commitment discounts you intended to. Once they apply, the remaining credit stretches further.
- Clean up resources nobody is using. Not to save credit, but so they do not keep billing after the credit is gone - these orphaned resources are the most common source of surprise charges.
- Check for commitments that would be wasted. If you plan to close the account or change anything, first confirm there are no unexpired reservations or Savings Plans - they keep billing to term even after closure.
The page in one line: credits buy time, not a cost structure. So the right use is to make the structure cheaper while the clock runs (right-sizing, architecture, discounts) - not "use more while it is free". The former still holds after the credit ends; the latter stops the day it does.
FAQ
Can I keep unused credit for later?
Normally not. Service credits carry an expiry, and the unused portion is generally not extended, not refunded and not transferable (the official terms are authoritative). So leaving credit unused is not saving, it is waste - which is why step one is writing down the expiry date.
How do I see how much credit is left?
The Billing and Cost Management console shows credit balances and usage, and the free tier pages provide current and forecast usage views. Use them alongside budget alerts, otherwise you oscillate between "forgot to look" and "already gone".
Does a credit cover data transfer?
The official wording states that data transfer is not included in the free tier, and credits generally do not cover it either. It is billed at standard rates, drawing on neither the allowance nor the credit - which makes it the most likely line to appear suddenly once the credit ends. The mechanics are in why AWS data transfer costs so much.
Can credits be used for third-party Marketplace software?
It depends on the specific terms and cannot be generalised. If your plan relies on credits to cover third-party software, confirm the scope first - many credits apply only to eligible AWS service usage.
How much will the bill rise when the credit runs out?
The difference is whatever was being offset. If you did no right-sizing and bought no discounts in the meantime, the rise equals your usage at full price - which is why standing still during the credit period is a mistake. What credits and discounts each are, and why they must not be conflated, is in AWS credits and discounts are not the same thing; lowering what you actually pay through a channel is in AWS discounts and reseller pricing, with the cross-provider differences in cloud discount mechanisms compared.