Article by Aenix Team

Private cloud architecture in 2026 — design, components, and implementation patterns

What private cloud means in 2026: the architectural layers, three patterns that work, capacity sizing, and the mistakes that recur in design reviews.

Open StackKubernetesKube VirtSovereigntyMulti TenancyFinancial Services

Private cloud has moved from “yesterday’s architecture” to “tomorrow’s default for regulated and cost-sensitive workloads” within ~3 years. The Broadcom Private Cloud Outlook 2025 found 53% of organizations now prioritize private cloud for new workloads. The LSEG Global Cloud Survey reports 84% of financial-services firms have adjusted cloud strategy due to regulatory pressure. The shift is real.

But the architecture decisions in 2026 are different from 2018-era OpenStack-centric private clouds. The default stack has moved to Kubernetes-native virtualization (KubeVirt) plus open-source storage and networking. The operational model has matured. The trade-offs are clearer.

What “private cloud” means in 2026

A private cloud is dedicated cloud infrastructure run for a single organization or tenant, with self-service consumption patterns matching public cloud (provision-on-demand, multi-tenancy, observability, automation) — but on infrastructure the organization controls.

In 2026, private cloud is one of:

  • Customer-owned, customer-operated — organization owns hardware, runs the platform.
  • Customer-owned, vendor-operated — organization owns hardware, vendor runs the platform under contract.
  • Vendor-owned dedicated — vendor provides dedicated infrastructure (single-tenant), organization consumes.
  • Sovereign hyperscaler region — hyperscaler-operated infrastructure with sovereignty controls (some count, some don’t).

This article focuses on customer-owned options 1 and 2 — the architecture is similar; the operations differ.

Architectural layers

A modern private cloud has six functional layers:

Layer 1: hardware

  • Compute — x86 or ARM servers; modern generations support all relevant workloads. AI/GPU adds a separate hardware tier (NVIDIA H100/H200/L40S/Blackwell, AMD MI-series).
  • Storage — replicated block storage (LINSTOR, Ceph, or vendor SAN). Object storage for backup and applications.
  • Network — datacenter fabric (BGP-routed leaf-spine increasingly default), 25-100 Gbps Ethernet sufficient for most non-HPC workloads.
  • Datacenter — own facility, colocation, or ROBO/edge. Power, cooling, physical security.

Layer 2: OS and platform foundation

  • OS — Linux, increasingly minimal (Talos, Bottlerocket, Flatcar) for Kubernetes hosts. RHEL / Ubuntu LTS for VM hypervisors when not in Kubernetes.
  • Kubernetes — vanilla, OpenShift, Cozystack, vendor-led. Distribution choice is structural.
  • Virtualization — KubeVirt for VM workloads inside Kubernetes (most modern); KVM/libvirt directly (OpenStack); VMware (legacy).

Layer 3: storage and networking

  • Block storage — LINSTOR (DRBD-based, default in Cozystack), Ceph (Rook-managed), vendor SAN.
  • Object storage — Ceph RGW, MinIO, SeaweedFS.
  • Network virtualization — Cilium (eBPF, default in 2026), Calico, OVN.
  • Load balancing — MetalLB for layer 2/3, Cilium L7, ingress controllers (NGINX / Traefik / Contour).

Layer 4: control plane

  • Multi-tenancy — Tenant CRD (Cozystack), namespace-based (vanilla Kubernetes), vCloud-Director-style (legacy).
  • Identity — Keycloak, Okta integration, AD integration. SPIFFE/SPIRE for service identity.
  • GitOps — Argo CD or Flux. Cozystack uses Flux.
  • Observability — VictoriaMetrics + VictoriaLogs (Cozystack default), Prometheus + Loki, vendor SaaS.
  • Backup/DR — Velero + S3, per-app patterns (PostgreSQL PITR).

Layer 5: application and platform services

  • Managed databases — PostgreSQL (CloudNativePG), MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse, RabbitMQ, NATS, OpenSearch.
  • Object storage as a service — S3-compatible.
  • AI/ML platform — KubeVirt for VM-based GPU, Kubernetes-native for container-based GPU, vLLM/Triton for inference.
  • Self-service portal — Backstage, Cozystack Cozystack Dashboard, custom.

Layer 6: operations

  • Runbooks — documented operational procedures.
  • On-call rotation — incident response model.
  • Capacity planning — quarterly hardware refresh, growth forecasting.
  • Compliance posture — audit logging, certifications (where applicable), regulator dialog.

Three architectural patterns that work

Pattern 1: Cozystack-based Kubernetes-native cloud

