Compute Engine is Google Cloud’s way of letting you rent virtual computers.

The simple definition

Compute Engine is an Infrastructure as a Service product, often shortened to IaaS. That means Google gives you the raw building blocks of computing: processing power, memory, storage, and network connections. You decide what to put on top. A computer that you rent this way is called a virtual machine, or VM. In Compute Engine, a VM is also called an instance. The two words mean the same thing here.

A virtual machine behaves like a normal computer. It has an operating system such as Linux or Windows. You can install programs, store files, and connect to it over the internet. The difference is that no one ships you a box. Google runs a very powerful physical server in a data center and carves a slice of it for you. Software called a hypervisor keeps your slice separate from everyone else’s slice, so neighbors cannot see your data.

Why does it exist?

Before cloud computing, a company that needed a server had to buy one, wait weeks for delivery, find space for it, and keep it cooled and powered. If the server was too small, they bought another. If it was too big, money was wasted. Compute Engine removes that waiting and guessing. You can create a VM in under a minute, use it for an hour, and delete it. This freedom is why start-ups and giant companies both use it.

Where is it used?

People use Compute Engine for websites, mobile app back-ends, databases they manage themselves, games, video processing, scientific calculations, and training artificial intelligence models. It is especially useful when you need full control over the operating system or when your software was written long before containers existed.

Almost everything in Compute Engine is made from a handful of simple parts.

Before going deeper, let us meet the cast of characters. Each of these terms appears again and again in documentation, job interviews, and architecture meetings. Learn them now and the rest of the tutorial will feel easy.

How the pieces fit together

When you create a VM, you make a handful of choices: which project, which location, which machine type, which image, which disk, and which network. Compute Engine then finds a physical server with free room, starts your VM there, attaches the disk over a fast internal network, and gives it an address. Because the disk is attached over the network rather than soldered inside the server, the VM can be moved, restarted, or rebuilt without losing the disk.

Location decides speed, price, and how well you survive failures.

Regions and zones

Google Cloud is split into regions. A region is a geographic area, such as Mumbai, Delhi, Iowa, or Frankfurt. Inside each region are several zones. A zone is like one separate building, or a group of buildings, with its own power, cooling, and networking. When you create a VM, you choose a zone, and that VM runs in that zone only.

The reason for this design is safety. If a fire, flood, or power cut affects one zone, the other zones in the same region keep working. Spreading your VMs across zones means a single bad day in one building does not take your whole application offline.

flowchart TD
  P["Google Cloud Project"] --> R1["Region: us-central1"]
  P --> R2["Region: asia-south1"]
  R1 --> Z1["Zone a"]
  R1 --> Z2["Zone b"]
  R1 --> Z3["Zone c"]
  Z1 --> V1["VM"]
  Z2 --> V2["VM"]
  R2 --> Z4["Zone a"]
  Z4 --> V3["VM"]
        

The diagram shows that a project is not tied to one place. You can run a VM near your customers in India and another near customers in the United States under the same project and the same bill.

How to choose a location

Choosing the right size and shape of VM is the most important cost decision you make.

What is a vCPU?

A vCPU is a virtual processor, the unit used to measure how much thinking power your VM has. In Compute Engine, one vCPU generally corresponds to one hardware thread of a real processor. A VM with four vCPUs can do four things at the same moment. Memory, measured in gigabytes, is the VM’s short-term workspace, like the size of a desk where you spread papers while working.

Machine families

Google groups machine types into families, each built for a certain kind of job. The family names change as new hardware arrives, but the ideas stay the same.

Predefined, custom, and shared-core types

A VM without storage forgets everything. Disks give it a memory that lasts.

Persistent Disk

The most common storage for Compute Engine is Persistent Disk. It is a network-attached drive. That means it is not inside the physical server your VM runs on; it lives in Google’s storage system and connects over the network. Because it is separate, your data survives even if the VM is stopped, deleted, or moved to another host. Data on Persistent Disk is stored redundantly, so the failure of one drive does not lose your files.

You can make a disk bigger while the VM is running, which is a big relief when storage runs low at midnight. You can also attach several disks to one VM, and some types let more than one VM read the same disk.

Types of block storage

Regional disks and sharing

For critical applications, regional Persistent Disk keeps a synchronized copy of your data in two zones of the same region. If one zone fails, you can start a replacement VM in the other zone and attach the same disk. This costs more but gives strong protection for databases that cannot afford to lose data.

These three tools let you build once and copy many times.

Images

An image is the starting contents of a boot disk. Google offers public images for popular systems such as Debian, Ubuntu, Rocky Linux, Red Hat Enterprise Linux, SUSE, Windows Server, and Container-Optimized OS, a lean system made for running containers. You can also build custom images that already contain your software and settings, so a new VM is ready to work the moment it starts.

