Local SSD is high-speed solid state storage that is physically attached to the host server running your Compute Engine virtual machine.

Most disks in Google Cloud are network disks. When your virtual machine reads or writes data on a Persistent Disk or Hyperdisk volume, the request travels across Google’s data center network to a storage system that keeps the data safe and replicated. That design gives you durability and flexibility, but every request pays a small cost for crossing the network. For most applications that cost is perfectly fine.

Some workloads cannot accept even that small cost. A database serving millions of lookups per second, a cache that must answer in microseconds, or a data processing job that writes huge temporary files all benefit from storage that sits on the same machine. Local SSD fills that role. Because the drive is attached to the host, requests skip the network entirely, giving very low latency and very high throughput for the price.

The trade-off is the heart of this entire topic. Local SSD is ephemeral. It is not replicated, it is not backed up, and it does not follow your VM if the VM is stopped or the host fails. It is a performance tool, not a safe place to keep the only copy of anything important.

Who uses it and why

Teams reach for Local SSD when they need speed more than they need single-copy durability. Typical cases include caches, scratch space for data processing, hot tiers of replicated databases, staging areas for machine learning training data, and temporary files created during video encoding. In each case, the data is either rebuildable from elsewhere or is already copied to other machines by the application itself.

A small set of terms explains almost every decision you will make about Local SSD.

Each term below is defined by what it is, why it exists, and where you will meet it. Spend a moment on each card, because mixing them up is the cause of most Local SSD surprises.

Block device, not a file system

A new Local SSD is a raw block device. It has no files, no folders, and no file system until you create one. This surprises beginners who expect a ready-to-use folder. You, or your startup scripts, must format the device, mount it, and handle the case where it is empty after certain events.

The speed and the fragility of Local SSD both come from the same fact: it lives inside the server.

To understand Local SSD you need a clear picture of where the bytes live. A Compute Engine virtual machine runs on a physical host, and that host has its own processors, memory, and, for Local SSD, flash drives physically installed inside or directly attached. When your VM talks to a Local SSD, the request travels over the host’s internal connection, a path of a few inches of wire and silicon.

When your VM talks to a Persistent Disk or Hyperdisk volume, the request leaves the host, crosses the data center network, and reaches a separate storage service that stores multiple copies of your data. This separation is what gives network disks their durability and flexibility. It is also what adds latency.

flowchart TD
  VM["Your Virtual Machine"] --> HOST["Physical Host Server"]
  HOST --> LSSD["Local SSD: attached to the host"]
  HOST --> NET["Data Center Network"]
  NET --> PD["Persistent Disk or Hyperdisk Storage Service"]
  PD --> R1["Replica 1"]
  PD --> R2["Replica 2"]
  PD --> R3["Replica 3"]
        

Why this explains every trade-off

What Local SSD cannot be

Local SSD cannot be used as a boot disk, because the operating system image and the VM’s identity must survive stops and restarts. It cannot be shared between VMs, because each device is wired to one host. It cannot be resized after creation, and it cannot be snapshotted by Compute Engine’s snapshot feature. These restrictions all follow from the same fact: the drive belongs to the host, not to the cloud storage system.

The most important question to answer before using Local SSD is which events preserve your data and which erase it.

Local SSD data persists through some events and is lost in others. Google’s documentation lists the exact rules, and they can vary by machine series and by newer features, so always verify against the current documentation. The general shape is stable and worth memorizing.

sequenceDiagram
  participant A as Application
  participant V as VM with Local SSD
  participant H as Host Server
  participant G as Google Maintenance
  A->>V: Write data to Local SSD
  V->>H: Data stored on host drive
  G->>H: Planned maintenance needed
  H->>V: Live migrate VM to new host
  Note over V,H: Data copied and preserved
  G->>H: Hardware failure strikes
  H--xV: Host lost, drive lost
  Note over V,H: VM restarts elsewhere with empty Local SSD
        

