Service 01

Compute Engine

ComputeInfrastructureIaaS

Compute Engine is Google Cloud's virtual machine service. You choose an OS image, a machine type that defines vCPU count and memory, a region and zone, a boot disk, and a network interface. From that point, it behaves like any Linux or Windows server. The physical hardware is Google's; the rest is yours to configure and operate.

One distinguishing feature is live migration: Google can move a running VM off hardware scheduled for maintenance without rebooting it. Other clouds offer live migration in various forms, but Compute Engine applies it transparently and by default across the fleet, so most maintenance events pass without a reboot. For workloads where downtime is expensive, this matters.

Machine Families and Types

Google organizes machine types into families with distinct cost and performance profiles. Choosing the wrong family for a workload is one of the most common and most expensive mistakes in cloud infrastructure.

General-purposeC4/C4D · N4 · C3/C3D · E2

Balanced, everyday workloads. C4/C4D and N4 are the current generation for new workloads; C4A runs Google's own Axion Arm chips; E2 stays the cheapest for dev/test and small services. (N2/N2D, T2D, and N1 are older generations, still widely used.)

Compute-optimizedC2 · H3/H4D

High CPU performance per core. When single-thread speed is the bottleneck — HPC, batch processing, CPU-bound analytics, low-latency services.

Memory-optimizedM3 · M4 · X4

Very high RAM per core. Chosen for memory capacity, not CPU speed — large in-memory databases and SAP HANA.

Accelerator-optimizedA3 · A4 · G2

Attached NVIDIA GPUs (H100, B200, L4). ML training and inference, rendering, and other GPU workloads — the choice is the accelerator, not the CPU. TPUs are separate Cloud TPU infrastructure, not GPUs attached to these VMs.

Choose by workload type first, not by a single cost-or-speed scale. The four families optimize for different things; the wrong one is both slower and more expensive for the job.

Family	Series	Best for
General Purpose	C4 / C4D / N4	The current generation for new workloads. C4 for performance, N4 for flexible cost-efficiency. Hyperdisk only.
General Purpose	C4A	Google Axion (Arm). Best price-performance for scale-out, throughput-oriented tasks.
General Purpose	E2	Cost-optimized workloads: dev, test, small services. Up to 32 vCPUs.
General Purpose	N2 / N2D	Previous generation of balanced everyday workloads. N2D uses AMD EPYC. Still common in existing fleets.
General Purpose	N1	Previous generation. Widest ecosystem of attached GPU options. Still widely used.
General Purpose	T2D / T2A	Older scale-out series: T2D (AMD), T2A (Arm Ampere Altra) — superseded by C4A for new Arm workloads.
Compute Optimized	C2 / C2D	High single-threaded performance. Gaming servers, HPC, media transcoding.
Compute Optimized	H3 / H4D	HPC-focused series for tightly coupled compute — dense cores, high-bandwidth networking.
Memory Optimized	M3 / M4 / X4	In-memory databases (SAP HANA), large analytics. X4 reaches 32 TB RAM.
Accelerator Optimized	A3 / A4	NVIDIA H100 / B200 GPUs. ML training, inference, HPC. (A2 with A100s is the previous generation.)
Accelerator Optimized	G2	NVIDIA L4 GPUs. Video transcoding, inference, virtual workstations.

You can also define custom machine types with any vCPU count and memory ratio within family limits — useful when predefined types waste either CPU or memory for your specific workload profile.

Preemptible VMs and Spot VMs

Preemptible VMs cost up to 91% less than standard pricing, but Google can reclaim them with a 30-second notice at any time, and they run for a maximum of 24 hours. Spot VMs extend the concept: also reclaimed with 30-second notice, no 24-hour limit, and dynamic pricing that changes at most once every 30 days. Both are unsuitable for workloads that cannot tolerate interruption without implementing checkpointing or graceful shutdown handling.

Appropriate use cases: batch processing, rendering farms, CI/CD build agents, ML training jobs with checkpointing, and any workload where partial completion has value and retries are cheap.

Pricing Models

On-demand pricing applies to standard instances with no commitment. Sustained use discounts are automatic and tiered, reaching up to 30% off at full-month utilization — no configuration required (note they do not apply to some cost-optimized series such as E2 and Tau). Committed use discounts offer larger savings — roughly up to 37% off for a one-year commitment and up to 55% off for three years, reaching as much as 70% on memory-optimized resources — in exchange for committing to a specific amount of vCPU and memory in a region.

Instance Templates and Managed Instance Groups

An instance template is a blueprint — it captures machine type, boot disk image, network configuration, startup script, labels, and service account. You cannot create a Managed Instance Group without one.

