Unit 4.1: Compute Class Selection

Introduction

Compute class is not a sizing decision; it is an architectural one, and on IONOS Cloud it is made per tier rather than per estate. The class you pick fixes four things at once: whether the workload gets an exclusive physical core or shares one, whether you can pin the CPU family, whether you can attach network Block Storage, and who carries the operational model. One of those decisions is effectively permanent (a Cube's template is immutable after provisioning), so getting the class right at design time is cheaper than every later workaround. This unit makes that decision explicit across the three IONOS Cloud compute classes, then ends by provisioning the Dedicated Core shell that Units 4.2 and 4.3 extend with storage, cloud-init, and auto-scaling.

1. The Four-Way Compute Decision

Every IONOS compute class answers the same four questions differently. Hold these four axes in mind and the class almost selects itself.

Core isolation. A Dedicated Core server is given a dedicated physical core, exposed to the guest operating system as two logical cores (one physical core with Hyper-Threading presents as two threads). A vCPU server shares physical cores with other tenants. Isolation buys predictable performance under contention; sharing buys a lower price. This is the contention model that Unit 2.4 framed as the first cost lever, now seen from the compute side.

CPU-family control. Only Dedicated Core lets you select and later change the CPU family (for example, pinning AMD EPYC for a workload that benefits from it, or standardising a tier on Intel Xeon). On a vCPU server the family is not selectable. This matters when a workload is sensitive to instruction-set or per-core-clock differences, or when a licence is tied to a CPU family.

Block-storage attachment. Dedicated Core and vCPU servers attach network Block Storage volumes (the boot disk and any data disks live on the iSCSI block fabric, covered in Unit 4.2). A Cube ships with a mandatory direct-attached NVMe volume that is part of its fixed template. The attachment model decides how you do storage lifecycle, snapshots, and resize.

Operational model and SLA. A Dedicated Core or vCPU server is a managed VM with live vertical scaling and a 99.95% per-service uptime SLA. A Cube is a fixed-template instance with a 99.9% SLA.

The following table sets the three classes against the axes that drive the decision.

A Dedicated Core server can be configured up to 62 cores and 230 GB RAM. RAM is allocated in 0.25 GB increments. These ceilings rarely bind a single tier, but they matter when you are sizing a large monolith before deciding whether to split it.

1.1 Dedicated Core: the default for tiers that need a guarantee

Choose Dedicated Core when the tier needs predictable performance under load or when you need to pin or change the CPU family. The exclusive physical core is what buys the performance guarantee under contention, and CPU-family control is unique to this class. Where a tier will also scale horizontally, its replica compute configuration (CPU architecture, cores, and RAM) is set at design time in the VM Auto Scaling replica template (Unit 4.3), so settling the tier's compute shape early still pays off. The cost of the exclusive core is the price you pay for the performance guarantee.

CPU-family selection on Dedicated Core is real but not free: changing the family on an existing server requires a restart. Treat a family change as a planned maintenance operation with a window, not as a live tuning knob.

1.2 vCPU: cost-effective where contention is acceptable

A vCPU server provisions and behaves like any other VM but shares physical cores, which is why it is the cost-effective default for development and test environments, essential internal software services, and tiers where occasional contention is acceptable. It supports live vertical scaling like Dedicated Core, but it cannot select a CPU family. The decision rule is simple: if the tier needs neither a performance guarantee nor CPU-family control, a vCPU server is the cheaper correct choice.

1.3 Cubes: the fixed-template instance, not a storage dead-end

A Cube is a fixed-configuration instance: vCPU, RAM, and a direct-attached NVMe volume come as a bundled template, and you may not change those template properties after provisioning. The NVMe volume is connected over PCI Express in the physical server and is software-RAID single-redundant; it occupies one of the instance's device slots and cannot be unmounted or deleted while the Cube exists. Basic templates run from Basic-Cube-XS (1 vCPU, 2 GB RAM, 60 GB NVMe) up to Basic-Cube-XL (16 vCPU, 32 GB RAM, 960 GB NVMe); memory templates trade cores for RAM (for example Memory-Cube-XL at 16 vCPU and 64 GB RAM).

Here is the trap, and it runs the opposite way to a common assumption. A Cube is often dismissed as unable to use Block Storage. That is wrong: a Cube supports up to 23 add-on HDD or SSD (Standard or Premium) Block Storage devices in addition to its mandatory NVMe volume, and those add-on devices can be unmounted and deleted at any time after provisioning. The real constraint is different and more specific: the template itself (vCPU, RAM, and NVMe size) is immutable, and the NVMe volume cannot be detached. Deleting a Cube deletes its NVMe volume, so take a snapshot first if the data must survive. So the honest design rule is: pick a Cube when its fixed bundle matches the workload and you want a predictable single line item, and plan persistent data onto add-on Block Storage volumes that outlive the template, not onto the immutable NVMe disk.

2. Class-Per-Tier as the Pattern

The unit of the compute-class decision is the tier, not the application. A layered enterprise design (the public-L7-to-stateless-compute-to-private-L4-to-private-data shape from Unit 1.2) routinely mixes classes: Dedicated Core for the tier that must scale and hold a performance guarantee, vCPU for internal or non-critical tiers, and a Cube where a fixed bundle is a clean fit. Where a workload needs a single-tenant managed platform (for example a regulated VMware estate), that is the dedicated VMware Private Cloud handled in Unit 4.4, not a Public Cloud compute class. Mixing classes by tier is the norm, not a compromise.

Two design rules fall out of this and are worth stating plainly, because both are easy to get wrong under time pressure:

• An auto-scaling tier's replica compute configuration is set at design time. VM Auto Scaling stamps new replicas from a replica template (CPU architecture, cores, RAM), and a template change applies only to replicas created afterwards, so the replica shape is a design-time decision rather than a live knob (Unit 4.3).
• A CPU-family change is a planned operation. It is available on Dedicated Core but needs a restart, so it belongs in a maintenance window, not in a live-tuning runbook.

For FinCorp, the regulated German financial-services firm running through this course, the customer-facing application tier is the one most likely to face variable load and the one most exposed to the public Layer 7 balancer. That tier is provisioned as Dedicated Core for a predictable performance guarantee under load and so its CPU family can be standardised for consistent performance, and it is the tier that later scales horizontally under a metric policy (Unit 4.3). FinCorp's internal batch-reporting tier, by contrast, tolerates contention and is provisioned as vCPU to save cost. The compliance angle reinforces this: BSI C5 (the Type 1 attestation of 7 November 2023) and IT-Grundschutz (the ISO 27001 certificate of 14 September 2022) both scope Compute Engine, so the standard VM classes sit inside FinCorp's attestation envelope. The regulated VMware estate is a separate decision handled by the dedicated VMware Private Cloud in Unit 4.4.

Design Considerations

• Cost. The exclusive core of Dedicated Core is the premium you pay for a performance guarantee and auto-scaling eligibility. Where neither is required, vCPU is the cheaper correct answer; do not buy isolation a tier does not need.
• Operations. The permanent decision (a Cube's immutable template) carries the highest operational cost when it is wrong, because correcting it means rebuilding rather than reconfiguring. Spend the most design care here.
• Scalability. Vertical scaling (live-growing CPU and RAM) is available on Dedicated Core and vCPU within limits covered in Unit 4.3; managed horizontal scaling adds and removes whole replicas under a metric policy, with the replica compute configuration fixed in the replica template at design time. Decide which axis a tier will scale on before you pick its class.

DCD Implementation Walkthrough

This walkthrough provisions the Dedicated Core server shell that the rest of Module 4 extends. It realises the design decision above for FinCorp's customer-facing tier: a Dedicated Core class for a predictable performance guarantee and so its CPU family is under our control. The prerequisite is the FinCorp Virtual Data Center created in Unit 3.1, into which this server is placed. Storage and image detail are deliberately deferred to Unit 4.2, so here we create the server and set its core, RAM, CPU family, and credentials only.

Build goal: Provision a Dedicated Core server shell (class, cores/RAM, credentials).

Steps (in the Data Center Designer):

1. Open the FinCorp VDC from Unit 3.1 in the Workspace. The procedure below applies to Canvas mode; if no data center exists yet, create one first.
2. From the Palette, drag a Dedicated Core server element onto the Canvas to add it to the VDC.
3. Select the new server to open the Inspector pane on the right, and give it a name that is unique within the VDC (this is its identity for the rest of the module).
4. Set the CPU architecture / family. On Dedicated Core this is selectable; pin the family the tier is standardised on. Note that changing the family later requires a restart, so choose deliberately.
5. Set Cores and RAM. Stay within the Dedicated Core limits (up to 62 cores, up to 230 GB RAM; RAM is allocated in 0.25 GB increments). Size for the tier's baseline, not its peak, because horizontal scaling will handle peaks in Unit 4.3.
6. Under Authentication, set the root/administrator password and/or attach an SSH key (select one from the SSH Key Manager, or paste an ad-hoc public key). This is how you will reach the server once it boots.
7. Leave storage and image for Unit 4.2; do not boot from an image yet. Click Provision Changes to apply, which commits the server shell.

Common mistakes:

• Treating the auto-scaling replica shape as a runtime knob. The replica template's compute configuration (CPU architecture, cores, RAM) is set at design time and applies only to new replicas, so size and shape the replica deliberately before the group runs (Unit 4.3).
• Treating the CPU family as a live knob. Changing it on Dedicated Core requires a restart; schedule it as planned maintenance.
• Oversizing the shell to its peak. Size the Dedicated Core baseline for steady-state load and let horizontal scaling (Unit 4.3) absorb peaks, rather than paying for a permanently large single VM.
• Forgetting that a newly provisioned server with more than 8 GB RAM may not start cleanly on the very first boot until the working memory is processed; this is expected behaviour, not a fault.

The architectural point that an immutable attribute carries is visible even in a one-line CLI create: the CPU family and class are set at creation, and the family change later is a restart-bearing operation, not a free edit.

ionosctl server create --datacenter-id "$FINCORP_VDC" \
  --name fincorp-app-01 --cpu-family INTEL_SKYLAKE --cores 4 --ram 8192

Summary

Compute class on IONOS Cloud is a per-tier architectural decision driven by four axes: core isolation, CPU-family control, Block Storage attachment, and operational model. Dedicated Core is the default where a tier needs a performance guarantee, CPU-family control, or eligibility for managed auto-scaling; vCPU is the cheaper choice where contention is acceptable; and a Cube is a fixed-template instance whose vCPU/RAM/NVMe bundle is immutable but which still attaches add-on Block Storage. Decide the class before sizing, because the most consequential constraints are the permanent ones, and provision the Dedicated Core shell as the foundation the rest of Module 4 builds on.

Key Points:

• Run the four-way decision (isolation, CPU family, block-storage attachment, operational model) per tier, not per estate.
• VM Auto Scaling is horizontal-only: it adds and removes whole replicas under a metric policy, and the replica compute configuration is fixed in the replica template at design time.
• A Cube's template (vCPU, RAM, NVMe) is immutable and its NVMe cannot be detached, but a Cube can still attach up to 23 add-on Block Storage devices; the constraint is the fixed template, not an inability to use Block Storage.
• A CPU-family change on Dedicated Core needs a restart; treat it as planned maintenance.

Important Terminology:

• Dedicated Core server: a VM given an exclusive physical core (two logical cores), with selectable CPU family.
• vCPU server: a VM sharing physical cores; cost-effective, no CPU-family control.
• Cube: a fixed-template instance with a mandatory direct-attached NVMe volume; template properties are immutable after provisioning.
• Live Vertical Scaling (LVS): growing or shrinking a running VM's resources, covered in depth in Unit 4.3.

Further Reading

• Unit 4.2: Images, Disks, and Cloud-Init (extends this server shell).
• Unit 4.3: Elasticity and VM Auto Scaling (how this tier scales horizontally).
• Unit 2.4: Cost Architecture and FinOps (the contention model as the first cost lever).