Before the details, let us build a simple picture of the problem Compute Engine solves.

The old way: buying your own servers

A server is simply a computer whose job is to answer requests from other computers. When you open a website, a server somewhere sends you the page. In the past, any company that wanted a website had to buy physical servers, rent space in a data center, connect cables, install software, and hire people to keep it all running.

This was slow and expensive. If you guessed that you needed ten servers but suddenly became popular, you could not get fifty by tomorrow. If you bought a hundred and only needed ten, the other ninety sat idle, and you had already paid for them.

The new way: virtual machines on demand

A virtual machine, often shortened to VM, is a computer made of software instead of a single box of hardware. One big physical machine can host many VMs at the same time. Each VM believes it is a whole computer with its own processor, memory, disk and network card, but in truth it is sharing the big machine with others, safely separated.

Compute Engine is Google Cloud’s service for creating and running these VMs. In cloud language, this type of service is called IaaS, which stands for Infrastructure as a Service. You rent the raw building blocks (processing power, memory, disks, networks) and you decide everything that runs on top.

A short history

Google had been running its own giant fleets of computers for years to power its own products. Compute Engine was first previewed in 2012 and became generally available at the end of 2013. It was Google’s way of letting everyone else rent a slice of that same infrastructure. Since then it has grown from a handful of machine shapes into a very large family of options, including machines with graphics chips, machines with huge memory, and machines built for special security needs.

Where Compute Engine sits among Google Cloud compute options

Google Cloud offers several ways to run programs. Compute Engine gives you the most control and needs the most care. Other services give you less control but do more of the work for you.

Compute Engine has its own small vocabulary. Learn these words once and everything else becomes much easier.

Project

A project is a container that holds all your Google Cloud resources. Every VM, disk and network you create lives inside exactly one project. The project is also the place where billing, permissions and settings are attached.

Region and zone

Google has data centers in many parts of the world. A region is a geographic area, such as a part of a country. Inside each region there are several zones. A zone is a separate group of data center resources with its own power, cooling and networking, so a problem in one zone usually does not hurt the others in the same region.

A VM always lives in one zone. If you want your service to survive the loss of a whole zone, you place copies of your VMs in more than one zone.

Instance

In Compute Engine, a running virtual machine is called an instance. People use “VM” and “instance” to mean the same thing.

Machine type

A machine type is the size and shape of an instance. It decides how many virtual CPUs (the thinking parts) and how much memory (the short-term working space) the instance gets. Names such as e2-medium or n2-standard-4 tell you the family, the style and the number of CPUs.

Image

An image is a ready-made copy of an operating system, such as Linux or Windows, used to start the disk of a new VM. Google provides public images, and you can also make your own custom images that already contain your software.

Disk

A disk is where an instance keeps its files. The operating system lives on the boot disk. You can also attach extra data disks.

Metadata

Metadata is information about an instance that you or Google attach to it, such as its name, its settings and optional startup instructions. A small internal service called the metadata server lets software inside the VM read this information.

Service account

A service account is an identity that belongs to a program instead of a person. A VM can run as a service account so that the software on it can call other Google Cloud services, without anyone typing a password.

VPC network

A Virtual Private Cloud, or VPC, is your own private network inside Google Cloud. Your instances live in it and talk to each other through it. We will study this in depth later.

Now let us zoom out and see how all the pieces connect when a real application runs on Compute Engine.

A typical setup has several layers. At the front, a load balancer receives traffic from users and spreads it across many instances. In the middle, groups of instances run your application. At the back, storage and databases keep the data. Around everything sit the network rules, the identity rules, and the monitoring tools.

flowchart TD
  U["Users on the Internet"] --> GLB["Global External Load Balancer"]
  GLB --> FW["VPC Firewall Rules"]
  FW --> MIGA["Managed Instance Group - Zone A"]
  FW --> MIGB["Managed Instance Group - Zone B"]
  MIGA --> VMA1["VM App Server 1"]
  MIGA --> VMA2["VM App Server 2"]
  MIGB --> VMB1["VM App Server 3"]
  MIGB --> VMB2["VM App Server 4"]
  VMA1 --> PD1["Persistent Disk"]
  VMA2 --> PD2["Persistent Disk"]
  VMB1 --> PD3["Persistent Disk"]
  VMB2 --> PD4["Persistent Disk"]
  VMA1 --> DB["Managed Database Cloud SQL"]
  VMB1 --> DB
  VMA1 --> CACHE["Memorystore Cache"]
  VMB1 --> CACHE
  VMA1 -.-> MON["Cloud Monitoring and Logging"]
  VMB1 -.-> MON
  IAM["IAM and Service Accounts"] -.-> VMA1
  IAM -.-> VMB1