A Managed Instance Group (MIG) creates and manages a collection of identical VMs based on an instance template. It handles:

Autohealing: attaches a health check; unhealthy instances are automatically deleted and recreated.
Autoscaling: grows or shrinks the group based on CPU utilization, HTTP load balancing, Cloud Monitoring metrics, or a custom schedule.
Rolling updates: replacing the instance template triggers a controlled rollout with configurable max surge and max unavailable settings.
Canary deployments: roll out a new template to a percentage of instances, validate, then continue or roll back.

MIGs come in two forms. Zonal MIGs run all instances in a single zone. Regional MIGs distribute instances across multiple zones, providing automatic cross-zone failover. For any production workload, use regional MIGs.

Stateful MIGs preserve per-instance state across recreations: specific disks, IP addresses, or metadata can be pinned to individual instances by name.

Startup and Shutdown Scripts

Startup scripts run as root when an instance boots. Shutdown scripts run (best-effort) before instance termination. The metadata server at 169.254.169.254 is accessible from within any instance and provides runtime configuration and the instance's service account token.

OS Patch Management

OS Patch Management lets you create patch jobs that apply OS updates across a fleet of instances with configurable maintenance windows and rollout strategies. Running without automated patching is a vulnerability backlog in waiting.

Shielded VMs and Confidential VMs

Shielded VMs verify the integrity of the boot chain using Secure Boot, vTPM, and integrity monitoring. Confidential VMs encrypt memory contents while the VM is running using technologies such as AMD SEV, SEV-SNP, and Intel TDX, protecting against insider threats at the hypervisor level. Shielded VM is on by default for new instances (only Secure Boot must be enabled explicitly); Confidential VMs are opt-in.

Sole-Tenant Nodes

Sole-tenant nodes give you dedicated physical servers hosting only your VMs, required for certain compliance regimes and software licenses tied to physical cores.

Compute Engine vs Cloud Run vs GKE

Compute Engine — OS-level control required, legacy application migration, software that cannot be containerized, GPU/TPU workloads.

Cloud Run — containerized HTTP services and batch jobs. No OS management. Scale-to-zero economics. The right default for new web services.

GKE — multiple containerized services that need coordinated orchestration, stateful workloads with complex storage, teams with existing Kubernetes investment.

Common Mistakes

Exposing VMs directly with public IPs instead of routing through a load balancer.
Not using MIGs for stateless services, losing autohealing and autoscaling.
Embedding service account key files in VM images or startup scripts instead of assigning a service account to the instance.
Not using OS Patch Management, accumulating unpatched vulnerabilities across a fleet.
Not using committed use discounts for baseline capacity that has been stable for 6+ months.

Best Practices

Assign service accounts to instances with the minimum IAM roles required.
Use Regional MIGs with autohealing and autoscaling for all stateless production workloads.
Define instance templates for all production VMs.
Enable OS Patch Management with a weekly schedule at minimum.
Never assign external IPs to instances that do not need them. Use Cloud NAT for outbound internet access.
Use Spot VMs for batch and CI workloads.
Purchase committed use discounts for stable baseline capacity.

Comparable services AWS EC2 + Auto Scaling Groups Azure Virtual Machines + VMSS

Knowledge Check

What is live migration in Compute Engine?

Copying a running VM's disks to another region on a schedule for disaster recovery failover
Moving a running VM off hardware scheduled for maintenance without rebooting it
Automatically scaling VMs based on CPU utilization
Migrating workloads from AWS or Azure to Google Cloud

What is the key difference between Spot VMs and Preemptible VMs?

Spot VMs are cheaper than Preemptible VMs
Preemptible VMs run with no 24-hour maximum runtime, whereas Spot VMs are capped at 24 hours
Spot VMs have no 24-hour limit and have demand-based pricing
There is no meaningful difference between them

What does a Managed Instance Group's autohealing feature do?

Automatically restores VMs from the most recent disk backup whenever instance data is lost
Detects unhealthy instances via a health check and replaces them automatically
Scales the group up when demand increases
Monitors VMs for security vulnerabilities

What discount is available with a 3-year committed use discount?

Up to 30% off standard pricing
Up to 57% off standard pricing
Up to 70% off standard pricing
Up to 91% off standard pricing

What is the purpose of an instance template in Compute Engine?

A cost estimate for running a particular VM configuration
A blueprint capturing machine type, disk, network config, startup script, and service account — required to create a MIG
A template of OS configuration files automatically deployed to existing running VMs across the project
A policy that restricts which machine types, regions, disk sizes, and boot images may be used to create VMs across the whole project

You got correct