Unit 4.4: Private Cloud (Dedicated VMware)

Introduction

The standard compute classes of Units 4.1 to 4.3 are the platform's elastic, multi-tenant fabric. Some workloads do not belong there: a regulated estate that must run on single-tenant hardware, a large existing VMware footprint whose operating model and skills the business wants to keep, or a workload that needs the predictability of dedicated capacity. For these, IONOS offers a different product, the dedicated VMware Private Cloud, and it sits in this module as a design-only unit because there is no self-service console build: provisioning is a guided engagement. The architectural questions this unit answers are when to reach for it, how to position it, and how it composes with the elastic platform around it. The mechanics of migrating a large estate into it are threaded forward to Unit 7.4.

1. What the Product Is and the Responsibility Boundary

IONOS Private Cloud is a dedicated VMware Software-Defined Data Center delivered as a service on single-tenant hardware. A cluster is a minimum of three dedicated physical hosts, and the VMware software stack and its licensing are included in the price (this is not bring-your-own-licence): vSphere Enterprise Plus 8.0 as the hypervisor and compute layer, vSAN 8.0 as the hyper-converged storage layer, NSX-T 3.2 as the software-defined networking and security layer, and vCenter 8.0 as the management plane. You manage your own VMware environment (create, resize, and delete VMs; define networks, storage, sizing rules, and users) through the native VMware tooling, while IONOS owns the support, maintenance, patching, and upgrades of the underlying SDDC.

That split is the defining characteristic and the thing to get right in a design. IONOS handles the platform lifecycle; everything inside the VMs and the virtual network is the customer's. The service is explicitly out of scope for provisioning and managing the VMs themselves, OS updates and patching inside VMs, role and rights management, additional software, the licensing of installed OSes and applications, monitoring of the VMs and virtual network, data security, external firewall rules, and load balancers. In other words, Private Cloud gives you a fully managed, dedicated VMware substrate and hands you the keys to operate on top of it. Using it well requires genuine VMware skills; it is not a managed-application service.

The cluster scales by adding hosts. The service-catalogue ceiling is 24 hosts per cluster (the Private Cloud documentation cites a higher 64-host technical ceiling), a vCenter manages up to 2,500 hosts, and a cluster supports up to 8,000 VMs. A single VM can be sized up to 256 vCPUs, 6 TB RAM, and a 62 TB virtual disk. Private Cloud is provisioned on demand as a self-service, and billing is per-minute. Bundles are sold by host profile (for example a Silver-48 cluster of three hosts, a Gold-512, or an XL-1024), with an additional host billed separately; this is dedicated capacity, so the cost is predictable rather than usage-spiky.

1.1 The Storage and Networking Layers

vSAN is the storage layer: it pools the hosts' local disks into a single datastore and tolerates failures by spreading data across the cluster, so a disk or a whole host can fail with data still available elsewhere. vSAN 8.0 here is configurable for fault tolerance through RAID-1 mirroring (minimum 3 hosts), RAID-5 erasure coding (minimum 4 hosts), or RAID-6 erasure coding (minimum 6 hosts), with AES-256 encryption available and storage-efficiency modes from none through compression to deduplication-and-compression. Raw capacity scales to 8 PB per cluster. Where you need shared file capacity beyond vSAN, an NFS datastore add-on is available from 2 TB upward.

NSX-T is the networking and security layer: it virtualises routing, switching, firewalling, and VPN into software, so those functions no longer depend on physical appliances. NSX segments are virtual Layer 2 domains you create to build isolated logical networks, and they support Bring Your Own IP ranges (an NSX segment subnet must be more specific than the BYOIP range, so a /24 BYOIP range allows segments of /25 or smaller). The NSX-T Standard edition here supports very large rule and switch counts (up to 100,000 distributed firewall rules and 10,000 logical switches); a few advanced functions (IDS/IPS, URL filtering, network sandboxing, SSL VPN remote access) require additional licensing.

2. When Dedicated VMware Wins

Private Cloud is the right answer for a specific and recognisable set of requirements, and a poor fit outside them. It wins when:

