How to make your free cloud credits last longer

First, the honest answer to "is it enough?"

For building and running an MVP, yes — comfortably. A $1,000–$2,000 entry-tier grant covers a small production workload for months if you are disciplined: a modest managed database, a couple of small instances or a serverless front end, object storage and a CDN.

For production at scale, no. A $200,000 Portfolio or Scale grant is real money, but a startup running GPU inference or a large managed data warehouse can move through it in well under a year. Treat credits as runway extension, not as a business model.

The things that actually drain credits

1. Orphaned resources

Load balancers left behind after a test. Unattached persistent disks. Elastic IPs charged precisely because nothing is using them. NAT gateways forgotten in a spare VPC. These are the single biggest source of silent spend on early accounts.

Run a cleanup on a calendar reminder, monthly, and use tags from day one so you can tell what belongs to what.

2. Always-on development environments

Dev and staging running 24/7 costs the same per hour as production. If your team works Indian business hours, a schedule that stops non-production instances outside 9am–9pm on weekdays cuts those environments by roughly 65%.

3. Data egress

Ingress is generally free; egress is not. Serving media directly from object storage to users, cross-region replication you did not need, and chatty cross-AZ traffic all bill. Put a CDN in front of anything user-facing and keep services that talk to each other in the same zone.

4. Oversized instances

The default instinct is to over-provision "to be safe." Check actual utilisation after two weeks. Most early workloads sit under 15% CPU on an instance three sizes larger than needed.

5. Logs and snapshots

Log retention set to "forever" and daily snapshots nobody prunes grow quietly and monotonically. Set retention policies once, early.

6. GPU instances left running

The most expensive mistake available. A single large GPU instance left running over a long weekend can consume more than an entire entry-tier grant. Never launch one without an auto-stop.

Structural moves worth making

• Set the budget alert first. AWS Budgets and Google Cloud budgets are both free and take minutes.
• Go serverless for spiky workloads. Lambda, Cloud Run and Cloud Functions charge for execution rather than uptime, which fits pre-product-market-fit traffic far better than idle instances.
• Use committed use or savings plans carefully. They cut rates meaningfully, but commit you for a year. Only sensible for a workload you are certain persists.
• Use spot or preemptible capacity for batch work. Training runs, ETL and CI can tolerate interruption and cost a fraction of on-demand.
• Right-size the database before the compute. Managed databases are usually the largest single line item on an early bill, and they are the least likely to have been sized deliberately.
• Pick one region and stay in it unless you have a specific reason. Multi-region on a pre-PMF product buys latency you cannot measure and bills you can.

Watch the expiry, not just the balance

Credits are lost to expiry at least as often as to overspend — particularly with Google's Scale tier, where coverage is a percentage of usage and unspent coverage is simply never granted. If you have credits sitting unused with six months on the clock, the right move may be to pull a migration forward rather than to economise further.

Our guide to checking your balance and expiry date shows where both consoles hide that date.

Before you optimise, check you are not leaving credits behind

Reducing spend on a $1,000 grant is worth less than qualifying for a $200,000 one. If you have raised, joined an accelerator, or have DPIIT recognition in India, you may be eligible for a much larger tier than you are on. Start with the eligibility criteria.