1. Overview
   1. Zonal standard persistent disk and zonal SSD persistent disk is an efficient, reliable block storage
   2. Regional standard persistent disk and regional SSD persistent disk is regional block storage replicated in two zones
   3. Local SSD is high performance, transient, local block storage
   4. Cloud Storage buckets are affordable object storage
   5. Filestore is a high performance file storage for Google Cloud users
   6. By default, each Compute Engine instance has a single boot-persistent disk that contains the operating system
   7. Block storage resources have different performance characteristics
   8. Consider storage size and performance requirements to determine the correct block storage type for instances
   9. Persistent disk IOPS and throughput performance depends on disk size, instance vCPU count, and I/O block size, among other factors
   10. Persistent disks can achieve greater throughput performance on instances with more vCPUs
2. Zonal disks
   1. Zonal disks
      1. Persistent disks are durable network storage devices that instances can access like physical disks in a desktop or a server
      2. The data on each persistent disk is distributed across several physical disks
      3. Compute Engine manages the physical disks and the data distribution to ensure redundancy and optimal performance
      4. Standard persistent disks are backed by standard hard disk drives (HDD)
      5. SSD persistent disks are backed by solid-state drives (SSD)
      6. Persistent disks are located independently from virtual machine (VM) instances, so can be detached or moved to keep data even after instances are deleted
      7. Persistent disk performance scales automatically with size
      8. Existing persistent disks can be resized or more persistent disks added to an instance to meet performance and storage space requirements
      9. Add a persistent disk to an instance when reliable and affordable storage with consistent performance characteristics is needed
   2. Ease of Use
      1. Compute Engine handles most disk management tasks, so no need to deal with partitioning, redundant disk arrays, or subvolume management
      2. No need to create larger logical volumes
      3. Secondary attached persistent disk capacity can be extended to 257 TB per instance
      4. Save time and get the best performance by formatting persistent disks with a single file system and no partition tables
      5. To separate data into multiple unique volumes, create additional disks rather than dividing existing disks into multiple partitions
      6. Resize persistent disks for additional space, and resize single file system rather than repartitioning and formatting
   3. Performance
      1. Persistent disk performance is predictable and scales linearly with provisioned capacity until the limits for an instance's provisioned vCPUs are reached
      2. Standard persistent disks are efficient and economical for handling sequential read/write operations, but they aren't optimized to handle high rates of random input/output operations per second (IOPS)
      3. Where apps require high rates of random IOPS, use SSD persistent disks
      4. SSD persistent disks are designed for single-digit millisecond latencies
      5. Observed latency is application specific
      6. Compute Engine optimizes performance and scaling on persistent disks automatically
      7. No need to stripe multiple disks together or pre-warm disks to get the best performance
      8. For more disk space or better performance, resize disks and possibly add more vCPUs to add more storage space, throughput, and IOPS
      9. Persistent disk performance is based on the total persistent disk capacity attached to an instance and the number of vCPUs that the instance has
      10. For boot devices, reduce costs by using a standard persistent disk
      11. Small, 10-GB persistent disks can work for basic boot and package management use cases
      12. To ensure consistent performance for more general use of the boot device, use either an SSD persistent disk as boot disk or use a standard persistent disk that is at least 200 GB in size
      13. Each persistent disk write operation contributes to the cumulative network egress traffic for the instance
      14. This means that persistent disk write operations are capped by the network egress cap for the instance
   4. Reliability
      1. Persistent disks have built-in redundancy to protect data against equipment failure and to ensure data availability through datacenter maintenance events
      2. Checksums are calculated for all persistent disk operations, to ensure that what is read is what was written
      3. Create snapshots of persistent disks to protect against data loss due to user error
      4. Snapshots are incremental, and take only minutes to create, even for snapshot disks that are attached to running instances
   5. Persistent disk encryption
      1. Compute Engine automatically encrypts data before it travels outside of instance to persistent disk storage space
      2. Each persistent disk remains encrypted either with system-defined keys or with customer-supplied keys
      3. Google distributes persistent disk data across multiple physical disks in a manner that users do not control
      4. When a persistent disk is deleted, Google discards the cipher keys, rendering the data irretrievable. This process is irreversible
      5. To control the encryption keys that are used to encrypt data, create disks with own encryption keys
   6. Limits
      1. Users cannot attach a persistent disk to an instance in another project
      2. Each instance can attach only a limited amount of total persistent disk space and a limited number of individual persistent disks
      3. Predefined machine types and custom machine types have the same persistent disk limits
