What if you could run a small server, store a few gigabytes of files, and query a terabyte of data every month without paying a cent? That is the promise of the Google Cloud Platform free tier, and for a lot of developers and small teams, it is the cheapest way to learn cloud infrastructure hands-on. But the free tier is not one thing. It is a bundle of always-free product limits plus a time-limited trial, and the rules around both change often enough that plenty of people get surprised by a bill they thought could not happen. (Distinguishing AI product and platform roles) (Cloud computing)
This article walks through how the free tier is structured, where the sharp edges are, and the practical habits that keep a free-tier project genuinely free.
Two Different Things Wearing the Same Name
The most common source of confusion is that “free tier” describes two separate programs that behave very differently.
The first is the always-free tier. It is a set of monthly usage allowances on specific products. It does not expire. It does not require you to be a new customer. As long as you stay under the published limits and follow the eligibility rules, that usage is not charged.
The second is the free trial. This is aimed at new customers and comes as a pool of credits that expires after a fixed window. Historically this has been described as roughly $300 in credits valid for 90 days, though figures like this are exactly the kind of detail that changes, so treat any number you read, including here, as something to confirm against current official documentation before you build a budget around it.
The two can overlap. You might run an always-free e2-micro instance while also burning trial credits on a bigger machine for a week. That is fine. What matters is understanding which bucket each resource draws from.
The Always-Free Menu, Roughly
The always-free allowances have stayed broadly similar in shape for years, even as the numbers move. Commonly cited items include:
| Product | Typical always-free allowance | Notes |
|---|---|---|
| Compute Engine | One e2-micro instance | Limited to select US regions |
| Cloud Storage | A few GB of standard storage | Usually restricted to a US region |
| BigQuery | Around 1 TB of queries per month and ~10 GB storage | Query allowance is the headline item |
| Cloud Run | A modest monthly request and CPU allowance | Good fit for small containerized apps |
| Cloud Functions | A limited number of invocations and compute seconds | Event-driven workloads |
| Firestore | Small daily document reads, writes, and storage | NoSQL document store |
Every one of those numbers should be checked rather than trusted. Google adjusts limits, adds products, and retires others. The regional restriction is the detail people miss most often: an e2-micro in the wrong region is not free, full stop.
You Still Need a Billing Account
Here is the part that makes people nervous. Even to use always-free resources, you generally have to attach a billing account with a valid payment method. Google is not being sneaky about this; it is how the platform verifies identity and enforces quotas. But it does mean the guardrail between you and a charge is your own configuration, not the absence of a credit card on file.
In practice, the safety net is a budget and alert. Set a budget at a low threshold, enable alerts, and optionally wire them to a pub/sub topic so you get an email or a chat message rather than discovering the problem at the end of the month. Budgets in Google Cloud notify; they do not automatically cap spending unless you build that automation yourself. That distinction trips up a lot of first-timers.
Where Free-Tier Projects Quietly Start Costing Money
The allowances are generous on paper. The trouble is that cloud billing is driven by everything around the free resource, not by the free resource alone.
Network egress is the classic offender. Inbound data is usually free. Data leaving Google’s network is not, and it is priced per gigabyte with regional variation. A free storage bucket that serves a popular file can generate egress charges that dwarf the storage cost. If you are moving data between regions or out to the internet, it is worth learning how cloud data transfer costs are tracked before you assume a free tier covers you.
Cross-region traffic is the second one. Two always-free-eligible resources in different regions talking to each other can produce inter-region transfer charges. Keep related services in the same region when you can.
Persistent disks and snapshots attached to a free instance are not automatically free. The instance allowance covers the VM, not necessarily the storage behind it.
Load balancers and static IPs carry their own line items. An unattached static IP has historically been billable precisely because it is reserved and unused.
Managed services with per-operation pricing can drift. A Firestore allowance measured in daily operations is easy to blow through with a chatty client that retries aggressively.
The pattern is consistent: the free part is narrow, and the surrounding infrastructure is where the meter runs.
The Free Tier Is Not a Production Home
It is tempting to treat a free e2-micro as a permanent home for a small side project. Sometimes that works. But there are structural reasons to be cautious.
Free-tier resources come with quotas that are lower than standard, and those quotas can change. No service level agreement backs them the way paid capacity is backed. Eligibility rules can shift. And the regional restriction means your “free” instance may sit far from your users, adding latency you would not accept in a real product.
A reasonable mental model: the free tier is a learning environment and a prototyping environment. It is excellent for that. It is a poor foundation for anything with an uptime promise attached.
Free Tier Versus Other Google Free Offers
People regularly conflate several unrelated things.
The GCP free tier covers Google Cloud infrastructure products: compute, storage, data, and serverless. It has nothing to do with the storage quota in a personal Google account, and nothing to do with Google Workspace subscription tiers. Those are separate products with separate limits.
It is also distinct from committed use discounts and sustained use discounts, which are pricing mechanics for paid usage rather than free allowances. A workload can benefit from both, but they are not the same lever.
And it is not the same as the credits that come through startup programs or educational partnerships. Those are separate pools with their own terms and expiry.
Practical Habits That Keep a Project Free
If the goal is to stay at zero, a few habits do most of the work.
- Pin everything to an eligible region. Check the region list for each product before you deploy, not after.
- Set a budget with alerts on day one. Low threshold, email notification, and a second alert at a higher level as a backstop.
- Tag and label resources. A consistent labeling scheme makes it possible to see, in billing reports, which project or experiment is responsible for a charge.
- Watch egress like a hawk. Any workload serving data to the public internet deserves an explicit egress estimate.
- Delete what you are not using. Idle disks, unattached IPs, and forgotten snapshots are the most common sources of small, persistent charges.
- Read the quota page for each product. Quotas are the real ceiling on free-tier experiments, and hitting one looks like a failure until you realize it is a limit.
That fourth point deserves emphasis. A surprising number of “the free tier charged me” stories trace back to outbound bandwidth, not to the compute allowance. Before launching anything public, it is worth reading up on how to inventory what a workload will actually consume, because the resource you think is the cost driver frequently is not.
How the Free Tier Fits Into a Broader Cloud Strategy
For teams, the free tier is less interesting as a permanent home and more interesting as a sandbox. It lets an engineer try a managed service without a procurement conversation. It lets a team validate an architecture before committing budget. It lets someone learn IAM, networking, and billing mechanics on real infrastructure rather than a simulation. (Building a shared platform without blocking delivery teams)
That sandbox value depends on keeping experiments isolated. Separate projects for separate experiments make it far easier to see costs, apply quotas, and delete cleanly. The same discipline that applies to splitting workloads across cloud accounts applies here at a smaller scale: isolation is what makes a mess recoverable.
There is also a governance angle. Free-tier experiments are still real cloud resources with real identity and access controls. Treating them as exempt from security review is a mistake. A leaked service account key in a hobby project is the same class of problem as one in production, just with a smaller blast radius.
What Changes and What Does Not
The specific numbers in the free tier move. The $300 trial figure, the storage gigabytes, the BigQuery query allowance, the eligible regions: all of these have been adjusted before and will be adjusted again. Anyone writing a budget around them should re-verify against current documentation.
What tends not to change is the structure. There will be an always-free set and a trial credit. Billing accounts will be required. Egress will cost money. Quotas will exist. Regional restrictions will persist because free capacity has to be placed somewhere. (9481.org)
Understanding that structure is more durable than memorizing a table of limits. If you know that the free part is narrow and the surrounding infrastructure is where charges appear, you can evaluate any future change to the program without relearning it from scratch.
Conclusion
The Google Cloud Platform free tier is genuinely useful and genuinely narrow. It gives you a real e2-micro instance, a few gigabytes of storage, a generous BigQuery query allowance, and serverless options, all without a subscription. It also requires a billing account, restricts key allowances to specific regions, and leaves egress, disks, and adjacent services fully billable.
The developers who get the most out of it are the ones who treat it as a lab rather than a host. They pin regions, set budgets with alerts, label everything, and keep an eye on outbound traffic. Do that, and the free tier is one of the better deals in cloud computing: a low-stakes way to learn a platform that otherwise asks for a credit card and a commitment.
Frequently Asked Questions
Do I need a credit card to use the Google Cloud free tier?
Generally, yes. Always-free resources still require a billing account with a valid payment method attached. Usage within the free limits should not be charged, but the payment method is part of how the account is set up and verified. Check current policy, since eligibility rules are adjusted from time to time.
Does the free tier expire?
The always-free allowances do not expire; they reset monthly. The free trial credits do expire after a fixed window, historically around 90 days. Those are two separate clocks, and mixing them up is a common source of confusion.
Why was I charged when I stayed within the free limits?
The most likely causes are network egress, cross-region data transfer, attached disks or snapshots, a resource deployed in a non-eligible region, or usage of a service that has no free allowance at all. The free allowance covers a specific resource, not the infrastructure around it.
Can I run a production website on the free tier?
Technically you can run something small, but it is not designed for production. Free-tier resources carry lower quotas, no service level agreement, and regional restrictions that may put your instance far from your users. Treat it as a lab or prototype environment.
Is the free tier the same as the free storage in my Google account?
No. The Google Cloud free tier covers infrastructure products such as Compute Engine, Cloud Storage, and BigQuery. Personal account storage quotas and Google Workspace plans are entirely separate products with their own limits.
How do I make sure I never get a surprise bill?
Set a budget with alerts at a low threshold on day one, label every resource so billing reports are readable, deploy only to eligible regions, estimate egress before serving anything publicly, and delete idle disks, snapshots, and unattached IP addresses. Alerts notify rather than cap, so pair them with periodic manual reviews of the billing console.
