A brief history

I remember in the early days of cloud computing, the major providers promoted the advantages of committing to a single platform. The message was clear: avoid complexity, embrace vendor lock-in by way of a multicloud strategy and use one provider as your primary home in the cloud.

Most customers listened politely and then carried on building multicloud environments anyway. Some made it work smoothly, others struggled, but almost all realised at least some benefits from spreading workloads across providers.

A few years later, the cloud vendors caught up with this reality. They began to offer deeper cross-service integrations with their competitors and now actively promote multicloud strategies of their own.

multicloud is now a fact of life for many enterprises, the chagrin of these cloud provicders. Acquisitions, regulatory requirements, specialist services and global scale all push organisations towards using more than one hyperscaler. Having workloads across AWS, Azure and Google Cloud can bring resilience and flexibility, but only if you are deliberate about strategy, architecture and operating model.

In this post I’ll walks through practical patterns for making multicloud work in real life. It focuses on concrete examples from the three major providers, and on things teams often discover late: metadata and tagging, networking and data gravity, Kubernetes as a common platform, shared observability and security, and cost management.

Start with strategy, governance and a single CCoE

A multicloud approach needs a clear decision framework, not just a list of services. That starts with governance and a Cloud Centre of Excellence (CCoE).

AWS prescriptive guidance describes a CCoE as a unit that defines objectives, builds a cross functional team, creates a charter and sets governance for cloud adoption. It emphasises that the CCoE owns both business and technical aspects of implementation, and recommends starting with low risk pilot projects while you develop capability and guardrails.

Microsoft’s Cloud Adoption Framework describes a CCoE as a function that helps an organisation balance speed and stability, and highlights typical roles such as cloud strategy, governance, adoption, platform and automation.

In a multicloud context, this means you should avoid separate CCoEs per provider. Instead, create a single function that owns:

• a primary provider strategy and criteria for exceptions
• cross cloud policies for security, compliance and data
• standard landing zones in AWS, Azure and Google Cloud
• shared patterns for networking, identity, tagging and cost allocation

If that function can make and enforce decisions across clouds, you avoid drift where each platform is treated as a separate world.

Make metadata and policy portable across clouds

Most governance problems show up first as messy metadata. You cannot manage cost, ownership or compliance across three providers if each uses a completely different labelling scheme.

On AWS, tags are key value pairs attached to resources so that you can track cost, ownership and automation targets. AWS guidance recommends standard tag keys such as environment, application and cost centre, and highlights uses such as attribute based access control and financial management.

Azure offers tags as metadata elements for resources, resource groups and subscriptions. Tags are also key value pairs that help you identify resources by environment, workload or business unit, and can be enforced using Azure Policy for governance and cost allocation.

Google Cloud provides labels, also key value pairs, which you can attach to many resource types. Labels are surfaced in billing so that you can break down charges by label values and apply consistent cost allocation policies. Best practice guidance encourages organisations to define a formal labelling policy that aligns with key stakeholders.

A practical multicloud pattern is to define a small, shared taxonomy such as business_unit, application, environment, owner and criticality, then implement that using:

• AWS tags and cost allocation tags
• Azure tags combined with Azure Policy to enforce required keys
• Google Cloud labels defined at project and resource level

This lets you build cross cloud views for compliance and cost without relying on provider specific naming conventions.

Place workloads deliberately and design the network first

Moving to multicloud does not mean splitting every workload across providers. In fact, tightly coupled or “contiguous” application components usually belong on a single primary cloud region to avoid latency, complexity and operational risk.

Network design is therefore one of the first decisions. Each provider offers private connectivity from your locations into its cloud:

• AWS Direct Connect provides dedicated network connections from your premises to AWS, designed to increase bandwidth throughput and deliver a more consistent experience than internet based links.
• Azure ExpressRoute lets you extend on premises networks into Microsoft cloud services such as Azure and Microsoft 365 over a private connection through a connectivity provider.
• Google Cloud Interconnect offers low latency, highly available connections from your networks into Google Cloud, and Cross Cloud Interconnect extends this to support private connectivity between Google Cloud and other clouds.

A common pattern is to keep transactional systems and their primary databases in one cloud, using the provider’s regional high availability options, then replicate or stream data into analytics or AI platforms running elsewhere. For example, you might:

• Run an order management platform in AWS, possibly extended on premises using AWS Outposts, which brings managed AWS infrastructure, services, APIs and tools into your data centre
• Export operational data into analytics platforms in Azure over ExpressRoute
• Feed curated datasets into Google Cloud using Cloud Interconnect or Cross Cloud Interconnect for advanced analytics or machine learning

This keeps synchronous dependencies within one provider while still letting you exploit specialist services from others.