3. Regional disk
   1. Regional disk
      1. Regional persistent disks have storage qualities that are similar to zonal persistent disks (standard and SSD)
      2. Regional persistent disks provide durable storage and replication of data between two zones in the same region
      3. If designing robust systems on Compute Engine, consider using regional persistent disks to maintain high availability for resources across multiple zones
      4. Regional persistent disks provide synchronous replication for workloads that might not have application-level replication
      5. Regional persistent disks are designed for workloads that require redundancy across multiple zones with failover capabilities.
      6. Regional persistent disks are also designed to work with regional managed instance groups
      7. Regional persistent disks are an option for high performance databases and enterprise apps that also require high availability
      8. In the unlikely event of a zonal outage, running workload can failover on regional persistent disks to another zone using the force-attach command
      9. The force-attach command attaches the regional persistent disk to a standby VM instance even if the disk can't be detached from the original VM due to its unavailability
      10. If both replicas are available, a write is acknowledged back to a VM when it is durably persisted in both replicas
      11. If one of the replicas is unavailable, a write is acknowledged after it is durably persisted in the healthy replica
      12. When the unhealthy replica is back up (as detected by Compute Engine), then it is transparently brought in sync with the healthy replica, and the fully synchronous mode of operation resumes
      13. This operation is transparent to a VM
      14. In the rare event that both replicas become unavailable at the same time, or the healthy replica becomes unavailable while another one is being brought into sync, the corresponding disk becomes unavailable
   2. Performance
      1. Regional persistent disks are designed for workloads that require a lower Recovery Point Objective (RPO) and Recovery Time Objective (RTO) compared to using persistent disk snapshots
      2. Regional persistent disks are an option when write performance is less critical than data redundancy across multiple zones
      3. Like standard persistent disks, regional persistent disks can achieve greater IOPS and throughput performance on instances with a greater number of vCPUs
      4. When more disk space or better performance is needed, resize regional disks to add more storage space, throughput, and IOPS
   3. Reliability
      1. Compute Engine replicates data of regional persistent disk to the zones selected when disks are created
      2. The data of each replica is spread across multiple physical machines within the zone to ensure redundancy
      3. Similar to regular persistent disks, users can create snapshots of persistent disks to protect against data loss due to user error
      4. Snapshots are incremental, and take only minutes to create even if snapshot disks are attached to running instances
   4. Limits
      1. Regional persistent disk limits are similar to zonal persistent disks
      2. Regional standard persistent disks have a 200-GB size minimum
      3. Regional persistent disks cannot be used with memory-optimized machines and compute-optimized machines
4. Local disk
   1. Local disk
      1. Local SSDs are physically attached to the server that hosts the VM instance
      2. Local SSDs have higher throughput and lower latency than standard persistent disks or SSD persistent disks
      3. The data stored on a local SSD persists only until the instance is stopped or deleted
      4. The performance gains from local SSDs require certain trade-offs in availability, durability, and flexibility
      5. Because of these trade-offs, Local SSD storage isn't automatically replicated and all data on the local SSD might be lost if the instance terminates for any reason
   2. Performance
      1. Local SSDs are designed to offer very high OPS and low latency
      2. Unlike persistent disks, users must manage the striping on local SSDs
      3. Combine multiple local SSD partitions into a single logical volume to achieve the best local SSD performance per instance, or format local SSD partitions individually
      4. Local SSD performance depends on the interface selected
      5. Local SSDs are available through both SCSI and NVMe interfaces
      6. Must use a NVMe-enabled image with the NVMe interface to achieve the best performance
   3. Local SSD encryption
      1. Compute Engine automatically encrypts data when it is written to local SSD storage space
      2. Customer-supplied encryption keys cannot be used with local SSDs
   4. Local SSDs and machine type
      1. Instances with shared-core machine types can't attach any local SSD partitions
      2. Local SSDs can be attached to most machine types available on Compute Engine
      3. To reach the maximum IOPS limits, use a VM instance with 32 or more vCPUs
      4. There are constraints around how many local SSDs can be attached based on each machine type
   5. Local SSDs and preemptible VM instances
      1. Start a preemptible VM instance with a local SSD and Compute Engine charges preemptible prices for the local SSD usage
      2. Local SSDs attached to preemptible instances work like normal local SSDs, retain the same data persistence characteristics, and remain attached for the life of the instance
      3. Request a separate quota for preemptible local SSDs, or choose to use regular local SSD quota when creating preemptible local SSDs
      4. Compute Engine doesn't charge for local SSDs if their instances are preempted in the first minute after they start running
      5. Reservations are required for committed-use pricing for Local SSDs.
5. Bucket
   1. Bucket
      1. Cloud Storage buckets are the most flexible, scalable, and durable storage option for VM instances
      2. If apps don't require the lower latency of Persistent Disks and Local SSDs, store data in a Cloud Storage bucket
      3. Connect instance to a Cloud Storage bucket when data must be shared easily between multiple instances or zones
   2. Performance
      1. The performance of Cloud Storage buckets depends on the storage class that is selected, and the location of the bucket relative to instance
      2. The standard storage class used in the same location as instance gives performance that is comparable to persistent disks but with higher latency and less consistent throughput characteristics
      3. The standard storage class used in a multiregional location stores data redundantly across at least two regions within a larger multiregional location
      4. Nearline and coldline storage classes are primarily for long-term data archival
      5. Unlike the standard storage class, these archival classes have minimum storage durations and read charges
      6. They are best for long-term storage of data that is accessed infrequently
   3. Reliability
      1. All Cloud Storage buckets have built-in redundancy to protect data against equipment failure and to ensure data availability through datacenter maintenance events
      2. Checksums are calculated for all Cloud Storage operations to help ensure that what is read is what was written
   4. Flexibility
      1. Unlike persistent disks, Cloud Storage buckets aren't restricted to the zone where the instance is located
      2. Data can be read and written to a bucket from multiple instances simultaneously
      3. Cloud Storage bucket can be mounted to instances as a file system
      4. Mounted buckets function similarly to a persistent disk when files are read or written
      5. Cloud Storage buckets are object stores that don't have the same write constraints as a POSIX file system and can't be used as boot disks
      6. Instance can write data to a file and overwrite critical data from other instances that are also writing data to the storage object simultaneously
   5. Cloud Storage encryption
      1. Compute Engine automatically encrypts data before it travels outside of instance to Cloud Storage buckets
      2. Users don't need to encrypt files on instances before writing them to a bucket
      3. Just like persistent disks, users can encrypt buckets with their own encryption keys