Your startup used $2,000 of cloud infrastructure last month.
The amount payable was zero.
Both numbers are correct. They answer different questions.
One tells you what the system costs to operate. The other tells you how much of that cost the business must fund.
Cloud credits give startups room to build. They reduce the initial cash required to launch a product, test an architecture or serve early customers. But they can also obscure a growing funding requirement when leadership focuses only on what leaves the bank account.
A workload does not become inexpensive because promotional credits cover the invoice.
The question is not just how many credits remain in your billing console. It is how much cash the business will require when those credits stop covering the workload.
The bill has three numbers
A useful cloud cost report separates the cost before promotional credits, the credits applied and the amount payable.
| Measure | What it tells you |
|---|---|
| Cost before promotional credits | What the workload costs at applicable prices, including relevant pricing discounts |
| Promotional credits applied | How much of that cost the credit award covers |
| Amount payable | The remaining amount the company must fund according to its payment terms |
For a simplified invoice without taxes or other adjustments:
Amount payable = cost before promotional credits − credits applied
A $2,000 workload offset by $2,000 in credits produces an amount payable of zero. The workload still costs $2,000.
That distinction matters when a founder calculates burn, when engineering evaluates database tiers, and when finance models the next two quarters.
If pricing discounts apply, include them in the baseline. The objective is to understand workload cost without promotional support, not inflate it by using undiscounted list prices.
Payment timing also matters. An amount payable on an invoice does not necessarily leave the bank account immediately.
The eligibility and expiry trap
Credits do not behave like cash.
Their usefulness depends on the charges they cover, the period in which they can be used and any limits attached to the award.
Three things can expose the business to payments:
- Exhaustion: Eligible charges consume the available balance.
- Expiry: The award ends while some credits remain unused.
- Coverage restrictions: Certain charges are not covered, or are only partly covered.
AWS’s promotional credit terms specify eligible charges, exclusions and expiry treatment. Google Cloud’s startup programme terms also restrict credits to qualifying usage and leave customers responsible for uncovered charges.
Do not assume that one programme’s rules apply to another. Check the specific award, including its effective date, expiry date, applicable services and coverage limits.
Billing-cycle treatment matters too. AWS’s current general terms allow redeemed credits to cover eligible charges incurred during the billing cycle in which they expire.
“$12,000 remaining” is therefore incomplete information. The business also needs a timeline showing how that balance can be used.
What $12,000 in credits actually buys
Consider a startup with:
- $12,000 in promotional credits available at the start of Month 1.
- A $2,000 cloud workload in Month 1.
- Full coverage of all modelled charges through the end of Month 4, subject to the remaining balance.
- Any unused credits expiring after Month 4.
- No additional credit awards.
We will compare flat spending with cost growing by 50% each month.
All figures are synthetic. The growth rate is a stress test, not a forecast. It describes infrastructure cost growth, which does not necessarily equal customer or traffic growth.
Taxes, payment fees and ineligible charges are excluded. For simplicity, the model assumes charges are paid in the same month they are incurred.
Scenario A: Flat spending
| Month | Cost before credits | Credits applied | Amount payable | Unused credits expired |
|---|---|---|---|---|
| 1 | $2,000 | $2,000 | $0 | $0 |
| 2 | $2,000 | $2,000 | $0 | $0 |
| 3 | $2,000 | $2,000 | $0 | $0 |
| 4 | $2,000 | $2,000 | $0 | $4,000 |
| 5 | $2,000 | $0 | $2,000 | $0 |
| 6 | $2,000 | $0 | $2,000 | $0 |
By the end of Month 4, the startup has used $8,000 of its award. The remaining $4,000 expires.
Month 5 is the first month with an uncovered charge.
Dividing the initial $12,000 balance by the $2,000 monthly cost suggests six months of coverage. The expiry rule reduces credit coverage to four months.
The workload does not become more expensive in Month 5. The business becomes responsible for paying for it.
Scenario B: Cost grows 50% each month
| Month | Cost before credits | Credits applied | Amount payable | Remaining credit balance |
|---|---|---|---|---|
| 1 | $2,000.00 | $2,000.00 | $0.00 | $10,000.00 |
| 2 | $3,000.00 | $3,000.00 | $0.00 | $7,000.00 |
| 3 | $4,500.00 | $4,500.00 | $0.00 | $2,500.00 |
| 4 | $6,750.00 | $2,500.00 | $4,250.00 | $0.00 |
| 5 | $10,125.00 | $0.00 | $10,125.00 | $0.00 |
| 6 | $15,187.50 | $0.00 | $15,187.50 | $0.00 |
The credit balance runs out during Month 4. Monthly totals do not establish the exact day.
The first uncovered charge is $4,250. By Month 5, the business must fund the full $10,125.
Across six months, Scenario B incurs $41,562.50 in infrastructure costs before credits. After applying the $12,000 award, the amount payable is $29,562.50.
Scenario A incurs $12,000 before credits and requires $4,000 in payments. Only $8,000 of its award is used before expiry.
The same starting credit balance produces different funding requirements.
The first uncovered month is only the beginning
A forecast that says “credits end in Month 4” leaves out the size of the transition.
In Scenario B, credits still cover part of Month 4. Month 5 receives no promotional coverage. The cost continues growing in Month 6.
A useful forecast identifies:
- The first month with any uncovered charges.
- The first month with no promotional coverage.
- The amounts payable in the following months.
- When those payments are expected to leave the bank account.
Those details give a team time to prepare for more than the first uncovered invoice.
Zero payment does not mean zero cost per customer
Suppose the startup serves 1,000 active customers in Month 1.
Its $2,000 cloud cost represents $2 per active customer. Because credits cover the bill, its cloud amount payable per customer is zero.
Both measures are useful:
| Measure | Month 1 result | Purpose |
|---|---|---|
| Cloud cost per customer before promotional credits | $2.00 | Assess the infrastructure cost of serving customers without promotional support |
| Cloud amount payable per customer | $0.00 | Understand current funding requirements |
Neither measure establishes the product’s gross margin. Payment processing, support and other delivery costs may still apply.
For a $5 monthly subscription, a $2 cloud cost consumes 40% of subscription revenue before considering those other costs. Credits can reduce the current cloud payment, but they do not establish that the product will remain profitable after coverage ends.
The denominator also needs care. Use a consistent definition of an active customer or completed transaction. Allocate shared infrastructure costs before comparing products.
Rising total spending does not automatically mean worsening efficiency. If customer growth outpaces cloud cost growth, average cost per customer may improve.
Reproduce the transition in Python
The following model uses Python’s standard library to reproduce both scenarios.
It records costs, credits applied, amounts payable, expired credits and the remaining balance. It also prints the first uncovered month.
from decimal import Decimal, ROUND_HALF_UP
ZERO = Decimal("0.00")
CENT = Decimal("0.01")
def forecast_credits(
starting_cost: Decimal,
growth_rate: Decimal,
credit_balance: Decimal,
expiry_month: int,
):
cost = starting_cost
balance = credit_balance
results = []
for month in range(1, 7):
# All modelled charges qualify while the award is valid.
applied = (
min(cost, balance)
if month <= expiry_month
else ZERO
)
payable = cost - applied
balance -= applied
# Unused credits expire after this month's coverage.
expired = balance if month == expiry_month else ZERO
balance -= expired
results.append({
"month": month,
"cost_before_credits": cost,
"credits_applied": applied,
"payable": payable,
"expired": expired,
"closing_credit_balance": balance,
})
cost = (
cost * (Decimal("1.00") + growth_rate)
).quantize(CENT, rounding=ROUND_HALF_UP)
return results
scenarios = [
("Flat spending", Decimal("0.00")),
("50% monthly cost growth", Decimal("0.50")),
]
for name, growth in scenarios:
rows = forecast_credits(
starting_cost=Decimal("2000.00"),
growth_rate=growth,
credit_balance=Decimal("12000.00"),
expiry_month=4,
)
first_uncovered = next(
(
row["month"]
for row in rows
if row["payable"] > ZERO
),
None,
)
total_payable = sum(
(row["payable"] for row in rows),
ZERO,
)
print(f"\n{name}")
print(f"First uncovered month: {first_uncovered}")
print(f"Six-month amount payable: ${total_payable:,.2f}")
for row in rows:
print(
f"Month {row['month']}: "
f"cost=${row['cost_before_credits']:,.2f}, "
f"credits=${row['credits_applied']:,.2f}, "
f"payable=${row['payable']:,.2f}, "
f"expired=${row['expired']:,.2f}, "
f"balance=${row['closing_credit_balance']:,.2f}"
)
The flat scenario identifies Month 5 as the first uncovered month and produces $4,000 payable over six months.
The growth scenario identifies Month 4 as the first uncovered month and produces $29,562.50 payable.
This is a simplified, single-award model. It assumes full coverage of eligible costs until the balance runs out or the award expires. It does not implement provider-specific rules for multiple awards, partial coverage, account sharing or service restrictions.
For an operational forecaster, use a billing file and a credit ledger.
The billing file should preserve costs before promotional credits and credit adjustments separately. The ledger should record each award’s balance, validity period, eligibility and coverage limits.
Apply the provider’s allocation rules and reconcile the results against actual invoices. Do not subtract credits twice from a billing export that already includes them.
The credit transition changes company runway
Cloud coverage is not company runway.
Consider the same startup with $60,000 in starting cash and $10,000 in monthly net cash burn excluding cloud payments.
That non-cloud burn represents other cash expenses minus cash receipts. Hold it constant in both scenarios.
Closing cash = opening cash − non-cloud net cash burn − cloud payment
| Month | Non-cloud net cash burn | Scenario A: projected closing cash | Scenario B: projected closing cash |
|---|---|---|---|
| 1 | $10,000 | $50,000 | $50,000 |
| 2 | $10,000 | $40,000 | $40,000 |
| 3 | $10,000 | $30,000 | $30,000 |
| 4 | $10,000 | $20,000 | $15,750 |
| 5 | $10,000 | $8,000 | −$4,375 |
| 6 | $10,000 | −$4,000 | −$29,562.50 |
Negative figures represent cumulative funding gaps if all assumed outflows continue. They are not actual spendable bank balances or a determination of insolvency.
Under flat cloud spending, the company can fund the modelled payments through Month 5 but encounters a shortfall in Month 6.
Under 50% monthly cloud cost growth, the shortfall begins in Month 5.
Dividing current cash by current net burn gives six months:
$60,000 ÷ $10,000 = 6 months
That estimate misses the additional payments once promotional coverage ends.
The issue is that the burn rate changes over the forecast period. A month-by-month cash model makes that change visible.
A precise cash-out date would require the timing of receipts and payments within each month.
Architecture decisions made while credits cover the bill
Subsidised usage can make an expensive design feel easier to accept.
A team may provision a search cluster before measuring its requirements. It may select a database tier without examining access patterns. It may leave staging environments running because there is no immediate payment attached to them.
These choices are not automatically wrong. The question is whether their value justifies their ongoing cost.
A managed service might improve recovery, reduce operational work or help a team deliver sooner. Those benefits belong in the comparison alongside its price.
If a tool costs $1,500 per month, evaluate what the business receives for that amount and what an alternative would cost to operate. Do not assume saved engineering hours translate directly into cash savings.
Also consider reversibility. Moving a data layer, changing a service dependency or rebuilding an operational process takes time. That work becomes harder to fund if the team waits until an uncovered invoice arrives.
Review significant architecture decisions against their cost before credits and their expected cost after expiry.
Use the credit period to prepare
The period before expiry gives the team room to act.
Review idle resources, unnecessary data movement and capacity that exceeds demand. Schedule non-production environments around actual usage. Examine retention policies against retrieval costs and recovery requirements.
Before purchasing commitments, check their payment schedule and whether the award covers the relevant charges. A lower unit price is useful only if the commitment fits the workload and the company can fund it.
Keep the credit balance, cost forecast and company cash forecast in the same conversation.
Do not spend more simply to exhaust an expiring award. Unused credits are not cash that can be recovered. Additional usage should serve a business purpose and come with a plan for any continuing costs.
When the credits stop paying
Cloud credits can fund experiments and reduce early cash pressure. They can give a startup time to learn what customers need and how to deliver it.
That advantage is more valuable when the business understands the cost of continuing after the support ends.
This is the question Runway Architect keeps returning to:
When the credits stop paying, can the business afford the system it has built?
The best time to answer is while the credits are still covering the bill.
Top comments (1)
tr.ee/dev-to