Use managed Kubernetes to increase portability, not to avoid cloud native services

Containers and Kubernetes are now the default abstraction for portable application platforms. Used well, they provide a consistent operational model across clouds without forcing everything into the lowest common denominator.

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that runs conformant clusters on AWS and on premises. It offloads control plane management while letting you integrate with the broader AWS ecosystem.

Azure Kubernetes Service (AKS) is a managed Kubernetes service that reduces the operational overhead of running Kubernetes in Azure, making it easier to deploy and manage containerised applications with minimal orchestration expertise.

Azure Arc enabled Kubernetes allows you to attach clusters running anywhere and manage them through Azure for consistent configuration, policy and GitOps based deployment. AWS Outposts brings native AWS services, including EKS, into on premises environments for a consistent hybrid experience. In practice, many organisations standardise on Kubernetes for the application layer, then:

• use EKS for workloads primarily on AWS
• use AKS where integration with Azure services and identity is strongest
• use GKE, optionally with Anthos, for Google centric workloads or when they want a unified control plane spanning clouds

Kubernetes gives developers a familiar deployment model, while cloud native services such as managed databases, messaging and security tools remain specific to each provider.

Build shared observability and security across clouds

Operating multiple clouds without a coherent observability and security story quickly becomes unmanageable. Fortunately, each provider offers capabilities that extend beyond its own platform.

On AWS, Systems Manager and Amazon CloudWatch can be used to monitor hybrid and multicloud environments, including virtual machines and applications in Azure and Google Cloud. AWS shows reference architectures in which CloudWatch dashboards provide a unified operational view across providers.

Azure Monitor is a comprehensive monitoring solution for collecting and analysing telemetry from cloud and on premises environments. With Azure Arc, you can connect servers and Kubernetes clusters in AWS and Google Cloud so that metrics and logs flow into Azure Monitor and Log Analytics for centralised analysis.

On the security side, AWS Security Hub aggregates findings from AWS services and supported third party products to give a consolidated view of security posture and compliance across AWS accounts. Microsoft Defender for Cloud is a cloud native application protection platform that can connect to AWS accounts and Google Cloud projects for agentless posture management and workload protection, with a unified secure score. Google Cloud’s Security Command Center is a risk management solution for Google Cloud, and the Enterprise tier is positioned as a multicloud risk management platform, integrating cloud security with security operations to manage risk across environments.

A pragmatic choice is to designate one of these platforms as your primary view of risk and posture, then integrate it with your SIEM and incident management tooling. The CCoE should define how findings from individual providers roll up into central processes, rather than expecting each team to juggle three or more consoles.

Treat cost management as a cross cloud product

Multicloud rarely saves money by itself. Without a deliberate approach to financial operations, it often does the opposite. Cost management needs to be treated as a cross cloud product with common data structures and shared dashboards.

On AWS, Cost Explorer provides an interface to visualise and analyse historical and forecasted spend, including the ability to group and filter by accounts, services and tags. For more detailed analysis, AWS Cost and Usage Reports deliver line item billing data, with resource level metadata, to Amazon S3 for analysis in tools such as Amazon Athena.

Azure Cost Management and Billing helps you analyse, monitor and optimise Microsoft cloud spend, offering tools for budgets, cost allocation and reporting within the Azure portal.

On Google Cloud, Cloud Billing export to BigQuery lets you export detailed usage and cost data throughout the day to a BigQuery dataset. You can then query that data directly or surface it in tools such as Looker Studio.

If your tag and label strategy is consistent, you can ingest:

• AWS Cost and Usage Reports keyed by cost allocation tags
• Azure Cost Management data broken down by tags and subscriptions
• Google Cloud billing export grouped by labels

into a shared analytics environment. That environment might be a data warehouse on one of the clouds or a neutral platform. The important point is that every business unit and product sees a single, reconciled view of cost across providers, along with agreed unit metrics such as cost per customer or per transaction.

Bringing it all together

A successful multicloud strategy usually has a primary provider and a clear set of justified exceptions. It relies on a single CCoE that can define policies and patterns across clouds, on a shared metadata model that feeds governance, security and cost, and on solid network design that respects data gravity.

Containers and managed Kubernetes services such as EKS, AKS and GKE provide a common platform for applications, while tools like Anthos, Azure Arc and AWS Outposts extend control planes into other environments. Observability and security platforms from each provider can reach beyond their own walls, but you need to choose how they fit together. Cost management finishes the picture by treating spend across AWS, Azure and Google Cloud as a single problem.

Approached in this way, multicloud stops being an accidental outcome of past decisions and becomes a deliberate architecture and operating model that supports resilience, compliance and innovation.