Which Workloads Are Safe to Move to Shared CPU?

As cloud costs continue to rise and teams seek efficient ways to balance performance and budget, one common question arises: which workloads are safe to move to shared CPU? At face value, shared CPU instances offer compelling cost benefits over dedicated ones. But blindly moving workloads to shared CPU without understanding the nuances can backfire, causing unplanned spikes, throttling, or degraded user experience.

In this deep-dive, we’ll explore:

What “shared CPU” means across major cloud providers
How to identify good candidates for shared CPU based on proper observation windows
Why averages lie and percentiles matter in deciding instance types
Leveraging tools like AWS Compute Optimizer and Azure Advisor for smarter sizing

Understanding Shared CPU: What Does It Actually Mean?

The term shared CPU covers a spectrum of instance offerings across cloud providers. To make safe workload migration decisions, you must understand how each provider defines “shared.”

AWS Burstable Instances (T Series)

AWS burstable performance instances (T2, T3, T4g) provide a baseline CPU that can be exceeded temporarily via CPU credits. When credits run out, CPU usage is throttled to baseline level, impacting peak workloads.

Baseline CPU% depends on instance size, typically between 10% and 40%
CPU credits accrue during low usage and are spent during bursts
Performance drops to baseline once credits are exhausted

Azure Burstable VMs (B Series)

Azure B-series VMs accumulate credits when idle and burst up to 100% CPU when needed. When credits are exhausted, the VM is throttled rightsizing kubernetes nodes to baseline.

Baseline performance varies with VM size
CPU credits accrue and are consumed similarly to AWS T series
Throttling affects sustained CPU-intensive tasks

Google Cloud Shared-Core VMs

Google Cloud offers shared-core machine types like f1-micro and g1-small, where a single vCPU is shared among multiple tenants. Unlike burstable credits, these typically do not guarantee full-core availability.

CPU is shared with noisy-neighbor risk
No burst credits; performance depends entirely on congestion

Common Misconceptions About Shared CPU Workloads

Shared CPU is often considered a “less reliable” or “slower” option purely because the CPU is shared or there is a burst balance that can be exhausted. However, some myths obscure the truth:

Myth: vCPU count equals performance guarantee. Shared CPU vCPUs do not have consistent access to a full core.
Myth: average CPU utilization dictates sizing. Average CPU hides spikes that cause throttling or latency.
Myth: shared CPU means poor uptime. Shared CPU does not directly correlate with network or disk uptime; some shared-core VMs run reliably in production.

Measure Peaks With the Right Observation Window

Your initial step before migration should be data-driven workload characterization. Here, it’s critical to ask:

What do the P95 and P99 CPU utilization metrics look like? Peaks matter more than averages.
How long do CPU spikes last? Are these short bursts that fit within credit limits, or sustained loads?
Is the workload latency-sensitive during these spikes? Impact on user experience or SLAs is non-negotiable.

Many teams make the mistake of sizing based on a 30-day average CPU usage. This misleads capacity decisions because short CPU bursts, even if rare (P99), cause throttling and performance degradation on shared CPU instances.

Example: Monitoring Window Impact

Metric 1-Minute Window 15-Minute Window 1-Hour Window P99 CPU Utilization 85% 60% 40% Average CPU Utilization 25% 22% 20%

Here, the 1-minute P99 spikes up to 85%, showing significant burst demand that averages smooth over. Short windows reveal spikes critical to sizing.

Which Workloads Are Safety Candidates for Shared CPU?

After collecting and analyzing peak utilization data, you can shortlist workloads that fit into shared CPU instance profiles. Safe candidates generally share these traits:

Intermittent or Low-Compute Baseline: Workloads mostly idle or lightly loaded, with infrequent CPU bursts that fit within credit budgets.
Short, Rare Spikes: CPU-intensive operations happen briefly and infrequently, not sustained beyond the burst window.
Non-Latency-Critical: Some performance degradation during CPU throttling windows is acceptable and won’t impact SLAs.
Resilient or Stateless: Services can be retried or scaled horizontally to mask throttling effects.

Examples of Good Shared CPU Workloads

Low-traffic internal web applications or dashboards
Development, staging, or test environments
Batch jobs with flexible deadlines and bursty CPU patterns
Background workers that process messages irregularly
Lightweight microservices with built-in queueing

Examples of Workloads to Avoid on Shared CPU

Production databases or data stores
Continuous real-time processing services with high CPU demand
Low-latency APIs or user-facing frontends that require predictable response times
Workloads with sustained CPU usage beyond burst capacity

Leveraging AWS Compute Optimizer and Azure Advisor for Right-Sizing

Manual analysis of usage alone isn’t scalable for entire fleets. Cloud providers provide native tools that analyze workload metrics and provide recommendations:

https://dibz.me/blog/what-should-i-measure-besides-cpu-for-a-shared-cpu-migration-1253

AWS Compute Optimizer

Analyzes EC2, EBS, Lambda, and Auto Scaling groups
Recommends instance types including burstable candidates based on usage profiles
Use Compute Optimizer insights to find “burstable VM candidates” that match your workloads
Provides percentile CPU and memory utilization patterns, not just averages

Azure Advisor

Intelligent recommendations across cost, security, availability
Suggests VM resizing including burstable B series when appropriate
Includes historical performance insights factoring P95 and P99 CPU utilization
Highlights VMs with wasted capacity or idle CPUs suitable for shared CPU migration

Rollback Criteria and Pilot Testing

Before committing to a full fleet migration to shared CPU:

Define rollback criteria informed by latency, error rates, and user impact metrics.
Run a pilot with representative workloads and monitor P95/P99 CPU, response times, and throttling event counts.
Have alerting on throttling or saturation that triggers automatic rollback to dedicated CPU.
Observe spike durations — if bursts regularly outlast credit replenishment, rollback.

This approach prevents costly surprises, downtimes, and wasted engineering hours.

Summary Table: Deciding Factors for Shared CPU Migration

Criteria Key Question Ideal for Shared CPU? CPU Utilization Pattern Are CPU spikes short and below credit limits? Yes Latency Sensitivity Can some throttling-induced latency be tolerated? Yes Workload Type Is it stateless, batch, or low-traffic? Yes SLA and Availability Critical uptime required? No (prefer dedicated CPU) Duration of High CPU Are spikes longer than burst credits? No

Conclusion

Moving workloads to shared CPU instances is a cost-saving lever—but only when done with data-backed confidence. Understanding cloud provider-specific shared CPU semantics, focusing on P95 and P99 utilization rather than averages, and using native tools like AWS Compute Optimizer and Azure Advisor can help you find the right "burstable VM candidates." Always include careful pilot testing and rollback criteria to avoid performance pitfalls.

Finally, remember: always-on small services hiding in the shadow of cloud waste can be optimized—but only with proper metrics and observation windows guiding the way.

With this framework, you can safely leverage shared CPU instances and reduce costs without compromising your critical workload performance.