Walking through the picture

The users are people with phones and laptops. Their requests first meet the global external load balancer. This is a Google-run front door that has one public address and can send visitors to healthy instances in many regions. You do not run it yourself, so it does not turn into a single point of failure that you must babysit.

Next come the firewall rules. These are the guards that check each packet of data and decide whether it may enter. After the guards, traffic reaches a managed instance group, which is a team of identical VMs that Google keeps healthy and counts for you. Here we show two teams, one in each zone.

Each VM has its own persistent disk, which holds the operating system and local files. Shared information, such as customer orders, lives in a managed database, and quick-to-read information lives in a cache, which is a small, very fast store that remembers common answers.

Dotted lines show support services. Monitoring and logging collect numbers and messages from every VM. IAM, which stands for Identity and Access Management, controls who and what may do things.

Why this design works

Every layer can be repeated. If one waiter is sick, the host sends guests to the others. If a whole building is closed, the second building keeps serving. The design avoids placing all your eggs in one basket, which is the core idea behind building reliable systems at scale.

This is the part many tutorials skip. Knowing it will help you understand why Compute Engine behaves the way it does.

The hypervisor: the referee between VMs

On every physical machine in a Google data center runs a special program called a hypervisor. Its job is to carve one physical machine into many virtual ones and to keep them apart. Compute Engine uses a hypervisor built on KVM, a well-known open technology in the Linux world, and Google has hardened and customized it for its own needs.

The hypervisor hands each VM a share of processor time and a block of memory. It also makes sure one VM can never peek into another VM’s memory. This separation is what makes it safe for strangers’ workloads to share the same hardware.

Hardware helping the hypervisor

In newer machine generations, Google moves a lot of the busy work, such as handling network traffic and disk traffic, off the main processors and onto dedicated helper chips. This design, which Google calls Titanium for some families, frees more of the processor for your programs and adds a strong security boundary. As a user you do not configure it. You simply benefit from steadier performance.

The control plane and the data plane

Cloud systems are often described using two layers. The control plane is the brain that takes requests such as “create a VM” and decides where and how to do it. The data plane is the muscle that actually carries your traffic and runs your programs.

This split matters for reliability. A problem in the brain should not stop machines that are already running. In practice, your running instances usually keep serving users even if you cannot create new ones for a short time.

Placement: choosing a host

When you ask for a new instance, the control plane must pick a physical machine with enough free room in the zone you chose. Google runs its internal fleet with large-scale scheduling systems, and the idea is the same: find a good host, reserve the processor and memory, and start the VM there. You can influence the choice with options such as sole-tenant nodes, which reserve a whole physical server for your use, and placement policies, which ask for VMs to be close together for speed or spread apart for safety.

Live migration: moving a running VM without stopping it

Physical machines need updates and repairs. Normally, that would mean shutting down everything on them. Compute Engine avoids this with live migration. While your VM keeps running, Google copies its memory and state to another physical host in small steps, then switches over in a very short pause that most programs never notice.

Live migration does not work for every VM. Machines with attached graphics accelerators and Spot VMs follow different rules. For those, Compute Engine may stop the VM during maintenance, so you must design for that.

Networking: Andromeda

Google’s virtual network software is named Andromeda. It is a software-defined network, which means the roads between VMs are drawn by software rather than by fixed cables. When two of your VMs talk, Andromeda finds the physical path, applies your firewall rules, and delivers the data. Because the network is software, Google can add features such as global VPC networks without rebuilding hardware.

Disks: storage over the network

Persistent Disk does not live inside the same physical box as your VM. It is stored in Google’s distributed storage system and reached over a fast network. This is why you can detach a disk from one VM and attach it to another, and why a disk survives even if the host machine fails. We cover storage fully in a later chapter.

Every instance has a life story. Understanding each stage helps you avoid surprise bills and surprise outages.

What happens when you create a VM

Let us follow a single request from your click to a running machine.