Planned versus unplanned

The difference between a planned event and an unplanned one is the key insight. When Google plans to update a host, it can live migrate your VM and carry the Local SSD contents along. When something breaks without warning, there is no chance to copy anything. A design that survives only the planned events is not safe, because unplanned failures eventually happen to every fleet.

Newer preservation features

Google has been expanding what happens to Local SSD data around certain operations on some machine series, such as suspend and resume behavior. Features like this are specific to certain series and change over time. Do not build a design that depends on them without confirming support for your exact machine type in the current documentation.

Local SSD is fast, but how fast depends on the interface, the number of disks and the size of the VM.

Three numbers describe storage performance. Latency is how long a single request takes. IOPS is how many requests complete each second. Throughput is how much data moves each second. Local SSD gives very good numbers on all three because there is no network between the VM and the drive.

NVMe versus SCSI

Local SSD can be attached using NVMe or SCSI. NVMe was designed for flash. It supports many parallel queues, so multiple processor cores can issue requests at the same time without waiting on each other. SCSI is an older protocol designed in the era of spinning disks, and it handles flash more slowly. When your machine type and operating system support NVMe, it is usually the better choice for performance. Google’s documentation publishes representative numbers per disk and for a fully populated VM, with NVMe delivering substantially higher read IOPS than SCSI at the same capacity. Treat the published figures as the authority, because they differ by machine series.

Performance grows with disk count and vCPUs

Each Local SSD contributes its own share of performance, so adding disks adds capacity and speed together. Combining several disks into a striped volume lets one file system use all of them at once. But there is a catch: the VM must have enough virtual CPUs to drive the disks. A tiny VM cannot generate enough parallel requests to saturate many drives, and Google’s documentation notes that achievable performance depends on the vCPU count. Choosing a very small VM with many disks wastes money.

You cannot choose any size you like, and the rules differ across machine families.

On many machine types, each Local SSD disk has a fixed size of 375 gibibytes, and you attach a number of disks at VM creation. The maximum number of disks per VM depends on the machine series and often on the number of vCPUs, so a larger VM can usually hold more disks than a smaller one. Some newer or specialized machine series work differently, offering variants where a set amount of Local SSD is bundled into the machine type, sometimes in larger sizes. Always consult the machine family documentation for the exact options, because these details change as new series appear.

Hard limits worth memorizing

A fresh Local SSD is an empty block device, and getting it ready is your job.

When a VM with Local SSD first starts, the operating system sees one raw device per disk. There is no file system and no mount point. Before an application can use the space, someone has to prepare it. In production, this preparation is automated so that a replacement VM comes up ready without human help.

Striping and the redundancy question

Striping several disks into one volume multiplies speed and capacity but also multiplies risk in a specific way: if any one disk is lost, the whole striped volume is lost. For Local SSD this matters less than for ordinary servers, because the data is already considered disposable and the failure of any disk is usually tied to the loss of the whole VM or host anyway. Mirroring would waste half your capacity and does not protect against host loss. The sound strategy is to stripe for speed and protect data by replicating across machines at the application level.

Handling an empty drive on restart

Because data can disappear while the VM comes back, your startup process must distinguish between “this drive has my data” and “this drive is empty and needs formatting.” Reformatting a drive that actually holds data would destroy it, while skipping formatting on an empty device leaves the application with nothing to write to. Robust startup logic checks the device before acting and records what it did.

Using Local SSD safely means moving durability out of the disk and into the architecture.

Since Local SSD offers no durability of its own, every safe design adds durability somewhere else. There are three main approaches, and most real systems combine them.

flowchart LR
  APP["Application"] --> W{"Write path"}
  W --> L["Local SSD: fast working copy"]
  W --> D["Durable store: Cloud Storage or network disk"]
  APP --> R{"Read path"}
  R --> L
  L -. "Lost or empty" .-> REB["Rebuild from durable store"]
  D --> REB
  REB --> L
        

