Sizing Compute, Storage and Autoscaling for Workloads

Determining storage and data throughput requirements means matching a workload to the right Google Cloud storage based on IOPS, throughput, latency, durability, and cost. IOPS measures how many small read and write operations a volume can handle per second, while throughput measures how much data moves per second for larger transfers. Latency measures how quickly each operation completes, which depends on both the storage type and the region where data lives relative to users and compute.

1.1Block Storage for Virtual Machines with Persistent Disk and Hyperdisk

Block storage for virtual machines is durable storage attached to a Compute Engine instance that persists even when the instance stops. Persistent Disk (opens in a new tab) provides zonal volumes that live in one zone and regional Persistent Disk volumes (opens in a new tab) that replicate data synchronously across two zones in the same region. Data in Persistent Disk volumes is not replicated across regions, so regional Persistent Disk protects against a zone outage but not a region outage.

Google Cloud Hyperdisk (Hyperdisk) provides better performance, flexibility, and efficiency than Persistent Disk for boot and data volumes. Hyperdisk Balanced lets you provision IOPS and throughput separately and change them dynamically, so you can tune the volume without overprovisioning both together. Hyperdisk Extreme provides higher maximum IOPS and throughput than SSD Persistent Disk, which makes it the choice when a database or high-performance workload needs more headroom. Standard Persistent Disk uses hard-disk technology for low-cost sequential work, while SSD Persistent Disk uses solid-state technology for higher IOPS and lower latency.

1.2Ordered Decision for Choosing Block Storage

Choosing block storage follows durability first, then platform support, then performance tuning. This order matters because temporary storage cannot protect data that must survive, and Hyperdisk cannot be used where the machine series does not support it. The documented decision order is:

1. Determine whether you need durable or temporary block storage: the boot volume for a compute instance must use durable block storage.
2. Use temporary storage when possible: if you need temporary block storage, use Local SSD if Local SSD is available for your machine series.
3. Select the durable family: if you need durable storage, use Hyperdisk if it is available for your machine series, and use Persistent Disk if your machine series does not support Hyperdisk.
4. Choose the specific disk type: choose the Hyperdisk or Persistent Disk type that best suits your workload, such as Balanced for tunable IOPS and throughput or Extreme for maximum performance.

Beyond attached disks, you can create a file server on Compute Engine for NFSv3 and SMB3 sharing or mount a RAM disk inside VM memory for high throughput and low latency. Traffic flows from the application to the RAM disk in memory, but the RAM disk loses data when the VM stops, so it fits temporary scratch and caching rather than durable primary storage.

1.3Object Storage with Cloud Storage Classes

Cloud Storage is consistent, scalable, large-capacity object storage for files, backups, images, and other unstructured data. Data in regional buckets is replicated synchronously across zones in the region, which keeps reads and writes low-latency within that region. Data in dual-region or multi-region buckets is stored redundantly in at least two separate geographic locations, where metadata is written synchronously across regions and data is replicated asynchronously.

For dual-region buckets, turbo replication ensures objects replicate across the region pair with a recovery point objective (RPO) of 15 minutes. This RPO defines how much recent data could be lost if a region fails, so turbo replication fits workloads that need faster cross-region durability than default asynchronous replication. Choose regional buckets when low latency in one region matters most, and choose dual-region or multi-region buckets when replicated storage across locations matters more.

Cloud Storage classes separate data by how often it is accessed:

Placing hot data in Archive raises retrieval cost and delay, while placing cold data in Standard wastes money, so match the class to actual access frequency.

1.4Shared File Storage for Multiple Virtual Machines

Shared file storage for multiple virtual machines is a file system that many Compute Engine VMs can mount at the same time. Filestore is high-performance, fully managed NFS file storage where data in a regional instance is replicated synchronously across three zones in the region. This synchronous replication across three zones keeps the file share available through a zone outage, and you can replicate a Filestore instance to a different region for protection against a region outage.

A Filestore regional instance fits data shared across a web tier or application tier because one mount serves many clients with the same files. Common shared contents include:

• Shared configuration files used by every VM in the tier
• Common tools and utilities installed once and run everywhere
• Centralized logs collected from multiple VMs