Snapshots

A snapshot is a backup of a disk. The first snapshot copies everything; later ones save only what changed, which keeps costs low and speed high. You can schedule snapshots to run automatically, such as every night, and keep them for a chosen number of days. If a disk is damaged or a bad change is made, you create a new disk from a snapshot and you are back in business.

Machine images and instance templates

A machine image captures an entire VM, including its settings and all attached disks. An instance template is lighter: it stores the configuration for building new VMs, such as the machine type, the image, the network, and labels. Templates are the foundation for groups of identical machines.

Every VM moves through a clear set of states from birth to deletion.

The lifecycle

When you press create, the VM does not appear instantly in a working state. It moves through stages, and knowing them helps you understand what the console is telling you and what you are being billed for.

flowchart LR
  A["Provisioning"] --> B["Staging"]
  B --> C["Running"]
  C --> D["Stopping"]
  D --> E["Stopped"]
  E -->|Start| A
  C --> F["Suspended"]
  F -->|Resume| C
  C --> G["Repairing"]
  G --> C
  E -->|Delete| H["Deleted"]
        

Live migration and maintenance

Physical servers need updates and repairs. On many machine types, Compute Engine can move a running VM to a different physical host without turning it off. This is called live migration. Your application may notice a very brief pause, but it does not reboot. For some specialized hardware such as certain GPU machines, live migration is not possible, so the VM is stopped during maintenance instead. You can set a policy that decides whether the VM migrates or stops, and whether it restarts automatically after a failure.

The metadata server

Every VM can ask a special internal service, the metadata server, about itself. The VM can learn its own name, zone, network details, and custom settings you attached. Startup scripts use this service to learn what they should do when the machine boots. It is only reachable from inside the VM, which keeps it private.

A VM is only useful if the right people and programs can talk to it, and the wrong ones cannot.

VPC networks

A Virtual Private Cloud, or VPC, is your private network inside Google Cloud. One special thing about Google’s design is that a VPC network is global. Its subnets, which are smaller address ranges, belong to specific regions, but the network as a whole spans the world. VMs in different regions can talk to each other over private addresses on Google’s own backbone without you building special links.

Internal and external addresses

Each VM gets an internal address for talking to other resources in your network. It can also get an external address so that the public internet can reach it. External addresses are either ephemeral, meaning temporary and they may change, or static, meaning reserved and stable. A VM does not have to have a public address at all. Many secure designs keep VMs private and let traffic in only through a load balancer.

Firewall rules

VPC firewall rules decide which traffic is allowed to reach or leave your VMs. By default, incoming traffic is blocked and outgoing traffic is allowed, and you add rules to open specific doors. Rules can target VMs using network tags or service accounts, so you can say “let web traffic reach the machines labeled web” without listing addresses one by one. Rules are stateful, so replies to allowed traffic are let back in automatically.

Security in the cloud is shared: Google protects the building, and you protect what is inside your apartment.

The shared responsibility idea

Google secures the physical data centers, the hardware, and the hypervisor. You are responsible for your operating system updates, your application, your firewall rules, and who is allowed to do what. Many cloud problems come from the customer’s side of this line, not Google’s.

Identity and access

IAM, which stands for Identity and Access Management, decides which people and programs may perform which actions on your VMs. You grant roles, such as permission to view instances or permission to start and stop them. The golden rule is least privilege: give each person only the access they need to do their work.

Programs on a VM also need an identity. This is a service account, a special account that represents the application rather than a human. The VM uses it to call other Google Cloud services without storing passwords in files. The default service account often has broad permissions, so it is wise to create dedicated service accounts with narrow roles.

Safe ways to log in

Protecting the machine itself

Shielded VMs add checks that confirm the VM has not been tampered with at startup. They include Secure Boot, a virtual trusted platform module, and integrity monitoring that warns you if the boot process changes unexpectedly. Confidential VMs go further by keeping data encrypted even while it is being processed in memory, which matters for sensitive industries. Data on disks is encrypted by default, and you can bring your own encryption keys if your rules demand it.

One VM is a hobby. A group of VMs that manages itself is a service.

Managed instance groups

A managed instance group, or MIG, is a collection of identical VMs built from one instance template and managed as a single unit. A MIG can live in one zone or spread across several zones in a region, which is the better choice for important workloads. Because every VM in the group comes from the same recipe, any one of them can be replaced without anyone caring which specific machine it was.

flowchart TD
  U["Users"] --> LB["Cloud Load Balancer"]
  LB --> M["Managed Instance Group"]
  M --> V1["VM 1 in zone a"]
  M --> V2["VM 2 in zone b"]
  M --> V3["VM 3 in zone c"]
  HC["Health Check"] -.-> M
  AS["Autoscaler"] -.-> M
  T["Instance Template"] --> M
        

