How Do I Compare Shared CPU Models Across Google, AWS, and Azure?

In the era of cloud-native applications, cost efficiency is a top priority alongside reliable performance. When running always-on small services — think microservices, internal tooling, or lightweight worker queues — organizations often lean on fractional CPU or shared CPU virtual machine models to save costs. However, comparing these shared CPU models across the three Click for more info leading cloud providers — Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure — can be deceptively complex.

This post dives deep into the nitty-gritty of fractional CPU vs credits, the nuances of provider differences in CPU sharing, and how to establish a proper performance baseline. We’ll examine why averages lie, highlight the importance of measuring peak CPU utilization with the right observation windows, discuss meaningful percentiles like P95 and P99, and share how to interpret insights from AWS Compute Optimizer and Azure Advisor.

Understanding Shared CPU Models: Fractional CPU vs Credits

The term “shared CPU” aggregates several different technical implementations of fractional CPU provisioning. Fundamentally, a shared CPU instance is a VM type designed to provide a baseline level of CPU performance suited for low or intermittent utilization workloads, with the ability to borrow additional CPU resources temporarily.

Credit-Based CPU Models (AWS and Google)

Both AWS and Google Cloud use credit-based bursting models for their shared CPU offerings. In this paradigm:

The VM earns CPU credits when operating below a baseline CPU utilization.
When the workload demands more CPU, the instance consumes these credits to burst above its baseline.
Once credits are exhausted, the CPU is throttled to baseline levels.

AWS offers T-series instances (t4g, t3, t3a, etc.). The instance accumulates credits per vCPU roughly proportional to a baseline percentage of CPU usage. Credits can be consumed within a window to allow bursts, ensuring that workloads running below baseline “bank” credits for future use.

Google Cloud provides similar burstable VM types like the e2-micro and f1-micro with their own credit models. The concept is alike: earn credits at low usage and spend them to burst.

Fractional CPU Models (Azure)

Azure diverges by offering instance types with only fractional, fractionalized vCPUs outright, without a credit system. For example, the B-series shares physical CPU between multiple VMs, but the documentation doesn’t emphasize explicit "credits" as a first-class concept like AWS and Google.

This means Azure’s baseline fractional CPU allocation and bursting policies can seem more opaque because Microsoft doesn’t expose credit accounting as transparently.

Provider Differences: CPU Sharing is Not One-Size-Fits-All

It’s crucial to understand the architectural and operational differences in CPU sharing, as imprecise assumptions lead to wrong choices and wasted cloud spend.

Feature AWS T-Series Google Burstable VMs Azure B-Series CPU Sharing Model Credit-based bursting per vCPU Credit-based bursting per vCPU Fractional CPU allocation without exposed credits Visible Credit Tracking Yes, detailed CPU credit balance metrics Yes, viewable credit usage in Stackdriver No explicit credit tracking Baseline CPU % Explicit; e.g., t3.nano baseline ~ 5% Explicit per instance type Implicit, documented roughly Burst Duration Limits Dependent on credit balance Dependent on credit balance Guidance varies; less clear thresholds Typical Use Cases Low-traffic web, dev/test, small microservices Similar to AWS burstable VMs Lightweight apps, low baseline loads Cost Savings Approach Pay for baseline + burst via credits Similar to AWS Pay for fractional CPU allocation

Another key provider difference lies in physical CPU oversubscription and hyperthreading decisions that directly impact latency under load. For example, AWS’s Graviton-based T4g instances deliver different performance characteristics compared to Intel CPUs on Azure’s B-series.

Why Averages Lie: Measure Peaks With the Right Observation Window

A common pitfall when evaluating shared CPU models is relying on average CPU utilization, which hides the critical performance spikes that cause throttling or latency outliers.

Shared CPU models rely on a performance baseline and allow bursts that consume credits or run above baseline for short durations. If a workload’s CPU consumption exceeds the baseline for sustained periods, performance degradation or throttling is inevitable.

Why Look at Percentiles?

Percentile-based metrics like the 95th (P95) and 99th (P99) give insight into tail-end CPU demand:

P95: CPU usage level exceeded only 5% of the time.
P99: CPU usage level exceeded only 1% of the time.

These help identify short, intense CPU consumption spikes which average metrics can hide.

Duration of Spikes Matters

Equally important is the duration, or length of CPU spikes. For example, a 10-second CPU spike at 100% over baseline might be sustainable, borrowing from credits or fractional allocations. However, a 10-minute spike will rapidly drain credits, leading to throttling.

Defining Your Observation Window

Select the right time window for CPU utilization metrics to detect bursts:

Short windows (e.g., 1-minute averages) catch very transient spikes but are volatile.
Medium windows (like 5 minutes) smooth transient noise while revealing burst patterns.
Longer windows (~30 minutes to 1 hour) can mask bursts, making instances seem underutilized.

Typically, a combination of 1-minute and 5-minute windows, combined with percentiles, gives a clear picture of burst behavior.

Leveraging AWS Compute Optimizer and Azure Advisor

Cloud providers offer tools to analyze and optimize VM usage in ways that incorporate insights about shared CPU and resource utilization.

AWS Compute Optimizer

AWS Compute Optimizer analyzes historical utilization—including CPU, memory, and networking—to recommend appropriate instance types, including burstable types like T3 or T4g. It uses:

Peak and average CPU utilization over recent weeks
Credit balance metrics tracking burst usage
Application of thresholds tuned for workload patterns

It flags when workloads are exceeding baseline regularly, allowing you to decide between buying larger fixed CPU instances or adjusting architectures.

Azure Advisor

Azure Advisor offers VM right-sizing recommendations based on CPU and memory utilization, but it doesn’t explicitly track “credit” consumption as AWS does. Instead, it looks at:

Peak and average CPU
Memory pressure
General VM health signals

Because Azure’s fractional CPU models are less transparent, you’ll need to manually correlate VM SKU documentation with application performance metrics.

Practical Recommendations: What Worked for Me

Start With P95 and P99 CPU Usage on Short Windows: Before touching any instance types, gather CPU utilization percentiles with 1-5 minute granularity. This reveals bursts threatening baseline throttling.
Don’t Assume vCPU Count Equals Performance: Distinguish between physical cores, hyperthreads, and CPU credit models. A shared vCPU with bursting can outperform a static fractional vCPU in short bursts but may degrade under sustained load.
Use Provider Monitoring Tools to Track Credit Balances: For AWS T-series and GCP burstables, monitor CPU credit metrics tightly. Azure users may need custom scripts or logs.
Document Rollback Criteria Before Pilots: If moving from fixed CPUs to burstable/shared CPU, define clear criteria for failure such as repeated throttling, elevated latencies, or error rates.
Avoid Always-On Tiny Instances for Critical Components: Small shared CPU VMs are great for ephemeral, low-cost workloads but hide cost waste when used for heavy always-on services without burst resets.
Combine CPU Metrics With Application Metrics: CPU throttling affects response times and queue lengths. Correlate infrastructure metrics with business-level KPIs.
Incorporate Storage and Egress Costs: Compute alone isn’t the full story. Low CPU cost but heavy I/O or networking fees can quickly negate savings.

Summary

Comparing shared CPU models across Google, AWS, and Azure is less about raw CPU numbers and more about understanding how each provider implements bursting or fractional resource allocation. The nuanced differences in credit systems, CPU baselines, and bursting mechanisms dramatically impact performance under load and overall cloud cost efficiency.

To make informed decisions:

Measure CPU utilization at P95 and P99 with appropriate observation windows.
Don’t rely on averages; spikes and their durations dictate performance bottlenecks.
Use AWS Compute Optimizer and Azure Advisor as starting points, but complement with custom monitoring.
Align fractional CPU usage with real application performance to validate platform choices.

Ultimately, making shared CPU decisions without understanding these complexities risks hidden throttling, increased latency, and un-expected cloud waste.

Have you recently navigated burstable CPU or fractional instance migration? I’m always keen to hear what P95 and P99 metrics told you before and after. Drop your stories or questions in the comments!