Local SSD is a fast storage drive that sits inside the very same physical server that runs your virtual machine.

Let us break the name into pieces. SSD stands for Solid State Drive. It is a storage device made of memory chips with no moving parts. Older hard disks had spinning plates and a tiny arm that moved over them, a bit like a record player. An SSD has nothing spinning, so it finds your data almost instantly.

The word Local tells you where the drive lives. In Google Cloud, most disks are far away from the computer that uses them. They sit in a separate storage system and talk to your virtual machine over a network cable. A Local SSD is different. It is plugged into the same physical server as your virtual machine, so the data does not have to travel across a network at all.

A virtual machine, or VM, is a pretend computer that runs inside a real, bigger computer. Google Cloud calls its virtual machine service Compute Engine. When you create a VM there, you may ask for one or more Local SSD drives to be added to it.

The most important thing to remember is the word ephemeral. It means short-lived. Data on a Local SSD is tied to the life of the VM. That single fact shapes every design choice you will meet in the rest of this guide.

Some programs care more about speed than about keeping a permanent copy of every byte.

Cloud disks are designed to be safe. Your data is copied to several machines, so if one breaks, nothing is lost. That safety has a price. Every read and every write must cross a network, and the storage system must do extra work to keep copies in sync. Even when this is very quick, it can never beat a drive that is plugged straight into the machine.

Now think about the kinds of work that need raw speed. A cache stores copies of popular data so that answers come back fast. A big data job such as sorting a huge pile of records needs a large scratch area to shuffle data around. A database that already keeps copies on other machines does not need its disk to be copied again. In all these cases, losing the local data is not a disaster, because the real data lives somewhere else or can be rebuilt.

Google Cloud built Local SSD for exactly these jobs. It gives you very high speed and very low waiting time, at a lower price per unit of speed than network disks. In return, you accept that the data is temporary and you design your system to cope with that.

A few simple words unlock the whole topic. Learn them once and the rest becomes easy.

Block storage

A block device is a disk that your operating system sees as a long row of numbered boxes, called blocks. The operating system can read or write any box by its number. Local SSD shows up as a block device, just like any other disk. You can format it, put a file system on it, and use it with normal programs.

IOPS

IOPS means Input and Output operations Per Second. It counts how many small reads or writes a disk can finish each second. Think of a cashier. IOPS is how many customers they can serve in one minute when each customer buys just one item.

Throughput

Throughput is how much data moves per second, such as megabytes per second. Using the cashier again, throughput is how many total groceries get bagged per minute when customers have full carts. A disk can be great at many small jobs, great at big jobs, or both.

Latency

Latency is the waiting time for one request. It is the gap between asking and getting. Low latency feels instant. Local SSD shines here because there is no network trip in the middle.

NVMe and SCSI

These are two ways a computer talks to a disk. SCSI is the older style. NVMe, short for Non-Volatile Memory Express, is the newer style made for fast flash memory. It can handle many requests at once, like a highway with many lanes instead of one. Local SSD in Google Cloud can be attached using either, and NVMe is the choice for the best speed on supported machines.

Ephemeral and persistent

Ephemeral storage disappears when its host goes away. Persistent storage stays until you delete it on purpose. Local SSD is ephemeral. Persistent Disk and Hyperdisk, the other Google Cloud disk families, are persistent.

Follow one request from your program all the way down to the flash chips.

When your program writes a file, the request passes through several layers. First comes your application. It asks the operating system inside the VM to store some data. The operating system uses a file system, which is the filing cabinet that organizes data into files and folders. The file system then hands raw block requests to the NVMe driver, a small piece of software that knows how to talk to this kind of disk.

Inside Google Cloud, the VM does not touch the real hardware directly. A layer called the hypervisor sits between them. A hypervisor is the manager that lets many VMs share one physical server safely. It presents a virtual NVMe controller to your VM, and passes requests along to the real drives on the host server.

