Metal Compute Calculator

Calculator

Cloud environments like AWS EKS operate on shared infrastructure. When you’re told you have 2426 vCPUs, you aren’t guaranteed full access to those resources all the time. Due to noisy neighbors, overcommit, and shared tenancy, sustained usage is often far lower (30–50%). Likewise, RAM allocations are not always 100% available or consistent.

In contrast, QBO metal nodes are fully dedicated, meaning compute and memory availability is stable and predictable. Additionally, because metal eliminates hypervisor overhead, workloads are 20–30% more efficient, needing fewer total cores to achieve the same performance.

This calculator translates your claimed vCPU and RAM allocations in a shared cloud environment into the equivalent number of dedicated QBO metal nodes. It accounts for actual usage, efficiency gains on bare metal, and the capacity of your chosen hardware to provide a realistic comparison.

Claimed vCPUs (EKS)

These are virtual CPUs reported in AWS EKS. They are shared across tenants and not always available 100% of the time.

Claimed RAM (GB) (EKS)

The RAM allocated in the cloud, subject to variability and sharing.

Average CPU Utilization (%)

Estimate of how much CPU is actually being used over time (e.g. 30% means you’re only getting sustained compute 30% of the time).

Average RAM Utilization (%)

Same as CPU, this is the sustained average use of RAM.

Bare Metal Efficiency Gain (%)

Due to dedicated resources and lower virtualization overhead, metal is often 20–30% more efficient.

Bare Metal Node Cores

Physical cores available per QBO metal server.

Bare Metal Node RAM (GB)

Amount of physical memory per QBO node.

Example Comparison: Cloud vs Metal Over Time

Metric	AWS EKS (Shared)	QBO Metal (Dedicated)
vCPUs	2426 (shared)	672 physical cores
Avg Available CPU	~849 (35%)	672 (100%)
RAM	7369 GB	5376 GB
Avg Available RAM	3684 GB (50%)	5376 GB

EKS Shared (fluctuating CPU)

QBO Metal (stable CPU)

VM-Based Infrastructure vs QBO Summary

This document compares QBO on metal with VM-based infrastructure (such as EKS, EC2, or other cloud VMs) across four key operational areas: node draining, autoscaling, spot instance behavior, and container vs VM scaling.

Aspect	VM-Based Infrastructure (e.g., EKS, EC2)	QBO on Metal
Node Draining	Can happen unexpectedly due to AWS maintenance or scaling.	You control it. No surprise evictions or reboots.
Autoscaling	Scales VMs (EC2/Fargate) which takes 1–3+ minutes.	Scales containers instantly on existing metal.
Spot Interruptions	Spot VMs can be interrupted with 2 minutes’ notice.	No spot concept. Your metal is reserved and dedicated.
Scaling Target	Scales virtual machines, then schedules containers.	Scales containers (processes) directly on Linux.
Latency to Scale	60–180+ seconds — VMs must boot and join the cluster.	Milliseconds to seconds — containers on demand.
Overhead	High — VMs add resource overhead and complexity.	Minimal — no hypervisor, no nested OS.
Predictability	Shared environment — susceptible to external events.	Deterministic behavior — you fully control lifecycle.
Efficiency	Virtualized, shared CPU/RAM with hypervisor overhead.	Direct use of hardware resources.
Cost Consistency	VMs billed by the minute/hour, can spike with autoscale.	Flat cost per metal node — no surprise billing.
Best For	General-purpose cloud-native workloads with elasticity.	AI/ML, low-latency workloads, GPU-heavy apps, HPC.