sequenceDiagram
  participant E as Engineer
  participant API as Compute Engine API
  participant CP as Control Plane
  participant H as Physical Host
  participant D as Persistent Disk Service
  participant N as Andromeda Network
  E->>API: Create instance request
  API->>API: Check permissions and quotas
  API->>CP: Valid request accepted
  CP->>H: Reserve CPU and memory
  CP->>D: Create boot disk from image
  CP->>N: Attach network interface and rules
  H->>H: Boot guest operating system
  H-->>E: Instance state becomes Running

Startup scripts and metadata

You can give an instance a startup script through metadata. When the VM boots, it reads the script and runs it. This is a simple way to install software or fetch configuration automatically so that every new VM comes up ready to work.

Data flow at runtime

Once a VM is running, data moves in three main directions. Requests arrive through the network card. Reads and writes travel to the persistent disk over the storage network. And outgoing calls go to other services such as databases, queues and APIs. Each of these paths has its own limits, which is why one overloaded path can slow the whole VM even when the processor looks idle.

Picking a machine type is like picking a vehicle. A bicycle, a van and a truck all move things, but each is best at a different job.

How machine types are named

A name such as n2-standard-8 has three parts. The first part, n2, is the series, which is a hardware generation and style. The middle part, standard, is the memory ratio, which tells you how much memory comes with each CPU. The last part, 8, is the number of virtual CPUs. A vCPU is one virtual processor thread given to your VM.

The main families

Predefined, custom and extended memory

Most people choose a predefined machine type, such as four CPUs with sixteen gigabytes of memory. If none of the standard shapes fits, some families let you build a custom machine type, where you pick the exact number of CPUs and the exact amount of memory. This avoids paying for memory you never use. Some families also allow extended memory, which adds more memory per CPU than usual for programs that are very memory hungry.

CPU platforms: Intel, AMD and Arm

Compute Engine offers processors from different makers. Some series use Intel chips, some use AMD chips, and some newer series use Arm-based chips designed for strong performance per dollar. Your software must be built for the right chip type. Most Linux programs are available for both, but older closed-source software may be built for only one.

How to right-size

Right-sizing means matching the machine to the real work. Too small, and users wait. Too big, and money is wasted. Follow these steps:

1. Start with a sensible guess based on a similar application.
2. Run the real workload and watch processor, memory, disk and network graphs for at least a week.
3. If the processor is nearly always below one quarter, try a smaller size. If it often reaches ninety percent, try a larger size or add more machines.
4. Check Google’s built-in recommendations, which look at past usage and suggest better sizes.
5. Repeat every few months, because workloads change.

A VM that forgets everything when it stops is not much use. Storage is how your data stays safe and fast.

Persistent Disk

Persistent Disk is network-attached block storage. “Block storage” means the disk looks to the VM like a normal hard drive that you can format and fill with files. “Persistent” means the data stays even when the VM is stopped or deleted, as long as you keep the disk.

Zonal and regional disks

A normal Persistent Disk lives in one zone. A regional Persistent Disk keeps copies in two zones of the same region. If one zone fails, you can attach the disk to a VM in the other zone and carry on. This costs more but gives you a strong safety net for important data.

Local SSD

Local SSD disks are physically attached to the host machine, so they are extremely fast. The trade-off is that their data is not meant to last. If the VM is stopped or the host has a problem, the data on a Local SSD can be lost. Use them only for scratch work, caches and temporary files, never for the only copy of anything.

Performance depends on more than the disk

Three things set how fast a Persistent Disk feels. First, the disk type. Second, the disk size, because larger disks of many types are allowed more operations per second. Third, the VM size, because small VMs have a lower cap on how much disk traffic they can push. If a database is slow, check all three before blaming the software.

Images, custom images and image families

An image is the starting copy used to fill a boot disk. Google supplies popular operating systems. A custom image is one you make yourself after installing your software, so new VMs start with everything ready. An image family is a named line of images, so that asking for the family always gives you the newest one in it.

Snapshots and machine images

A snapshot is a saved copy of a disk at a point in time. After the first full copy, later snapshots store only what changed, which saves space and money. Snapshots are how you back up disks, and how you copy a disk to another zone or region. A machine image goes further: it saves the VM’s settings, metadata and all its disks together.

Encryption

Data on Persistent Disk is encrypted at rest by default, which means it is scrambled while stored so that a stolen disk would be unreadable. By default Google manages the keys. If your rules require it, you can supply keys through Cloud KMS, which stands for Key Management Service, or provide your own, so you control when data becomes unreadable.

