Table of Contents

1. Executive Summary
2. Key Takeaways for Architects and Decision-Makers
3. Defining Multi-Tenancy as a First-Class Architectural Concern
4. Multi-Hypervisor IaaS: Coexistence by Design
5. Multi-Hypervisor IaaS: Designed to Coexist
6. vCloud Director Exit and Greenfield IaaS Builds
7. CloudStack’s Role as an IaaS Control Plane
8. Reference Architecture Patterns

 

Executive Summary

Modern IaaS platforms are heterogeneous by default. Multiple hypervisors, infrastructure tiers, and tenancy models coexist in the same environment, driven by cost optimisation, workload specialisation, regulatory requirements, and risk management.

The primary architectural challenge is how to consistently govern, operate, and scale multi-tenant, multi-hypervisor environments without fragmenting governance or operational processes.

In this blog post, we show why a resilient IaaS control plane is essential for a strong cloud architecture. When governance, tenancy, and lifecycle logic are embedded in the execution layer, infrastructure evolution leads to duplicated workflows, inconsistent policies, and operational silos. A control-plane-centric architecture, by contrast, separates governance from execution. This allows infrastructure layers to evolve while preserving a consistent service model.

 

Figure 1 – IaaS Control Plane and Execution Layer Separation

“The dashed line illustrates the architectural boundary between governance and execution. Above it, CloudStack operates as a control plane responsible for tenancy, policy, and lifecycle intent. Below it, heterogeneous execution pools provide compute, network, and storage capabilities without embedding governance logic.”

In this model, the multi-tenancy is central. Rather than being an infrastructure-level isolation mechanism, tenancy is treated as a first-class control plane concept. Structural multi-tenancy enables consistent delegation, policy enforcement, quota management, and accountability across heterogeneous execution environments. This supports enterprise internal clouds as well as commercial CSP and MSP platforms.

In this architectural model, Apache CloudStack is the IaaS control plane designed for multi-hypervisor and multi-tenant environments by architecture, not by transition. CloudStack coordinates heterogeneous execution layers through a unified governance and lifecycle framework, without replacing hypervisors or enforcing lowest-common-denominator abstractions.

This paper presents reference architecture patterns that show how enterprises, CSPs, and MSPs can build resilient IaaS platforms, managing diverse infrastructure as a single, unified service rather than as separate, siloed stacks.

Key Takeaways for Architects and Decision-Makers

The main challenge in modern IaaS isn’t picking the ‘right’ hypervisor—it’s keeping governance, tenancy, and lifecycle management consistent as environments become more diverse. When governance logic is embedded in execution-layer tooling, each new platform introduces fragmentation and duplicated operational models.

1. Heterogeneity Is No Longer an Exception. It Is the Operating Baseline.

Enterprise, CSP and MSP IaaS environments are structurally heterogeneous by default. Multiple hypervisors, infrastructure tiers, regions, and compliance domains coexist not because of incomplete migrations, but because they serve distinct cost, performance, risk, and regulatory needs. Architectures that assume homogeneity inevitably accumulate operational debt as diversity grows.

2. A Durable IaaS Architecture Requires a Dedicated Control Plane

Separating the control plane from the execution layer is no longer optional at scale. A centralised control plane provides a stable system of record for tenancy, policy, and lifecycle intent, allowing infrastructure strategies to evolve without repeatedly redefining operating models, access boundaries, or service semantics.

3. Multi-Tenancy Must Be Treated as an Architectural Construct, Not an Infrastructure Feature

Effective multi-tenancy extends beyond network isolation or resource partitioning. Structural multi-tenancy defined at the control plane level enables consistent delegation, quota enforcement, accountability, and lifecycle ownership across heterogeneous execution environments. This model scales equally well for enterprise internal platforms, CSP and MSP commercial offerings.

4. Multi-Hypervisor Coexistence Should Be Designed, Not Tolerated

