Multi-cloud strategies

A multi-cloud estate runs workloads on more than one provider and has to keep identity, network, data, deployment and observability coherent across all of them. AWS sells very few services designed for that job. Most of its management services govern AWS and nothing else, so the first task when planning a multi-cloud design is separating the services that actually cross the boundary from the ones that stop at it.

What crosses the boundary

Identity. IAM Identity Center can take an external identity provider as its source of users and groups, and can itself federate users into SAML 2.0 applications. That makes one directory — usually the corporate IdP — the single place where joiners and leavers are handled, with AWS as one relying party among several. What it does not do is grant permissions in another cloud; each provider still has its own authorisation model.

Network. Transit Gateway is a regional hub for VPCs, VPN connections and Direct Connect gateways. It reaches another cloud only the way it reaches a data centre: over an IPsec Site-to-Site VPN to that cloud’s gateway, or over Direct Connect into a colocation facility where the other provider also has a presence. Neither is a cross-cloud feature of Transit Gateway; both are ordinary attachments carrying traffic to somewhere that happens not to be AWS. Address planning matters more than the technology: overlapping CIDR ranges between clouds are the usual reason a connection that works in a lab cannot be used in production.

DNS and traffic distribution. Route 53 health checks any reachable public endpoint, not only AWS ones, and its latency, weighted and failover routing policies can therefore distribute traffic across providers or fail over between them. This is the most common working multi-cloud control, because it needs nothing from the other side beyond an address to point at.

Data movement. AWS DataSync transfers files and objects between AWS storage and on-premises storage, Google Cloud Storage, Azure Blob Storage, Azure Files and S3-compatible providers. For whole servers, AWS Transform MGN replicates physical, virtual and other-cloud servers into EC2 — note the direction: it brings workloads to AWS, it does not move them out.

Observability. The CloudWatch agent and the PutMetricData and PutLogEvents APIs accept data from any machine with credentials and network access, so a single CloudWatch account can hold metrics and logs from outside AWS. Teams that want to avoid that dependency instrument with OpenTelemetry and choose the backend later, which is the more portable arrangement.

Service discovery. AWS Cloud Map maintains a registry of application resources with custom attributes and health checks, and a registered resource does not have to be an AWS one.

What does not

Organizations and Control Tower govern AWS accounts. Service control policies, the account factory and the guardrails apply to AWS and have no visibility of any other provider. Treating them as a cross-cloud governance layer is the most common mistake on this subject.

CloudFormation provisions AWS resources only, as does the CDK, which synthesises CloudFormation templates. Where infrastructure as code has to span providers, teams generally standardise on a tool that is not owned by any of them.

Aurora Global Database and DynamoDB Global Tables replicate across AWS Regions, not across clouds. They solve a geography problem, not a provider-independence one. (Aurora global databases are created through the console, the aws rds create-global-cluster command or the API — there is no SQL statement that creates one.)

ECS and EKS are AWS control planes. What travels is the container image and, for Kubernetes, the manifests — portability comes from the packaging format and the orchestrator being an open standard, not from the managed service. ECS Anywhere and EKS Anywhere invert the arrangement by running the workload on hardware you manage, which is useful for hybrid estates but is not a way to run on a competitor’s managed platform.

Practices that hold up

• Standardise the unit of deployment. A container image and a Kubernetes manifest are the closest thing to a portable artefact. Anything that depends on a proprietary runtime, event format or managed database is where the cost of a second provider concentrates.
• Plan address space once. Non-overlapping CIDR allocation across every cloud and data centre has to be decided before the first VPC, because it cannot be retrofitted cheaply.
• Centralise identity, not authorisation. One directory, federated everywhere; permissions stay native to each platform.
• Decide what each provider is for. Multi-cloud that is genuinely a split of responsibility — one provider for the product, another for a specific capability — is operable. Multi-cloud that means running the same workload twice doubles the operational surface and the number of staff who must be current on two platforms, and is rarely justified by the resilience it buys.
• Budget for egress. Moving data between providers is billed on the way out and is often the dominant recurring cost of a cross-cloud design.