vCPU vs. Core: What’s the Difference and How Many Do You Need?

A CPU core is a physical processing unit inside a processor. A vCPU is a virtual unit of processing capacity assigned to a virtual machine.

The distinction can be easy to miss when you’re comparing infrastructure. You can’t reliably size a dedicated server by simply matching the number of vCPUs on one spec sheet to the number of cores on another. What’s more, two different processors with the same number of cores can differ drastically in performance. 

For teams migrating from cloud to bare metal, getting that comparison wrong can lead to an oversized server or a deployment that cannot keep up under load. It’s a common pitfall, but, luckily, one that can be avoided. 

In this guide, we’ll explain how vCPUs relate to physical cores, which performance factors matter when comparing processors, and how to translate your current cloud resource usage into an appropriately sized dedicated server.

vCPU vs. core: The short answer

CPU cores and vCPUs describe processing capacity at different layers of the infrastructure. A core is part of the physical processor. A vCPU is a unit of processing capacity that a hypervisor presents to a virtual machine, backed by access to the underlying server’s physical processor.

To illustrate that distinction more clearly, let’s look at CPU cores and vCPUs separately:

What is a CPU core?

A CPU core is a physical execution unit inside a processor. Modern server processors contain many cores on the same chip, and each can execute its own stream of instructions. When software can divide its work across multiple threads, those cores can process different parts of the workload in parallel.

For example, a 16-core server can distribute a multithreaded application’s work across up to 16 physical cores.

That makes core count an important specification, but not an absolute measure of performance. A processor with twice as many cores will not necessarily run an application twice as fast. The application must be able to use those cores effectively, and the performance of each core also affects how quickly the work is completed.

When comparing processors for a dedicated server, look at both the processor model and its physical core count. The processor model will indicate what each core is capable of; the core count tells you how much work the processor can potentially handle in parallel.

What is a vCPU?

A vCPU is a unit of processing capacity that a hypervisor assigns to a virtual machine (VM). From the VM’s perspective, each vCPU functions like a CPU core that its operating system can use to run application threads.

Behind the scenes, however, a vCPU is not necessarily a dedicated physical core. The hypervisor schedules the VM’s work on the host server’s physical processor and shares the available processing capacity among the VMs running on that server.

Because most VMs do not use all their assigned processing capacity continuously, cloud providers may oversubscribe a host server. This means they assign more vCPUs across its VMs than the physical processor can support simultaneously. 

When several VMs require substantial processing capacity at the same time, they may have to compete for the host server’s available CPU resources. Providers manage this risk by monitoring utilization, limiting oversubscription, and maintaining spare capacity, although contention can still occur.

Does one vCPU equal one core?

Usually, no. A vCPU does not have one universal physical equivalent. However, on many cloud instance types, each vCPU represents one hardware thread on which the VM’s operating system can schedule work.

On many modern server processors, each physical core supports two hardware threads through a process known as simultaneous multithreading (SMT). The operating system sees each hardware thread as a logical processor, and cloud providers commonly present each logical processor as one vCPU.

In this common configuration, the relationship looks like this:

1 physical core = 2 hardware threads = 2 logical processors = 2 vCPUs

Under this convention, a 16-vCPU instance reflects a CPU topology of 16 hardware threads across eight physical cores.

This 2:1 relationship is common, but it is not universal. AWS Graviton processors, for example, do not use SMT, so each vCPU corresponds to one physical core. Always check the processor and CPU topology of the specific instance type before converting its vCPU count into a bare metal core requirement.

How to convert cloud vCPUs to physical cores for bare metal

The common 2:1 relationship gives you a useful starting point, but converting vCPUs to physical cores is not as simple as dividing by two. 

That calculation may tell you how many physical cores sit behind your provisioned vCPUs, however, it doesn’t tell you how much of that capacity your workload actually uses, or whether the cores in a different processor will deliver comparable performance.

Correctly sizing a dedicated server capable of replacing the vCPU capacity of your cloud environment requires looking at each of those factors. 

The following process will help you establish a physical-core baseline, account for real-world utilization, and evaluate the processors available for your new server:

Step 1: Inventory your cloud CPU resources

Start by listing each virtual machine you plan to move. 

For every VM, record its instance type, vCPU count, processor architecture, physical core count, and number of threads per core. 

Cloud providers generally publish this information in their instance specifications. For AWS EC2, you can look up the instance type in the AWS documentation or use the describe-instance-types CLI command to find its default number of vCPUs, cores, and threads per core.

This inventory gives you both your provisioned vCPU capacity and a physical-core baseline for the workloads being moved.

Step 2: Measure actual CPU utilization

The number of provisioned vCPUs tells you how many virtual processors a VM can use, but not how much CPU capacity your workload regularly consumes.

Before carrying that full allocation over to bare metal, review the utilization of each VM across a representative period that includes normal traffic, recurring peaks, batch jobs, and other demanding events.

Note the average utilization, peak utilization, and how long those peaks last. A VM with 16 vCPUs averaging 25% utilization is consuming roughly one-quarter of its aggregate CPU capacity, but that does not mean it can automatically be replaced by four physical cores. A short spike and several hours of sustained demand create different sizing requirements.