Multi-hypervisor environments are most successful when treated as a long-term operating state rather than a transitional phase. Cost tiering, workload optimisation, resilience, and vendor risk management all benefit from intentional coexistence—provided governance and lifecycle consistency are enforced centrally.

5. Lowest-Common-Denominator Abstraction Is an Architectural Anti-Pattern

Simplifying heterogeneous platforms by stripping away platform-specific capabilities undermines the value of execution diversity. A strategic control plane coordinates differences rather than erasing them, preserving execution-tier depth while standardising governance and service behaviour.

6. Platform Exit Initiatives Are Often Governance Corrections Rather Than Technology Failures

Many “exit” initiatives are not driven by dissatisfaction with a platform’s technical capabilities, but by the inability of platform-bound governance models to survive infrastructure evolution. Decoupling governance from execution reframes these discussions from replacement to architectural correction.

7. CloudStack Fits Where Governance Must Outlive Infrastructure Choices

Apache CloudStack’s architectural value lies in its role as a control plane rather than as an execution stack. By maintaining clear boundaries between governance and execution, it provides a stable foundation for multi-tenant, multi-hypervisor IaaS environments where infrastructure choices can evolve independently of the service model.

8. Enterprise, CSP and MSP Use Cases Converge at the Control Plane Layer

While enterprise internal clouds, CSP and MSP-operated platforms differ in commercial and operational objectives, their architectural requirements converge at the control plane: delegated tenancy, consistent policy enforcement, lifecycle predictability, and accountability across diverse execution pools.

9. Strategic Advantage Comes from Operating Model Stability, Not Feature Accumulation

In mature IaaS environments, long-term success is defined less by feature richness and more by architectural durability. A control-plane-centric model enables incremental infrastructure evolution, reduces organisational risk, and preserves a coherent service experience over time.

Read our blog post Building a Compliant IaaS with Apache CloudStack

Defining Multi-Tenancy as a First-Class Architectural Concern

In IaaS architecture, multi-tenancy must be elevated from a functional “add-on” to a first-class architectural concern. Rather than viewing tenancy as a simple tagging mechanism or a set of firewall rules, a modern control plane treats it as the primary logical framework.

Structural vs. Infrastructure-Level Multi-Tenancy

Architects must distinguish between physical resource sharing and the logical structures that govern access and ownership. Infrastructure-level tenancy focuses on physical or network-layer separation.   This is often enforced through hardware boundaries or network segmentation tied directly to the execution layer. While necessary, this approach alone does not address governance, delegation, or lifecycle ownership.

On the other hand, structural multi-tenancy is implemented at the control plane level. It defines:

• how organisations – internal or external – are represented within the platform
• how resources are delegated
• how authority is distributed

This model enables recursive delegation, allowing a primary tenant to partition and manage resources for sub-organisations or projects without direct involvement from global infrastructure administrators.

Tenant Isolation, Delegation, and Policy Boundaries

A mature control plane sets clear boundaries for each tenant. It keeps tenants isolated and prevents interference. Delegated authority enables self-service and independent lifecycle management. Policies are enforced consistently across cost, compliance, and operations. These controls must remain effective regardless of where workloads are executed.

 

Figure 2 – Control Plane-Driven Multi-Tenancy and Delegation Model

“Logical view of how governance, delegation, and consumption boundaries are defined at the control plane level, independent of execution infrastructure.”

Enterprise Internal vs. CSP vs. MSP External Tenancy

While the architectural foundations of multi-tenancy are consistent, its role differs by operating model.

• Enterprise internal platforms: tenancy structures internal departments, teams, or projects. The focus is on controlled autonomy, cost visibility, and consistent governance operated by a central platform team.
• CSP environments: tenancy is directly tied to commercial service delivery. Structural isolation, delegated administration, and clear accountability are mandatory, as the infrastructure itself represents a revenue-generating product.
• MSPs: combines both models. Their tenancy model must support dedicated managed environments alongside shared cloud services, without fragmenting governance or requiring separate platforms. Customers consume different service types under a single, coherent control plane.

