Compute Engine: Build and Operate a Google Cloud VM

Compute Engine Overview

Compute Engine provides virtual machines with control over the image, machine shape, disks, network interfaces, service account, metadata, and maintenance behavior. That control also leaves patching, process supervision, hardening, and capacity decisions with the workload team.

A single VM is a useful learning unit but not a resilient production architecture. Managed instance groups add templates, health-based repair, autoscaling, and rolling updates for replicated workloads.

Instance Configuration

Start with workload requirements: CPU architecture, memory, accelerators, local or durable storage, expected traffic, operating system support, and zone availability. Machine families optimize for different balances rather than forming a simple small-to-large ladder.

Boot disks persist differently from local SSD, while deletion behavior is configurable. Snapshots help recover disk state but do not replace application-consistent backups or a tested restore procedure.

Use a supported image family or a controlled custom image.
Avoid a public IP when administration and traffic can use private paths.
Attach a workload-specific service account with narrow API scopes and IAM roles.

Startup and Bootstrap

A startup script runs during boot and is valuable for small demonstrations. For repeatable fleets, bake stable dependencies into an image and keep startup work short, observable, and safe to run more than once.

Serial console output, guest logs, systemd status, health checks, and instance metadata provide better evidence than an open browser tab. A failed package repository or missing IAM permission can leave the VM running but the application absent.

Create a small web VM with explicit settings

gcloud compute instances create vm-web-01 \
  --project=tl-cloud-lab \
  --zone=us-central1-a \
  --machine-type=e2-micro \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --no-service-account \
  --metadata=startup-script="#!/bin/bash
apt-get update
apt-get install -y nginx
systemctl enable --now nginx"

gcloud compute instances get-serial-port-output vm-web-01 \
  --zone=us-central1-a --port=1

No service account is attached because this static web lab calls no Google API.
Create a narrowly targeted firewall rule separately if HTTP access is required.

Managed Instance Group Rollout

An instance template makes VM configuration immutable enough to reproduce. A managed instance group can replace unhealthy members and spread replicas according to its regional or zonal design.

Rolling updates need a health signal, surge and unavailable limits, application startup time, connection draining, and a rollback plan. Autoscaling also needs upper bounds and quota headroom.

Instance Design Contract

A Compute Engine VM combines a machine type, boot image, disks, network interfaces, metadata, labels, scheduling behavior, and service account in a zone. Choose CPU platform, memory, accelerator, and disk performance from measured workload demand. Region and zone selection must also consider dependency location, quota, hardware availability, latency, data residency, and recovery rather than proximity alone.

Treat the boot disk and guest configuration as reproducible inputs. Build a patched image or use a deterministic startup process, pin important versions, and keep application state outside the disposable boot lifecycle. Startup scripts run with powerful local context and can fetch metadata, so protect who can change instance metadata and avoid embedding secrets directly in scripts or images.

Use Shielded VM, OS Login, secure boot where compatible, and a dedicated least-privilege service account. Prefer Identity-Aware Proxy or managed access paths over exposing SSH or RDP to the internet. Network tags and service accounts can target firewall rules, but tags are not identities and should be governed as security-relevant configuration.

Benchmark the intended machine family with representative load.
Record image, disk, network, identity, and metadata ownership.
Keep secrets in Secret Manager or another approved system.
Remove external IP addresses unless the workload requires them.

Managed Instance Groups

A managed instance group creates and reconciles VMs from an instance template. Use a regional MIG for stateless services that must tolerate a zonal failure, and place it behind a health-checked load balancer. Autoscaling changes replica count from a signal such as CPU, load-balancer utilization, a monitoring metric, or schedule; it does not repair a slow database or remove a downstream quota.

Autohealing health checks should measure whether an instance can serve useful work, while load-balancer health checks decide whether it should receive traffic. Make initialization periods long enough for startup without masking a stuck application. A repaired VM may be recreated, so local changes disappear. Stateful MIG features preserve selected identity, disk, IP, or metadata state but add operational constraints and do not replace backups.

Instance-template updates create a new desired version. Configure surge, unavailable capacity, replacement method, and minimum ready time according to real headroom. Canary a small percentage, observe application and infrastructure signals, then continue or roll back. An update operation reporting completion does not prove every new instance passed business-level checks.

