The pitch for multi-cloud always sounds clean. Avoid vendor lock-in. Optimize costs by running workloads on whichever provider is cheapest for a given task. Improve resilience by distributing across independent failure domains. On paper, it's a compelling case. In practice, the teams living with multi-cloud deployments often describe something closer to the opposite: doubled operational complexity, halved observability, and a category of reliability problems that only exist because there are two clouds instead of one.A team I worked closely with made the move to multi-cloud workloads on AWS and ML inference pipelines on GCP because of better GPU availability and pricing at the time and spent the next eight months dealing with a class of incident they hadn't anticipated: failures that were neither the application's fault nor either cloud provider's fault but existed in the boundary between them. Data transfer latency spikes that only appeared under load. Authentication token expiry edge cases that only trigger during cross-cloud calls. Network policy interactions that passed every pre-production test and failed in production at 3 am. The problems weren't hard individually. They were hard because the diagnostic tools for each cloud pointed inward, and the failure lived in the space neither tool was looking at.