flowchart LR
    A["Your Application"] --> B["Guest OS and File System"]
    B --> C["NVMe Driver in the VM"]
    C --> D["Virtual NVMe Controller"]
    D --> E["Hypervisor on Physical Host"]
    E --> F["Local SSD Drive 1 - 375 GB"]
    E --> G["Local SSD Drive 2 - 375 GB"]
    E --> H["Local SSD Drive N - 375 GB"]
    

Notice what is missing from this picture: there is no storage network and no storage cluster. That is the whole secret. The drives belong to the host server. Because the path is short, the waiting time is small.

The main components

Why is it so quick, and what happens inside the drive when you save something?

The speed comes from three things working together. The first is flash memory. Flash stores bits as tiny electrical charges in memory cells. Reading a cell takes microseconds, which are millionths of a second. The second is the direct path. The drive connects to the host through a fast internal connection, so no network hop is needed. The third is parallelism. NVMe lets the operating system keep many requests in flight at the same time, and the drive spreads them across many flash chips.

Each Local SSD disk that Google Cloud gives you is a fixed size piece. Historically each disk is 375 GB. You pick how many disks to attach, and the VM sees each as its own device. More disks mean more space, and also more speed, because the work is spread across more hardware.

What happens during a write

Why TRIM and cleanup matter

Flash memory has a quirk. You cannot overwrite a used cell directly. The drive must first erase a whole group of cells, then write fresh data. To do this smoothly, the drive quietly moves data around in the background. This housekeeping is called garbage collection. If the operating system tells the drive which blocks are no longer used, using a feature called TRIM or discard, the drive can clean up earlier and stay fast. Without it, performance can slowly drop on a heavily used disk.

This is the most important chapter. Misunderstanding it is the number one cause of lost data.

A Local SSD is created together with its VM and can only be added when the VM is created. You cannot plug one in later, and you cannot unplug one and move it to a different VM. The disk and the VM share one life.

So when is your data safe, and when is it gone? The simple rule is this. If the same VM keeps running on the same host, the data stays. If the VM is taken away from that host, the data does not follow it.

flowchart TD
    A["Create VM with Local SSD"] --> B["VM Running - Data Readable and Writable"]
    B --> C["Guest OS Reboot"]
    C --> D["Data Kept"]
    D --> B
    B --> E["Live Migration Between Hosts"]
    E --> F["Data Kept by Google Cloud"]
    F --> B
    B --> G["Stop or Delete the VM"]
    B --> H["Spot VM Preempted"]
    B --> I["Host Hardware Failure"]
    G --> J["Data Lost"]
    H --> J
    I --> J
    

Events that normally keep the data

• Restarting the operating system from inside the VM. The VM never leaves the host, so the disk is untouched.
• Live migration for many machine types. This is when Google moves a running VM to another host for maintenance with almost no pause. For supported types, Google copies the Local SSD contents along with the VM.

Events that destroy the data

• Stopping or deleting the VM.
• Preemption of a Spot VM. Spot VMs are discounted machines that Google can take back at any time.
• Host failure that cannot be handled by migration, such as a sudden hardware fault.
• Maintenance on machine types that do not support live migration of Local SSD. Some newer, very large machine families need a stop and restart instead.

Also remember that Local SSD cannot be backed up with disk snapshots or turned into a machine image. If you want a copy, your own software must copy the data to a safe place.

How much Local SSD can you get, and which machines can have it?

Compute Engine groups its VMs into machine families. A family is a set of machine types built for a certain style of work, like general purpose, compute heavy, memory heavy, or storage heavy. Not every family supports Local SSD in the same way.

For many general purpose machine types, you can attach Local SSD disks of 375 GB each. The allowed number of disks depends on how big the VM is. Small VMs get fewer disks, and large VMs can attach many more, with a classic upper limit of 24 disks, which adds up to 9 TB per VM. Newer families have their own rules. Some come with Local SSD built in at fixed sizes, and some storage focused families offer much larger totals. Because these numbers are updated as new hardware arrives, treat any number you read in a blog as a hint and confirm it in the official limits page.

Interface choice