Networking connects your machines to each other and to the world. It is also where many security mistakes begin.

VPC networks are global

In many clouds, a private network is tied to one region. In Google Cloud, a VPC network is a global resource. One VPC can contain machines in Asia, Europe and America, and they can talk to each other over Google’s private backbone without you building tunnels. Inside the VPC you create subnets, and each subnet belongs to one region and owns a range of internal addresses.

Internal and external IP addresses

An IP address is the number that identifies a machine on a network. Every instance gets an internal IP for talking inside the VPC. It can also get an external IP for talking to the public internet. External IPs can be ephemeral, which means they may change when the VM stops, or static, which means you reserve them so they never change.

Many safe designs give application VMs no external IP at all. They reach the internet only through a managed gateway called Cloud NAT, which lets machines make outgoing requests, such as downloading updates, without letting strangers connect inward.

Firewall rules

A firewall rule decides which traffic is allowed or blocked. Each rule says which direction (incoming or outgoing), which source or destination, which protocol and port, and which machines it applies to. By default, incoming traffic is denied and outgoing traffic is allowed. You open only what you need. Rules can target machines by network tags or by service accounts, so new VMs get the right rules automatically.

flowchart LR
  NET["Internet"] --> LB["External Load Balancer"]
  LB --> WEB
  subgraph VPC["Custom VPC Network"]
    subgraph SUBA["Subnet A - Region 1"]
      WEB["Web Tier VMs - no external IP"]
    end
    subgraph SUBB["Subnet B - Region 1"]
      APP["App Tier VMs"]
    end
    subgraph SUBC["Subnet C - Region 1"]
      DBT["Database VMs"]
    end
    WEB -->|"allow port 8080"| APP
    APP -->|"allow database port"| DBT
  end
  APP --> NAT["Cloud NAT"]
  NAT --> NET
  ADMIN["Admin via IAP"] -.-> APP

Load balancing options

A load balancer spreads work across many instances and stops sending traffic to broken ones. Google offers several kinds. Global external Application Load Balancers handle web traffic at the front door across the world, using one address. Regional and internal load balancers handle traffic inside a region or inside your private network. Network load balancers pass raw connections for non-web protocols. Behind each one sits a group of instances and a health check, which is a small repeated test that asks each machine, “Are you well?”

Network tiers

Google offers Premium Tier networking, which carries your traffic on Google’s own backbone for as long as possible, and Standard Tier, which hands traffic to the public internet sooner and costs less. Premium is better for speed and steadiness. Standard can suit cost-sensitive work in a single region.

Other connection tools

• Cloud DNS turns names such as shop.example.com into IP addresses.
• VPC peering connects two VPCs privately.
• Cloud VPN and Cloud Interconnect link your office or old data center to Google Cloud over an encrypted tunnel or a private line.
• Private Google Access lets VMs without external IPs reach Google services.

Running one VM by hand is easy. Running hundreds that heal and grow by themselves is where Compute Engine becomes powerful.

Instance templates

An instance template is a saved recipe for a VM. It records the machine type, image, disks, network, tags, service account and startup script. Once you have a template, you can create identical machines again and again without clicking through every option. Templates cannot be edited after creation. To change something, you make a new template.

Managed instance groups

A managed instance group, or MIG, is a team of identical VMs built from one template and managed as one unit. You tell the group how many machines you want, and Compute Engine makes it so. A regional MIG spreads machines across up to three zones, which protects you if one zone has trouble.

An unmanaged instance group is just a bag of machines you place together by hand, with no automatic creation or healing. It is rarely the best choice for new work.

What a MIG does for you

Autoscaling signals

The autoscaler watches a number and tries to keep it near a target you set. Common signals are average processor use, requests per second reaching a load balancer, and custom metrics from your own software, such as the length of a job queue. You also set a minimum and maximum number of machines. The minimum keeps a safe floor. The maximum puts a ceiling on cost. Schedules can raise the minimum before a known busy time.

New machines take time to start. A cool-down period tells the autoscaler to wait for a new machine to warm up before judging its numbers, which prevents wild swings.

