Hybrid Cloud Explained

What hybrid cloud means, and what it does not

Hybrid cloud describes an estate where workloads run both on infrastructure you control, typically a data centre or colocation space, and on a public cloud, with the two operated as a connected whole.

The last clause is what distinguishes hybrid from simply having servers in two places. If the office file server and the cloud application never speak, share no identity system and are managed by different processes, you do not have a hybrid architecture. You have two estates.

It is also distinct from multi-cloud, which describes using more than one public provider. A company can be both, and many larger ones are, but the problems each creates are different.

Hybrid is usually not chosen for elegance. It arrives because an organisation has existing infrastructure it cannot abandon, an obligation that pins some data in place, or an appetite for the cloud that outran its ability to move everything.

The shapes hybrid takes

The last row deserves honesty. A large share of hybrid estates are mid-migration rather than deliberately designed, and treating that state as temporary when it will last for years leads to underinvestment in the connective tissue.

Joining the two halves

Connectivity is the foundation, and there are two tiers of it.

A site-to-site VPN over the public internet is quick to establish and inexpensive. Every major provider supports it: AWS Site-to-Site VPN, Azure VPN Gateway and Cloud VPN on Google Cloud. The trade is that throughput and latency depend on the internet path between the two ends, which nobody guarantees.

A dedicated circuit removes that variability. AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect provide private links with consistent characteristics, arranged through a carrier or an exchange facility. They take weeks to provision and involve a contract, so start early if you need one.

Address planning matters more than teams expect. Choose non-overlapping private ranges across the data centre and every cloud network before you build anything, because renumbering a live estate is painful. Plan DNS resolution across the boundary at the same time, with forwarders in both directions so names resolve wherever a workload runs. The underlying concepts are covered in private networking between cloud servers.

One identity, two environments

Split identity is the most common operational weakness in hybrid estates. Two directories mean two joiner processes, two leaver processes and two places a stale account can hide.

The usual answer is to federate. An existing directory becomes the source of truth and the cloud provider trusts it for sign-in, so access is granted and removed once. Microsoft Entra ID is the common bridge for organisations with an on-premises Active Directory, and the major providers support standard federation protocols for other directories.

Machine identity needs the same treatment. Workloads authenticating across the boundary should use short-lived credentials issued by a central authority rather than long-lived keys copied into configuration files. The principles are the same as in any cloud estate and are set out in cloud IAM fundamentals.

Managing both halves as one

Providers sell tooling that extends cloud management across the boundary. Azure Arc brings servers and Kubernetes clusters running elsewhere under Azure management. AWS Outposts places provider-operated hardware in your facility running the same APIs. Google Distributed Cloud extends Google's stack to your location, and Anthos-derived tooling manages clusters wherever they run.

These are worth evaluating, particularly if your estate is large enough that inconsistent management is a genuine cost. They also deepen your relationship with one vendor, which is a trade to make deliberately rather than by default.

The vendor-neutral alternative is to standardise your own tooling. One infrastructure-as-code workflow, one configuration management system, one monitoring stack and one deployment pipeline covering both halves. That is more work initially and it keeps the choice of provider open.

Whichever path you take, the goal is the same: an engineer should not need to remember which half of the estate a workload is on in order to deploy to it or debug it.

Where the data lives decides everything

Application tiers move easily. Data does not, and in a hybrid estate the placement of data determines the latency and the cost of everything built around it.

Chatty applications separated from their database by a wide area link behave badly, and no amount of bandwidth fixes a round trip. Keep the components that talk constantly on the same side of the boundary, and design the cross-boundary interfaces to be coarse: batched, asynchronous and tolerant of a slow response.

Egress charges apply to data leaving the cloud, so a pattern that repeatedly pulls large datasets back to the data centre will be expensive in a way that is invisible at design time. The pricing behaviour is explained in egress costs.

Where regulation is the reason for the hybrid arrangement, document the data flows explicitly rather than relying on architecture diagrams. The considerations are covered in data residency and sovereignty.

Frequently asked

See cloud repatriation for that adjacent topic, and the AWS and IBM Cloud comparison for two platforms with notably different hybrid positions. Account details are in the Azure and AWS listings. The vendor documentation for the management layers is the Azure Arc overview and the AWS Outposts user guide.