Most organisations now run workloads across more than one cloud provider. The question is whether that happened by design or by accident, and what it takes to manage it well.
Most organisations running meaningful cloud workloads are running more than one. AWS for one set of services, Azure for another, Google Cloud where a specific capability or commercial arrangement made it the right choice. In some cases the mix grew deliberately; in many it accumulated over time as different teams made different decisions.
The result is the same either way: a multicloud estate that has to be connected, secured, governed, and evidenced. Whether that estate works well depends less on which providers are in the mix and more on how the connectivity and operating model underneath it is designed.
The reasons for running more than one cloud provider are varied and mostly legitimate. Different providers have genuine strengths in different areas. AWS leads on breadth of services and global infrastructure. Azure integrates deeply with Microsoft tooling that most organisations already run. Google Cloud has particular strength in data analytics and AI workloads. For an organisation with diverse requirements, no single provider is the obvious choice for everything.
Vendor lock-in is a genuine concern. Organisations that commit entirely to one provider’s native services find migration difficult and costly if requirements change, pricing shifts, or a provider’s roadmap diverges from their needs. Spreading workloads across providers preserves optionality.
Regulatory requirements add a further dimension for UK regulated organisations. Some workloads carry data residency or sovereignty requirements that constrain which providers and which regions can be used. An NHS organisation running clinical workloads may have different requirements from the same organisation running back-office functions. A multicloud approach can allow each workload to sit where it is most appropriate rather than forcing every decision through a single provider’s compliance posture.
The benefits are real. The complexity is also real, and it tends to accumulate in the areas that matter most.
Connectivity between cloud environments and back to on-premise systems is the first pressure point. Each cloud provider has its own connectivity model, its own private interconnect service, and its own egress pricing. Without deliberate design, the paths between cloud environments and between cloud and on-premise can become ungoverned, poorly documented, and difficult to evidence.
Security policy consistency is the second. Each cloud provider offers its own security tooling, configured independently. The risk is that policy varies between environments in ways that are not visible or intended, creating gaps that assessors will find before the organisation does.
Visibility is the third. Without a common observability layer across providers, understanding what is happening across the estate requires logging into multiple portals, reconciling data from different sources, and assembling evidence that no single tool produces.
For regulated organisations, all three create compliance problems. CAF, DSPT, NIS2 and DORA all require evidenced controls. A multicloud estate managed as a collection of separate environments produces separate evidence trails, if it produces them at all.
The difference between a multicloud estate that works and one that creates ongoing operational overhead is whether it was designed as a whole or accumulated in pieces.
A designed multicloud estate has a single connectivity fabric underneath it. Private connections to each cloud provider – AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect – managed under one operating model, with one contract and one team accountable for the paths between them. Traffic between cloud environments and back to on-premise or regulated networks travels over governed, monitored paths rather than the public internet by default.
Security policy is applied at the fabric level, not configured separately per provider. Inspection, access control, and policy enforcement are consistent across every environment. A change to policy propagates across the estate rather than being applied site by site or provider by provider.
Observability is unified. Performance, security posture, incident data, and SLA delivery are visible in one place, drawn from telemetry across every managed environment. When an auditor asks for evidence of controls at the cloud boundary, the data is already there.
For a healthcare technology company delivering a cloud-hosted product to NHS customers, multicloud by design means the connectivity from each cloud environment to HSCN is compliant and evidenced, the security layer at the boundary meets the supplier assurance requirements NHS governance teams will apply, and the operating model can scale as the customer base grows without rebuilding the architecture.
For a central government department running workloads across AWS and Azure, it means the paths between environments and back to PSN are governed and visible, policy is consistent, and the evidence that CAF assessors expect is generated as a by-product of running the service.
For any multi-site organisation with a mix of cloud and on-premise systems, it means the network and security estate underneath the cloud layer is as well-governed as the cloud environments themselves.
The workloads in a multicloud environment are usually well designed. The cloud teams have done their work. The applications are up and running. The connectivity back to the rest of the estate is where the deferred decisions tend to sit.
That connectivity is worth the same level of deliberate design as the workloads it serves. The path between a cloud-hosted application and the on-premise systems, regulated networks, and users that depend on it determines whether the application performs reliably, whether the data it handles can be evidenced, and whether the security controls that protect it are consistent and auditable.
Cloud Gateway delivers managed private cloud connectivity across AWS, Azure and Google Cloud, alongside compliant connectivity to HSCN and PSN for regulated organisations, under one operating model. For more on how this works, see our Connect to the cloud page or Business Connect: Cloud.
