Local SSD on GCP is physically attached storage on the Compute Engine host that delivers very high throughput and low latency, priced per GB and billed for the life of the instance, but it is ephemeral: the data is lost the moment the instance stops, is deleted, is preempted, or migrates. That single property decides the economics. Local SSD pays off when a workload needs the highest storage performance and the data is regenerable, such as scratch space, caches, temporary processing, or a database whose durability lives elsewhere, because it replaces a large and expensive amount of provisioned performance on persistent SSD. It costs you when it is used for anything that must survive, where a storage saving becomes an outage.
Local SSD is not cheaper persistent disk. It is fast disk you must be willing to lose.
What are you actually paying for?
GCP offers two broad disk families. Persistent disk, including balanced and SSD variants, lives on the network, survives the instance, replicates for durability, and supports snapshots, which is why it is the default for anything stateful. Local SSD instead sits on the physical host the instance runs on, so it skips the network hop entirely and delivers throughput and latency that network attached storage cannot match. You pay per GB of local SSD attached, and you pay for it the whole time the instance exists, attached in fixed size increments rather than provisioned to an arbitrary capacity.
The economic distinction is not the per GB sticker. It is that local SSD bundles performance into the storage, while persistent SSD makes you provision and pay for throughput and IOPS to reach high performance. For a throughput hungry workload, matching local SSD performance on persistent SSD can mean buying a lot of provisioned performance, and that is where the comparison actually lives.
When does local SSD genuinely save money?
Local SSD wins on workloads that are throughput bound and tolerant of data loss. Scratch space for large data processing jobs, where intermediate results are written, read, and discarded, is the textbook case: the job regenerates the data if a node fails, so ephemerality is free. Caches and temporary indexes that can be rebuilt from a source of truth are another. So is a distributed database or analytics engine that holds its own durability through replication across nodes, where each node can treat its local disk as fast and disposable because the cluster, not the disk, owns durability. In all of these, local SSD delivers performance that would otherwise require heavy provisioned IOPS on persistent SSD, so the saving is on the performance you avoid buying, not on capacity.
When does it quietly cost you more?
Three traps turn local SSD into a loss. The first is durability misuse: putting a primary datastore with no external copy on local SSD trades a modest storage line for the risk of total data loss on a stop, a preemption, or a live migration, which is not a cost saving, it is an incident waiting to bill you. The second is idle waste: because local SSD is billed for the life of the instance regardless of use, an oversized attachment or an instance left running with local SSD it no longer needs pays full price for nothing. The third is the wrong machine: local SSD is available only on certain machine families and in fixed increments, so chasing it can push you onto a larger or pricier instance than the compute alone justified, where the instance premium swallows the storage benefit.
A European SaaS company ran a batch analytics tier on instances with large persistent SSD volumes provisioned for high throughput, paying for IOPS the jobs needed only during processing. The intermediate data was fully regenerable, so moving the scratch and shuffle space onto local SSD removed most of the provisioned performance on persistent disk, and the jobs ran faster because the storage was host attached. Right sizing the instances so the local SSD increment matched the machine, rather than forcing a larger family, kept the compute side honest. The combined change cut the tier's storage and instance cost meaningfully while improving job time. Figures are verified against billing data and anonymised; exact rates are indicative pending a check against current GCP pricing.
Where this sits in the wider GCP picture
Local SSD is one decision inside the broader compute and commitments lever. The same disposable performance logic underpins spot and preemptible capacity, covered in arbitraging spot and preemptible capacity, and the durable side of storage, snapshots and backups, has its own discipline in snapshot and backup cost discipline on GCP. The full estate playbook lives in the GCP cost optimization guide, and the cross cloud view, including how AWS instance store and Azure ephemeral OS disks compare, is in the cross cloud cost optimization guide.
Frequently asked questions
What is GCP local SSD and how is it priced?
When does local SSD save money?
What is the risk of using local SSD?
Put a number on your storage tier
We map each workload to the storage that fits its durability and throughput needs, so you stop paying for provisioned performance you could get from host attached disk, and stop risking data that should never sit on ephemeral storage. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.