Table of Contents
Introduction
Google Cloud Platform, or GCP, is Google’s public cloud environment where you can run Linux systems on Google’s infrastructure. In this chapter you focus on how Linux fits into GCP specifically, not on general cloud concepts and not on other providers. You learn how Linux appears in GCP, how it is created, accessed, and managed, and what is special about Google’s tooling and services around Linux instances.
Linux as a GCP Compute Option
In GCP the main place you run Linux is on Compute Engine virtual machine instances. A Compute Engine VM is a virtual server that runs a guest operating system, often a Linux distribution. GCP also runs Linux images in other services like Google Kubernetes Engine and Cloud Run, but at the level of this chapter you treat those as higher level services that sit on top of Google’s own Linux based infrastructure.
When you work with Compute Engine you choose an image for your VM. For Linux there are official images maintained by Google, images maintained by distribution vendors, and custom images you create yourself. Compute Engine handles the virtualization, networking, and storage, and your Linux system behaves like a regular server with a virtual disk and network interfaces.
Common Linux Distributions on GCP
GCP offers many ready to use Linux images. These include Debian, Ubuntu, Rocky Linux, AlmaLinux, SUSE Linux Enterprise Server, and Red Hat Enterprise Linux. There are also specialized images such as Container Optimized OS and Google’s own optimized variants of Ubuntu and Debian, which come with Google guest tools and agents already integrated.
A key detail is that different images may have different licensing and support models. Debian and Ubuntu images provided by Google are usually included in the base VM price. Enterprise distributions like RHEL or SLES may add extra licensing costs, which GCP shows in the pricing estimate when you select them.
The choice of Linux distribution on GCP is similar to your choice on physical hardware. The biggest differences come from how well the distribution integrates with GCP features such as guest environment tools, metadata, logging, and networking agents.
GCP Machine Types and Linux
Each Linux instance you create must use a machine type, which describes how many virtual CPUs and how much memory the VM has. On GCP you can choose from general purpose types, compute optimized types, memory optimized types, and sometimes specialized types that include accelerators like GPUs. Your Linux system sees these as virtual hardware resources, for example as CPU cores, RAM, and PCI devices for GPUs.
You can also use custom machine types, where you manually choose the number of vCPUs and memory size. This is useful when you want a Linux server tailored to a specific workload, such as a small system service or a memory hungry cache. GCP charges Linux VMs by the vCPU and memory requested per second, with discounts for sustained use.
Some machine families are tuned for different use cases. For example compute optimized families favor CPU heavy Linux workloads such as compilers or media encoding, while memory optimized families favor in memory databases or caches. From inside Linux you manage these resources as usual, but the cost and performance characteristics come from the GCP machine type.
Storage for Linux VMs on GCP
Every Compute Engine Linux instance has at least one persistent disk. This disk holds the root filesystem, and GCP presents it to Linux as a block device such as /dev/sda or /dev/nvme0n1, depending on the interface type. You format this disk with a filesystem, commonly EXT4 or XFS in most standard images, and mount it as the root filesystem.
You can attach additional persistent disks to a Linux VM at creation time or later. These act like extra virtual hard drives. You then partition them, create filesystems, and mount them in directories such as /mnt/data. Persistent disks are independent of the VM lifecycle, so you can delete a Linux VM while keeping its disks, then attach them to a different instance.
GCP also has local SSDs, which your Linux system sees as very fast ephemeral block devices. These provide high input and output performance but do not survive VM stop or host failure. They are appropriate for temporary Linux data that you can rebuild, such as caches or scratch spaces.
Networking for Linux on GCP
Each Linux VM in GCP connects to one or more virtual networks. To the VM, these appear as network interfaces, commonly named ens4 or eth0, with IP addresses that GCP assigns. There are usually two kinds of addresses: an internal IP used inside the GCP network and optionally an external IP for public access.
From within Linux you configure networking with standard tools like ip or ifconfig, but in most GCP provided images the primary network interface is automatically configured by the guest agent. Firewalls around your Linux VM are defined at the GCP level as VPC firewall rules, rather than entirely inside the guest system, although you can still run local firewalls such as iptables or nftables in Linux itself.
Some GCP features affect how Linux sees the network. For example, if you enable multiple network interfaces or alias IP ranges, Linux will see additional IP addresses bound to interfaces. For load balanced or managed instance scenarios, GCP may route traffic from external clients to your Linux VM using internal virtual IPs, while your Linux system only sees local connections.
Creating Linux VMs on GCP
You can create a Linux VM through the GCP Console, the gcloud command line tool, or the REST API. When using the console you choose Compute Engine, click to create a new instance, select a region and zone, select a machine type, then pick a Linux image. You also configure boot disk size and type, networking, and metadata such as startup scripts.
With the CLI you use gcloud compute instances create with flags for machine type, image, disk, and network configuration. For example, you might specify --image-family and --image-project to select an Ubuntu LTS image family maintained by Google. The gcloud tool automatically communicates with the Compute Engine API to provision the Linux VM.
GCP also supports instance templates and managed instance groups. An instance template captures the configuration of a Linux VM, such as its image, machine type, and metadata. You then use it to create many identical instances, either manually or in an autoscaled group.
Authentication to Linux Instances on GCP
The primary way to access Linux VMs in GCP is SSH. GCP integrates key based SSH authentication with both project level and user level metadata. When you use the GCP Console to open a browser based SSH session, or when you use gcloud compute ssh, Google’s tools generate or use existing SSH keys and add them to the VM on your behalf.
In GCP metadata there are entries that store authorized SSH keys or OS Login settings. OS Login is a feature that ties Linux user accounts on VMs to Google identities, such as Google Workspace or Cloud Identity accounts. With OS Login enabled, you manage SSH access through IAM roles at the project or instance level, rather than manually editing ~/.ssh/authorized_keys inside Linux.
From the Linux perspective, you see users and SSH keys as usual. For example, keys appear in /home/USERNAME/.ssh/authorized_keys or managed by the OS Login PAM modules. The difference is that GCP’s guest agent may update these files when IAM or metadata changes.
GCP Metadata and the Linux Guest Environment
Every Compute Engine instance can access GCP metadata through a special HTTP endpoint available only from inside the VM. In Linux you can query it with tools such as curl by calling a fixed IP address with specific headers. Metadata contains instance information, custom values, and service account tokens.
The Linux guest environment on GCP is a collection of tools and agents that integrate Linux with the platform. These include the metadata agent, OS Login components, logging and monitoring agents, and scripts to handle features such as automatic SSH key injection and disk resizing. GCP images maintained by Google come with these components preinstalled and configured.
You can use metadata to pass configuration into Linux at boot. For example you can set a startup script in instance metadata. On boot the Linux guest agent downloads and runs this script with root privileges. This is commonly used to install packages, configure services, or fetch application code on first boot.
Logging and Monitoring from Linux on GCP
GCP provides Cloud Logging and Cloud Monitoring, which you can integrate with Linux VMs using agents. On newer images a unified agent often called the Ops Agent is available. This runs on Linux as a system service and collects system logs and metrics, then sends them to GCP.
From the Linux side, your applications typically log to standard locations such as /var/log or through systemd’s journal. The agent reads these logs, tags them with metadata about the VM, and sends them to Cloud Logging. You can then view them in the GCP Console, filter them, and create alerts.
Monitoring works in a similar way. The agent collects CPU, memory, disk, and network metrics from Linux, then reports them to Cloud Monitoring. If you run a database or web server on Linux, you can configure additional metrics such as connection counts or response times.
Service Accounts and Access from Linux
Every Linux VM in GCP can have a service account attached. A service account is an identity for applications that run on the VM. Inside Linux, code that uses Google Cloud client libraries or the Compute Engine metadata server can obtain access tokens for this service account and call other GCP APIs.
The token endpoint is part of the same metadata service that the Linux guest uses for other information. Your applications call this endpoint or rely on library support, and GCP enforces the permissions assigned to the service account. This avoids storing long term credentials directly in the Linux filesystem.
On the Linux side, this means that instead of embedding API keys, you configure applications to use default credentials. GCP’s environment then maps these calls to the VM service account. Changing what a Linux based application can do is then a matter of updating IAM roles on the service account, not changing anything in the guest system.
Snapshots, Images, and Backups of Linux VMs
GCP can create snapshots of persistent disks that back Linux VMs. A snapshot is a point in time copy of the disk that you can use to restore data or create new disks. To Linux, snapshot creation is invisible, but you achieve more consistent backups if you quiesce the filesystem or ensure that applications flush their data to disk before taking a snapshot.
From snapshots you can create new persistent disks and attach them to Linux VMs. This is a common way to clone a system or recover from accidental data loss. For root disks you can also use snapshots to build new images, so you can reuse a configured Linux system across many instances.
Custom images are another level of reuse. Once you configure a Linux VM the way you want, you create an image from its disk. This image then appears as a new option when you create instances. It behaves like the original distribution, but with your specific software and configurations baked in.
Autoscaling and Managed Linux Instance Groups
When you need multiple identical Linux instances on GCP, you use managed instance groups. These groups rely on instance templates, which define the Linux image and VM configuration. GCP then creates and manages a fleet of Linux VMs based on that template.
Autoscaling adds or removes Linux VMs automatically based on metrics such as CPU utilization, HTTP load balancer traffic, or custom metrics. To the Linux guest, scaling events appear as creation or deletion of instances. Your application must be stateless or store its state in shared services so that these instance lifecycle changes do not lose data.
Managed instance groups also support rolling updates. You can update the instance template to refer to a new Linux image or configuration, and GCP gradually replaces existing VMs with new ones, following a policy for how many instances to update at a time. Inside Linux this is just a normal boot and configuration run, but from the GCP perspective it is coordinated fleet management.
Linux Containers on GCP
Although this chapter focuses on VMs, it is useful to understand that many container based services on GCP, such as Google Kubernetes Engine or Cloud Run, run Linux containers. You do not manage the underlying Linux hosts in those services, but the container images often contain Linux distributions or minimal Linux userspace environments.
In Kubernetes on GCP, your container images might use distributions such as Alpine, Debian, or Ubuntu as their base. The Linux kernel is shared among all containers on the same node, and GCP handles patching and scaling the nodes. You still work with Linux tools within the container, but you do not administer the host operating system.
Cost and Optimization Considerations for Linux on GCP
On GCP the cost of running a Linux VM depends on machine type, region, disk size and type, and network usage. Linux licenses are often included, so the cost per vCPU and memory is generally lower than for Windows. You can lower costs further through sustained use discounts, committed use contracts, or preemptible VMs that are cheaper but can be terminated by GCP at short notice.
From a Linux standpoint, you may adjust system settings to make good use of the resources you pay for. For example, tuning memory usage for a database or limiting worker processes for a web server ensures that the VM’s CPU and memory usage aligns with the machine type. You also consider separating concerns across multiple smaller Linux VMs or combining workloads on a single larger instance, depending on performance and management tradeoffs.
Summary
Linux on GCP appears in several forms, most obviously as Compute Engine VMs backed by various Linux distributions. You choose images, machine types, disks, and networks to shape the environment in which Linux runs, then interact with it through SSH and GCP’s guest tools. Platform features such as metadata, service accounts, logging, monitoring, snapshots, and managed instance groups extend what you can do with Linux systems without changing how Linux itself works. Understanding these GCP specific integrations lets you take full advantage of Linux in Google’s cloud.