Skip to content

COST.md

Latest commit

 

History

History
88 lines (73 loc) · 4.72 KB

COST.md

File metadata and controls

88 lines (73 loc) · 4.72 KB
Raw

Chapter 7 Cost Decision: GKE Standard vs Autopilot

This is a teardown project, not a standing bill. You'll spin this up for the migration chapters, then destroy it when you're done. Nothing here is designed to run for a full month. Monthly figures below are a unit of comparison (including against infra/aws/COST.md), not a prediction of what you'll actually be charged. Read the daily figure first.

# The exit, in reverse stage order: costs stop when the resources are gone
cd infra/gcp/terraform/08-edge && terraform destroy
# then 07-observability through 01-foundation, same command in each

Prices below are on-demand, us-east4, current as of September 2026. Verify against the GCP Pricing Calculator before treating these as gospel, they drift, and regional multipliers change (us-east4 currently runs about 8% above the us-central1 baseline most published prices quote).

What Standard actually costs here

Component Spec Daily cost Monthly cost (reference only)
GKE control plane zonal Standard cluster $2.40, first cluster per billing account gets a ~$2.48/day credit, so this is effectively $0 for most readers running one cluster $0.10/hr (~$72/mo), first-cluster credit ~$74.40/mo
Node (steady state) 1× e2-medium (2 vCPU, 4 GiB) ~$1.44 $0.060/hr ($43/mo) with the us-east4 premium
Node (peak, autoscaled to 3) 3× e2-medium ~$4.32, only while actually scaled up ~$129/mo, only while actually scaled up
Disk 30 GB pd-standard per node ~$0.04 per node ~$1.20/mo per node
Cloud NAT 1 VM + 1 static NAT IP ~$0.15 ($0.0014/VM-hr gateway + $0.005/hr for the IP; data is a separate $0.045/GiB) ~$4.50/mo + data

Realistic range for this project: roughly $1.60–5/day (about $50–150/month as a reference unit), depending almost entirely on how much of the time the node pool is scaled past 1 node, which depends on your traffic during the migration chapters, not on a fixed formula.

A weekend on the 1-node steady state, with the control-plane credit, is somewhere around $3–5. Dual-run with AWS still up adds AWS's ~$1.25/day on top (infra/aws/COST.md).

Why this book uses Standard instead of Autopilot: stated plainly

This is not a claim that Standard is cheaper. There is no universal answer to that question, and don't let anyone (including an earlier draft of this repo's own reasoning) tell you otherwise as a blanket rule:

  • Autopilot bills per pod resource request, roughly $0.0445/vCPU-hr and $0.0049/GiB-hr as of early 2026. Against typical, imperfectly-tuned Standard usage, Autopilot usually wins, because it structurally eliminates idle-node waste.
  • A team that actively right-sizes Standard node pools and runs Spot VMs well can beat Autopilot on raw cost. Google's own published comparisons say as much. Autopilot's per-unit price is higher; its advantage is eliminating waste, not a lower rate.
  • There is no fixed utilization percentage where one wins, it depends on machine type, bin-packing, Spot mix, and workload shape. Don't trust a number pulled from a blog post (including this one) over your own math for your own workload.

The actual reason this project uses Standard: this is a book about production judgment, and Autopilot removes the exact layer there is to learn, node pools, machine selection, bin-packing, autoscaling behavior. Autopilot is the right call for a team that wants to trade cost-tuning effort for operational simplicity. This project isn't that team, on purpose, because the tuning IS the lesson.

Do the calculation yourself before you accept this

  1. Estimate your actual pod resource requests (Chapter 10 sets these), CPU and memory, per replica, per environment.
  2. Multiply by Autopilot's per-unit rates above → that's your Autopilot estimate (convert to daily the same way this file does).
  3. Compare against this file's Standard estimate, adjusted for how much of the time you expect to run at 1 node vs 3.
  4. Whichever number is actually lower, for your actual numbers, is your answer, not whichever this file or any blog post recommends.

Zonal vs regional cluster

This repo uses a zonal cluster (03-gke/variables.tf, zone = "us-east4-a"). A regional cluster replicates the control plane across three zones for higher availability, and by default spreads the node pool across those same three zones too, meaningfully more node cost for resilience this demo project doesn't need. If you're adapting this for something that actually needs zone-level HA, that's a real reason to switch; doing it here "because it looks more production-grade" is the same trap the environment-count decision (Chapter 10c) already avoided once.