Across all models, the conclusion is the same: multi-tenancy must be enforced at the control plane level. Importantly, structural multi-tenancy does not inherently require shared infrastructure and can govern both dedicated and shared execution environments under the same control plane. Only then can policy, lifecycle behaviour, and operational consistency remain stable as execution layers evolve.

Multi-Hypervisor IaaS: Coexistence by Design

In modern IaaS environments, multiple hypervisors are no longer a transitional condition but a deliberate and sustained operating model. Across enterprises, CSPs, and MSPs, execution heterogeneity is driven by cost tiering, workload specialisation, and risk management. Many organisations now plan to operate multiple virtualisation platforms as a long-term strategy rather than converging on a single execution stack.

Figure 3 – A centralised IaaS control plane enforcing consistent tenancy, governance, and policies across heterogeneous execution pools.

 

Drivers for Intentional Heterogeneity

Organisations adopt multi-hypervisor architectures to address key business requirements:

• Cost tiering: Not all workloads justify premium infrastructure. Heterogeneous platforms allow architects to align workload criticality with appropriate cost and performance tiers.
• Workload alignment and resilience: Different execution environments are better suited to specific workloads, while hypervisor diversity improves resilience by reducing systemic risk and limiting the impact of platform-specific failures.
• Disaster recovery: Hypervisor diversity can lower capital costs at secondary sites while maintaining recovery objectives.

 

Coexistence vs. Transition Models

Coexistence by design differs fundamentally from transition-based approaches. Migration models treat secondary hypervisors as temporary targets with consolidation as the objective, whereas coexistence architectures treat multiple hypervisors as complementary execution pools operating side by side over the long term. By avoiding tight coupling between governance logic and specific execution layers, coexistence models prioritise operating stability and allow infrastructure strategies to evolve without forcing disruptive changes to governance or operating models.

Consistent Governance over Uniform Execution

In multi-hypervisor environments, architectural success depends more on consistent governance and lifecycle behaviour than on uniform execution. A strategic control plane shifts the focus away from standardising execution layers and instead decouples tenancy, policy, and lifecycle management from individual hypervisor toolchains, ensuring operational consistency even as execution environments differ.

Figure 4 – Siloed execution stacks on shared infrastructure, each enforcing its own access control, network policies, and tenancy model, leading to fragmented governance.

Through consistent exposure of governance and lifecycle functions via UI and API, the control plane maintains a stable operational experience independent of underlying execution environment changes, enabling simplified operations and long-term infrastructure evolution.

Avoiding Lowest-Common-Denominator Abstractions

A common pitfall in multi-hypervisor design is the use of lowest-common-denominator abstractions to simplify management. While superficially attractive, this approach undermines the value of heterogeneity by obscuring platform-specific capabilities and limiting optimisation across execution tiers.

An effective IaaS control plane coordinates heterogeneous execution environments without erasing their differences. It preserves execution-tier depth while enforcing consistent governance and lifecycle behaviour, allowing new hypervisors to be introduced without reworking policy or tenancy models. By treating multi-hypervisor operation as a permanent architectural state, organisations establish a durable foundation for control-plane-centric IaaS architectures.

Multi-Hypervisor IaaS: Designed to Coexist

Modern IaaS platforms increasingly run on more than one hypervisor. This is no longer just a temporary migration phase. For many enterprises, cloud service providers (CSPs), and managed service providers (MSPs), using multiple virtualisation platforms is now a deliberate long-term strategy.

Organisations choose this model to balance cost, performance, and risk. Instead of trying to force all workloads onto a single platform, they match different workloads to the environments that suit them best.

Why Organisations Use Multiple Hypervisors

There are several practical reasons for adopting a multi-hypervisor approach:

• Cost control: Not every workload needs premium infrastructure. Different platforms allow teams to place critical workloads on high-performance systems and less demanding workloads on lower-cost tiers.
• Workload fit: Some platforms are better for specific use cases, such as virtual desktops or low-latency applications.
• Resilience and risk reduction: Relying on one hypervisor creates a single point of failure. Using multiple platforms reduces the impact of outages or vulnerabilities.
• Disaster recovery: Running recovery environments on different hypervisors can reduce costs while still meeting recovery goals.