Know your recovery time

Every Local SSD design has a recovery time: how long it takes to return to a healthy state after a VM loses its data. Rebuilding a few gigabytes of cache may take seconds. Resynchronizing a replica of several terabytes from its peers may take hours, during which the cluster has less redundancy. Calculate this number, not just the happy-path performance, because it determines how much risk you actually carry.

Choosing storage is about matching speed, durability and flexibility to the job.

Google Cloud offers several storage categories, and Local SSD is only one of them. The right choice follows from how your application treats data, not from which option sounds fastest.

Where Local SSD sits in the speed ladder

Memory is faster than Local SSD, and Local SSD is generally faster than network disks in latency terms. But memory is small and expensive per gigabyte, while Local SSD offers far more capacity at a much lower price per gigabyte than memory. That makes Local SSD the natural overflow tier: bigger than memory, faster than network disks, cheaper per gigabyte than either memory or high-performance network volumes for the speed it gives.

Distributed databases are the classic home of Local SSD, because they bring their own replication.

Systems such as distributed wide-column stores, search engines, analytical databases and key-value stores are designed to run on many machines and to keep several copies of each piece of data. They tolerate the loss of a machine by design. That makes them a natural match for ephemeral, very fast storage: each node uses Local SSD for speed, and the cluster itself provides durability.

How the cluster protects the data

In a typical replicated database, each record is stored on several nodes, often placed in different zones. When a node loses its Local SSD, the database notices that some data now has fewer copies than required and begins copying data from healthy nodes to restore the target number. The node returns to service once its share is rebuilt. The application sees nothing, as long as enough replicas survive.

Single-node relational databases

A single relational database server that holds the only copy of important data is a poor fit for Local SSD, unless a replica or streaming backup protects the data. Some teams do run a primary on Local SSD for speed, with synchronous or asynchronous replicas on separate VMs and continuous archiving of the transaction log to durable storage. This can work, but it demands rigorous testing of the failover and recovery procedure, and it accepts a larger operational burden than simply using a fast network disk.

Whenever a job creates large temporary data, Local SSD is a natural fit.

Data processing frameworks often write intermediate results to disk, for example when sorting or when moving data between stages of a computation. These intermediate files are needed only until the job completes, and they can be recreated if lost by rerunning part of the job. That description matches Local SSD perfectly: huge volumes, short lives, and a need for speed.

Typical scratch uses

The cache warm-up cost

A cache on Local SSD starts empty after any data-loss event. During the warm-up period, requests fall through to the origin, which can briefly overload it. If many cache nodes restart at the same time, the origin may see a sudden flood. Plan for this by staggering restarts, rate limiting fallbacks to the origin, and, for important caches, pre-loading hot data when a node starts.

Data-hungry workloads often starve on slow storage, and Local SSD feeds them quickly.

Machine learning training reads huge datasets repeatedly. If the storage cannot deliver data fast enough, expensive accelerators sit idle waiting for the next batch. By staging the dataset onto Local SSD, training jobs read at local speeds while the permanent copy remains safely in Cloud Storage. The same idea helps media transcoding, scientific simulation, genomics pipelines and other jobs that process large files.

Why staging beats streaming for repeated reads

Streaming data from object storage is convenient and scales well, but each pass over the data pays network and request overhead. If a job makes many passes, copying once to Local SSD and then reading locally can be much faster overall. If a job reads each item only once, streaming may be simpler and just as fast. Measure both approaches for your workload.

Accelerator machines and bundled storage

Some accelerator-equipped and high-performance machine series include Local SSD as part of the machine configuration, because their workloads are so data-hungry. If you use such a series, check what storage is included, how it is presented to the operating system, and how its data behaves when the VM stops, since these details depend on the series.

Kubernetes treats Local SSD as node-local storage, which shapes how pods may use it.