What: Single Kubernetes cluster (or fleet) with Cozystack as the platform layer. KubeVirt for VMs, Kubernetes for containers, LINSTOR for storage, Cilium for networking, Tenant CRD for multi-tenancy, Cozystack Dashboard for self-service.

Best for: Service providers, sovereign-cloud builders, regulated multi-tenant. Greenfield deployments.

Pros: Open-source, single-stack, multi-tenancy native, virtualization + container in one platform.

Cons: Newer than OpenStack; smaller community than Kubernetes-only deployments.

Pattern 2: OpenStack-based traditional private cloud

What: OpenStack as compute orchestrator, Ceph for storage, OVN for networking, Heat/Terraform for provisioning. Optional Kubernetes-on-OpenStack for container workloads.

Best for: Organizations with deep OpenStack experience; large telco/sovereign deployments where OpenStack is the procurement standard.

Pros: Mature, broad community, many vendor options.

Cons: Operationally complex; harder to find OpenStack engineers in 2026; less Kubernetes-native.

Pattern 3: VMware Cloud Foundation (VCF) — legacy

What: vSphere + vSAN + NSX + vCD + vRealize. Closed source, subscription-licensed.

Best for: Existing VMware estates that haven’t yet been triggered out by Broadcom economics.

Pros: Mature, well-known, extensive integration.

Cons: Subscription-only post-Broadcom, 2-5× price increases observed, lock-in to single vendor’s roadmap.

(For VMware exit guidance see VMware alternative.)

Architectural decisions that matter most

Five decisions with the highest long-term impact:

Decision 1: virtualization layer

KubeVirt or traditional hypervisor? KubeVirt is the 2026 default for greenfield; traditional hypervisor (KVM/libvirt directly) is appropriate for very-large-scale OpenStack deployments where KubeVirt’s overhead matters.

Decision 2: storage architecture

LINSTOR/DRBD for replicated block? LINSTOR is operationally simpler and Cozystack-default. Ceph is more flexible but operationally heavier. Vendor SAN is an option but contracts limit your scaling pattern.

Decision 3: networking

Cilium has become the default CNI for new deployments. NSX-equivalent (Cilium L7, service mesh) replaces VMware NSX functionality. The decision is more about your team’s eBPF familiarity than about technical fit.

Decision 4: multi-tenancy model

For service-provider model: Tenant CRD (Cozystack) is the default. For internal multi-BU: namespace-based + RBAC is sufficient. For absolute isolation: cluster-per-tenant (operationally expensive).

Decision 5: operational model

Customer-operated (you run it), vendor-operated (Ænix or similar runs it for you), or hybrid (you operate; vendor provides 2nd-line). Decision driven by internal team capacity and risk appetite.

Capacity sizing

A practical sizing rubric for a 100-VM-equivalent workload:

  • Compute: 6-10 servers, dual-socket, 256-512 GB RAM each. Reserve 30% headroom for failures and growth.
  • Storage: ~100 TB replicated (3-replica) for steady-state plus snapshot/backup capacity. ~300 TB raw for that target.
  • Network: 25 Gbps NIC per server, leaf-spine fabric, 100 Gbps backbone.
  • Datacenter: ~6-10 kW per rack at modern density.
  • DR site: comparable secondary footprint.

Scaling beyond 1000 VMs: hardware grows roughly linearly; platform team grows sublinearly with good automation.

Operational practices that matter

  • Quarterly capacity reviews — hardware ahead of growth.
  • Twice-yearly Kubernetes upgrades — stay current on CVEs and feature parity.
  • Documented incident response — incident commander, scribe, blameless post-mortems.
  • Compliance posture — audit logs, certifications, regulator dialog where applicable.
  • Platform-team headcount sized realistically — 1-3 engineers for a single-cluster small private cloud; 5-15 for a multi-cluster service-provider.

Common architectural mistakes

Mistake 1: copying public-cloud architecture

Designing the private cloud to look like AWS internally. Different scale economics; public-cloud architecture patterns (massive distributed eventual-consistency systems) are over-engineering for most private clouds.

Mistake 2: vendor-led private cloud

Buying “private cloud appliance” rebuilds lock-in with new vendor. The vendor’s roadmap becomes yours.

Mistake 3: under-engineering operations

Compute and storage solved; observability/identity/backup-DR/runbook layer underinvested. Operational debt builds.

Mistake 4: skipping multi-tenancy at design

Single-tenant cluster scaled to multi-tenant later. Bolted-on multi-tenancy fails at scale or under regulator audit.

Mistake 5: hardware refresh skipped in budget

Year 4 hardware refresh ignored in initial economics. The refresh cliff arrives unexpectedly.

Want to dig deeper?

Test yourself: private cloud architecture in 2026

5 questions · ~2 min

Read also

← Back to blog