Coexistence, Not Just Transition

Traditional migration models treat extra hypervisors as temporary, with the goal of eventually moving everything to one platform. A coexistence model is different: it assumes multiple hypervisors will run side by side for the long term.

This matters because coexistence focuses on stable operations, not just moving workloads. By keeping management and governance independent from any one hypervisor, organizations can adopt new platforms in the future without major disruption.

Consistent Governance Matters More Than Uniform Platforms

Success in a multi-hypervisor environment depends more on consistent governance than on making all platforms behave the same.

Instead of forcing standardisation at the execution layer, organisations should use a shared control plane that provides:

• Unified provisioning
• Central monitoring
• Cost visibility
• Lifecycle management

This ensures consistent operations even when the underlying platforms are different.

A common mistake is trying to simplify management by using “lowest-common-denominator” features that work everywhere. This approach removes the unique strengths of each platform and limits optimisation.

vCloud Director Exit and Greenfield IaaS Builds

 

Why vCloud Director Architectures Are Being Reassessed

In the evolution of multi-tenant IaaS, platforms such as vCloud Director established a widely understood reference model for tenant representation, isolation boundaries, delegated administration, and service delivery constructs. This model has become the operational baseline for “how multi-tenancy is done” at scale.

As the market matures, vCloud Director–based approaches are reassessed due to architectural reasons, rather than purely commercial. The core driver is the growing tension between platform-bound governance and the reality of heterogeneous infrastructure. Over time, organisations accumulate execution diversity:

• additional hypervisors
• specialized infrastructure tiers
• new compliance zones
• regional footprints
• integrations with third-party services

When tenancy, lifecycle, and governance logic remain tightly bound to a single platform’s execution assumptions and toolchain, operational complexity increases and governance becomes harder.

The result is a familiar pattern: governance becomes fragmented, platform teams lose leverage, and environments begin to drift into silos – each with its own processes, access model, and lifecycle semantics.

The Control Problem Behind “Exit” Conversations

Many organisations are trying to recover architectural control as their environments evolve beyond a single, tightly coupled operating model.

In practice, exit conversations often emerge when the control problem becomes visible in day-to-day operations:

• multiple platforms require duplicate onboarding, provisioning, and governance workflows
• tenant boundaries are difficult to keep consistent across execution tiers
• reporting, metering, and operational ownership diverge between platforms
• self-service and delegated administration behave differently across environments
• platform teams spend more time integrating tools than improving the service

This is the point where the decision shifts from “which platform do we prefer” to “how do we design governance that survives heterogeneity.”

Evolving Multi-Tenancy Expectations E

Multi-tenancy is no longer limited to isolation and access control within a single platform; it is increasingly expected to behave consistently across the entire infrastructure estate.

What drives this evolution:

• Tenancy independent of topology: Tenants must be able to span infrastructure boundaries (clusters, zones, regions) without redefining identity, access policies, or governance semantics each time the execution environment changes.
• Consistency across execution tiers: Whether a workload runs on VMware, KVM, or a specialised environment, the tenant should experience consistent lifecycle patterns, reporting, quota enforcement, and operational responsibilities.
• Unified governance surface: Enterprises, CSPs, and MSPs increasingly require a single governance contract for provisioning, lifecycle, visibility, and accountability, independent of the underlying execution layer.

As a result, multi-tenancy becomes a control-plane concern first, with infrastructure-level isolation acting as an enforcement mechanism rather than the defining construct.

Coexistence and Selective Retention of VMware Workloads

A key reality in most “exit” scenarios is that VMware does not disappear overnight. The mature outcome is often a coexistence architecture where VMware continues to serve specific workloads while other execution layers are introduced to meet cost, flexibility, or operational goals.

Common patterns include:

• Premium tier execution: VMware remains a high-SLA tier for performance-sensitive or tightly integrated enterprise workloads.
• Constraint-driven retention: Certain workloads remain due to vendor certification constraints, operational risk tolerance, or legacy dependencies.
• Controlled dual execution: VMware and alternative hypervisors operate side by side, with governance and tenancy handled consistently above them.

Figure 5 – Tiered Execution Pools with VMware Retained as a Premium Platform under a Central IaaS Control Plane

“The strategic point is not to remove VMware. The point is to avoid creating a second siloed platform that replicates the same coupling problem in a different stack.”

Learn more about VMware to Apache CloudStack migration.

Greenfield IaaS Builds as an Opportunity to Avoid Legacy Coupling

Greenfield builds are often where organisations can correct the architectural mistake of coupling governance to execution. Instead of replicating the same platform-bound model, modern designs increasingly prioritise a standalone control plane that is decoupled from hypervisor tooling, physical topology, and vendor roadmaps.

In a decoupled approach:

• tenancy constructs, delegation, and policy boundaries remain stable as execution tiers evolve
• lifecycle semantics and governance remain consistent across heterogeneous environments
• new infrastructure options can be introduced without re-architecting the service model
• platform teams can focus on operating the service, not stitching together toolchains

This is particularly relevant for organisations building new internal platforms (enterprise) or new service catalogues (CSP/MSP). Greenfield is not just “new infrastructure”. It is a chance to design the control plane and operating model as first-class elements from the start.

CloudStack’s Role as an IaaS Control Plane

 

CloudStack as a Control Plane, Not an Execution Stack

Apache CloudStack can be understood as a control plane implementation for IaaS environments where heterogeneity and multi-tenancy are structural requirements. Its primary architectural role is to provide a consistent governance and lifecycle surface above execution layers, rather than attempting to standardise or replace them.

CloudStack sits at the layer where organisations define how infrastructure is exposed as a service:

• who can consume it
• under what policies
• with what boundaries
• with what lifecycle semantics

The execution layer remains responsible for workload processing and platform-specific capabilities, while the control plane provides the system of record for identity, tenancy, allocation, and lifecycle intent.

This distinction is central to CloudStack’s ability to support heterogeneous environments without collapsing them into a lowest-common-denominator model. The objective is not to enforce a single execution platform, but to provide a governance layer capable of coordinating multiple execution tiers consistently.

A Clear Split Between Control and Execution

CloudStack embodies the separation of control logic from execution in a way that is operationally meaningful. The control plane owns the administrative state of the cloud: tenancy structure, allocation boundaries, service definitions, and lifecycle actions as an intent model. Execution environments implement those actions within their own constraints and strengths.

The architectural value of this separation is durability. When governance and lifecycle models are embedded in platform-bound tooling, architectural change becomes disruptive. New hypervisors, new regions, new compliance zones, or new infrastructure tiers require the governance model to be reworked. A dedicated control plane reduces this fragility by keeping governance stable while execution evolves.

This is the core point: CloudStack does not attempt to eliminate heterogeneity. It makes heterogeneity governable.

Native Multi-Tenancy as an Operating Model

Multi-tenancy is not an implementation detail. It is the operating model of an IaaS platform. CloudStack treats tenancy as a structural construct in the control plane. It enables consistent isolation boundaries, delegated administration, and policy enforcement independent of physical topology or hypervisor boundaries.

This tenancy model naturally extends into the broader enterprise ecosystem. Core governance functions such as identity and access management can integrate with external identity systems, including enterprise directories (LDAP/Active Directory) and federated identity providers based on standards such as SAML2. This allows individual Domains to align cloud access with their own organisational identity models, including cross-organisation federation, while remaining governed centrally by the control plane.

Figure 6 – Control-plane-based multi-tenancy where individual Domains align with external identity systems while maintaining centralised governance.

Beyond identity integration, the control plane is designed to operate within a broader infrastructure ecosystem rather than as a closed, monolithic platform. It can integrate with external systems for networking services, automation, billing, and operational tooling, while governance intent remains centralised and execution and supporting services evolve independently.

