What's changed: Created Associate Cloud Engineer Chapter 2 (Domain 2 "Planning and configuring": choosing compute = Compute Engine/GKE/Cloud Run/Cloud Functions/Spot VM/custom machine types; choosing storage and databases = Cloud SQL/Spanner/Firestore/Bigtable/BigQuery/Cloud Storage classes/Persistent Disk; planning networking = regions-zones/load balancers/Network Service Tiers).
2.1Choosing compute
Understand how to choose among four compute options by workload (Compute Engine VMs, managed Kubernetes GKE, serverless containers on Cloud Run, event-driven Cloud Functions), plus Spot VMs for cost and custom machine types to fit requirements.
Planning a cloud solution starts with "which compute to run on." Control versus operational ease is a trade-off; choose by workload nature (existing VMs, containers, or event-driven).
2.1.1Four compute options
| Service | Best for | Characteristic |
|---|---|---|
| Compute Engine | Existing VMs / OS-level control | IaaS, most control |
| GKE | Large containers/microservices | Managed Kubernetes |
| Cloud Run | Containers serverless | Scale to zero, pay per use |
| Cloud Functions | Event-driven small tasks | Run on a trigger |
Compute Engine is an IaaS VM with OS-level control, suited to migrations and special requirements. GKE is managed Kubernetes for large containers/microservices with Kubernetes-level control. Cloud Run runs containers serverless, scaling to zero when idle. Cloud Functions suits event-driven small tasks like "when a file is uploaded." Remember: "need OS control = CE; need Kubernetes = GKE; easy containers = Cloud Run; small event task = Cloud Functions."
2.1.2Spot VMs and custom machine types
On Compute Engine, you tune cost and performance to requirements. Spot VMs are much cheaper in exchange for possible preemption, suited to interruption-tolerant batch. When predefined machine types do not fit, custom machine types let you specify exactly the CPU and memory needed, avoiding waste. Map "cheap interruption-tolerant work = Spot VM" and "predefined ratios do not fit = custom machine type."
Common: requirement → service/option. E.g., "OS-level control / migrate existing VMs" = Compute Engine; "large containers on Kubernetes" = GKE; "easy serverless containers, scale to zero" = Cloud Run; "small event task" = Cloud Functions; "cheap interruption-tolerant batch" = Spot VM; "optimize CPU/memory ratio" = custom machine type.
Watch the mix-ups: (1) Cloud Run (containers, simple) vs GKE (keep Kubernetes control)—same containers, different operating models. (2) Cloud Functions = event-driven functions; Cloud Run = containers. (3) Spot VMs can be preempted, so they are unfit for interruption-sensitive work.
2.1.3Section summary
- CE (OS control/IaaS) / GKE (managed Kubernetes) / Cloud Run (serverless containers) / Cloud Functions (event-driven)
- Spot VM = deep discount for interruption-tolerant work (batch)
- Custom machine type = specify exactly the CPU/memory needed, avoiding waste
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to migrate existing Linux VMs with OS-level control. Which compute is best?
Q2. You want to operate containerized apps at scale while keeping Kubernetes control. Which is best?
Q3. You want a containerized web API that scales to zero when idle and bills per use. Which is best?
Q4. You want a small event-driven task triggered when a file is uploaded to Cloud Storage. Which is best?
Q5. You want to run a large interruption-tolerant batch as cheaply as possible. Which Compute Engine option is best?
Q6. When predefined machine-type CPU/memory ratios do not fit the workload, which choice fits?