• Single-tenancy and compliance isolation are mandatory. The hardware is dedicated, so there is no multi-tenant neighbour at the hypervisor layer. For regulated workloads where isolation is a control requirement, this is a cleaner story than shared compute.
• Performance must be predictable. Dedicated capacity removes the contention variability of shared infrastructure, which matters for workloads with tight latency or throughput envelopes.
• The organisation wants to retain VMware skills and operating model. A team already fluent in vSphere, vSAN, and NSX-T keeps its tooling, runbooks, and automation rather than re-platforming onto a different operational model.
• There is a large existing VMware estate. Moving an established VMware footprint into a managed VMware environment is a far smaller change than refactoring it onto cloud-native primitives. The estate keeps running the way it already runs, with IONOS taking over the platform lifecycle.

It is the wrong answer where the workload is genuinely cloud-native and elastic, where multi-tenant standard compute is acceptable and cheaper, or where no VMware skills exist and the team would rather consume managed primitives. For those, the standard compute classes and managed services covered elsewhere in this course are the better choice. The architectural discipline is to place only the workloads that need dedicated VMware onto Private Cloud, and to use the elastic platform for everything else.

3. Competitive Positioning: Control-Plane Sovereignty and Cost Predictability

The differentiator that matters for a regulated European customer is not the VMware stack itself, which is the same software a US hyperscaler would also run, but who operates the control plane and under whose jurisdiction it sits. As Unit 1.4 established, EU legal sovereignty is a property of operator jurisdiction, not merely of region: a VMware-on-hyperscaler offering hosted in a European region but operated by a US company still carries US CLOUD Act exposure. IONOS operates the Private Cloud control plane as an EU provider, so the management plane (vCenter, NSX Manager, the provisioning and billing surface) sits under EU jurisdiction rather than a foreign one. For a customer whose entire reason to run dedicated hardware is isolation and sovereignty, putting the control plane under foreign jurisdiction would undercut the design; keeping it EU-operated is the point.

The second axis is cost predictability. Private Cloud is dedicated capacity billed per host bundle (per-minute granularity, included VMware licensing), so the monthly cost is a function of how many hosts you run, not of fluctuating consumption. The published per-service availability target is 99.95%, the same 99.95% per-service uptime figure that applies to general IONOS IaaS compute rather than an improvement on it (one internal document lists a 99.9% Private Cloud figure, an unresolved discrepancy). For a finance team that needs to forecast spend on a stable estate, fixed dedicated capacity is easier to budget than a usage-metered VMware service whose bill moves with activity and whose licensing may be charged separately.

4. The Hybrid Pattern and How Workloads Move In

The strongest architecture is rarely all-VMware or all-elastic; it is the hybrid. The dedicated VMware Private Cloud is the regulated, stable core for the estate that needs single-tenancy and the VMware operating model, while elastic standard IONOS compute (the Dedicated Core auto-scaling tiers of Units 4.1 to 4.3) handles the variable, cloud-native edge. The two are linked over the hybrid connectivity primitives from Module 3 (VPN Gateway, NAT Gateway, Cross-Connect), giving a single logical estate with each workload placed on the substrate that fits it.

Moving an existing estate into the Private Cloud uses VMware-native tooling, and IONOS supports a specific set of it. The primary mechanism is VMware Cloud Director Availability (VCDA) 4.7.x, a disaster-recovery-as-a-service tool that protects VMs and vApps with asynchronous replication, migrates them, and performs failover and reverse failover between an on-premises vCenter and the IONOS Private Cloud. VCDA migration is included; ongoing per-VM protection is billed at roughly 50 EUR per VM per month, and the cloud endpoint uses port 55443. For extending a Layer 2 network during a migration, NSX-T provides an L2 VPN as an add-on, so a subnet can span the source and the Private Cloud while workloads move. Within a cluster, vMotion moves a running VM between hosts; it is an intra-cluster operation, not a cross-site live-mobility mechanism, so a migration into Private Cloud is engineered with VCDA replication and a planned failover rather than assumed to be a seamless live move across sites. These three (VCDA, NSX-T L2 VPN, intra-cluster vMotion) are the supported tooling for getting workloads in; the full wave-planned mechanics, with honest per-path downtime, are the subject of Unit 7.4.