In Google Kubernetes Engine, you can attach Local SSD to the nodes in a node pool. Pods can then use that fast storage in one of two broad ways. The first is as ephemeral storage, where the space backs temporary directories and container scratch areas. The second is as raw block storage that a workload or an add-on manages directly. Which mechanisms are available and how they are configured evolves with GKE releases, so follow the current documentation for the exact options.

The scheduling consequence

Data on a node’s Local SSD exists only on that node. If a pod using node-local data is rescheduled to a different node, it will not find its data. That is acceptable for caches and scratch space, but it must be handled explicitly for stateful workloads. Teams solve it by pairing node-local volumes with application-level replication, by pinning pods to nodes, and by accepting that node loss means rebuilding from peers.

flowchart LR
  P["Pod using node-local volume"] --> N1["Node A with Local SSD"]
  N1 --> D1["Data lives only on Node A"]
  N1 -. "Node lost or replaced" .-> X["Data gone"]
  X --> RB["Application rebuilds from replicas"]
  P2["Pod rescheduled"] --> N2["Node B with its own Local SSD"]
  RB --> N2
        

Node upgrades and autoscaling

Cluster operations that replace nodes, such as upgrades and automatic repairs, create new nodes with empty Local SSD. Cluster autoscaling adds nodes with empty drives and removes nodes along with their data. Any design that keeps important state on node-local storage must tolerate these routine events, using surge settings, careful ordering and replication so that the cluster never loses too many replicas at once.

Automation platforms recreate VMs freely, so Local SSD design must assume constant replacement.

Spot VMs and Local SSD

Spot VMs offer large discounts in exchange for the possibility of being stopped by Google when capacity is needed. Local SSD can be used with Spot VMs, and it is sometimes discounted as well. The combination suits fault-tolerant batch work well, because the job is already built to survive losing machines. Since preemption erases Local SSD data, treat Spot plus Local SSD as strictly scratch storage with checkpoints in durable storage.

Managed instance groups

A managed instance group creates VMs from an instance template, and the template can include Local SSD. When the group heals a failed VM or scales out, the new VM arrives with a new, empty Local SSD. Even stateful instance group features, which preserve certain disks and settings across recreation, do not carry the contents of a Local SSD with them. The group is therefore a good fit for stateless caches and scratch-heavy workers, and a risky fit for anything that needs its Local SSD data to survive recreation.

Infrastructure as code and startup automation

Because VMs with Local SSD are replaced regularly, the storage preparation must be automated and idempotent. Idempotent means that running the process twice has the same result as running it once. A good startup process detects an already prepared device and leaves it alone, formats a blank device, and reports status through logs so operators can see what happened.

Local SSD is encrypted at rest by default, but ephemeral storage still deserves careful security thinking.

Compute Engine encrypts data on Local SSD automatically, without any action from you. The encryption is managed by Google, and customer-managed encryption keys are generally not available for Local SSD the way they are for Persistent Disk, so teams with strict key-control requirements must check whether Local SSD satisfies their policy. When a VM is deleted or its Local SSD is released, the data is made unreadable and the drive is prepared for reuse, so another customer cannot read what you stored.

Sensitive data and ephemeral storage

There is a useful security side effect of ephemeral storage: data that disappears with the VM leaves no long-lived copy to leak. Scratch files containing sensitive intermediate data are automatically destroyed when the job ends. That said, you should not rely on disappearance as a deletion policy. If regulations require provable deletion at a specific time, design and document an explicit process.

Compliance questions to ask early

Local SSD is priced by capacity and tends to give excellent performance per dollar, but it is not free of traps.

Local SSD is billed by the amount of capacity provisioned, measured in gibibytes over time, as part of the VM’s resources. Compared with network disks, you do not buy separate performance tiers or provisioned IOPS: performance comes with the hardware. Spot VMs can receive discounted Local SSD pricing, and committed use arrangements may reduce the cost of steady, long-term usage. Prices and discount programs change, so check the official pricing page for current numbers and conditions.