Use immutable templates and version them with the release artifact.
Test autohealing separately from autoscaling.
Protect zonal capacity by distributing a regional group.
Drain connections before deleting serving instances.

Disk and Data Recovery

Persistent Disk and Hyperdisk options differ in performance, sharing, durability, and regional capability. Size performance from IOPS, throughput, latency, and workload shape, not only gigabytes. Filesystem consistency and application consistency are separate: a crash-consistent snapshot may still require database recovery, while a coordinated snapshot or native database backup can provide a cleaner restore point.

Snapshot schedules reduce manual work, but a backup is useful only when restoration is proven. Test creating a disk in the intended recovery project and region, attaching it to a clean VM, validating data, and documenting elapsed time. Protect snapshots and backup projects with narrower deletion rights than the production instance. Replication or a regional disk improves availability but can replicate corruption and is not historical recovery.

Define behavior for a full disk, failed mount, detached disk, accidental deletion, compromised administrator, and unavailable zone. Monitor capacity and latency before the filesystem becomes read-only or the application stalls. Keep temporary files, logs, and caches on storage whose deletion and cost characteristics match their value.

Match disk type and size to measured I/O demand.
Separate replication, snapshot, backup, and archive objectives.
Practice restore with an operator who did not create the backup.
Record RPO and RTO evidence from the drill.

Operations and Shutdown

Monitor guest health, application health, serial console output, CPU, memory through an agent, disk latency, network traffic, uptime, and service-level indicators. Logs and metrics must identify image version, instance group, zone, and release. Alert on user impact and exhausted capacity rather than every transient host event that the platform can repair automatically.

Maintenance behavior depends on machine features and scheduling configuration. Decide whether live migration, restart, termination, or host error is acceptable, and design the process accordingly. Spot VMs can be economical for interruptible work but require checkpointing, idempotent tasks, bounded retries, and capacity fallback. They are not simply cheaper permanent servers.

On shutdown or preemption, stop accepting work, drain requests, checkpoint safe progress, flush telemetry, and exit within the available notice window. Test the path by deleting instances from a group during load. Also rehearse zone loss, quota exhaustion, failed image rollout, metadata error, expired package repository access, and a downstream outage before declaring the fleet production-ready.

Automate patching and replace instances instead of nursing drift.
Set deletion protection only with an explicit removal procedure.
Use labels for owner, environment, application, and lifecycle.
Review idle VMs, disks, snapshots, and reserved capacity together.

Capacity Loss Exercise

A regional design can still fail when the selected machine family, accelerator, Spot capacity, or quota is unavailable in the remaining zone. Run a capacity-loss exercise that prevents placement in one zone and observes managed instance group behavior, autoscaler decisions, load-balancer health, startup time, and downstream connection pressure.

Define acceptable fallback before the event: another zone, a compatible machine type, reserved capacity, queued work, reduced features, or controlled load shedding. Changing machine shape during an incident can affect performance and licensing, so benchmark the fallback and keep it in reviewed instance templates.

Include image and package availability in the test. A group cannot recreate VMs if a referenced image was deleted, an artifact repository is unreachable, or startup downloads depend on the failed region. Preserve immutable inputs and verify that replacement capacity reaches application readiness, not merely VM running state.

Measure time from capacity loss to useful service.
Keep a tested placement fallback.
Verify immutable startup dependencies remain available.
Confirm fallback capacity preserves the service objective.
Record regional quota required by the fallback shape.
Recheck placement policy after capacity reservations change.
Verify emergency templates remain deployable.

Compute Engine Examples

Roll a Managed Instance Group Safely

A new instance template boots but fails the application health check.

Roll a Managed Instance Group Safely

Constraints: At least 90% capacity must remain available and instances contain no unique state.
Decision: Start a canary update, watch health and logs, then halt and roll back to the prior template when the canary fails.
Verification: Healthy capacity stays above the limit and the previous template serves all traffic after rollback.
Failure test: Make startup fail before the health check and confirm autohealing does not create an unbounded replacement loop.

Output

Expected evidence: Healthy capacity stays above the limit and the previous template serves all traffic after rollback.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on