You choose NVMe or SCSI when you create the disks. Prefer NVMe wherever your machine type and operating system image allow it, because it generally gives higher speed and lower latency. Some machine types only support NVMe. Make sure your image has a recent enough driver, which nearly all current Linux and Windows images do.

Local SSD is built to be the fastest storage option on Compute Engine.

With a full set of NVMe disks, a large VM can reach over a million read IOPS and several gigabytes per second of throughput, with response times well under a millisecond. Network disks can be tuned to high numbers too, but reaching them usually costs more money and they still carry network delay.

These headline numbers are maximums that the documentation lists for particular setups. Your own results depend on the machine type, the number of disks, the interface, the file system, the block size, and how many requests your program keeps open at once. The right way to know is to test with a disk benchmarking tool such as fio on the same machine type you will use in production.

What helps speed

• Use NVMe when available.
• Attach enough disks and combine them so the load is shared.
• Keep many requests in flight. A single request at a time cannot use the drive’s parallel power.
• Use a modern file system such as ext4 or XFS with sensible settings.
• Enable discard or run TRIM regularly so the drive stays tidy.

How it scales

Local SSD scales in two directions. Inside one VM, you add more disks and stripe them together. Striping means splitting data across several disks so each does a part of the work, like four friends carrying a sofa at once. This is often done with software RAID 0, which gives the best speed but no protection if a disk fails. Across many VMs, you add more machines, each with its own Local SSD, and let your software spread data among them. Systems like Cassandra, ScyllaDB, and Elasticsearch are built to do exactly this.

You do not need to memorize commands. You need to understand the order of the steps.

On Google Kubernetes Engine, often shortened to GKE, you can also use Local SSD without doing these steps by hand. GKE can place a node’s temporary storage, such as scratch space for pods, on Local SSD, or hand out raw block devices to workloads that want them. The same ephemeral rule applies: when a node is replaced, its Local SSD data is gone.

Choosing the right storage is mostly about answering one question: can I afford to lose this data?

The usual smart design uses them together. The boot disk is a persistent disk, so the operating system always survives. A Local SSD handles the hot, fast work. Cloud Storage holds the long-term copy, such as backups and finished results. This three layer pattern appears everywhere in cloud design.

What about RAM, the memory chips used for running programs? RAM is even faster than Local SSD, but it is much smaller and more costly per gigabyte, and it is also wiped on power loss. Local SSD sits in a useful middle: far larger and cheaper than RAM, far faster than network disks.

Every engineering choice gives something and takes something. Here is the honest list.

The big trade-offs in plain words

Speed against safety. You get the fastest disk, and you accept that your software must protect the data. Simplicity against control. Network disks are easy to manage because Google handles durability. With Local SSD you take on that job yourself through replication and backups. Flexibility against cost. Because the sizes are fixed, you might pay for more space than you need just to reach the speed you want.

Even temporary data deserves protection.

What you are still responsible for

Google protects the hardware and the hypervisor, but your own settings still matter. Control who can log in to the VM, using Identity and Access Management, usually shortened to IAM. Keep the operating system updated. Protect secrets. If your application stores sensitive data on the Local SSD, such as customer records in a cache, remember that anyone with root access to the VM can read it, because the operating system sees the disk as plain.

You cannot protect or tune what you cannot see.

Monitoring means watching numbers over time. Logging means keeping a written record of events. Google Cloud offers Cloud Monitoring and Cloud Logging for both jobs. For Local SSD, you usually collect disk numbers from inside the VM, using the Ops Agent, which is a small helper program that ships host and disk metrics to Cloud Monitoring.

Numbers worth watching

• Read and write operations per second to see how busy the disk is.
• Read and write bytes per second to see throughput.
• Latency or wait time per request. A rising line is an early warning.
• Queue depth, which is how many requests are waiting. A long queue means the disk is saturated.
• Free space and inode use, so a full disk never surprises you.
• Disk utilization percentage, which shows how much of the time the drive is busy.

Events worth logging

