Multi-Cloud Strategy Vocabulary

Vendor lock-in: a situation where an organisation becomes so deeply dependent on a single cloud provider's proprietary APIs, managed services, or pricing model that switching providers is extremely costly — in time, money, and effort. Multi-cloud: a strategy of using two or more cloud providers (e.g., AWS + GCP, or Azure + AWS) to distribute workloads, avoid lock-in, and leverage best-of-breed services. Key multi-cloud vocabulary: Cloud portability — the ability to move workloads between cloud providers with minimal rework. Achieved via containers, Kubernetes, and cloud-agnostic tooling. Abstraction layer — a software layer (e.g., Terraform, Kubernetes, a cloud-agnostic SDK) that hides provider-specific APIs, enabling portability. Cloud-agnostic — designed to function on any cloud provider without depending on proprietary features. In conversation: "We adopted an abstraction layer — all infrastructure is in Terraform modules and all compute runs in Kubernetes — so we're not tied to any single provider's managed services."

Workload placement: the strategic decision of which cloud provider (or which region within a provider) should host a specific workload, based on factors such as available services, performance, cost, and data residency requirements. Related multi-cloud concepts: Active-active multi-cloud — the same workload runs concurrently across two or more providers, sharing live traffic. Provides zero-downtime resilience but requires sophisticated routing and data synchronisation. Failover cloud — a secondary provider that receives traffic only when the primary fails. Simpler to operate than active-active, but involves a brief outage during switchover. Latency-optimised routing — directing user requests to the cloud region or provider with the lowest network latency for that user's location. Often implemented via Anycast DNS or a global load balancer (e.g., AWS Global Accelerator, Cloudflare). In conversation: "We use latency-optimised routing — UK users hit AWS eu-west-2, EU users hit GCP europe-west4, and the two regions share a read replica for the database."

Egress cost (also: data transfer cost / data egress fee): the charge a cloud provider applies when data leaves its network. Ingress (data coming in) is typically free. Egress is often the hidden cost that makes multi-cloud more expensive than planned. Typical egress rates: AWS charges ~$0.09/GB out to the internet; inter-provider transfers between AWS and GCP incur both AWS egress and GCP ingress. Multi-cloud cost vocabulary: FinOps (multi-cloud) — the practice of managing and optimising cloud financial operations across multiple providers simultaneously. Requires unified cost visibility tools (e.g., CloudHealth, Apptio) because each provider has separate billing consoles. Governance policy — rules and guardrails applied across cloud providers: tagging standards, approved regions, permitted services, spending limits. Cloud management platform (CMP) — software that provides a single pane of glass for managing resources, costs, and policies across multiple cloud providers (e.g., HashiCorp Terraform Cloud, Morpheus, VMware Aria). In conversation: "We redesigned the data pipeline to keep the ML training data inside GCP rather than pulling it from AWS every night — that alone cut our egress bill by 80%."

Data residency (also: data sovereignty): the legal, regulatory, or contractual requirement that data must be stored and processed within a specific geographic territory — typically a country or region. Common drivers: GDPR (EU/EEA), UK GDPR, NHS data governance, financial regulators (FCA, PRA), and government contracts. Multi-cloud data residency patterns: Geo-pinned deployments — cloud accounts or projects are scoped to specific regions; automated policy prevents resource creation outside permitted regions. Policy-as-code enforcement — governance policies are expressed in code (AWS SCP, GCP Organisation Policies, Azure Policy) and enforced at the platform layer. Cloud broker — an intermediary platform or service that abstracts cloud provider selection, routing workloads to the correct provider and region based on data classification and residency rules. In conversation: "We use GCP's europe-west2 (London) region for UK NHS data, Azure UK South for our government contract data, and enforce residency via Organisation Policies so no engineer can accidentally deploy patient records to a US region."

Active-active multi-cloud: an architecture where the same production workload runs concurrently on two or more cloud providers, each handling live traffic. No idle standby — both providers are active. During a provider outage, the load balancer redistributes traffic to the surviving provider automatically. Compared with failover cloud (active-passive): in a failover architecture, the secondary cloud is on standby (cold or warm) and only receives traffic after the primary fails. This is simpler and cheaper to operate, but involves some downtime during switchover. Active-active multi-cloud challenges: Data synchronisation — keeping databases consistent across providers (often solved with a globally distributed database or a primary DB that both providers access). Consistency and latency — cross-provider writes add latency; eventual consistency models may be required. Operational complexity — two sets of infrastructure, two billing accounts, two monitoring integrations. Requires a cloud management platform for unified visibility. Key term: cloud broker — a platform or service that sits in front of multiple providers and manages routing, policy enforcement, and cost allocation. Can be a vendor product (e.g., HashiCorp) or a custom internal platform team capability. In conversation: "Active-active doubled our operational overhead, but our SLA improved from 99.9% to 99.99% — the business decided the reliability was worth it."