flowchart TD
  M["Metrics: CPU, requests, queue length"] --> AS["Autoscaler"]
  AS -->|"load high: add machines"| MIG["Managed Instance Group"]
  AS -->|"load low: remove machines"| MIG
  TPL["Instance Template"] --> MIG
  HC["Health Check"] --> MIG
  MIG --> V1["VM 1"]
  MIG --> V2["VM 2"]
  MIG --> V3["VM 3"]
  HC -.->|"unhealthy: recreate"| V2
  LB["Load Balancer"] --> V1
  LB --> V2
  LB --> V3

Rolling out new versions safely

Stateless and stateful groups

Most MIGs are stateless, meaning any machine can be thrown away and replaced because nothing precious lives on it. Some programs, such as databases, need a machine to keep its name, disk and address after repair. Stateful MIGs support that by preserving chosen disks and settings.

Cloud bills can surprise people. Once you understand the pricing levers, you can cut costs a great deal without hurting users.

What you pay for

The bill for a VM has several parts. You pay for processor and memory while the instance runs. You pay for disks and snapshots for as long as they exist. You pay for network traffic that leaves Google Cloud, and for some traffic between regions and zones. You pay for reserved external addresses and for any special licenses, such as certain Windows or database products. Graphics chips cost extra as well.

The pricing models

Spot VMs explained

Google’s data centers always keep some spare room. Spot VMs let you use that spare room cheaply. The catch is that Google can preempt, which means stop and reclaim, your VM when it needs the capacity, usually giving only a short warning of about thirty seconds. Spot VMs have no fixed maximum lifetime, unlike the older preemptible type that stopped after twenty-four hours.

Use Spot VMs for video conversion, data processing, scientific runs and test systems. Design the work in small pieces that save progress, so a preemption only loses a little.

More ways to save

1. Right-size machines using the recommendations in the console.
2. Stop or delete idle machines. Instance schedules can start development machines in the morning and stop them at night.
3. Delete unattached disks and old snapshots. These are quiet money leaks.
4. Release unused static addresses.
5. Keep traffic local. Put chatty services in the same zone or region where possible, since crossing zones and regions can add charges.
6. Use labels on every resource, such as team and environment, so the bill can be split and understood.
7. Set budgets and alerts so someone is told before costs run away.

Machines break, buildings lose power, and software has bugs. A reliable system is one that keeps working anyway.

What availability means

Availability is the share of time your service works for users. People often describe it in “nines”. Ninety-nine percent allows about three and a half days of downtime in a year. Ninety-nine point nine percent allows under nine hours. Ninety-nine point ninety-nine percent allows under an hour. Each extra nine is much harder and more costly to reach.

Reliability is a wider idea: the service gives correct answers, quickly, over a long time. A site that is “up” but returns errors is available in name only.

What Google does for you

• Live migration moves running VMs away from hosts that need maintenance, so most planned events cause no restart.
• Automatic restart brings a VM back if it crashes or its host fails. You choose this in the availability policy.
• Redundant storage, since Persistent Disk keeps multiple copies inside Google’s storage system.
• A service level agreement, or SLA, which is a written promise of uptime with credits if Google misses it. Google offers its highest promise to instances spread across more than one zone. Read the current SLA for exact numbers and conditions.

What you must do

Google protects the hardware. You protect the design. Reliability on Compute Engine rests on four habits.

flowchart TD
  USERS["Users"] --> GLB["Global Load Balancer with Health Checks"]
  GLB --> RA["Regional MIG - Zone A"]
  GLB --> RB["Regional MIG - Zone B"]
  GLB --> RC["Regional MIG - Zone C"]
  RA --> SQL["Primary Database Zone A"]
  RB --> SQL
  RC --> SQL
  SQL -->|"synchronous copy"| STBY["Standby Database Zone B"]
  RA --> OBJ["Cloud Storage for shared files"]
  RB --> OBJ
  RC --> OBJ

Recovery targets

Two numbers guide every recovery plan. RTO, the Recovery Time Objective, is how long you can afford to be down. RPO, the Recovery Point Objective, is how much recent data you can afford to lose. A shop that can lose no orders needs a very small RPO, which means copying data constantly. A report system that can lose one day of data can use nightly snapshots.

Disaster recovery patterns

Security in the cloud is a shared job. Google protects the building, the hardware and the hypervisor. You protect everything you put on top.

The shared responsibility model

With Compute Engine, Google secures the physical data centers, the network, the storage system and the virtualization layer. You are responsible for the guest operating system, the software you install, the firewall rules, the accounts that can log in, and the data you store. Because Compute Engine is infrastructure as a service, your share is bigger than with Cloud Run or App Engine.