Google Cloud NetApp Volumes is fully managed NFS and SMB file storage for workloads with strict availability needs. If a Microsoft SQL Server failover cluster instance needs operating system access, NetApp Volumes provides continuous availability (CA) SMB storage for the database. Choose Filestore when Linux VMs need shared NFS access, and choose NetApp Volumes when Windows failover clustering needs continuously available SMB storage.

Evaluating compute and memory configurations is the process of matching virtual machine size to workload needs for performance, scalability, and cost-efficiency. In Compute Engine (opens in a new tab), this means selecting a predefined machine type or building a custom machine type, using utilization recommendations to right-size VMs, and choosing a provisioning model such as Spot VMs when savings outweigh availability needs. The VM multithreading setting further tunes how virtual CPUs map to physical cores for specialized workloads.

2.1Choosing Machine Types for Workload Profiles

Choosing a machine type means selecting the balance of virtual CPUs (vCPUs) and memory that fits the performance requirements of a workload tier. Compute Engine offers predefined families for general-purpose, memory-optimized, and compute-optimized profiles, plus customizable sizes for exact needs. For example, a machine type in the C4 machine series from the general-purpose family provides consistently high performance for database workloads, while web and application tiers use types matched to their own throughput and latency needs. The choice also affects networking because the per-VM limit for egress network bandwidth depends on the machine type and whether traffic stays in the same Virtual Private Cloud (VPC) network.

2.2Custom Machine Types for Predictable Workloads

Custom machine types are VMs where vCPUs and memory are sized independently instead of using a fixed predefined ratio. A custom machine type is useful when workload requirements are predictable and fall between predefined sizes, because resources can be tailored to actual needs to avoid paying for unused capacity. Extended memory options allow more memory per core without adding unneeded vCPUs, which also helps control third-party software costs that are licensed per CPU core. Use a custom machine type when monitoring shows steady CPU and memory use that does not align well with any predefined machine type.

2.3Right-Sizing with Machine Type Recommendations

Machine type recommendations are automated suggestions in Compute Engine that help optimize resource utilization of existing VM instances. The recommendation engine observes actual CPU and memory use and suggests a machine type that more closely matches the workload compute requirements. Applying these recommendations prevents overprovisioning large VMs that sit idle and underprovisioning small VMs that become bottlenecks. Review recommendations regularly after deployment, then move steady workloads to a better-fitting predefined type or to a custom machine type.

2.4Spot VMs to Balance Cost and Availability

Spot VMs are Compute Engine VMs offered at significantly lower cost than regular VMs in exchange for lower availability. A Spot VM uses the same machine types, options, and performance as a regular VM, but Compute Engine can preemptively stop or delete the Spot VM to reclaim capacity when resources are needed elsewhere. Traffic flows from the managed instance group (MIG) controller to Spot VM instances, so the MIG depends on available spare capacity to create or replace those instances during scale-out.

When zone capacity is limited, a MIG that depends on Spot VMs might not scale out to its target size until capacity becomes available again. Choose Spot VMs for fault-tolerant application and web tiers and for batch processing without high availability requirements.

2.5Configuring Virtual CPUs and Multithreading

VM multithreading controls how vCPUs map to physical processor cores on the host machine. Each vCPU allocated to a Compute Engine VM is implemented as a single hardware multithread, and by default two vCPUs share one physical CPU core through simultaneous multithreading (SMT). For applications with highly parallel operations or floating-point calculations, such as genetic sequence analysis and financial risk modeling, performance can improve by reducing the threads per core from two to one. Reducing threads per core also changes licensing exposure for some third-party software, so check vendor rules and consider disabling SMT and using custom machine types to provision only the needed cores.

Establishing resource baselines through profiling and scaling policies is the practice of measuring how a workload consumes resources under load and using those measurements to configure automatic scaling. The baseline defines the minimum efficient capacity for normal traffic plus headroom for peaks, while the scaling policy adds and removes capacity as demand changes. In Google Cloud, baselines come from load testing and observability data, and scaling is implemented with Compute Engine managed instance groups (MIGs) (opens in a new tab), Google Kubernetes Engine (GKE), Cloud Run, and data services such as Bigtable.

3.1Profile Workloads with Load Testing and Observability

Workload profiling measures resource efficiency, which is the relationship between application load and the CPU, memory, disk I/O, and network resources the application consumes. Load testing simulates realistic traffic for normal and peak conditions, while stress testing pushes the system to its limits to reveal bottlenecks where efficiency deteriorates. Benchmarks must be repeated at regular intervals because efficiency changes as code, traffic mix, and data volume evolve.