Read the diagram from top to bottom. Users send requests to the load balancer. The load balancer shares those requests among healthy VMs. The group is built from a template, watched by a health check, and resized by the autoscaler.

What a MIG gives you

Stateless design

Autoscaling works best when VMs are stateless, meaning they do not keep unique, irreplaceable data on themselves. Sessions, uploaded files, and records should live in a database, a shared storage service, or a cache. Then any VM can disappear and a fresh one can take its place with no loss.

Cloud bills reward careful planning and punish forgotten machines.

How you are charged

Compute Engine bills by the second after the first minute for running VMs. You pay for the vCPUs and memory while the VM runs, for the disks as long as they exist, for network traffic leaving Google Cloud, for reserved external addresses, and for any licensed software such as certain Windows or enterprise Linux images. Exact rates depend on the region and the machine type, so always check Google’s current price list or calculator before committing.

Ways to pay less

You cannot fix what you cannot see.

Metrics

Cloud Monitoring automatically collects basic numbers about every VM, such as CPU use, disk activity, and network traffic. Memory use and details about running programs are not visible from outside the VM, so you install the Ops Agent, a small helper program that reports them. With these numbers you can draw dashboards and spot trends, like a server that slowly fills its memory every day.

Logs

Cloud Logging gathers text records from the operating system and your applications in one searchable place. When something breaks at 3 AM, you can search the logs of a hundred VMs together instead of logging in to each one. Audit logs also record who created, changed, or deleted resources, which is vital for security reviews.

Alerts and health checks

Alerting policies watch a metric and notify people by email, chat, or paging tools when it crosses a line, for example when CPU stays above ninety percent for ten minutes. Health checks test whether an application actually answers, which is better than only knowing that the machine is switched on.

Good designs are repeated by many teams. Bad designs are repeated even more often by accident.

Patterns that work

Anti-patterns to avoid

Every technology choice gives something and takes something.

Best practices checklist

Compute Engine is one of several ways to run software on Google Cloud, and the best choice depends on how much control you want.

flowchart TD
  S["Need to run an app"] --> Q1{"Need full OS control?"}
  Q1 -->|Yes| CE["Compute Engine"]
  Q1 -->|No| Q2{"Packaged as containers?"}
  Q2 -->|Many services, need orchestration| GKE["GKE"]
  Q2 -->|Simple service| CR["Cloud Run"]
  Q2 -->|Small event handlers| CF["Cloud Run functions"]
        

If you know another cloud

People who have used other clouds can map ideas across. The names differ, but the concepts are close cousins.

Here is how different kinds of teams put Compute Engine to work.

Questions that almost every beginner asks, answered plainly.

Yes. In Google Cloud, “instance”, “VM”, and “virtual machine instance” all describe the same thing: a virtual computer running on Google’s hardware.

Not if it is on a persistent disk. Persistent Disks keep your data when the VM is stopped. Data on Local SSD is not kept, and it is also lost if the VM is deleted along with a disk that was set to be deleted with it.

Yes. Normally you stop the VM, change its machine type, and start it again. Plan a short pause, or use a group with several VMs so users are served while one is resized.

A region is a geographic area such as a city. A zone is an isolated location inside a region. Spreading VMs across zones protects you from a failure in one of them.

Spot VMs use spare capacity, so Google can take them back when it needs the room. Design Spot workloads so that unfinished work can be picked up again by another machine.

No. A VM can have only a private address and still talk to other resources. It can reach the internet through Cloud NAT and be reached by people through secure tunneling or a load balancer.

Set budgets with alerts, label resources so you know who owns them, delete unused disks and addresses, schedule development machines to switch off, and review right-sizing recommendations regularly.

If you have one application or need deep control of the operating system, Compute Engine is simple and direct. If you run many containerized services that must be coordinated, Kubernetes through GKE saves effort. Many companies use both.

Google keeps the underlying storage durable, but that is not the same as a backup that you can roll back to. You should schedule snapshots yourself and test restoring them.

Google publishes a service level agreement for Compute Engine, and the promised availability is higher when you run instances across multiple zones. Read the current agreement for exact numbers and conditions.

Compute Engine gives you virtual computers on demand, with full control over what runs on them. You choose a location, a machine type, an image, disks, and a network, and Google runs the VM on its infrastructure. For safety and growth you group VMs from templates, spread them across zones, put a load balancer in front, and let autoscaling and health checks keep the system healthy. For cost, you match the pricing option to the workload, switch off what you do not use, and measure continuously. With these habits, a beginner can move from a single practice VM to a dependable, secure, and affordable production system.