Choosing the right GCP machine family is a standing cost lever because the default is rarely the cheapest fit: E2 and Tau exist precisely to deliver general purpose and scale out compute at a lower price than premium performance families. E2 is a cost optimized general purpose family running on shared, dynamically scheduled hardware, which suits steady, latency tolerant workloads such as web servers, microservices, and development environments. Tau, the T2 family, is built for cost per vCPU on scale out workloads that spread across many cores, such as containerised microservices and horizontally scaled web tiers. Matching the family to the workload's actual performance profile, rather than defaulting to a performance family, captures a meaningful discount with no loss to workloads that never needed the premium.
This walks the families, where each one pays, and how the choice compounds with commitments and spot capacity.
What problem do E2 and Tau solve?
Most general purpose workloads do not need the peak per core performance of a premium family; they need adequate, steady compute at the lowest price. E2 delivers exactly that by running on shared hardware with dynamic scheduling, trading guaranteed peak performance for a lower rate. Tau takes a different angle: it is engineered so that the cost per vCPU is low when you scale out across many cores, which is the pattern of stateless web tiers and microservices that add replicas rather than growing a single large instance. The premium families remain the right choice for workloads bound by single thread speed or specialised hardware, but using them for ordinary general purpose load is a quiet, recurring overpayment.
| Family | Profile | Best fit |
|---|---|---|
| E2 | Cost optimized general purpose on shared, dynamically scheduled hardware | Steady, latency tolerant web, microservices, dev and test |
| Tau (T2) | Scale out, low cost per vCPU across many cores | Horizontally scaling stateless services |
| Performance families | Higher per core performance, specialised hardware | Single thread bound or specialised workloads only |
How do you decide which family a workload belongs on?
Start from the workload's measured behaviour, not its label. If a service runs at moderate, steady utilization and tolerates the occasional scheduling variation, E2 is usually the cheapest correct home. If a service scales by adding replicas and its cost is dominated by aggregate vCPU rather than peak per core, Tau's cost per vCPU advantage compounds across the fleet. If a workload is bound by single thread performance, latency sensitive at the core level, or needs specialised accelerators, keep it on the family built for that and do not force a cheaper shape. The discipline is to profile before you place, because a wrong family choice either overpays on a premium shape or underperforms on a cost shape.
List your largest compute spend by machine family. If general purpose web and microservice workloads are sitting on premium families, moving the latency tolerant ones to E2 and the scale out ones to Tau is a price cut with no architecture change for workloads that never needed the premium.
How does family choice compound with commitments and spot?
Family choice is the base layer; commitments and spot multiply it. Once a workload is on the right family, a spend based CUD on the steady portion locks in a further discount that survives shape changes within the service, while resource based CUDs suit a family and region you are confident will persist. For interruption tolerant batch and stateless scale out work, spot and preemptible capacity layer on a deeper discount still. The order matters: pick the right family first so you are committing to and discounting the correct, cheaper baseline, rather than committing to a premium shape you should have moved off.
A worked example
A European SaaS company ran its entire stateless web and microservice tier on a premium general purpose family by default, with low commitment coverage. We profiled the workloads, moved the latency tolerant general purpose services to E2 and the horizontally scaling tier to Tau, then committed spend based CUDs on the new, lower baseline and moved batch jobs to spot capacity. Per workload compute cost fell from the family change alone, and the commitment and spot layers compounded it, all without touching the application code. Figures are verified against billing data and anonymized.
Where this fits
Family choice is one of the architecture decisions covered in the GCP architecture choices that cut cost, and the spot layer is detailed in spot VMs and preemptible economics on GCP. The full method, including how compute sits alongside commitments and BigQuery, is in the GCP cost optimization guide, with the cross cloud comparison in the cross cloud cost optimization guide.
Frequently asked questions
What is the GCP E2 machine family used for?
What is the Tau machine family on GCP?
Should you use E2 or Tau for cost savings?
Take the next step on your cloud spend
We are an independent buyer side advisory that cuts public cloud spend across AWS, Azure, GCP, and OCI. We hold over $2.4B in annual cloud spend under management, take zero provider commissions, and deliver a 31 percent median reduction in the first 90 days. Our guarantee is simple: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk to you.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.