This matters because “multi-tenant” means more than separation. It includes:

• Delegation and responsibility boundaries: Platform teams define what tenants can do, what they cannot do, and where responsibilities shift between provider and consumer.
• Consistency of lifecycle semantics: Tenants expect the same operational experience across execution tiers: predictable provisioning patterns, quota boundaries, and lifecycle behaviours that do not change simply because workloads land on different infrastructure.
• Accountability and visibility: Enterprises require internal transparency and governance across business units, while CSPs and MSPs require commercial-grade accountability and consumption visibility. In both cases, the tenancy model is inseparable from the governance model.

The key architectural implication is that tenancy becomes a portable logical layer. A tenant’s identity and policy boundaries remain stable even when workloads span multiple execution environments.

10 Reasons Why to Choose Apache CloudStack as a VMware Alternative

Coordinating Multi-Hypervisor IaaS Without Oversimplification

CloudStack enables a long-term multi-hypervisor state by providing consistent governance and lifecycle coordination while allowing execution platforms to retain their depth.

The common failure mode in heterogeneous environments is over-abstraction: attempting to force all platforms into the same minimal set of behaviours to simplify management. This is precisely what undermines heterogeneity, because it prevents organisations from using execution tiers for what they are good at.

A strategic control plane must do something subtler:

• provide a unified lifecycle and governance surface
• preserve execution-tier differentiation
• allow intentional workload placement across tiers without creating operational silos

This is where CloudStack’s control plane role becomes distinct from “tool sprawl” approaches. Instead of requiring a separate management worldview for each execution stack, the control plane keeps tenancy, policy, and lifecycle consistent while execution remains heterogeneous by design.

Strategic Boundaries and What CloudStack Does Not Replace

To keep the architecture clean, it is important to define what CloudStack is not trying to subsume.

CloudStack is not an attempt to replace the execution layer. It does not attempt to become the hypervisor, nor does it aim to replicate platform-native tooling for deep platform-specific administration. Its role is to orchestrate execution environments through a consistent service model and governance framework.

This boundary is strategically important for two reasons:

1. Preservation of execution-layer value: Organisations can retain mature, enterprise-grade execution choices where they make sense, without sacrificing governance consistency.
2. Avoiding new forms of coupling: If a control plane becomes a monolithic platform that must be adopted end-to-end, it risks recreating the same coupling problem it was meant to solve. A control-plane-centric approach must remain integration-friendly and execution-agnostic.

This is also why CloudStack fits naturally into greenfield designs as previously discussed: it allows organisations to define the governance surface first and then attach execution tiers as needed, rather than committing governance to the assumptions of a single platform.

Why This Matters for Enterprise and CSP and MSP Strategy

The value of an IaaS platform is defined by how well it sustains a long-term operating model as infrastructure evolves.

For Enterprises, the challenge is governance durability. As internal platforms grow to span multiple execution tiers, regions, and compliance domains, coupling governance logic to infrastructure tooling quickly becomes a constraint.

By anchoring tenancy, policy, and lifecycle semantics in a stable control plane, enterprises enable platform teams to operate as internal service providers. Governance remains consistent while execution layers evolve. This reduces the friction between platform, security, and infrastructure teams and avoiding repeated redefinition of access models and operational processes.

For CSPs and MSPs, multi-tenancy is not an architectural option but the foundation of the commercial model. Isolation guarantees, delegated administration, consumption visibility, and lifecycle consistency are contractual requirements. A control plane tightly bound to a single execution stack limits the provider’s ability to introduce new service tiers, optimize costs, or evolve infrastructure without fragmenting the service portfolio.

A control-plane-centric architecture allows providers to evolve execution tiers independently of the customer-facing service model, preserving tenant identity, governance rules, and operational workflows while adapting pricing, performance, and infrastructure strategy over time.

Strategic outcome

For CSPs and MSPs, the benefit is architectural rather than feature-driven. A durable IaaS control plane acts as the system of record for governance, tenancy, and lifecycle intent, allowing heterogeneous execution environments to operate as interchangeable fulfillment layers under a consistant service model.