Identity and access: IAM

IAM decides who can do what to which resource. A role is a bundle of permissions. Follow the principle of least privilege: give each person and program only the permissions needed for the job, and nothing more. Broad roles such as Owner or Editor on a whole project are risky.

Service accounts

Each VM runs as a service account. By default, new VMs may use the Compute Engine default service account, which in many older projects holds very wide permissions. Create a separate, narrow service account for each application, and grant it only what that application needs. Avoid downloading long-lived key files. A VM can obtain short-lived credentials from the metadata server instead, so nothing secret sits on disk.

Safe login: OS Login and IAP

OS Login ties Linux and Windows logins to Google identities, so access is controlled by IAM and can be removed in one place, rather than by loose key files copied onto machines. Identity-Aware Proxy TCP forwarding, usually called IAP, lets administrators connect to machines that have no external IP, after Google checks who they are. This removes the need to expose login ports to the internet at all.

Shielded VM and Confidential VM

• Shielded VMs use a secure boot chain, a virtual security chip called a vTPM, and integrity monitoring. They help detect attackers who change the boot process or install hidden low-level malware.
• Confidential VMs use special processor features to keep memory encrypted even while the VM runs, protecting data in use from the host itself. They suit very sensitive workloads.

Network protection

Combine several layers. Use custom VPC networks with small subnets, not the permissive default network. Write narrow firewall rules. Give application machines no external IP and use Cloud NAT for outbound needs. Place a load balancer in front, and add Cloud Armor, Google’s web application firewall and attack-absorbing service, for public sites. Use VPC Service Controls when you need to fence in sensitive Google services so data cannot be copied out.

Keeping the operating system healthy

Software ages and gains known flaws. VM Manager helps you see which machines lack updates and apply patches on a schedule. Best of all is to rebuild images regularly with updates included and roll them out through your instance groups, rather than patching long-lived machines by hand.

Protecting data

Disks are encrypted at rest by default. Traffic between Google data centers is also protected. Use Secret Manager to store passwords and tokens, and never write them inside images, startup scripts or source code. Turn on audit logs so you can answer, “Who did what, and when?”

You cannot fix what you cannot see. Observability is the habit of making your system explain itself.

The three kinds of signals

Metrics are numbers over time, such as processor use or requests per second. Logs are written messages that record events, such as an error or a login. Traces follow one request as it travels through many services, showing where time was spent. Together they answer three questions: Is something wrong? What went wrong? Where did it go wrong?

Cloud Monitoring and the Ops Agent

Without any setup, Compute Engine reports basic numbers about each VM, such as processor use, disk traffic and network traffic. These come from outside the machine, so they cannot see inside the operating system. For deeper information, such as memory use inside the VM, individual processes and application logs, you install the Ops Agent. It is one small program that collects both metrics and logs and sends them to Google Cloud.

Cloud Logging

Cloud Logging stores logs from your machines and from Google Cloud itself. Platform audit logs record administrative actions, such as who created or deleted a VM. You can search logs, build charts from them, route copies to storage or analytics tools, and set how long to keep them. Remember that very chatty logs cost money to store, so log with purpose.

The signals worth watching

These four signals, often called the golden signals, give a quick and honest picture of health for almost any service.

Alerts that help, not annoy

An alert is a message sent when a number crosses a line. Good alerts point to problems that users feel and that a person must act on. Bad alerts fire constantly for small things, and people learn to ignore them. Alert on symptoms, such as high error rate or slow responses, rather than on every small cause. Attach to each alert a short runbook, which is a written list of steps for fixing the problem.

Uptime checks and dashboards

An uptime check is a robot that visits your service from several places around the world and reports whether it answered. A dashboard puts your key charts on one page. Build one per service, so that during an incident everyone looks at the same picture.

Debugging a misbehaving VM

When a machine will not start or cannot be reached, the serial console gives you the text output the machine prints while it boots, even when networking is broken. Combine it with the logs, the guest agent messages and the instance’s state history to find the cause.

A pattern is a proven way to solve a common problem. An anti-pattern is a common mistake that looks reasonable but causes pain later.

Patterns that work

Anti-patterns to avoid

This chapter collects the habits of teams that run Compute Engine well, and the mistakes of those who learned the hard way.

Best practices

Organization and governance

