This page compares the different storage solutions that are available to your Compute Engine instances.
If you are not sure which option to use, the most common solution is to add a persistent disk to your instance.
By default, each Compute Engine instance has a single root persistent disk that contains the operating system. When your applications require additional storage space, you can add one or more additional storage options to your instance.
|Standard persistent disks||SSD persistent disks||Local SSDs||Cloud Storage buckets|
|Storage type||Efficient and reliable block storage||Fast and reliable block storage||High-performance local block storage||Affordable object storage|
|Price per GB/month||$0.040 - $0.052||$0.170 - $0.221||$0.218 - $0.283||$0.007 - $0.026|
|Maximum space per instance||64 TB||64 TB||3 TB||Almost infinite|
|Scope of access||Zone||Zone||Instance||Global|
|Encryption at rest||Yes||Yes||Yes||Yes|
|Custom encryption keys||Yes||Yes||No||Yes|
|Machine type support||All machine types||All machine types||Most machine types||All machine types|
|Zone availability||All zones||All zones||All zones||All zones|
|Add a standard persistent disk||Add an SSD persistent disk||Add a local SSD||Connect a bucket|
In addition to the storage options that Google Cloud Platform provides, you can deploy alternative storage solutions on your instances.
- Create a file server or distributed file system on Compute Engine to use as a network file system with NFSv3 and SMB3 capabilities.
- Mount a RAM disk within instance memory to create a block storage volume with high throughput and low latency.
Block storage resources have different performance characteristics. Consider your storage size and performance requirements to help you determine the correct block storage type for your instances.
|Standard persistent disks||SSD persistent disks||Local SSD (SCSI)||Local SSD (NVMe)|
|Maximum sustained IOPS|
|Read IOPS per GB||0.75||30||266.7||453.3|
|Write IOPS per GB||1.5||30||186.7||240|
|Read IOPS per instance||3,000||40,000||400,000||680,000|
|Write IOPS per instance||15,000||30,000||280,000||360,000|
|Maximum sustained throughput (MB/s)|
|Read throughput per GB||0.12||0.48||1.04||1.77|
|Write throughput per GB||0.12||0.48||0.73||0.94|
|Read throughput per instance||180||800||1,560||2,650|
|Write throughput per instance||120||400||1,090||1,400|
Persistent disks (Standard and SSD)
Persistent disks are durable network storage devices that your instances can access like physical disks in a desktop or a server. The data on each persistent disk is distributed across several physical disks. Compute Engine manages the physical disks and the data distribution to ensure redundancy and optimize performance for you. Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD).
Persistent disks are located independently from your virtual machine instances, so you can detach or move persistent disks to keep your data even after you delete your instances. Persistent disk performance scales automatically with size, so you can resize your existing persistent disks or add more persistent disks to an instance to meet your performance and storage space requirements.
Add a persistent disk to your instance when you need reliable and affordable storage with consistent performance characteristics.
Ease of use
Compute Engine handles most disk management tasks for you so that you do not need to deal with partitioning, redundant disk arrays, or subvolume management. You can apply these practices to your persistent disks if you want, but you can save time and get the best performance if you format your persistent disks with a single file system and no partition tables. If you need to separate your data into multiple unique volumes, create additional disks rather than dividing your existing disks into multiple partitions.
Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD). Standard HDD persistent disks are efficient and economical for handling sequential read/write operations, but are not optimized to handle high rates of random input/output operations per second (IOPS). If your applications require high rates of random IOPS, use SSD persistent disks.
Compute Engine optimizes performance and scaling on persistent disks automatically. You do not need to stripe multiple disks together or pre-warm disks to get the best performance. When you need more disk space or better performance, simply resize your disks to add more storage space, throughput, and IOPS.
Performance on persistent disks is predictable and scales linearly. See Optimizing Persistent Disk and Local SSD Performance for more information about performance scaling limits and optimization.
Each persistent disk write operation contributes to the cumulative network egress traffic for your instance. This means that persistent disk write operations are capped by the network egress cap for your instance.
Persistent disks have built-in redundancy to protect your data against equipment failure and to ensure data availability through datacenter maintenance events. Checksums are calculated for all persistent disk operations so we can ensure that what you read is what you wrote.
Additionally, you can create snapshots of persistent disks to protect against data loss due to user error. Snapshots are incremental, and take only minutes to create even if you snapshot disks that are attached to running instances.
Persistent Disk Encryption
Compute Engine automatically encrypts your data before it travels outside of your instance to persistent disk storage space. Each persistent disk remains encrypted either with system-defined keys or with customer-supplied keys. Additionally, Google distributes persistent disk data across multiple physical disks in a manner that users do not control.
When you delete a persistent disk, Google discards the cipher keys, rendering the data irretrievable. This process is irreversible.
If you want to control the encryption keys that are used to encrypt your data, create your disks with your own encryption keys.
Each persistent disk can be up to 64 TB in size, so there is no need to manage arrays of disks to create large logical volumes. Each instance can attach only a limited amount of total persistent disk space and a limited number of individual persistent disks. Predefined machine types and custom machine types have the same persistent disk limits.
Most instances can have up to 64 TB of total persistent disk space attached. Shared-core machine types or custom machine types with less than 3.75 GB of memory are limited to 3 TB of total persistent disk space. Total persistent disk space for an instance includes the size of the root persistent disk.
You can attach up to 16 independent persistent disks to most instances, but instances with shared-core machine types or custom machine types with less than 3.75 GB of memory are limited to a maximum of 4 persistent disks.
Increased persistent disk limits
Attaching more than 16 persistent disks is available as a Beta feature. You can attach up to 128 persistent disks to instances with predefined machine types depending on the number of vCPUs in that instance. Instances with custom machine types are still limited to 16 disk volumes per instance.
|Number of vCPUs||Disk number limit|
|1 vCPU||32 disks|
|2-4 vCPUs||64 disks|
|8 or more vCPUs||128 disks|
Local SSDs are physically attached to the server that hosts your virtual machine instance. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks. The data that you store on a local SSD persists only until you stop or delete the instance. Each local SSD is 375 GB in size, but you can attach up to eight local SSD devices for 3 TB of total local SSD storage space per instance.
Create an instance with local SSDs when you need a fast scratch disk or cache and do not want to use instance memory. Also use local SSDs when your workload itself is replicated across multiple instances.
Local SSDs are designed to offer very high IOPS and low latency. Unlike persistent disks, you must manage the striping on local SSDs yourself. Combine multiple local SSD devices into a single logical volume to achieve the best local SSD performance per instance, or format local SSD devices individually.
Local SSD performance depends heavily on which interface you select. Local SSDs are available through both SCSI and NVMe interfaces. If you choose to use NVMe, you must use a special NVMe-enabled image to achieve the best performance. For more information, see Choosing a disk interface type.
Local SSD Encryption
Compute Engine automatically encrypts your data before it travels outside of your instance to local SSD storage space. You cannot use custom encryption keys with local SSDs.
Data persistence on local SSDs
Data on local SSDs persists as long as your instance exists and continues to run. Data persists on local SSDs if you restart your instance, but not if you stop your instance.
Data on your local SSDs persists through live migration events. If Compute Engine migrates an instance with a local SSD, Compute Engine copies data from your local SSD to the new instance with only a short period of decreased performance.
You can create instances with up to eight 375 GB local SSD partitions for 3 TB of local SSD space for each instance. However, instances are limited to only four partitions for 1.5 TB of total SSD space in the following zones:
Performance for local SSDs scales up until you reach a total Local SSD storage space of 1.5 TB. Beyond 1.5 TB, throughput and IOPS does not increase.
Instances with shared-core machine types cannot attach any local SSD devices.
Google Cloud Storage buckets
Google Cloud Storage buckets are the most flexible, scalable, and durable storage option for your virtual machine instances. If your applications do not require the lower latency of persistent disks and local SSDs, you can store your data in a Cloud Storage bucket.
Connect your instance to a Cloud Storage bucket when latency and throughput are not a priority and when you must share data easily between multiple instances or zones.
The performance of Cloud Storage buckets depends on the storage class that you select and the location of the bucket relative to your instance.
The Regional Storage class has performance that is comparable to persistent disks but with higher latency and less consistent throughput characteristics. The Multi-Regional Storage class stores your data redundantly across at least two regions within a larger multi-regional location.
Nearline and Coldline Storage classes are primarily for long-term data archival. Unlike the Regional and Multi-Regional Storage classes, these archival classes have minimum storage durations and read charges. Consequently, they are best for long-term storage of infrequently-accessed data.
All Cloud Storage buckets have built-in redundancy to protect your data against equipment failure and to ensure data availability through datacenter maintenance events. Checksums are calculated for all Cloud Storage operations so we can ensure that what you read is what you wrote.
Unlike persistent disks, Cloud Storage buckets are not restricted to the zone where your instance is located. Additionally, you can read and write data to a bucket from multiple instances simultaneously. For example, you can configure instances in multiple zones to read and write data in the same bucket rather than replicate the data to persistent disks in multiple zones.
Furthermore, you can mount a Cloud Storage bucket to your instance as a file system. Mounted buckets function similarly to a persistent disk when you read or write files. However, Cloud Storage buckets are object stores that do not have the same write constraints like a POSIX file system and cannot be used as root disks. Your instance can write data to a file and overwrite critical data from other instances that are also writing data to the storage object simultaneously.
Cloud Storage Encryption
Compute Engine automatically encrypts your data before it travels outside of your instance to Cloud Storage buckets. You do not need to encrypt files on your instances before you write them to a bucket.
Just like persistent disks, you can encrypt buckets with your own encryption keys.