Additionally, check how utilization is distributed across the VM’s vCPUs, rather than relying only on its overall average. A VM can show low total CPU usage even when one vCPU is working at full capacity. This may indicate that part of the workload is limited by single-threaded performance and would benefit from faster individual cores rather than a higher core count.

Step 3: Compare processor performance

Once you know how many physical cores sit behind your cloud VM and how much of that capacity the workload uses, you can start evaluating processors for the dedicated server.

Two 16-core processors can deliver very different performance depending on their age, clock speed, cache, memory support, and instructions per clock (the amount of work each core can complete during a clock cycle). A newer processor may therefore meet the same workload requirements with fewer cores than an older one with more cores.

Identify the processor supporting your cloud VM, then compare it with the processors offered for your dedicated server. Look at both single-thread and overall benchmark results. Single-thread benchmarks help indicate how quickly each core can work, while overall scores provide a better sense of performance when a workload can use many cores at once.

PassMark’s CPU Comparison tool offers both scores for many server processors. These general benchmarks are useful for an initial comparison, but tests that resemble your actual workload will provide the best evidence.

Step 4: Add headroom and test

Once you have a likely processor in mind, make sure the rest of the server can support the workload as well. Check its memory capacity, storage capacity and performance, and network bandwidth. A CPU upgrade will not help much if one of those resources becomes the new bottleneck.

The configuration should also leave enough headroom for traffic spikes, demanding jobs, and near-term growth. How much you need will depend on the workload and how predictable its usage is.

Before migrating production traffic, test the workload on the proposed server under realistic conditions. Monitor CPU, memory, storage, and network utilization. If any resource approaches its limit, you still have the chance to go back and select a more suitable configuration before completing the migration.

What’s better: More cores or faster cores?

Once you start comparing processors, you might run into a common dilemma: is it better to choose a newer CPU with fewer, faster cores or an older CPU that offers more cores at roughly the same price?

Neither is automatically the better value. The right choice depends on how well your workload can use the additional cores and how much work each core can perform.

More cores help when an application can split its work into operations that run at the same time, a capability known as parallelism. Many batch-processing, video-encoding, and scientific-computing workloads can benefit from this approach.

But parallelism doesn’t automatically make more cores the better choice. Workloads rarely scale perfectly as cores are added, and their individual execution threads still benefit from stronger per-core performance. If the newer cores are substantially faster, a processor with fewer of them may still deliver better total performance than an older, higher-core-count model.

As a rule of thumb, prioritize stronger per-core performance when the workload is lightly threaded or latency-sensitive. Prioritize additional cores when testing shows that the workload can use them to deliver a clear throughput advantage.

Bare metal sizing example

To help illustrate how requirements translate from a cloud vCPUs to physical cores on a bare metal server, let’s put the process into practice with a simplified migration from AWS to Rackdog.

Suppose a team is running a workload on one AWS m5.8xlarge instance. AWS provides the instance with 32 vCPUs and 128 GiB of memory. Those 32 vCPUs are backed by 16 physical cores with two hardware threads per core, giving us an initial baseline of:

32 vCPUs ÷ 2 threads per core = 16 physical cores

Then suppose monitoring shows that the workload averages 35% CPU utilization and regularly peaks at around 65%. There’s unused capacity in the existing instance, but the new server still needs enough headroom to handle those peaks, so 16 physical cores remains the target. 

Based on that information, a Rackdog AMD 4565P would be a reasonable configuration to test as a replacement for this m5.mx.large instance:

The Rackdog server preserves the 16-core baseline while moving the workload to a newer processor architecture with stronger per-core performance. It also includes more memory, local NVMe storage, and a 10 Gbps port with unmetered bandwidth. 

What’s more, at $454 per month, the Rackdog server costs about 60% less than the AWS instance’s compute charge alone, before EBS storage and data transfer are added. 

As a final step before migrating, the team should validate the complete configuration by comparing relevant processor benchmarks, confirming that local NVMe meets the workload’s storage requirements, and testing it under realistic demand.

AWS pricing is based on the listed U.S. Linux On-Demand rate of $1.536 per hour for the m5.8xlarge, calculated over 730 hours. It excludes EBS storage and data transfer charges. Rackdog pricing is current as of August 2026.

Final takeaway

Understanding how vCPUs relate to physical cores provides a stronger foundation for sizing dedicated infrastructure. By evaluating the workload as a whole, teams can select a server configuration that delivers the right balance of performance, capacity, and cost.

If you’re planning a move from cloud to bare metal, Rackdog’s engineers can review your current environment and recommend a configuration suited to your workload and migration requirements.

Rackdog offers bare metal servers in a range of configurations, including options with modern, high-clock-speed processors and up to 64 physical cores. Our team regularly helps organizations migrate existing workloads to dedicated infrastructure and can recommend server specifications suited to their performance and capacity requirements.

Create an account to start deploying, or talk to an expert about your infrastructure needs.