Performance per dollar

For workloads that need very high IOPS or throughput, Local SSD is often far cheaper than buying equivalent performance from network volumes, because you pay for capacity and receive speed as a built-in bonus. The comparison reverses when you need little speed or when the data must be durable, since you would then pay for replication and backup elsewhere on top of the Local SSD.

Hidden cost drivers

Ephemeral storage needs watching, because failures arrive silently as empty drives.

Operating Local SSD well means observing three layers: the health of the storage devices, the behavior of the application on top of them, and the state of the cluster that protects the data. Because the storage hides no durability machinery, the monitoring must watch for the symptoms of data loss and recovery.

Alerts that matter

Alert on rising numbers of under-replicated data, because that is the moment your cluster is one failure away from losing data. Alert on sudden cache hit rate drops and on origin load spikes. Alert on repeated VM restarts, which may indicate a startup script problem reformatting drives. Alert on disk space above a safe threshold, and on rebuild operations that run unusually long.

Game days and failure drills

The best way to trust a Local SSD design is to break it on purpose. Stop a VM, delete one, simulate a preemption, and watch how the system recovers. Record how long it takes and whether any user-visible errors appear. Do this in a safe environment first, then regularly in production-like conditions, because systems drift and assumptions go stale.

A few reliable patterns make Local SSD safe, and a few predictable traps make it dangerous.

Patterns that work well

Anti-patterns to avoid

A short checklist separates calm Local SSD operations from painful ones.

Best practices

Common mistakes

Concrete stories show how the ideas combine under real pressure.

Short answers to the questions engineers ask most when evaluating Local SSD.

Yes, a guest operating system reboot normally preserves the data, as does live migration during host maintenance. Stops, deletions, preemptions and host failures generally do not preserve it, so verify the current rules for your machine series.

No. Local SSD is chosen when the VM is created. To get it later, create a new VM with Local SSD and move your workload to it.

No. Compute Engine snapshots and machine images do not capture Local SSD contents. Copy important data out through your application, to Cloud Storage or to a durable disk.

Generally it offers lower latency and very high IOPS and throughput because it is attached to the host, but high-end network volumes also offer strong performance with durability. Compare against published figures for your exact machine and volume types.

No. The boot disk must be a persistent volume, because the operating system must survive stops and restarts.

Often yes, for a single larger and faster volume, since the data is disposable and durability comes from elsewhere. Remember that losing any one disk loses the whole striped volume, so rely on replication or rebuild at the application level.

Yes, it is encrypted at rest automatically with Google-managed keys. Customer-managed encryption keys are generally not supported for Local SSD, so use application-level encryption if you need your own key control.

Yes, but data is lost on preemption and on recreation of a VM by the group. Use it for scratch, caches and replicated systems, with checkpoints in durable storage.

Common causes are using SCSI instead of NVMe, too few vCPUs to drive the disks, too little parallelism in the application, a nearly full drive, or a workload pattern that differs from the benchmark. Test with your real access pattern.

Ask what happens if every byte on it disappears right now. If the answer is a short, planned rebuild, Local SSD is a good fit. If the answer is a crisis, put the data somewhere durable.

Local SSD offers a clear bargain: storage physically attached to the host gives very low latency and very high throughput at a good price, in exchange for giving up durability. Its data lives and dies with the VM and its host. It survives reboots and live migrations, but not stops, deletions, preemptions or host failures, and it cannot be snapshotted, shared, resized or used as a boot disk.

The skill in using it is architectural. Place the authoritative copy of your data in durable storage or replicate it across machines and zones, automate the preparation of each fresh drive, plan for cache warm-up and rebuild traffic, and test failures on purpose. Used for caches, scratch space, hot tiers of replicated databases and staged training data, Local SSD makes systems dramatically faster. Used as the only home of precious data, it eventually causes an outage.