• Use separate projects for development, testing and production, so a mistake in one cannot touch another.
• Group projects in folders under an organization and apply organization policies for safe defaults.
• Label every resource with its owner, environment and cost center.
• Manage infrastructure as code, using a tool such as Terraform or Google’s own deployment tools, so that every change is reviewed and repeatable.

Operations

• Use managed instance groups for anything that serves users, even if you only need one machine today.
• Build golden images through an automated pipeline and keep them updated.
• Test restores, failovers and scale-up before you need them.
• Keep a written runbook for each alert.
• Request quota increases ahead of a big launch, because quotas can quietly block new machines at the worst moment.

Performance

• Choose the machine family for the job: compute-optimized for fast processors, memory-optimized for huge memory.
• Place machines near their users and near the data they use.
• Put chatty components in the same zone and use a cache to avoid repeated slow calls.
• Test with realistic load before launch, and look at the slowest requests, not just the average.

Cost

• Review right-sizing recommendations monthly.
• Use commitments for stable load and Spot VMs for restartable work.
• Schedule development machines to stop outside working hours.
• Clean up unused disks, snapshots, images and addresses.

Common mistakes

Let us look at the kinds of work that Compute Engine carries every day, with companies that have spoken publicly about using Google Cloud.

What these stories have in common

Each example shares the same ideas that run through this guide. Machines are created from templates and replaced when they fail. Work is spread across zones. Capacity follows demand. Costs are matched to how steady the work is. Security and monitoring are built in from the start. The names and numbers differ, but the habits are the same.

Building a system is one job. Keeping it healthy for years is another. This chapter covers the everyday tools and routines that make the second job calmer.

The guest environment

Inside most Google-supplied images runs a small helper program called the guest environment, sometimes called the guest agent. It talks to the metadata server and performs small chores for the VM. It creates user accounts for logins, sets up the network, runs startup and shutdown scripts, and reports useful facts back to Google Cloud. If you build your own custom image from scratch, you should install this helper, or many convenient features will quietly stop working.

Startup and shutdown scripts

A startup script runs every time the VM boots. A shutdown script runs when the VM is being stopped or preempted, and gets only a short time to finish. Startup scripts are handy for small configuration steps, such as setting a machine name or fetching a setting from Secret Manager. Shutdown scripts are handy for saving a last piece of work or telling a load balancer, “I am leaving.” Because the time is short, shutdown scripts should do only quick, simple things.

Metadata: project level and instance level

Metadata can be set for the whole project or for a single instance. Project-level metadata is shared by all machines in the project. Instance-level metadata applies to just one machine and wins when both exist. Software inside the VM can ask the metadata server for values such as the instance name, the zone, the project and short-lived access tokens for its service account. It can also wait for changes, which lets you pass new settings to running machines without logging in to them.

Because the metadata server hands out access tokens, any software that can reach it can act as the VM’s service account. That is another reason to keep service accounts narrow, and to treat any flaw that lets outsiders make the VM send requests to internal addresses as serious.

Maintenance behavior

Every instance has a maintenance policy. For most machines the default is live migration, which keeps the VM running. For others, the policy is to terminate the VM when its host needs work. You also choose whether the VM should automatically restart after such a stop. For long-running services, choose automatic restart. For one-time batch jobs, you may prefer that a stopped VM simply stays stopped.

Instance schedules

An instance schedule automatically starts and stops groups of VMs at set times. A classic use is a development environment that runs only on weekdays from morning until evening. Over a month, this can cut the cost of those machines by more than half, with no change to the software.

Patching and configuration with VM Manager

VM Manager is a set of tools for managing many machines at once. It can list which software packages are installed on each machine, check for missing security updates, and apply patches in controlled waves, for example starting with test machines and moving to production only after success. It can also check that machines match a desired configuration and report those that have drifted away.

Machine lifecycle in the real world

Quotas and capacity

Every project has quotas, which are limits on how many resources of each type you can create in each region. Examples include the total number of CPUs, the number of GPUs, the number of external addresses and the amount of disk space. Quotas protect you from accidental runaway use and help Google plan capacity. They can also block a legitimate launch if you forget about them. Check your limits well before a big event and ask for increases in time.

Quotas are different from capacity. Even with enough quota, a zone may sometimes lack free machines of a very popular type, especially graphics chips. If a launch must not fail, you can make a reservation, which holds a set number of machines for you in a chosen zone. You pay for reserved machines whether or not you use them, so reservations suit only the most important needs.

