Hyperscaler cloud providers are increasingly looking beyond their data centers for new services and capabilities. A decade ago, many hyperscaler cloud providers dismissed so-called hybrid clouds — where infrastructure is managed across both public cloud and on-premises venues — as unnecessary. They saw on-premises infrastructure as an outdated technology, arguing that public cloud services could do anything an on-premises deployment could do.

Over time, cloud providers have accepted that regulatory requirements, a desire for greater control, and geopolitical boundaries mean that many enterprises are not willing to fully commit to the public cloud. In the Uptime Institute annual survey, data security (60%) and regulatory and compliance (44%) stand out as the top reasons why enterprises choose not to host mission-critical workloads in the public cloud (see Uptime Institute Global Data Center Survey 2024).

To address a market that remains resistant to public cloud, cloud providers have launched new services that deliver some public cloud-like capabilities within the customer’s choice of data center. However, these cloud services often lack clear, descriptive naming conventions, making it difficult to understand their core functionality or to make direct comparisons across competing platforms. Additionally, commonly used terms such as “private cloud” and “hybrid cloud” are interpreted differently across the industry, leading to inconsistency and confusion in both technical and strategic discussions.

This report describes how this seemingly complex array of on-premises offerings can be grouped into four categories, with each varying in terms of sovereignty, integration, convenience and customization.

Public, private and hybrid

The public cloud provides on-demand access to a wide range of services from centralized data centers. Cloud providers track the consumption of these services — such as virtual machines, storage, machine learning, analytics and others — and bill customers monthly based on usage.

The primary benefit of the public cloud is scalability and flexibility: users can provision and run any cloud service without considering how it is delivered from a hardware or software level.

Private cloud offers similar on-demand access to services, but with the underlying hardware hosted in the customer's choice of data center — whether it is their own or a colocation facility. Customers generally adopt private cloud when they want to control the location of their data while also providing users with the flexibility to consume services on demand without concerning themselves with the underlying hardware.

In both public and private clouds, users can access services on demand. However, in the public cloud, the cloud provider handles data center operations and server capacity, whereas in a private cloud, those responsibilities fall to the organization’s IT department.

In a hybrid cloud, customers use both cloud provider infrastructure and their own infrastructure, managing them through a common interface so that services can be consumed across locations. Common use cases for hybrid cloud include:

• Disaster recovery and backup — keeping core systems on-premises while backing up data to the public cloud (or vice versa).
• Cloud bursting — using public cloud resources to handle demand spikes.
• Gradual cloud migration — migrating applications or data in phases from on-premises to the cloud.
• Sovereignty — retaining sensitive workloads and data on-premises while using public cloud for non-personal data.
• Application modernization — maintaining legacy systems on-premises while developing new applications in the cloud.
• Low latency applications — running latency-sensitive workloads on on-premises sites, while using the cloud for centralized processing and data storage.

It would be easier for cloud providers if all workloads were migrated to their public cloud, giving them complete control over the data center, hardware and software. However, with most enterprises still demanding on-premises capabilities due to technical debt, legislation, compliance or sovereignty, it is hard to see that happening. While hyperscaler cloud providers offer public cloud at their core, they now also offer options for private and hybrid clouds. These options ultimately vary based on two key attributes: who manages the control plane and who manages the hardware.

Control planes

Cloud providers divide the technologies that underpin their services into two “planes" — the control plane and the data plane. Each plane is a set of distributed components that work together to perform overall management of resources (the control plane) and user requirements (the data plane). On-premises versions of public cloud infrastructure vary depending on whether these control plane components are primarily hosted in the public or private cloud.

Control plane tasks include:

• Communicating with server nodes to provision a virtual machine or allocate other resources on a physical server, through software installed on each node.
• Configuring the resource with custom settings.
• Hosting an application programming interface (API) endpoint so users and code can programmatically manage resources.
• Providing a management graphical user interface for operations teams to administrate their cloud estates.

Data plane tasks include:

• Routing packets to and from resources.
• Writing and reading to and from disks.
• Executing application instructions on the CPU.