This makes it easier to evolve the platform over time, lowers operational risk, and keeps the service model consistent even as the underlying infrastructure changes.

Reference Architecture Patterns

The following reference architecture patterns illustrate how a control-plane-centric IaaS architecture applies consistently across enterprise, CSP, and MSP operating models, without changing the underlying governance principles.

These patterns are not industry-specific or deployment-size dependent. Instead, they describe repeatable architectural structures that emerge whenever multi-tenancy, governance consistency, and execution heterogeneity must coexist over time.

Enterprise Internal Cloud — Delegated Multi-Tenancy under a Central IaaS Control Plane

Delegated Multi-Tenancy under a Central IaaS Control Plane

Figure 7 – Enterprise Internal Cloud — Delegated Multi-Tenancy under a Central IaaS Control Plane

“This pattern illustrates how internal enterprise cloud consumption can be organised through structural multi-tenancy, delegated administration, and consistent lifecycle governance, independently of execution platforms.”

Key characteristics:

• A single CloudStack control plane governs tenancy, access, quotas, and lifecycle.
• Domains and accounts map to organisational structures such as departments, teams, or product units.
• Multiple execution tiers (different hypervisors, hardware profiles, or Zones) coexist under the same governance model.
• Development, staging, and production environments follow consistent policies regardless of workload placement.

Architectural intent:

Enable enterprise platform teams to operate IT-as-a-Service without creating hypervisor-specific silos or duplicating governance logic as infrastructure evolves.

CSP-Operated Multi-Tenant Public Cloud — Hierarchical Tenancy under a Central IaaS Control Plane

Hierarchical Tenancy under a Central IaaS Control Plane

 

Figure 8 – CSP Multi-Tenant Public Cloud with Hierarchical Tenancy under a Central IaaS Control Plane

“This pattern applies to Cloud Service Providers delivering public, multi-tenant IaaS services to external customers at scale.”

Key characteristics:

• Customer Domains are first-class tenants, isolated structurally rather than through custom tooling.
• Sub-tenancy supports customer teams, environments, and projects.
• Shared infrastructure pools are governed centrally while execution remains abstracted.
• Lifecycle consistency and policy enforcement are maintained across all tenants.

Architectural intent:

Support commercial-scale IaaS delivery with predictable service behaviour, strong tenant isolation, and the ability to evolve infrastructure platforms without impacting customer-facing contracts.

MSP-Delivered Managed Private and Hybrid Cloud

Customer-Centric Tenancy with Unified Governance

This pattern represents Managed Service Providers (MSPs) delivering managed private cloud environments alongside shared cloud services under a single, centralised IaaS control plane.

Rather than operating separate platforms for private and public offerings, the MSP exposes multiple execution Zones under the same governance model, each Zone reflecting a specific service contract or consumption intent.

Figure 9 – Dual-Mode MSP IaaS Architecture with Dedicated and Shared Execution Zones

“This architecture illustrates how an MSP can combine per-customer dedicated execution Zones and a shared public cloud Zone under a single CloudStack control plane, while preserving consistent tenancy, policy enforcement, and lifecycle governance across all service types.”

Key characteristics:

• A single CloudStack control plane governs all tenants, Zones, and policies.
• Each customer is represented as a first-class tenant (Domain) in the control plane.
• Dedicated execution Zones provide managed private cloud capacity per customer, supporting contract-specific SLAs and compliance requirements.
• A shared execution Zone operated by the MSP provides public cloud–style capacity under strict structural tenant isolation.
• Customers may consume resources from one or multiple Zones without redefining identity, access models, or lifecycle semantics.

Architectural intent:

Enable MSPs to deliver contract-driven managed private clouds alongside shared cloud services using a unified control plane, avoiding platform sprawl, duplicated governance models, and hypervisor-specific operational silos. This approach allows infrastructure tiers to evolve independently while preserving a stable, predictable service model for customers.