Google Cloud's Always Free tier includes a genuinely permanent virtual machine — one e2-micro instance, running continuously, at no charge. It is the smallest of the three big-cloud free VM offers, and the one whose limits are easiest to breach by accident, because the binding constraint is not the machine. It is the one gigabyte of monthly egress.

There is also a charge most people do not expect, on the default configuration, which the free tier page does not mention at all. It is covered below.

What this article is: a reading of published free-tier limits with the practical consequences worked out, checked against Google's own pages on 12 August 2026. What it is not: a review or benchmark. Yangworks runs on Cloudflare, not on Compute Engine, and has provisioned none of these instances. No throughput, latency, or uptime figure is measured or claimed.

What the allowance actually is

Quoting the Free Tier page directly:

Instance    "1 non-preemptible e2-micro VM instance per month
             in one of the following US regions"
Regions     "Oregon: us-west1"
            "Iowa: us-central1"
            "South Carolina: us-east1"
Disk        "30 GB-months standard persistent disk"
Egress      "1 GB of outbound data transfer from North America
             to all region destinations (excluding China and
             Australia) per month"
Excluded    "GPUs and TPUs are not included in the Free Tier
             offer. You are always charged for GPUs and TPUs
             that you add to VM instances."

Two things about that list are easy to misread.

The instance allowance is metered in hours, not instances. Google spells this out: Your Free Tier e2-micro instance limit is by time, not by instance. Each month, eligible use of all of your e2-micro instances is free until you have used a number of hours equal to the total hours in the current month. Usage calculations are combined across the supported regions. So it funds one machine running continuously — or, equivalently, two machines each running half the month. Run two e2-micro instances concurrently for a full month and roughly half that usage is billable.

Only three US regions qualify. E2 machine types are available in essentially every Google Cloud region; free-tier eligibility is not. Launch your e2-micro in Frankfurt or Singapore and it is an ordinary billable VM that looks identical in the console. This is the single most common way people are surprised by a Compute Engine bill.

The machine: two vCPUs that are really a quarter of one

e2-micro is a shared-core machine type with 1 GB of memory. It presents two vCPUs, each entitled to 12.5% of CPU time — 25% of a core in total — with the ability to burst above that for short periods. Bursting does not cost extra; it is part of the shared-core design rather than a credit you buy.

Author judgment: treat the "2 vCPU" in the spec sheet as a scheduling detail, not as capacity. A quarter of a modern core is enough to run a small compiled service comfortably and enough to make a package install or a container build feel slow. If your mental model is "two cores," you will be disappointed; if it is "a quarter core that can briefly sprint," you will size things correctly.

The disk trap: your default boot disk is probably the wrong type

The 30 GB-month allowance is specifically for standard persistent disk — pd-standard. Balanced and SSD persistent disks bill at ordinary rates from the first gigabyte.

This matters because the default boot disk type for many current images is balanced, not standard. Accept the defaults in the console and you get a free VM attached to a billable disk — a small charge, but a recurring one that arrives with no warning and is genuinely confusing to diagnose, because the instance line item really is zero.

gcloud compute instances create free-box \
  --machine-type=e2-micro \
  --zone=us-west1-b \
  --boot-disk-type=pd-standard \
  --boot-disk-size=30GB

The --boot-disk-type=pd-standard flag is the one that is easy to omit and expensive to forget.

One gigabyte of egress, and what it rules out

This is the limit that decides whether the free tier fits your project at all. Google's wording is 1 GB of outbound data transfer from North America to all region destinations (excluding China and Australia) per month — so the allowance is measured leaving North America, and traffic to China or Australia does not draw on it at all.

A gigabyte a month is roughly 33 MB a day. Some arithmetic to make that concrete:

A 200 KB page view            ~5,000 views/month
A 2 MB page with images         ~500 views/month
Streaming API responses       depends entirely on volume
Serving any media             not viable

Inbound transfer is free — the network pricing page states No charge for inbound data transfer, with the caveat that a resource processing that data may itself be billed. Traffic to a different Google Cloud service in the same region using an external or internal IP is also listed as no charge, with named exceptions including Memorystore for Redis, Filestore, GKE, and Cloud SQL.

Author judgment: the 1 GB ceiling means the free e2-micro is a compute box, not a serving box. It is well suited to work that consumes bytes and emits few: a scheduled job, a scraper writing to a database, a webhook receiver, a bot, a monitoring agent, a build runner, a personal VPN endpoint used lightly. It is unsuited to hosting a website you hope people read. If you want the same machine class for public serving, look at a provider whose free egress is measured in terabytes rather than gigabytes.

The part that is not free: the external IP address

This is the most important thing in this article, and the free tier page does not mention it. An external IPv4 address attached to a running VM is billed, and the free allowance for it is an hour a month.

From Google's VPC network pricing page:

Free Tier: Both static and ephemeral IP addresses assigned to standard VM instances are offered with a free tier. This free usage is limited to one hour per month per account.