Sole-tenant nodes and licensing

Normally your VMs share physical servers with other customers, safely separated by the hypervisor. A sole-tenant node is a whole physical server dedicated to your project. You place your VMs on it. This is useful when software licenses are tied to physical processors, when compliance rules demand separation from other customers, or when you want tight control over where machines live. It costs more and needs careful planning to avoid wasting spare room on the node.

Windows and special software

Compute Engine runs Windows Server as well as many Linux versions. Windows images carry a license fee that is added to the hourly price. Some database and enterprise products can also be licensed through Google, or you can bring licenses you already own, if the terms allow. Check license rules before you migrate, because they can change the real cost more than the machine itself.

Speed is a feature. This chapter shows how to find what is slow, and how to plan for growth before it surprises you.

Find the bottleneck first

A bottleneck is the narrowest part of a pipe, the part that limits how much can flow through. Making any other part faster will not help until the bottleneck is fixed. The four usual suspects are the processor, the memory, the disk and the network. Tune them in that order of evidence, not in order of guesswork. Look at the charts first, change one thing, and measure again.

Network bandwidth and machine size

The outgoing network speed of a VM depends on its size. Small machines get a lower cap, and large ones get a higher cap. Some series offer special high-bandwidth settings for very demanding programs. If a data-heavy application is slow, check whether the machine’s network cap, rather than the application, is the limit.

Placement for speed

Distance matters. Light in a cable takes real time, so a request that crosses an ocean is slower than one that stays in a city. Place machines in a region close to most of your users, and keep tightly connected machines in the same zone when speed matters most. A compact placement policy asks Google to place machines close together, which helps programs that talk constantly to each other, such as scientific calculations that spread one problem over many machines.

Caching: avoiding repeat work

A cache remembers answers to common questions so the program does not have to work them out again. Put a cache such as Memorystore in front of a slow database, or use a content delivery network such as Cloud CDN in front of your web machines, so popular pages are served from places close to users. A good cache can remove most of the load from your machines, which is cheaper than adding machines.

Warm-up and cold starts

A new machine is not instantly useful. It must boot, start your software, fill its caches and pass health checks. In practice a few seconds to a few minutes pass before it carries a full share of traffic. Plan for this by scaling a little early, using custom images, and telling the autoscaler how long a machine needs to warm up.

Capacity planning in five steps

1. Measure today. Find your normal and peak requests per second, and how much of each resource they use.
2. Find the unit of capacity. For example, one machine safely handles two hundred requests per second at seventy percent processor use.
3. Forecast. Estimate growth, special events and seasonal peaks. Add a safety margin.
4. Test. Run load tests that copy real traffic patterns, and confirm that the autoscaler and the database keep up.
5. Review. Compare forecasts with reality each quarter and adjust.

The calculation is simple. If peak traffic is ten thousand requests per second and each machine handles two hundred, you need fifty machines at peak. Add machines for the safety margin and for the loss of a zone. If you run in three zones and must survive losing one, each zone must be able to take half of the load alone, so you need about seventy-five machines in total rather than fifty.

Many teams do not start from nothing. They already have servers, and the question is how to move them without breaking the business.

The common migration styles

A safe migration path

Things that surprise teams

• Latency changes. If the application stays in the cloud but its database stays in the old data center, every query crosses a long link and the app may feel much slower. Move tightly connected parts together.
• Licensing. Some software is priced by processor or by physical server. Check that the license allows virtual machines in the cloud.
• Hardware assumptions. Old programs may expect a fixed machine name, a special device, or a shared disk. Test for these early.
• Network design. Plan IP address ranges so that the cloud network does not overlap with your office or old data center ranges, because overlapping ranges cannot be joined cleanly.
• Cost shape. Cloud costs are ongoing and flexible, while old data centers were large one-time purchases. Without cleanup and right-sizing, a lifted-and-moved system can cost more than expected.

Short, direct answers to questions that beginners ask most often.

You have now seen Compute Engine from the outside and from the inside. Here is the whole story in one place.

Compute Engine rents you virtual machines running on Google’s global infrastructure. A hypervisor keeps machines apart, live migration keeps them running during maintenance, Andromeda carries their traffic, and Persistent Disk keeps their data safe. You choose the machine shape, the disk, the network and the rules, and Google does the heavy lifting underneath.