• VM start, stop, preemption, and migration events from the audit and system logs.
• Startup script results: did it find an empty disk, format it, and mount it?
• Operating system messages about disk errors.
• Application level warnings, such as cache rebuild started or replica resync finished.

Use tools such as iostat on the VM for a live view while you test. Keep a baseline from your first benchmark. A baseline is a saved picture of normal behavior, and it makes later problems easy to spot.

Good designs assume the disk can vanish and make that harmless.

Pattern 1: Replicated database nodes

Run a database that keeps several copies of every record on different machines, ideally in different zones. A zone is one separate data center area inside a Google Cloud region. If one VM and its Local SSD disappear, the other copies keep serving. A new node joins, copies the missing data, and the cluster heals.

flowchart TB
    U["Users"] --> LB["Load Balancer"]
    LB --> N1["Node 1 - Zone A - Local SSD"]
    LB --> N2["Node 2 - Zone B - Local SSD"]
    LB --> N3["Node 3 - Zone C - Local SSD"]
    N1 --- N2
    N2 --- N3
    N1 --- N3
    N1 --> BK["Cloud Storage Backups"]
    N2 --> BK
    N3 --> BK
    

In this picture, the load balancer spreads user requests. Each node holds a copy of the data and shares updates with the others. Periodic backups go to Cloud Storage, which is durable. This is the classic shape of a safe Local SSD system.

Pattern 2: Cache in front of a database

A cache keeps popular answers close. Put the cache’s disk-backed layer on Local SSD, and keep the source of truth on a persistent database. If the cache node dies, the system gets slower for a short time while the cache warms up again, but no data is lost.

Pattern 3: Scratch space for big jobs

Analytics engines such as Spark and Hadoop write huge temporary files during a step called the shuffle, when data is regrouped between machines. Putting this on Local SSD speeds the job a lot. The final results are saved to Cloud Storage or BigQuery.

Pattern 4: Tiered storage

Keep hot data on Local SSD, warm data on persistent disk, and cold data in Cloud Storage. Many search and time series systems move data through these tiers as it ages.

Pattern 5: Write locally, mirror elsewhere

Some teams write to a fast Local SSD and a persistent disk together, and read from the fast one. Reads are quick, and the persistent copy provides safety. Discord has publicly described a design in this spirit for its large ScyllaDB clusters.

These designs look fine on day one and hurt on day ninety.

A short checklist that saves real pain.

Best practices

• Design for loss first. Ask what happens when this node disappears right now, and make the answer boring.
• Use NVMe on machine types that support it.
• Test with a benchmark on the exact machine type before launch.
• Automate disk setup in a startup script that is safe to run many times.
• Use stable device names from the system’s by-id listing rather than names that can change between boots.
• Back up to Cloud Storage on a schedule, and practice restoring.
• Spread nodes across zones and set the replication factor to match your risk.
• Watch latency and free space with alerts.
• Check the family rules for live migration and maintenance behavior.

Common mistakes

Where Local SSD shows up in real production systems.

Speed is only a good deal if you pay for what you actually use.

Local SSD is billed by the amount of storage per month, in the same way as other disks, and the price is usually lower per gigabyte than a high performance network disk. Spot VMs offer extra discounts on Local SSD as well. Exact prices vary by region and change over time, so check the Google Cloud pricing page for current numbers.

How to keep the bill sensible

• Count disks carefully. You pay for each 375 GB piece you attach, even if you fill half of it.
• Compare performance per dollar, not only price per gigabyte. If Local SSD removes the need for an oversized network disk or a larger machine, it can save money.
• Use Spot VMs for rebuildable jobs. Batch processing and scratch workloads can tolerate preemption and gain big discounts.
• Delete unused clusters. Since the disk is part of the VM, idle VMs with many disks still cost money.
• Consider commitments. If a steady workload runs all year, committed use discounts can lower the compute side of the cost.

Local SSD is the kitchen counter of Google Cloud storage: very close, very fast, and cleared when the work is over. Used well, it makes databases, caches, and data jobs faster and cheaper. Used carelessly, it loses data. The difference is whether you designed the system so that losing one disk does not matter.