{"id":631,"date":"2026-04-14T19:53:11","date_gmt":"2026-04-14T19:53:11","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-local-ssd-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-14T19:53:11","modified_gmt":"2026-04-14T19:53:11","slug":"google-cloud-local-ssd-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-local-ssd-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"Google Cloud Local SSD Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>What this service is<\/strong><br\/>\n<strong>Local SSD<\/strong> is a high-performance, physically attached (host-local) solid-state drive option for <strong>Google Cloud Compute Engine<\/strong> virtual machines (VMs). It provides very low latency and high throughput for temporary data.<\/p>\n\n\n\n<p><strong>Simple explanation (one paragraph)<\/strong><br\/>\nUse Local SSD when you need extremely fast disk performance on a VM\u2014faster than network-attached disks\u2014and you can tolerate the data being temporary. It\u2019s commonly used for caches, scratch space, temporary processing, and high-speed staging during compute jobs.<\/p>\n\n\n\n<p><strong>Technical explanation (one paragraph)<\/strong><br\/>\nLocal SSD is ephemeral block storage that is <strong>directly attached to the physical host<\/strong> running your Compute Engine VM (typically exposed as NVMe or SCSI devices). Because it is not network-attached, it delivers high IOPS and throughput with low latency. The tradeoff is durability: Local SSD data does <strong>not<\/strong> persist if the VM is stopped\/terminated or if the VM is moved to a different host (for example, during certain maintenance or failure scenarios). You typically pair it with durable storage such as Persistent Disk \/ Hyperdisk, Cloud Storage, or a database for authoritative data.<\/p>\n\n\n\n<p><strong>What problem it solves<\/strong><br\/>\nLocal SSD solves the \u201cI need disk speed now\u201d problem for compute workloads that are bottlenecked by storage latency\/IOPS, especially when the data is disposable or reconstructable (caches, scratch, intermediate outputs). It\u2019s a key building block for performance-sensitive architectures in the <strong>Compute<\/strong> category on Google Cloud.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Local SSD?<\/h2>\n\n\n\n<p><strong>Official purpose<\/strong><br\/>\nLocal SSD provides <strong>high-performance ephemeral local block storage<\/strong> for Compute Engine VMs. It is designed for workloads that need very fast read\/write access to temporary data.<\/p>\n\n\n\n<p><strong>Core capabilities<\/strong>\n&#8211; Attach one or more Local SSD devices to a VM (subject to machine type and platform support).\n&#8211; Use Local SSD as raw block devices, format them with a filesystem (ext4, xfs, etc.), or combine multiple devices using RAID for higher throughput.\n&#8211; Achieve very low latency and high IOPS compared to network-attached block storage.<\/p>\n\n\n\n<p><strong>Major components<\/strong>\n&#8211; <strong>Compute Engine VM instance<\/strong>: Local SSD is not a standalone service; it is configured as part of a VM.\n&#8211; <strong>Local SSD device(s)<\/strong>: Presented to the guest OS as block devices (commonly NVMe).\n&#8211; <strong>Guest OS filesystem \/ RAID layer<\/strong>: You decide how to format and mount devices, and whether to use RAID (mdadm) for performance.<\/p>\n\n\n\n<p><strong>Service type<\/strong>\n&#8211; <strong>Ephemeral block storage<\/strong> attached to Compute Engine instances (in the <strong>Compute<\/strong> category).<\/p>\n\n\n\n<p><strong>Scope (regional\/global\/zonal\/project-scoped, etc.)<\/strong>\n&#8211; Local SSD is <strong>zonal<\/strong> in practice because it is tied to a VM running in a specific zone and on a specific host.\n&#8211; It is <strong>project-scoped<\/strong> in the sense that you allocate it as part of VM resources in a project, but it is not a separately managed \u201cdisk resource\u201d you can move around independently.<\/p>\n\n\n\n<p><strong>How it fits into the Google Cloud ecosystem<\/strong>\n&#8211; Works with <strong>Compute Engine<\/strong> directly and indirectly supports performance architectures for:\n  &#8211; <strong>Google Kubernetes Engine (GKE)<\/strong> nodes (Local SSD-backed ephemeral volumes for pods, depending on GKE mode and node configuration).\n  &#8211; <strong>Data analytics \/ HPC<\/strong> jobs on Compute Engine.\n  &#8211; High-performance caching layers in front of durable stores (Cloud Storage, Persistent Disk \/ Hyperdisk, Cloud SQL, etc.).<\/p>\n\n\n\n<p><strong>Name status (renamed\/legacy\/deprecated?)<\/strong><br\/>\nAs of the latest generally available Compute Engine storage options, <strong>\u201cLocal SSD\u201d is still the current product name<\/strong> used in Google Cloud documentation. Verify any newly introduced variants or platform-specific behaviors in the official docs if you are planning a production design:\n&#8211; https:\/\/cloud.google.com\/compute\/docs\/disks\/local-ssd<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Local SSD?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time-to-results<\/strong>: Shorter job runtimes for data processing, builds, and simulations translate to lower compute time and faster delivery.<\/li>\n<li><strong>Cost efficiency for temporary performance<\/strong>: For workloads where the dataset is transient, it can be more economical to use ephemeral high-speed storage than to overprovision durable storage or compute.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Very low latency<\/strong>: Local attachment avoids network hops inherent in network-attached block storage.<\/li>\n<li><strong>High IOPS\/throughput<\/strong>: Suitable for high-IO workloads (indexes, shuffle, temporary sort\/merge, build artifacts).<\/li>\n<li><strong>Predictable performance<\/strong>: Especially useful when you want consistently high performance for scratch space.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Simple lifecycle<\/strong>: Local SSD exists only with the VM; provisioning is part of instance creation.<\/li>\n<li><strong>No snapshot\/backup management<\/strong>: Because it is not meant for durability, you don\u2019t manage snapshots; you manage <em>recreation<\/em>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security \/ compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Good fit for non-authoritative data<\/strong>: Store derived or temporary data that can be re-generated.<\/li>\n<li><strong>Encryption at rest<\/strong>: Google Cloud encrypts data at rest by default. (Key-management options for Local SSD may differ from durable disks\u2014verify CMEK support in official docs for your exact platform and needs.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability \/ performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale-out throughput<\/strong>: Use multiple Local SSDs and\/or scale horizontally across multiple VMs.<\/li>\n<li><strong>Fast local staging<\/strong>: Pull from Cloud Storage to Local SSD, process locally, push results back.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Local SSD<\/h3>\n\n\n\n<p>Choose Local SSD when:\n&#8211; Data is <strong>temporary<\/strong> or <strong>reconstructable<\/strong> (cache\/scratch\/intermediate).\n&#8211; You need <strong>maximum disk performance<\/strong> on Compute Engine VMs.\n&#8211; You can design around <strong>data loss<\/strong> on stop\/terminate\/host move scenarios.\n&#8211; You can keep authoritative data on durable storage and treat Local SSD as a performance tier.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should <em>not<\/em> choose Local SSD<\/h3>\n\n\n\n<p>Avoid Local SSD when:\n&#8211; You need <strong>durable storage<\/strong> (persistent across VM stop\/terminate, snapshots, backups).\n&#8211; You require <strong>easy detach\/reattach<\/strong> to other instances.\n&#8211; Your compliance requires <strong>specific key management<\/strong> features not supported by Local SSD (verify).\n&#8211; Your workload cannot tolerate data loss or needs strong durability guarantees.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Local SSD used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Financial services<\/strong>: Low-latency analytics, backtesting scratch space, risk simulations.<\/li>\n<li><strong>Gaming<\/strong>: Asset caches, match servers, temporary state caches.<\/li>\n<li><strong>Media &amp; entertainment<\/strong>: Transcoding scratch, temporary render caches.<\/li>\n<li><strong>Adtech\/Martech<\/strong>: Real-time bidding intermediate storage, fast ETL staging.<\/li>\n<li><strong>Life sciences<\/strong>: Genomics pipelines temporary files, compute-heavy workflows.<\/li>\n<li><strong>Manufacturing\/IoT<\/strong>: High-throughput time-series pre-processing caches.<\/li>\n<li><strong>Software\/SaaS<\/strong>: CI\/CD build caches and artifact staging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform teams building standardized VM templates.<\/li>\n<li>SRE\/DevOps teams optimizing latency and throughput.<\/li>\n<li>Data engineering teams running batch ETL and Spark-like workloads.<\/li>\n<li>HPC teams running MPI\/compute simulations.<\/li>\n<li>Application teams needing high-speed caching on VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cache layers<\/strong> (HTTP caches, object caches, DB caches).<\/li>\n<li><strong>Build systems<\/strong> (compilation caches, dependency caches).<\/li>\n<li><strong>Batch analytics<\/strong> intermediate shuffle\/sort data.<\/li>\n<li><strong>Temporary database storage<\/strong> (only if designed for ephemeral behavior\u2014e.g., read replicas, rebuildable indexes, or non-critical staging).<\/li>\n<li><strong>High-speed staging<\/strong> for data ingestion and transformation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Tiered storage architecture<\/strong>: Durable store (Cloud Storage \/ PD \/ Hyperdisk) + Local SSD cache tier.<\/li>\n<li><strong>Ephemeral compute<\/strong>: Autoscaled instance groups where each VM uses Local SSD for scratch.<\/li>\n<li><strong>Pipeline staging<\/strong>: Dataflow-like patterns on VMs: download \u2192 process \u2192 upload.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Common for caches and performance scratch where data can be lost safely.<\/li>\n<li><strong>Dev\/test<\/strong>: Great for performance testing, CI runners, and reproducible build caches (as long as you accept ephemeral behavior).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Local SSD is a strong fit. Each includes the problem, why Local SSD fits, and an example.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) High-speed application cache on Compute Engine<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Application latency is dominated by disk reads\/writes for cached objects.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Low latency and high IOPS make cache access fast.<\/li>\n<li><strong>Example<\/strong>: A microservice stores rendered templates and frequently accessed blobs on Local SSD; authoritative objects remain in Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) CI\/CD build and dependency cache<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Build pipelines waste time downloading dependencies and writing build artifacts.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Fast local storage speeds up dependency unpacking and compilation.<\/li>\n<li><strong>Example<\/strong>: Self-hosted CI runners on Compute Engine store Maven\/npm caches on Local SSD; build outputs upload to Artifact Registry or Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Batch ETL scratch space<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: ETL jobs create many intermediate files (sorts, joins, partitions).<\/li>\n<li><strong>Why Local SSD fits<\/strong>: High sequential throughput and IOPS reduce ETL runtime.<\/li>\n<li><strong>Example<\/strong>: Nightly job downloads parquet files from Cloud Storage, processes locally using Local SSD scratch, and uploads aggregated results.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Temporary \u201cshuffle\u201d storage for distributed processing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Distributed compute frameworks use heavy local disk I\/O for shuffle.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Lower shuffle spill time improves job completion time.<\/li>\n<li><strong>Example<\/strong>: A VM-based Spark cluster uses Local SSD for shuffle and spill directories; durable inputs\/outputs are in Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) High-performance content processing (transcode\/render scratch)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Media processing writes huge intermediate files.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Excellent throughput for large-file sequential workloads.<\/li>\n<li><strong>Example<\/strong>: Transcode workers stage video segments on Local SSD and upload final outputs to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Database acceleration for ephemeral or rebuildable components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A DB workload is I\/O bound for temporary tables or rebuildable indexes.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Put <em>non-authoritative<\/em> structures on Local SSD for speed.<\/li>\n<li><strong>Example<\/strong>: A reporting pipeline uses Local SSD for temporary tables and sorting; source-of-truth data remains on durable disks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) ML feature preprocessing cache<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Feature preprocessing repeatedly reads\/writes intermediate tensors\/files.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Fast local staging can reduce training pipeline bottlenecks.<\/li>\n<li><strong>Example<\/strong>: Training jobs on Compute Engine stage TFRecord shards to Local SSD, train, and checkpoint to durable storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Gaming server temporary state\/cache<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Game servers need fast local access to session caches and hot assets.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Improves tick stability and reduces jitter tied to disk I\/O.<\/li>\n<li><strong>Example<\/strong>: Match servers use Local SSD for cached assets and logs; critical events stream to Cloud Logging \/ Pub\/Sub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) High-speed log processing buffer<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Log ingestion bursts overwhelm slower disks.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: High ingest throughput buffers bursts reliably (while VM runs).<\/li>\n<li><strong>Example<\/strong>: A VM-based ingestion tier writes raw logs to Local SSD and batches uploads to Cloud Storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Temporary staging for data migration or re-indexing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Large migrations and reindex operations require fast staging.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Local staging avoids repeated remote disk I\/O.<\/li>\n<li><strong>Example<\/strong>: Reindex job pulls from a database export in Cloud Storage, processes on Local SSD, then writes indexes to a durable database\/storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) API response caching \/ edge-like caching inside a region<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: High read traffic causes expensive backend calls.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Cheap, fast on-VM caching reduces backend load.<\/li>\n<li><strong>Example<\/strong>: A VM fleet behind an internal load balancer uses Local SSD to store cached API responses.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Temporary workspace for security scanning \/ malware analysis sandboxes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Sandboxes process many files with heavy I\/O and must be disposable.<\/li>\n<li><strong>Why Local SSD fits<\/strong>: Fast and ephemeral aligns with \u201cdestroy after analysis.\u201d<\/li>\n<li><strong>Example<\/strong>: Disposable scanning VMs write samples and extracted artifacts to Local SSD; results are pushed to a durable store.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can vary by machine series, zone, and guest OS. Always confirm in the official Local SSD documentation for your chosen instance type and region\/zone:\nhttps:\/\/cloud.google.com\/compute\/docs\/disks\/local-ssd<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Host-local, ephemeral block storage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides block devices physically attached to the VM\u2019s host.<\/li>\n<li><strong>Why it matters<\/strong>: Minimizes latency and maximizes throughput versus networked storage.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster scratch operations, caching, and staging.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Data is <strong>not durable<\/strong> across VM stop\/terminate and host changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: High performance (low latency, high IOPS\/throughput)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables very fast read\/write operations.<\/li>\n<li><strong>Why it matters<\/strong>: Storage bottlenecks are common; Local SSD can materially reduce job runtimes.<\/li>\n<li><strong>Practical benefit<\/strong>: Better throughput for pipelines, builds, and media workloads.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Actual performance depends on machine type, CPU\/memory, block size, queue depth, and filesystem\/RAID tuning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Multiple devices per VM (scaling performance with striping)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you attach multiple Local SSD devices (subject to limits).<\/li>\n<li><strong>Why it matters<\/strong>: You can increase aggregate throughput\/IOPS by striping (RAID 0).<\/li>\n<li><strong>Practical benefit<\/strong>: Better performance for large parallel I\/O workloads.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: RAID 0 increases failure domain for that scratch volume\u2014design for loss.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: NVMe or SCSI device interfaces (platform dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes Local SSD as NVMe or SCSI devices to the guest OS.<\/li>\n<li><strong>Why it matters<\/strong>: NVMe often yields better performance and modern tooling support.<\/li>\n<li><strong>Practical benefit<\/strong>: Higher I\/O queue depth and potentially lower latency.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Device naming and driver support differ across OS images and kernel versions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Instance lifecycle-coupled provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Local SSD is created\/allocated with the VM and released with it.<\/li>\n<li><strong>Why it matters<\/strong>: Simplifies provisioning\u2014no separate disk resource management.<\/li>\n<li><strong>Practical benefit<\/strong>: Easy ephemeral compute patterns with managed instance groups.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: No \u201cdetach and move\u201d workflow like Persistent Disk \/ Hyperdisk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Encryption at rest by default<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Data is encrypted at rest by Google Cloud.<\/li>\n<li><strong>Why it matters<\/strong>: Helps meet baseline security expectations.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduced need for application-level encryption for non-sensitive scratch (though you may still require it for compliance).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Customer-managed encryption key (CMEK) support and controls can differ from durable disks\u2014<strong>verify in official docs<\/strong> if required by policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Suitable for ephemeral Kubernetes storage (design dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Local SSD can back certain ephemeral storage patterns for containers running on Compute Engine nodes.<\/li>\n<li><strong>Why it matters<\/strong>: Containers may need fast scratch volumes.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster build pods, ML preprocessing pods, transient caches.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Behavior depends on GKE mode and node config; Local SSD is not a drop-in replacement for persistent volumes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: Works with standard Linux filesystems and tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: You can format and mount it like any other block device.<\/li>\n<li><strong>Why it matters<\/strong>: Easy adoption for Linux workloads.<\/li>\n<li><strong>Practical benefit<\/strong>: Use ext4\/xfs, LVM, mdadm, fstrim, etc.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: You must handle formatting\/mounting (and re-creation) yourself.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Compute Engine API provisions a VM with one or more Local SSD devices attached.<\/li>\n<li><strong>Data plane<\/strong>: The guest OS reads\/writes directly to the Local SSD devices on the host.<\/li>\n<li><strong>Durability boundary<\/strong>: Local SSD data is durable only within the lifetime of that VM on that host. If the VM is stopped\/terminated or moved to another host, Local SSD content should be considered lost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (conceptual)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You create a VM with Local SSD using the Google Cloud Console, <code>gcloud<\/code>, or API.<\/li>\n<li>Compute Engine schedules the VM onto a host that can provide Local SSD capacity.<\/li>\n<li>The guest OS detects one or more new block devices (often <code>\/dev\/nvme*<\/code>).<\/li>\n<li>You format\/mount devices (or RAID them).<\/li>\n<li>Your application reads\/writes temporary data at high speed.<\/li>\n<li>On VM stop\/terminate or host move events, Local SSD data is discarded.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Storage<\/strong>: Common durable source\/target for input\/output datasets; use Local SSD as a staging layer.<\/li>\n<li><strong>Persistent Disk \/ Hyperdisk<\/strong>: Keep authoritative state on durable block storage; use Local SSD for cache\/scratch.<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: Observe VM metrics; export logs rather than keeping them only on Local SSD.<\/li>\n<li><strong>Managed Instance Groups (MIGs)<\/strong>: Horizontal scaling of ephemeral workers using Local SSD for scratch.<\/li>\n<li><strong>GKE<\/strong>: Node-local storage patterns for ephemeral workloads (verify exact current features in GKE docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine<\/strong>: Local SSD is a Compute Engine feature; it does not exist independently.<\/li>\n<li><strong>VPC networking<\/strong>: Not directly required for local I\/O, but almost always required for data ingress\/egress, management, and monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access is controlled by <strong>IAM<\/strong> for Compute Engine resources:<\/li>\n<li>Who can create\/modify instances with Local SSD.<\/li>\n<li>Who can SSH into instances and read local data.<\/li>\n<li>On the VM, standard OS-level permissions apply (Linux filesystem permissions, sudo, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD traffic is <strong>not network traffic<\/strong>; it\u2019s local I\/O within the host.<\/li>\n<li>But typical architectures use network for:<\/li>\n<li>Pulling input data (Cloud Storage, APIs).<\/li>\n<li>Pushing results.<\/li>\n<li>Remote administration (IAP TCP forwarding, SSH).<\/li>\n<li>Monitoring\/logging export.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track:<\/li>\n<li>VM disk throughput\/IOPS (via Cloud Monitoring metrics for instances; exact metrics vary).<\/li>\n<li>Application-level latency for operations using Local SSD.<\/li>\n<li>Capacity usage (filesystem utilization).<\/li>\n<li>Governance:<\/li>\n<li>Use labels\/tags for VM resources to track workloads using Local SSD (cost allocation, inventory).<\/li>\n<li>Use OS policies or startup scripts to enforce formatting\/mounting standards.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[Cloud Storage\\n(durable)] --&gt;|download inputs| B[Compute Engine VM]\n  B --&gt; C[Local SSD\\n(ephemeral scratch\/cache)]\n  B --&gt;|upload outputs| A\n  B --&gt; D[Cloud Monitoring &amp; Logging]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph VPC[Google Cloud VPC]\n    ILB[Internal\/External Load Balancer] --&gt; MIG[MIG: Compute Engine Workers\\n(Local SSD for scratch)]\n    MIG --&gt;|reads\/writes| LSSD[(Local SSD\\nEphemeral)]\n    MIG --&gt;|writes logs\/metrics| Ops[Cloud Logging &amp; Monitoring]\n    MIG --&gt;|fetch secrets via IAM| IAM[IAM \/ Service Accounts]\n  end\n\n  subgraph Durable[Durable Data Layer]\n    GCS[Cloud Storage\\nData Lake \/ Artifacts]\n    PD[Persistent Disk \/ Hyperdisk\\nAuthoritative State]\n    DB[(Managed DB\\n(e.g., Cloud SQL\/Spanner))]\n  end\n\n  MIG --&gt;|stage input\/output| GCS\n  MIG --&gt;|read\/write durable state| PD\n  MIG --&gt;|queries| DB\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Compute Engine API enabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum permissions to run the lab (choose one approach):\n&#8211; For learning in a sandbox project:\n  &#8211; <code>roles\/compute.admin<\/code> (broad; simplest for labs)\n  &#8211; <code>roles\/iam.serviceAccountUser<\/code> (if attaching\/using service accounts)\n&#8211; For least privilege (more complex):\n  &#8211; Permissions to create instances, set metadata, use images, and manage firewall rules.\n  &#8211; If you use IAP for SSH: roles for IAP TCP tunneling (verify current roles in IAP docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD is <strong>billable<\/strong>; there is no general free tier for Local SSD.<\/li>\n<li>You will also pay for the VM while it runs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud CLI (<code>gcloud<\/code>)<\/strong> installed and authenticated:<\/li>\n<li>https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>An SSH client (built-in on macOS\/Linux; Windows via PowerShell\/WSL or Cloud Shell).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region\/zone availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD availability varies by:<\/li>\n<li>Zone<\/li>\n<li>Machine series\/type<\/li>\n<li>Capacity in that zone<br\/>\n  Always confirm availability for your chosen zone and machine type:<\/li>\n<li>https:\/\/cloud.google.com\/compute\/docs\/disks\/local-ssd<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine quotas apply:<\/li>\n<li>CPUs\/instances per region<\/li>\n<li>Local SSD \/ resources per zone (availability\/capacity constraints)<br\/>\n  Check quotas in the Cloud Console and verify Local SSD attachment limits for your machine type in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine<\/li>\n<li>(Optional but recommended) Cloud Logging\/Monitoring are enabled by default for most projects.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<blockquote>\n<p>Do not rely on static numbers in blog posts for pricing. Local SSD pricing is region-dependent and can change. Always check the official pricing pages and your project\u2019s billing reports.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how you are charged)<\/h3>\n\n\n\n<p>Local SSD is charged based on:\n&#8211; <strong>Allocated Local SSD capacity<\/strong> attached to your VM (not \u201cused bytes\u201d).\n&#8211; <strong>Time<\/strong> the Local SSD is provisioned (commonly tied to VM runtime; if the VM stops and Local SSD is released, charges typically stop\u2014verify current behavior in official docs).\n&#8211; Pricing varies by region\/zone and may vary by platform.<\/p>\n\n\n\n<p>Official pricing references:\n&#8211; Compute disk pricing (includes Local SSD): https:\/\/cloud.google.com\/compute\/disks-pricing<br\/>\n&#8211; Pricing calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GB-month (or equivalent)<\/strong> for Local SSD capacity.<\/li>\n<li><strong>Compute Engine VM costs<\/strong>: CPU and memory (and any GPU\/TPU if used).<\/li>\n<li><strong>OS licensing<\/strong>: Some OS images have licensing costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD is generally <strong>not<\/strong> included in the Google Cloud Free Tier. Verify current Free Tier details:<\/li>\n<li>https:\/\/cloud.google.com\/free<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Main cost drivers<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>VM size and runtime<\/strong> (vCPU\/memory): Usually the largest cost component.<\/li>\n<li><strong>Number\/size of Local SSD devices<\/strong>: You pay for provisioned Local SSD capacity while attached.<\/li>\n<li><strong>Scale-out<\/strong>: Many worker VMs with Local SSD can multiply costs quickly.<\/li>\n<li><strong>Data transfer<\/strong>:\n   &#8211; Ingress to Cloud Storage is often free, but egress and inter-zone\/inter-region transfers can cost money.\n   &#8211; Pulling large datasets repeatedly can become a major cost driver.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Re-download\/recompute costs<\/strong>: Because Local SSD is ephemeral, you may repeatedly rehydrate caches from Cloud Storage or databases.<\/li>\n<li><strong>Operational overhead<\/strong>: Startup scripts to format\/mount\/RAID, plus monitoring and alerts.<\/li>\n<li><strong>Capacity constraints<\/strong>: If Local SSD capacity is limited in a zone, you may need to use a more expensive zone\/region or larger instances.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using Local SSD does not itself incur network charges, but the typical pattern is:<\/li>\n<li><strong>Download<\/strong> from Cloud Storage to Local SSD \u2192 local compute \u2192 <strong>upload<\/strong> results.<\/li>\n<li>If your compute and storage are in different regions\/zones, <strong>data transfer<\/strong> can dominate cost and latency. Prefer co-locating compute and storage in the same region when possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Local SSD <strong>only<\/strong> for performance-critical, temporary data.<\/li>\n<li>Prefer <strong>autoscaling<\/strong> and short-lived VMs for batch workloads (MIG + autoscaler).<\/li>\n<li>Keep durable datasets in-region; avoid cross-region transfers.<\/li>\n<li>Consider whether <strong>Persistent Disk \/ Hyperdisk<\/strong> performance tiers meet your needs at lower operational risk.<\/li>\n<li>Avoid overprovisioning Local SSD count\/size \u201cjust in case\u201d\u2014measure I\/O requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A starter lab VM cost is typically composed of:\n&#8211; VM runtime (e.g., small general-purpose instance for &lt;1 hour)\n&#8211; 1 Local SSD device attached during that runtime<br\/>\nTo estimate:\n1. Go to the pricing calculator: https:\/\/cloud.google.com\/products\/calculator\n2. Add a Compute Engine VM with your chosen machine type and hours.\n3. Add Local SSD capacity.\n4. Ensure region\/zone matches your deployment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production pipelines using Local SSD:\n&#8211; Costs scale with:\n  &#8211; number of workers\n  &#8211; concurrency window (hours per day)\n  &#8211; Local SSD per worker\n&#8211; If the workload runs 24\/7, Local SSD charges become continuous and may not be cost-optimal compared to durable disks with sufficient performance.\n&#8211; Design for <strong>cache warmup<\/strong> and <strong>data locality<\/strong> to avoid repeated expensive downloads.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a real, minimal setup: a Compute Engine VM with Local SSD, formatted and mounted, then validated with a quick performance sanity check. It also demonstrates the <em>ephemeral<\/em> nature conceptually and includes cleanup.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a Compute Engine VM in Google Cloud with <strong>Local SSD<\/strong> attached.<\/li>\n<li>Identify the Local SSD device in Linux.<\/li>\n<li>Format and mount it safely.<\/li>\n<li>Verify it works by writing\/reading data.<\/li>\n<li>Clean up resources to avoid charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Pick a zone where Local SSD is available.\n2. Create a VM with one Local SSD (NVMe interface where supported).\n3. SSH into the VM.\n4. Format and mount the Local SSD.\n5. Run simple I\/O checks.\n6. Clean up the VM (which releases Local SSD).<\/p>\n\n\n\n<blockquote>\n<p>Notes:\n&#8211; Device names vary by OS and interface (NVMe vs SCSI).\n&#8211; Local SSD is ephemeral. Treat everything stored on it as disposable.\n&#8211; Commands below assume Debian\/Ubuntu-like Linux.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set project, region\/zone, and enable APIs<\/h3>\n\n\n\n<p>Open <strong>Cloud Shell<\/strong> (recommended) or use your local terminal.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth login\ngcloud config set project YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>Enable Compute Engine API (no output means it was already enabled):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Choose a zone. Availability varies, so you may need to try another zone if capacity is unavailable.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set compute\/zone us-central1-a\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Compute Engine API is enabled; your default zone is set.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a VM with Local SSD<\/h3>\n\n\n\n<p>Create a VM (example uses an Ubuntu image family; you can switch to Debian if preferred).<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create localssd-lab-1 \\\n  --machine-type=n2-standard-2 \\\n  --image-family=ubuntu-2204-lts \\\n  --image-project=ubuntu-os-cloud \\\n  --boot-disk-size=20GB \\\n  --local-ssd=interface=nvme\n<\/code><\/pre>\n\n\n\n<p>If your chosen machine type or zone doesn\u2019t support Local SSD, you may see an error such as:\n&#8211; \u201cLocal SSD is not supported for the selected machine type\u201d\n&#8211; \u201cInsufficient resources\u201d \/ capacity errors<\/p>\n\n\n\n<p>If that happens:\n&#8211; Try a different zone in the same region.\n&#8211; Try a different machine series supported by Local SSD.\n&#8211; Verify supported configurations in official docs.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: A VM named <code>localssd-lab-1<\/code> is created with one Local SSD attached.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: SSH into the VM and identify the Local SSD device<\/h3>\n\n\n\n<p>SSH in:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh localssd-lab-1\n<\/code><\/pre>\n\n\n\n<p>List block devices:<\/p>\n\n\n\n<pre><code class=\"language-bash\">lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL\n<\/code><\/pre>\n\n\n\n<p>Look for an unmounted device that matches the Local SSD size. On NVMe, it often looks like:\n&#8211; <code>\/dev\/nvme0n1<\/code>, <code>\/dev\/nvme0n2<\/code>, etc.<\/p>\n\n\n\n<p>Also check dmesg for NVMe devices:<\/p>\n\n\n\n<pre><code class=\"language-bash\">dmesg | grep -i nvme | tail -n 50\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You can see an unmounted block device representing the Local SSD.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Format the Local SSD and mount it<\/h3>\n\n\n\n<blockquote>\n<p>Warning: Formatting erases all data on the target device. Double-check the device name.<\/p>\n<\/blockquote>\n\n\n\n<p>Assume the device is <code>\/dev\/nvme0n1<\/code> (adjust if yours differs). Create a filesystem:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkfs.ext4 -F \/dev\/nvme0n1\n<\/code><\/pre>\n\n\n\n<p>Create a mount point and mount it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkdir -p \/mnt\/localssd\nsudo mount \/dev\/nvme0n1 \/mnt\/localssd\n<\/code><\/pre>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">df -h \/mnt\/localssd\nmount | grep localssd\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>\/mnt\/localssd<\/code> is mounted and shows available capacity.<\/p>\n\n\n\n<p><strong>Optional (recommended for automation): mount via UUID<\/strong><br\/>\nGet the UUID:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo blkid \/dev\/nvme0n1\n<\/code><\/pre>\n\n\n\n<p>Then add an <code>\/etc\/fstab<\/code> entry (example\u2014verify the UUID and filesystem type):<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo 'UUID=YOUR_UUID_HERE \/mnt\/localssd ext4 defaults,nofail 0 2' | sudo tee -a \/etc\/fstab\n<\/code><\/pre>\n\n\n\n<p>This helps remount after reboot. (Remember: reboot is different from stop\/terminate. Local SSD is expected to survive a simple reboot, but you should verify behavior for your exact maintenance\/lifecycle scenario in the official docs.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Write data and run basic I\/O checks<\/h3>\n\n\n\n<p>Write a test file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">time dd if=\/dev\/zero of=\/mnt\/localssd\/testfile.bin bs=256M count=4 oflag=direct status=progress\n<\/code><\/pre>\n\n\n\n<p>Read it back:<\/p>\n\n\n\n<pre><code class=\"language-bash\">time dd if=\/mnt\/localssd\/testfile.bin of=\/dev\/null bs=256M iflag=direct status=progress\n<\/code><\/pre>\n\n\n\n<p>Create many small files (metadata-heavy test):<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p \/mnt\/localssd\/smallfiles\ntime bash -c 'for i in $(seq 1 20000); do echo $i &gt; \/mnt\/localssd\/smallfiles\/f_$i; done'\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Commands complete successfully and demonstrate that Local SSD is working and fast.<\/p>\n\n\n\n<blockquote>\n<p>For deeper benchmarking, consider <code>fio<\/code>, but be mindful that uncontrolled benchmarks can consume CPU and impact shared environments. If you use <code>fio<\/code>, install it and run a short test:<\/p>\n<p><code>bash\nsudo apt-get update &amp;&amp; sudo apt-get install -y fio\nfio --name=randrw --directory=\/mnt\/localssd --size=2G --bs=4k --rw=randrw --iodepth=32 --numjobs=4 --runtime=30 --time_based --group_reporting<\/code><\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6 (Optional): Demonstrate persistence boundaries (reboot vs stop)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reboot test<\/strong> (usually retains Local SSD contents):\n  1. Create a marker file:\n     <code>bash\n     echo \"hello localssd\" | sudo tee \/mnt\/localssd\/marker.txt<\/code>\n  2. Reboot:\n     <code>bash\n     sudo reboot<\/code>\n  3. SSH back in and check:\n     <code>bash\n     cat \/mnt\/localssd\/marker.txt<\/code><\/li>\n<li><strong>Stop\/Start behavior<\/strong>: Local SSD is ephemeral and is generally <strong>not preserved<\/strong> across stop\/start. The exact workflow and behavior can vary; verify current behavior in official docs before relying on any persistence across lifecycle actions.<\/li>\n<\/ul>\n\n\n\n<p><strong>Expected outcome<\/strong>: Reboot typically preserves data; stop\/terminate does not.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run the following to validate correct setup:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Local SSD is mounted:\n   <code>bash\n   df -h | grep -E '\/mnt\/localssd'<\/code><\/p>\n<\/li>\n<li>\n<p>You can write and read:\n   <code>bash\n   echo OK | sudo tee \/mnt\/localssd\/ok.txt\n   cat \/mnt\/localssd\/ok.txt<\/code><\/p>\n<\/li>\n<li>\n<p>Performance sanity check (optional):\n   &#8211; <code>dd<\/code> read\/write tests complete without errors.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p>1) <strong>VM creation fails: Local SSD not supported<\/strong>\n&#8211; Cause: Machine series\/zone doesn\u2019t support Local SSD.\n&#8211; Fix:\n  &#8211; Try a different machine type (e.g., N2 vs E2).\n  &#8211; Try a different zone.\n  &#8211; Confirm in docs: https:\/\/cloud.google.com\/compute\/docs\/disks\/local-ssd<\/p>\n\n\n\n<p>2) <strong>VM creation fails: insufficient capacity<\/strong>\n&#8211; Cause: Local SSD capacity in a zone can be constrained.\n&#8211; Fix:\n  &#8211; Try a different zone.\n  &#8211; Use smaller\/larger machine type (availability can differ).\n  &#8211; Consider reservations for production (capacity planning).<\/p>\n\n\n\n<p>3) <strong>Can\u2019t find the Local SSD device<\/strong>\n&#8211; Cause: Device naming differs (NVMe vs SCSI), or you\u2019re looking at the boot disk.\n&#8211; Fix:\n  &#8211; Use <code>lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL<\/code>\n  &#8211; Check <code>\/dev\/disk\/by-id\/<\/code>\n  &#8211; Inspect <code>dmesg<\/code><\/p>\n\n\n\n<p>4) <strong>Mount disappears after reboot<\/strong>\n&#8211; Cause: <code>\/etc\/fstab<\/code> not configured (or wrong UUID).\n&#8211; Fix:\n  &#8211; Mount by UUID and ensure <code>nofail<\/code> is set to avoid boot issues.\n  &#8211; Re-check <code>blkid<\/code> and <code>fstab<\/code> syntax.<\/p>\n\n\n\n<p>5) <strong>Permission denied when writing<\/strong>\n&#8211; Cause: Mount point permissions.\n&#8211; Fix:\n  &#8211; Adjust ownership:\n    <code>bash\n    sudo chown -R $USER:$USER \/mnt\/localssd<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the VM (which also releases Local SSD):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete localssd-lab-1 --quiet\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The VM is deleted, and Local SSD charges stop with it.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Treat Local SSD as disposable<\/strong>: Design so loss of Local SSD data is a non-event.<\/li>\n<li><strong>Keep authoritative data elsewhere<\/strong>: Use Cloud Storage, Persistent Disk\/Hyperdisk, or managed databases as the source of truth.<\/li>\n<li><strong>Warm caches deliberately<\/strong>: If using Local SSD as cache, plan a warmup strategy and accept cache misses after restarts.<\/li>\n<li><strong>Use tiered storage<\/strong>: Durable storage for state + Local SSD for hot\/temp data yields a good performance\/cost balance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Restrict who can:<\/li>\n<li>create instances with Local SSD<\/li>\n<li>SSH into instances<\/li>\n<li>change instance metadata (startup scripts can exfiltrate data)<\/li>\n<li>Prefer <strong>OS Login<\/strong> and <strong>IAP<\/strong> for SSH access where appropriate (verify your org\u2019s standard).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Local SSD only for workloads that demonstrate measurable benefit.<\/li>\n<li>Autoscale worker pools; shut down when idle.<\/li>\n<li>Avoid cross-region data movement; place compute near data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Consider <strong>striping (RAID 0)<\/strong> across multiple Local SSDs for higher throughput (when supported and needed).<\/li>\n<li>Choose filesystem settings appropriate to workload (ext4 vs xfs; mount options).<\/li>\n<li>Benchmark with representative I\/O patterns (block size, concurrency), not just sequential <code>dd<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Store checkpoints and outputs on durable storage frequently enough to meet RPO\/RTO.<\/li>\n<li>For pipelines: make tasks idempotent so they can restart after VM replacement.<\/li>\n<li>Use managed instance groups with health checks for ephemeral workers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use startup scripts or images to:<\/li>\n<li>detect Local SSD devices<\/li>\n<li>format if needed<\/li>\n<li>mount consistently<\/li>\n<li>Export logs\/metrics externally (Cloud Logging\/Monitoring). Don\u2019t rely on Local SSD for log retention.<\/li>\n<li>Apply labels for ownership, environment, cost center.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming pattern example:<\/li>\n<li><code>mig-etl-workers-localssd-prod<\/code><\/li>\n<li><code>vm-ci-runner-localssd-dev-01<\/code><\/li>\n<li>Labels:<\/li>\n<li><code>env=prod|dev<\/code><\/li>\n<li><code>team=data-platform<\/code><\/li>\n<li><code>purpose=etl-scratch<\/code><\/li>\n<li><code>cost-center=1234<\/code><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM governs control-plane actions<\/strong>: who can create\/modify\/delete instances with Local SSD.<\/li>\n<li><strong>OS access governs data-plane access<\/strong>: anyone with root\/admin on the VM can read Local SSD contents.<\/li>\n<li>Prefer:<\/li>\n<li>least privilege IAM roles<\/li>\n<li>OS Login with MFA\/SSO if available<\/li>\n<li>IAP-based SSH to reduce public exposure<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest by default.<\/li>\n<li>If you have requirements for:<\/li>\n<li>customer-managed encryption keys (CMEK)<\/li>\n<li>customer-supplied encryption keys (CSEK)<\/li>\n<li>specific HSM-backed controls<br\/>\n<strong>Verify in official docs<\/strong> whether and how Local SSD supports those controls, and design accordingly. Local SSD is not the same as Persistent Disk\/Hyperdisk in manageability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD itself isn\u2019t exposed to the network, but the VM is.<\/li>\n<li>Reduce VM exposure:<\/li>\n<li>no public IP unless required<\/li>\n<li>firewall rules scoped to known sources<\/li>\n<li>use IAP \/ bastion patterns for admin access<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t store secrets only on Local SSD.<\/li>\n<li>Use Secret Manager or your org\u2019s secrets solution; deliver secrets via:<\/li>\n<li>Secret Manager access at runtime using service account permissions<\/li>\n<li>short-lived tokens<\/li>\n<li>Avoid embedding secrets in instance metadata startup scripts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Audit Logs to track Compute Engine API actions (instance creation\/deletion).<\/li>\n<li>Use Cloud Logging agent \/ Ops Agent as needed for OS\/application logs.<\/li>\n<li>Ensure logs are exported to a durable sink (Cloud Storage, BigQuery, SIEM) if required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD is best for <strong>non-authoritative<\/strong> and <strong>non-sensitive<\/strong> temporary data unless you have validated encryption\/key-management requirements with official docs and internal compliance.<\/li>\n<li>Ensure data classification policies explicitly allow ephemeral local storage for the chosen data type.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treating Local SSD like a durable disk and storing primary data there.<\/li>\n<li>Leaving SSH open to the internet with weak access controls.<\/li>\n<li>Storing secrets or sensitive dumps on Local SSD and forgetting to export necessary audit trails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use private subnets and IAP for management.<\/li>\n<li>Enforce OS patching and hardening (CIS where applicable).<\/li>\n<li>Apply least privilege IAM and service account scopes.<\/li>\n<li>Keep sensitive authoritative data on durable managed storage with proper encryption and access controls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>This section is intentionally direct. Local SSD is excellent at one thing\u2014fast ephemeral storage\u2014and unforgiving if treated like durable storage.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Durability and lifecycle<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data loss on stop\/terminate<\/strong>: Local SSD content is ephemeral. If the VM is stopped\/terminated, data is not preserved.<\/li>\n<li><strong>Host events<\/strong>: If the VM is moved to another host due to maintenance or failure, Local SSD data should be assumed lost. The exact behavior can depend on platform\/machine series\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">No snapshots \/ backups like durable disks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD is not designed for snapshots the way Persistent Disk\/Hyperdisk is. Plan to persist anything important elsewhere.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Availability constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD capacity can be constrained in specific zones.<\/li>\n<li>You may see \u201cinsufficient capacity\u201d errors, especially at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Machine type \/ platform constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not every machine series supports Local SSD.<\/li>\n<li>Attachment limits (how many devices you can add) vary by machine series\/type.<\/li>\n<li>Interface type (NVMe vs SCSI) varies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Device names can change<\/strong>: Don\u2019t hardcode <code>\/dev\/nvme0n1<\/code> in production scripts\u2014use stable identifiers (UUID, <code>\/dev\/disk\/by-id\/<\/code>).<\/li>\n<li><strong>Formatting on first boot<\/strong>: You must format before use; automate this.<\/li>\n<li><strong>Mount failures can break boot<\/strong>: Incorrect <code>\/etc\/fstab<\/code> entries can cause boot problems. Use <code>nofail<\/code> and test carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Local SSD charges accrue while provisioned\/attached to running VMs (typical). If you leave many instances running, costs scale quickly.<\/li>\n<li>Indirect cost: rehydrating caches repeatedly from Cloud Storage can increase network\/data processing costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some specialized OS images or older kernels may not handle NVMe devices as expected.<\/li>\n<li>Container orchestration integration is nuanced\u2014Local SSD is not a universal \u201cpersistent volume.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from Local SSD to durable storage requires redesign:<\/li>\n<li>data persistence<\/li>\n<li>backup\/snapshot strategy<\/li>\n<li>performance tuning<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Local SSD is one point in a broader storage design space. Here\u2019s how it compares to common alternatives.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Persistent Disk (PD)<\/strong>: Durable network-attached block storage for VMs.<\/li>\n<li><strong>Hyperdisk<\/strong>: Newer generation of durable block storage options with configurable performance (where available).<\/li>\n<li><strong>Filestore<\/strong>: Managed NFS file storage.<\/li>\n<li><strong>Cloud Storage<\/strong>: Object storage for durable blobs.<\/li>\n<li><strong>Memorystore<\/strong>: Managed in-memory caching (Redis\/Memcached).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS EC2 Instance Store<\/strong>: Ephemeral host-attached storage similar in concept.<\/li>\n<li><strong>Azure Temporary Disk<\/strong>: Ephemeral local storage on Azure VMs (varies by VM family).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source\/self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Self-managed NVMe in colocation\/on-prem<\/li>\n<li>Caching layers like Redis (self-hosted) on local disks (but then you manage durability\/replication)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Local SSD<\/strong><\/td>\n<td>Ultra-fast temporary scratch\/cache on Compute Engine<\/td>\n<td>Very low latency; high IOPS\/throughput; simple attachment<\/td>\n<td>Ephemeral; no detach\/reattach; lifecycle\/host constraints<\/td>\n<td>When data is disposable and performance matters most<\/td>\n<\/tr>\n<tr>\n<td><strong>Persistent Disk (Standard\/Balanced\/SSD)<\/strong><\/td>\n<td>General durable VM block storage<\/td>\n<td>Durable; snapshots; flexible<\/td>\n<td>Higher latency than host-local; network-attached<\/td>\n<td>When you need durability and standard VM storage patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Hyperdisk<\/strong><\/td>\n<td>Durable block storage with performance tuning (where available)<\/td>\n<td>Durable; performance options; modern features<\/td>\n<td>Availability\/feature set varies; still network-attached<\/td>\n<td>When you need durability but higher performance than classic PD tiers<\/td>\n<\/tr>\n<tr>\n<td><strong>Filestore (NFS)<\/strong><\/td>\n<td>Shared POSIX file storage<\/td>\n<td>Shared filesystem; managed<\/td>\n<td>Not for ultra-low-latency local scratch; cost<\/td>\n<td>When multiple VMs need shared files<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Storage<\/strong><\/td>\n<td>Durable object storage<\/td>\n<td>Very durable; scalable; cheap per GB<\/td>\n<td>Not block storage; higher latency; app changes<\/td>\n<td>Data lake, artifacts, backups, large datasets<\/td>\n<\/tr>\n<tr>\n<td><strong>Memorystore<\/strong><\/td>\n<td>Low-latency caching<\/td>\n<td>Managed; very fast; replication options<\/td>\n<td>Cost; data size limited vs disks<\/td>\n<td>Hot key-value caching with low latency needs<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS EC2 Instance Store<\/strong><\/td>\n<td>AWS equivalent ephemeral local storage<\/td>\n<td>Similar performance pattern<\/td>\n<td>AWS-specific; ephemeral<\/td>\n<td>If you\u2019re on AWS and need host-local scratch<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Temporary Disk<\/strong><\/td>\n<td>Azure equivalent ephemeral local storage<\/td>\n<td>Similar pattern<\/td>\n<td>Azure-specific; ephemeral<\/td>\n<td>If you\u2019re on Azure and need scratch<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Media processing pipeline at scale<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A media company transcodes large video files into multiple bitrates. The transcode process creates heavy intermediate I\/O and temporary files. Using only network-attached disks increases runtime and cost.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Cloud Storage bucket stores source videos and final outputs.<\/li>\n<li>Managed instance group of Compute Engine workers with <strong>Local SSD<\/strong> for scratch.<\/li>\n<li>Workers:<ol>\n<li>download source to Local SSD<\/li>\n<li>transcode and write intermediates to Local SSD<\/li>\n<li>upload final artifacts back to Cloud Storage<\/li>\n<\/ol>\n<\/li>\n<li>Cloud Monitoring tracks job success, instance health, and throughput.<\/li>\n<li><strong>Why Local SSD was chosen<\/strong><\/li>\n<li>Intermediate files are temporary and can be recreated.<\/li>\n<li>Transcoding is I\/O heavy and benefits from very fast local storage.<\/li>\n<li>Worker nodes are replaceable; job orchestration retries failures.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Reduced transcode wall-clock time.<\/li>\n<li>Better worker density per region due to faster scratch.<\/li>\n<li>Lower overall compute hours (even if Local SSD adds cost) because jobs finish faster.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Faster CI runners for a monorepo<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup\u2019s monorepo builds are slow; build steps repeatedly download dependencies and perform heavy local compilation. Managed CI minutes are expensive, and self-hosted runners are underperforming with standard disks.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Compute Engine VM template for CI runners with one Local SSD.<\/li>\n<li>Startup script formats\/mounts Local SSD and sets build cache directories there.<\/li>\n<li>Build outputs and long-term caches are pushed to Cloud Storage\/Artifact Registry.<\/li>\n<li><strong>Why Local SSD was chosen<\/strong><\/li>\n<li>CI caches are rebuildable; losing them is acceptable.<\/li>\n<li>High I\/O compilation and dependency extraction benefit from fast local storage.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Faster builds and reduced developer wait time.<\/li>\n<li>Predictable build performance on ephemeral runners.<\/li>\n<li>Cost control via autoscaling runners during peak hours.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Local SSD the same as Persistent Disk or Hyperdisk?<\/strong><br\/>\nNo. Local SSD is <strong>ephemeral host-attached<\/strong> storage. Persistent Disk and Hyperdisk are <strong>durable network-attached<\/strong> block storage services with snapshot\/restore and detach\/attach capabilities.<\/p>\n\n\n\n<p>2) <strong>Does Local SSD persist across VM reboot?<\/strong><br\/>\nTypically, Local SSD data persists across a guest OS reboot, but not across VM stop\/terminate or host migration events. Verify exact lifecycle behavior in official docs for your instance type.<\/p>\n\n\n\n<p>3) <strong>Does Local SSD persist across VM stop\/start?<\/strong><br\/>\nIn general, no\u2014Local SSD is ephemeral, and data should be assumed lost when the VM is stopped and restarted. Confirm current behavior in docs.<\/p>\n\n\n\n<p>4) <strong>Can I take snapshots of Local SSD?<\/strong><br\/>\nLocal SSD is not designed for standard disk snapshots like Persistent Disk\/Hyperdisk. Treat it as scratch\/cache and persist important data elsewhere.<\/p>\n\n\n\n<p>5) <strong>Can I detach a Local SSD and attach it to another VM?<\/strong><br\/>\nNo. Local SSD is tied to the VM\/host lifecycle and is not a portable disk resource.<\/p>\n\n\n\n<p>6) <strong>What interface does Local SSD use\u2014NVMe or SCSI?<\/strong><br\/>\nIt can be NVMe or SCSI depending on the VM platform and configuration. NVMe is common for modern machine types. Verify per machine series.<\/p>\n\n\n\n<p>7) <strong>How big is a Local SSD?<\/strong><br\/>\nLocal SSD capacity is provided in fixed increments per device and varies by platform over time. Check the official docs for current sizes and limits.<\/p>\n\n\n\n<p>8) <strong>How many Local SSDs can I attach to one VM?<\/strong><br\/>\nLimits depend on the machine series\/type and zone. Consult the Local SSD documentation and machine type specs.<\/p>\n\n\n\n<p>9) <strong>Is Local SSD encrypted at rest?<\/strong><br\/>\nGoogle Cloud encrypts data at rest by default. For customer-managed key requirements, verify Local SSD key-management support in official docs.<\/p>\n\n\n\n<p>10) <strong>Is Local SSD good for databases?<\/strong><br\/>\nIt can be used for <strong>non-authoritative<\/strong> database components (temporary tables, caches, rebuildable indexes) if your design tolerates data loss. For primary database storage, use durable storage.<\/p>\n\n\n\n<p>11) <strong>Is Local SSD cheaper than Persistent Disk\/Hyperdisk?<\/strong><br\/>\nNot necessarily. The right choice depends on required performance, durability, and runtime. Local SSD can reduce compute hours by speeding up jobs, which can offset its cost.<\/p>\n\n\n\n<p>12) <strong>Can I use Local SSD with managed instance groups (MIGs)?<\/strong><br\/>\nYes, commonly. It\u2019s a good match for ephemeral worker fleets where instances can be replaced and tasks retried.<\/p>\n\n\n\n<p>13) <strong>How do I mount Local SSD reliably if device names change?<\/strong><br\/>\nUse stable identifiers:\n&#8211; filesystem UUIDs (<code>blkid<\/code>)\n&#8211; <code>\/dev\/disk\/by-id\/<\/code> symlinks<br\/>\nAvoid hardcoding <code>\/dev\/nvme0n1<\/code> in production.<\/p>\n\n\n\n<p>14) <strong>What happens to Local SSD data if the host fails?<\/strong><br\/>\nYou should assume the data is lost. Design your application to rehydrate from durable storage or recompute.<\/p>\n\n\n\n<p>15) <strong>Should I use Local SSD for logs?<\/strong><br\/>\nYou can use it as a temporary buffer, but do not rely on it for retention. Export logs to Cloud Logging or a durable sink.<\/p>\n\n\n\n<p>16) <strong>Can containers use Local SSD on GKE?<\/strong><br\/>\nThere are patterns to use node-local storage (including Local SSD-backed ephemeral storage) depending on GKE configuration. Verify the current GKE guidance for Local SSD usage.<\/p>\n\n\n\n<p>17) <strong>What\u2019s the simplest safe pattern for Local SSD?<\/strong><br\/>\n\u201cDownload \u2192 process using Local SSD \u2192 upload results \u2192 delete VM.\u201d Keep authoritative state elsewhere.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Local SSD<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Local SSD overview (Compute Engine) \u2014 https:\/\/cloud.google.com\/compute\/docs\/disks\/local-ssd<\/td>\n<td>Primary source for supported machine types, lifecycle behavior, and configuration guidance<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Compute disk pricing (includes Local SSD) \u2014 https:\/\/cloud.google.com\/compute\/disks-pricing<\/td>\n<td>Official pricing model and region-dependent SKUs<\/td>\n<\/tr>\n<tr>\n<td>Official calculator<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build estimates for VM + Local SSD + data transfer<\/td>\n<\/tr>\n<tr>\n<td>Official docs (storage choices)<\/td>\n<td>Compute Engine disks overview \u2014 https:\/\/cloud.google.com\/compute\/docs\/disks<\/td>\n<td>Helps decide between Local SSD, Persistent Disk, Hyperdisk<\/td>\n<\/tr>\n<tr>\n<td>Official tutorial-style docs<\/td>\n<td>Compute Engine instances docs \u2014 https:\/\/cloud.google.com\/compute\/docs\/instances<\/td>\n<td>Covers VM lifecycle actions that affect Local SSD durability<\/td>\n<\/tr>\n<tr>\n<td>Official monitoring<\/td>\n<td>Cloud Monitoring \u2014 https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<td>Monitor VM performance and disk-related metrics<\/td>\n<\/tr>\n<tr>\n<td>Official logging<\/td>\n<td>Cloud Logging \u2014 https:\/\/cloud.google.com\/logging\/docs<\/td>\n<td>Export logs off ephemeral disks<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for compute\/storage patterns (use search for performance\/HPC)<\/td>\n<\/tr>\n<tr>\n<td>Kubernetes guidance (verify applicability)<\/td>\n<td>GKE storage docs \u2014 https:\/\/cloud.google.com\/kubernetes-engine\/docs\/concepts\/storage-overview<\/td>\n<td>For understanding how local\/ephemeral storage works in Kubernetes on Google Cloud<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Google Cloud Tech YouTube \u2014 https:\/\/www.youtube.com\/googlecloudtech<\/td>\n<td>Often includes deep dives on Compute Engine storage concepts<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Server Fault \/ Unix &amp; Linux Q&amp;A on NVMe, mdadm, filesystem tuning<\/td>\n<td>Practical OS-level tuning and troubleshooting (validate against Google Cloud docs)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>Google Cloud operations, CI\/CD, infrastructure practices (verify course catalog)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>DevOps\/SCM foundations and tooling (verify offerings)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops practitioners<\/td>\n<td>Cloud operations and reliability topics (verify offerings)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations teams<\/td>\n<td>SRE principles, monitoring, incident response (verify offerings)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops + ML\/automation learners<\/td>\n<td>AIOps concepts, automation in operations (verify offerings)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training resources (verify specifics)<\/td>\n<td>Beginners to working professionals<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentorship (verify specifics)<\/td>\n<td>DevOps engineers, SREs<\/td>\n<td>https:\/\/devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps freelance\/training services (verify specifics)<\/td>\n<td>Teams needing targeted help<\/td>\n<td>https:\/\/devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify specifics)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog)<\/td>\n<td>Architecture, automation, operations<\/td>\n<td>Designing VM worker fleets using Local SSD for ETL; building startup scripts and golden images; cost optimization<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement (verify service catalog)<\/td>\n<td>DevOps transformation, tooling, training<\/td>\n<td>Implementing CI runners on Compute Engine with Local SSD caches; setting up monitoring and governance<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service catalog)<\/td>\n<td>Delivery pipelines, infrastructure automation<\/td>\n<td>Migrating batch workloads to Google Cloud with Local SSD scratch; performance tuning and IaC standardization<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Local SSD<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>Projects, billing, IAM, VPC basics<\/li>\n<li>Compute Engine basics:<\/li>\n<li>VM creation, images, machine types, metadata\/startup scripts<\/li>\n<li>Linux fundamentals:<\/li>\n<li>Block devices, partitions, filesystems (ext4\/xfs), mounting, permissions<\/li>\n<li>Basic storage concepts:<\/li>\n<li>IOPS, throughput, latency, queue depth<\/li>\n<li>durability vs performance tradeoffs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Local SSD<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Durable storage design on Google Cloud:<\/li>\n<li>Persistent Disk and Hyperdisk performance tuning<\/li>\n<li>Cloud Storage lifecycle policies and optimization<\/li>\n<li>Automation:<\/li>\n<li>Infrastructure as Code (Terraform for Compute Engine)<\/li>\n<li>Golden images (Packer) and startup scripts<\/li>\n<li>Observability:<\/li>\n<li>Cloud Monitoring dashboards and alerting for VM fleets<\/li>\n<li>Log export pipelines<\/li>\n<li>Reliability patterns:<\/li>\n<li>Managed instance groups, autoscaling, health checks<\/li>\n<li>Idempotent batch job design and checkpointing<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Infrastructure Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Data Engineer (VM-based pipelines)<\/li>\n<li>HPC \/ Performance Engineer<\/li>\n<li>Platform Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Local SSD is part of Compute Engine knowledge. It\u2019s commonly relevant to:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud DevOps Engineer<br\/>\nUse Local SSD as a practical topic within Compute Engine storage and performance domains.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>ETL worker fleet<\/strong>: Build a MIG that stages data from Cloud Storage to Local SSD, processes it, and uploads results.<\/li>\n<li><strong>CI runner template<\/strong>: Create a VM image\/startup script that mounts Local SSD and configures build caches.<\/li>\n<li><strong>Performance lab<\/strong>: Benchmark PD vs Hyperdisk vs Local SSD with <code>fio<\/code> under multiple block sizes and queue depths.<\/li>\n<li><strong>Resilient caching<\/strong>: Implement an app that uses Local SSD for cache but repopulates automatically after VM replacement.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Block storage<\/strong>: Storage presented as a raw device (like <code>\/dev\/nvme0n1<\/code>) that you format with a filesystem.<\/li>\n<li><strong>Cache<\/strong>: Temporary storage of frequently accessed data to reduce latency and backend load.<\/li>\n<li><strong>Compute Engine<\/strong>: Google Cloud\u2019s Infrastructure-as-a-Service (IaaS) for VMs.<\/li>\n<li><strong>Durability<\/strong>: Likelihood that data remains intact and available across failures and lifecycle events.<\/li>\n<li><strong>Ephemeral storage<\/strong>: Temporary storage that can be lost when an instance stops, terminates, or moves hosts.<\/li>\n<li><strong>Filesystem<\/strong>: Data structure (ext4, xfs) used by an OS to organize files on a disk.<\/li>\n<li><strong>Host maintenance<\/strong>: Events where the cloud provider performs maintenance on the physical host; can trigger VM restarts\/migrations depending on configuration and platform.<\/li>\n<li><strong>IOPS<\/strong>: Input\/Output Operations Per Second\u2014how many reads\/writes a disk can perform per second.<\/li>\n<li><strong>Latency<\/strong>: Time it takes to complete an I\/O operation.<\/li>\n<li><strong>Local SSD<\/strong>: Google Cloud Compute Engine host-attached SSD for ephemeral high performance.<\/li>\n<li><strong>MIG (Managed Instance Group)<\/strong>: A group of identical VMs managed as a fleet, with autoscaling and healing.<\/li>\n<li><strong>Mount<\/strong>: Making a filesystem accessible at a directory path (e.g., <code>\/mnt\/localssd<\/code>).<\/li>\n<li><strong>NVMe<\/strong>: A high-performance storage interface commonly used for SSDs.<\/li>\n<li><strong>Persistent Disk \/ Hyperdisk<\/strong>: Durable network-attached block storage options for Compute Engine.<\/li>\n<li><strong>RAID 0 (striping)<\/strong>: Combines multiple disks into one volume to increase performance; no redundancy.<\/li>\n<li><strong>Throughput<\/strong>: Amount of data read\/written per unit time (e.g., MB\/s, GB\/s).<\/li>\n<li><strong>Zonal resource<\/strong>: A resource tied to a specific zone in a region.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p><strong>Local SSD<\/strong> in <strong>Google Cloud Compute Engine (Compute)<\/strong> is host-attached, ultra-fast <strong>ephemeral<\/strong> block storage designed for scratch space and caching. It matters because it can significantly reduce latency and runtime for I\/O-heavy workloads, often improving overall system efficiency when paired with durable storage for authoritative data.<\/p>\n\n\n\n<p>Key points to remember:\n&#8211; <strong>Cost<\/strong>: You pay for provisioned Local SSD capacity while it\u2019s attached (plus VM runtime). Use the official pricing pages and calculator for accurate regional estimates.\n&#8211; <strong>Security<\/strong>: Data is encrypted at rest by default, but key-management and compliance requirements should be validated in official docs for your specific needs.\n&#8211; <strong>When to use<\/strong>: Caches, scratch space, intermediate pipeline data, build artifacts\u2014anything <strong>reconstructable<\/strong>.\n&#8211; <strong>When not to use<\/strong>: Primary data, anything requiring snapshots\/backups, or workflows needing detach\/attach portability.<\/p>\n\n\n\n<p><strong>Next learning step<\/strong>: Compare Local SSD with <strong>Persistent Disk and Hyperdisk<\/strong> for your workload\u2019s performance and durability requirements, then practice automation with startup scripts or Terraform to mount and manage Local SSD consistently at scale.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,51],"tags":[],"class_list":["post-631","post","type-post","status-publish","format-standard","hentry","category-compute","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=631"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/631\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}