Public and private clouds must be able to work in isolation, without relying on an external data center for administration. As a result, the control plane for a public cloud is hosted within the cloud provider's data center, while the control plane for a private cloud is hosted in the customer's data center.

By definition, a hybrid cloud shares a control plane across public cloud and on-premises locations. Most control plane functionality is hosted on the public cloud (see Figure 1).

Figure 1 Differences between public, hybrid and private cloud

Figure 1 shows how an administrator can communicate directly with both public and private clouds via their respective control planes. In a hybrid cloud, however, a single venue needs to host most of the control plane components that control both cloud and on-premises venues.

Why is the control plane primarily hosted on a public cloud in a hybrid cloud model? If an organization is comfortable running its workloads in the public cloud, it stands to reason that it would also trust the public cloud to host its control plane. Furthermore, from a security standpoint, a cloud provider would take a substantial risk by permitting an external control plane to control the hardware and software installed in their hyperscale data centers.

A hybrid cloud is a compromise. Workloads can run on either public or private clouds, depending on the specific workload requirements, such as data protection or compliance. However, the control plane must span both venues, which — for some organizations — may raise security concerns. In principle, a malicious actor could attack the control plane, potentially hijacking or deleting resources. The control plane exchanges metadata with data planes situated in different locations. While personal data is likely subject to some compliance requirements, the compliance status of associated metadata can be unclear. A network outage could also cause a loss of connectivity between the control plane and the on-premises data plane, preventing some management tasks from being performed.

In summary, a cloud control plane provides better unification and integration of applications and resources across locations than a local control plane. The downside, however, is that control resides outside the data center, which may have repercussions for security, resiliency and compliance in some workloads.

Deployment model

There are two primary ways that on-premises hyperscaler options can deploy cloud services into the enterprise data center: either via a managed hardware appliance or through software installed on the customer's choice of hardware.

In the appliance model, an integrated hardware and software appliance — effectively a scaled-down public cloud server — is shipped and installed on-premises. Customers rent or purchase the appliance, with the provider responsible for maintaining the hardware and software functionality. This model enables users to consume cloud resources as services. However, customers are responsible for ordering and installing new capacity if needed.

In the software model, the customer installs software on their choice of server. In this case, the provider usually does not manage any aspect of the deployment or guarantee any level of performance.

Typically, this software allows users to provision containers on the server through API calls. A container is a package of code that shares both the physical server and the operating system — it is essentially a lightweight form of virtualization. Containers are designed to execute small pieces of code — often for short durations — that work together to deliver an application’s functionality (see Cloud scalability and resiliency from first principles for a deeper dive into containers).

The on-premises software is typically a scaled-down version of that used in the hyperscaler’s public cloud. It supports containers that follow the same format as those in the public cloud service, and API calls to the public cloud and the on-premises container platform are structured similarly. However, moving containers between public cloud and on-premises infrastructure requires a common control plane that can communicate with both the cloud provider’s infrastructure and the on-premises software. This common control plane is often referred to as container orchestration.

The benefit of an appliance is that the customer does not need to manage hardware — this responsibility lies with the cloud provider. It is plug and play, meaning the hardware can be connected to the rack and used almost immediately with minimal configuration. Usually, an appliance has a greater range of cloud service options than software, which only supports containers.

However, customers may opt for a software-only model because it can be installed on existing hardware, thus avoiding the need for new investment. This approach also enables enterprises to choose the underlying hardware and operating system, giving them greater control over the on-premises stack. That control, however, means the customer is responsible for managing the hardware and software, which requires skills and resources.

In summary, an appliance model offers better integration with cloud services and is usually easier to install and manage than a software model. The downside, however, is that customers have limited hardware choices, no control over the underlying software, cannot use existing hardware, and will likely incur higher costs. With a software model, customers can deploy it on any hardware and manage it as they see fit, but they take on responsibility for day-to-day operations.

Summary of hyperscaler options

Cloud product names often lack clear and descriptive naming conventions, making it difficult to understand the core functionality or compare products across competing platforms. Table 1 explains four common public cloud on-premises models and places specific provider products within those categories. Note that product offerings vary substantially, so products within the same category should not be viewed as directly comparable.

Table 1 Summary of hyperscaler options