Multi-cloud is the standard recommendation for avoiding vendor lock-in and improving resilience. The pitch is sound: no single provider can take down your entire system, you can optimize costs by routing workloads to the cheapest cloud for each job, and you are not betting your business on one vendor's uptime.
The reality of operating multi-cloud at production scale introduces failure modes that single-cloud setups do not have. Most of these failures are invisible until they surface as user-facing incidents.
The Cross-Cloud Latency Problem
Within a single cloud provider, traffic between services in the same region travels over the provider's backbone network. Latency is low and predictable. The network is the provider's responsibility and is part of the SLA.
Traffic between cloud providers travels over the public internet. Latency is higher, more variable, and completely outside your control. BGP routing changes, congestion at internet exchange points, and peering agreements between ISPs affect your cross-cloud traffic in ways you cannot anticipate or mitigate.
Teams discover this when they move a latency-sensitive service to a different cloud provider. The service works fine in isolation. The integration tests pass. Production shows 200ms of added latency on calls that used to take 20ms, and nobody can explain why because the monitoring shows both services as healthy.
The fix is private connectivity: AWS Direct Connect, Azure ExpressRoute, or GCP Dedicated Interconnect with cross-cloud interconnects between them. This is expensive and requires procurement and provisioning time. Factor it into your multi-cloud architecture before you commit to cross-cloud service communication.
Observability Fragmentation
Each cloud provider has its own observability stack. AWS CloudWatch, Azure Monitor, GCP Cloud Monitoring. They have different data models, different query languages, different retention policies, and different cost structures.
Correlating a trace that starts in an AWS service and ends in a GCP service requires a vendor-neutral observability layer. Without it, you have two separate views of the same request and no way to see the complete picture.
OpenTelemetry is the answer here, but it requires intentional adoption. If your services were instrumented with cloud-specific SDKs before you went multi-cloud, re-instrumentation is a migration project. Plan for it.
IAM Is Not Portable
AWS IAM, Azure Active Directory, and GCP IAM are different systems with different concepts, different policy languages, and different security models. A service that needs to access resources in multiple clouds needs identities in each cloud's IAM system.
Managing these identities separately creates drift. The same logical role ends up with different effective permissions in each cloud. Auditing becomes a multi-system exercise. When you need to rotate credentials or respond to a security incident, you are doing it in three different consoles with three different tools.
Centralizing identity through a federation provider, using workload identity federation where available, or adopting a tool like Teleport or Vault that spans clouds helps, but adds its own operational layer.
The Cost Model Breaks
The cloud cost optimization tools your FinOps team uses are built for single-cloud. AWS Cost Explorer, Azure Cost Management, GCP Cost Table. They show you costs within their own cloud. Seeing the total cost of a workload that spans both AWS and GCP, including data transfer costs between them, requires building a custom cost aggregation layer or buying a third-party tool.
Data transfer costs between clouds are real and significant. Moving 1TB of data from AWS S3 to Azure Blob Storage is not free. In high-throughput architectures, cross-cloud data transfer can become a major cost line that was not in the original architecture estimate.
Multi-cloud is worth it for the right organizations. Going in with clear eyes about the operational complexity it adds is how you avoid the blind spots.