Enterprise Case Study (FinCorp)

FinCorp's defining constraint is a large existing VMware estate under GDPR and BSI obligations, and that estate is the reason Private Cloud is central to its architecture. Re-platforming the whole estate onto cloud-native primitives would be a multi-year refactor with high risk; running it on a managed, dedicated VMware SDDC lets it keep its operating model while shifting the platform lifecycle to IONOS. FinCorp sizes a Private Cloud cluster (three hosts minimum, scaling by host as the estate lands) for the regulated core, keeps the vCenter and NSX-T control plane under EU operation to preserve the sovereignty position from Unit 1.4, and uses vSAN with an erasure-coding fault-tolerance policy sized to the host count. The new, customer-facing, elastic workloads do not go on the Private Cloud; they run on the standard Dedicated Core auto-scaling tier (Unit 4.3) at the edge, linked to the VMware core over Module 3 hybrid connectivity. The estate moves in via VCDA replication with NSX-T L2 VPN extending the relevant subnets during cutover, planned wave by wave in Unit 7.4. The decision recorded here, dedicated VMware for the regulated core plus elastic standard compute for the new edge, is the compute backbone the capstone assembles.

Decision Summary

Hard eligibility notes: a cluster is a minimum of three hosts; provisioning is a guided engagement, not a console build; the included VMware licensing is not BYOL; and the only IONOS-supported VMware tooling for moving workloads in is VCDA, NSX-T L2 VPN, and intra-cluster vMotion.

Summary

IONOS Private Cloud is a managed, dedicated VMware SDDC (vSphere Enterprise Plus, vSAN, NSX-T, vCenter, all 8.0/3.2, licensing included) on single-tenant hardware, provisioned as a guided engagement rather than self-service. IONOS owns the platform lifecycle; the customer operates the VMs and virtual network, which demands real VMware skills. It wins for single-tenant compliance isolation, performance predictability, VMware-skill retention, and large existing VMware estates, and its competitive edge for regulated European customers is an EU-operated control plane (sovereignty) plus predictable fixed-capacity cost. The strongest design is hybrid: the dedicated VMware core for the regulated estate plus elastic standard compute at the edge over hybrid connectivity, with workloads moved in via VCDA, NSX-T L2 VPN, and intra-cluster vMotion (the full migration mechanics come in Unit 7.4).

Key Points:

• Private Cloud is a managed dedicated VMware SDDC on single-tenant hardware, minimum three hosts, with included (not BYOL) licensing for vSphere Enterprise Plus, vSAN, NSX-T, and vCenter.
• IONOS owns platform maintenance/patching/upgrades; the customer owns the VMs, OS, virtual network, and security inside, so VMware skills are required.
• It wins for single-tenancy/compliance isolation, performance predictability, VMware-skill retention, and large existing VMware estates; it is the wrong fit for cloud-native elastic workloads.
• The competitive position for regulated EU customers is an EU-operated control plane (sovereignty) and predictable fixed-capacity cost.
• The hybrid pattern pairs the dedicated VMware core with elastic standard compute; the only IONOS-supported VMware tooling for moving workloads in is VCDA, NSX-T L2 VPN, and intra-cluster vMotion, with full mechanics in Unit 7.4.

Important Terminology:

• SDDC (Software-Defined Data Center): the VMware stack (vSphere, vSAN, NSX-T, vCenter) delivered as one managed, dedicated environment.
• vSAN: the hyper-converged storage layer that pools host-local disks into a fault-tolerant datastore.
• NSX-T: the software-defined networking and security layer providing virtual segments, routing, firewalling, and VPN.
• VCDA (VMware Cloud Director Availability): the IONOS-supported tool for asynchronous replication, migration, and failover of VMs into the Private Cloud.

Further Reading

• Unit 1.4: Sovereignty and Compliance as Design Inputs (the control-plane-jurisdiction argument).
• Unit 7.4: Migration and Hybrid Cutover (the wave-planned mechanics of moving the estate in).
• Unit 3.6: Hybrid Connectivity (the links that bind the VMware core to the elastic edge).