Cloud Monitoring (opens in a new tab) provides real-time visibility into CPU utilization, memory usage, network traffic, disk I/O, application response times, and business-specific metrics. Logs show system events, errors, and warnings, while traces show how requests flow from service to service and where round-trip time grows between tiers. Code profiling identifies functions that consume excessive resources, and the results guide concrete fixes such as adjusting VM or container counts, tuning web server and database configuration, adding caching, and improving indexing and queries.

3.2Forecast Demand and Estimate Required Capacity

Capacity estimation translates a load forecast into a specific quantity of Google Cloud resources that can meet performance and reliability objectives. The forecast considers user count, request rate, historical trends, seasonal variations, spikes during special events, and growth from business changes such as expansion to new geographies. The estimate then selects the deployment shape, for example MIG size, VM machine type, and the number, type, and size of persistent disks, and the Google Cloud Pricing Calculator can estimate the cost of that shape.

A reliable estimate builds in redundancy, quotas, and assured capacity before traffic arrives:

1. Plan adequate redundancy: provide at least one redundant component beyond the minimum needed for forecast load, known as N+1 redundancy, for every tier of the stack.
2. Verify quotas: confirm that resource quotas for creatable objects and rate quotas for API requests are sufficient at zonal, regional, or global scope, and request a quota adjustment when the forecast exceeds the current limit.
3. Reserve compute capacity: create a Compute Engine reservation that assures capacity in a specific zone for a specified number of VMs of a chosen machine type, scoped to one project or shared across projects.
4. Monitor and reassess: track utilization after deployment, remove idle resources, and periodically reassess behavior, objectives, user load, and budget.

This sequence ensures that autoscaling starts from a baseline that supports failover and is permitted by project limits.

3.3Define Autoscaling Policies That Respond to Demand

An autoscaling policy defines when capacity is added during high load and removed during low load so availability stays consistent without paying for idle redundancy. Horizontal scaling, which adds instances to distribute load, is preferred for most cloud-first applications because failure of one instance does not remove the application and variable load is handled efficiently. For horizontal scaling to work seamlessly, components should be stateless, with session state stored outside the compute instance such as in Memorystore for Redis, so any instance can handle any user request.

Effective policies combine reactive scaling for unpredictable spikes with proactive scheduled scaling for predictable patterns such as daily business hours, weekly reports, and major sales events. Reactive scaling responds to real-time metric changes, while proactive scaling pre-provisions capacity before an anticipated surge to avoid a scramble for resources. Policies should use workload-specific signals instead of CPU alone, such as queue depth, request latency, and custom application metrics, and they must define clear thresholds to prevent frequent unnecessary scaling, known as flapping.

Managed Service for Apache Spark follows the same pattern for batch analytics by dynamically scaling executors and other workload resources for each submitted batch. Together these options let the baseline handle steady load while the policy absorbs fluctuation without manual resizing.

3.4Monitor Utilization and Right-Size Continuously

Continuous right-sizing keeps the baseline aligned with actual demand by matching allocation to observed usage over time. Over-provisioning creates unnecessary cost and energy use, while under-provisioning creates bottlenecks that degrade performance and user experience. Cloud Monitoring tracks usage patterns and Recommender, part of Active Assist, analyzes utilization data to recommend more efficient machine types and sizes. Custom metrics extend right-sizing to application-specific signals, with alerts that notify administrators when thresholds are met so allocation can be adjusted promptly. Dashboards, reports, and cost analysis by tags and labels reveal high-use resources, idle capacity, and spending trends that guide the next baseline revision.

Key Facts

• Regional Persistent Disk replicates data synchronously across two zones in the same region but not across regions, while Hyperdisk Balanced allows IOPS and throughput to be provisioned separately.
• Dual-region Cloud Storage with turbo replication provides a 15-minute recovery point objective for cross-region replication.
• Spot VMs use the same machine types and performance as regular VMs at significantly lower cost but can be preemptively stopped or deleted to reclaim capacity.
• Horizontal scaling with stateless components is preferred for cloud-first applications, with session state stored outside the compute instance such as in Memorystore for Redis.
• N+1 redundancy provides at least one redundant component beyond the minimum needed for forecast load in every tier of the stack.