The rates that apply after that hour:

Static/ephemeral IP, in use on a standard VM   $0.005 / hour
Static/ephemeral IP, in use on Spot/preemptible $0.0025 / hour
Static IP, assigned but unused                 $0.01  / hour
IP attached to a forwarding rule               no charge
External IPv6 assigned to a VM                 no charge

Arithmetic, since the consequence is what matters:

$0.005/hr x 730 hr        = $3.65 / month
                          ~ $43.80 / year
minus the 1 free hour     = $3.645 / month

Note also Google's definition of "in use": Google Cloud considers a static external IP address as in use if it is associated with a VM instance whether the instance is running or stopped. Stopping the VM does not stop the address charge.

Author judgment: this is the single most misleading thing about the offer, and it is not a trap in the sense of a mistake you make — it is the default. Create an e2-micro the ordinary way, in the right region, with the right disk type, and you still have a machine that costs roughly $3.65 a month. That is cheap, and it is not free, and every "free VPS forever" article that omits it is wrong. The instance line item genuinely reads zero, so the charge appears under networking where nobody thinks to look.

Two ways out. Run the instance with no external IPv4 address and reach it over Identity-Aware Proxy or a tunnel, giving it outbound access via Cloud NAT — but Cloud NAT is itself billed at $0.005 per hour for the addresses it uses, so this only helps if you were already going to run one, or if the instance needs no outbound internet at all. Or use IPv6, which Google states is not charged for external addresses assigned to VM instances — viable only if everything you talk to is reachable over IPv6.

Either way: read the networking section of your first monthly bill, not just the Compute Engine section.

Free tier versus the trial credit

New accounts get a free trial credit, and the Free Tier is separate from it. Free Tier usage is not charged against the trial credit; during the trial you have access to both. When the trial ends and you upgrade to a paid account, remaining credit carries over and Free Tier access continues — you are billed only for usage beyond the free limits.

The practical consequence: the interesting question is not "what happens when my $300 runs out," it is "what am I running that sits outside the free limits." A free-tier e2-micro in us-west1 with a pd-standard boot disk and light egress should survive the end of the trial unchanged. A balanced disk, a second instance, or a wrong region will not.

What you can realistically run

Reasoning from documented specifications, not measurement. I have not run these workloads on this instance type.

One gigabyte of memory with a quarter core is a real constraint, but a narrower one than it looks for compiled services. New API, a frequently self-hosted LLM gateway, documents its requirements as SQLite with a mounted /data directory or a remote MySQL ≥ 5.7.8 or PostgreSQL ≥ 9.6, under Docker or Docker Compose, 64-bit only (amd64 / arm64). It states no minimum CPU or RAM at all.

That silence is the point: a Go service proxying HTTP is not what exhausts 1 GB. Co-locating a MySQL server with it is. On e2-micro the realistic configuration is the service plus SQLite, with swap configured, and the database elsewhere if you need a real one.

Comfortable    one small compiled service + SQLite
               reverse proxy / tunnel endpoint
               cron jobs, scrapers, webhook receivers
               monitoring or log-shipping agent

Tight          Docker builds (do them elsewhere, pull the image)
               anything JVM-based
               co-located MySQL or PostgreSQL

Wrong tool     serving public traffic at any volume
               (the 1 GB egress cap, not the CPU)

One caveat worth stating on a popular use case: routing a subscription-based AI CLI through a self-hosted proxy may conflict with that provider's terms of service. That is a licensing question rather than a capacity one, and running it on free infrastructure does not change the answer.

How to apply

1. Create a Google Cloud account; a billing account with a
   card is required even to use only free-tier resources.
2. Create the instance in us-west1, us-central1, or us-east1.
   Nowhere else qualifies.
3. Machine type e2-micro. Not e2-small, which is not free.
4. Explicitly set --boot-disk-type=pd-standard, 30 GB or less.
5. Decide the external IP question deliberately. Keeping one
   costs about $3.65/month; dropping it means reaching the box
   over IAP, a tunnel, or IPv6.
6. Set a billing budget alert at a low threshold, e.g. $1.
   This is the step that turns a silent mistake into an email.
7. After the first full month, read the billing report line by
   line — the networking section, not just Compute Engine.

Step 6 is the one I would not skip. The free tier's failure mode is not a big bill; it is a small recurring one you do not notice for a year.

Who should not use this

Anyone who needs the machine outside the three eligible US regions. Anyone serving more than a trickle of public traffic — the egress cap will decide this for you. Anyone who wants a free box for a client project, given that the configuration required to keep it free is precise enough that an unrelated console change can quietly start billing. And anyone who wants Arm: the free e2-micro is x86, and Google's Arm machine types are not in the free tier.

Above all, anyone who needs the total to be zero. Between the external IP address and the boot disk default, this offer is better described as a very cheap VM than a free one. If zero is the requirement, the offer to look at is one whose free machine keeps its address.