Multi-Cloud Strategy skill for Codex

Multi-cloud is a cost you pay for a specific benefit. A sound decision names that benefit (a regulation, a customer contract, a capability only one provider has, an acquisition, a credible exit plan), prices it, and chooses the cheapest level of portability that delivers it. “Avoiding lock-in” without a scenario is not a requirement; most teams are better served by one primary cloud, portable seams, and a tested exit plan.

Inspect first

1. Read AGENTS.md, the IaC repositories, architecture docs and ADRs, and the current cloud bill by service. The bill shows where lock-in really sits (managed databases, queues, identity, analytics).
2. Interview for the driver. Ask the user who is asking for multi-cloud and why; capture the exact wording of any regulation, contract clause or board request.
3. Inventory proprietary dependencies per workload: managed data stores, serverless triggers, IAM model, observability, CI/CD, DNS and CDN.

Classify the driver

Driver	Typical right answer
Regulator requires an exit strategy (for example EU DORA for financial entities)	Documented, periodically tested exit plan; data export and rebuild runbooks. Not active-active
Customer contract requires their cloud or region	Deploy the specific product to that cloud; keep the rest single-cloud
Best-of-breed service (BigQuery analytics, a specific AI model or GPU supply)	Segmented multi-cloud: one workload per cloud, clear data flows
Acquisition brought a second cloud	Coexist with shared identity, observability and guardrails; consolidate only where the business case is positive
Resilience against a full provider outage	Usually multi-region in one cloud first; cross-cloud active-passive only for the few systems that justify it
Price negotiation power	Credible only at large spend; a portable architecture plus a quote often suffices
Vague “no lock-in”	Portable seams and an exit plan; decline full portability

Levels of portability

Level	What it means	Cost
0. Single cloud, no plan	Use anything	Lowest; exit risk unknown
1. Exit-ready	Data exportable in open formats, IaC for everything, runbook to rebuild elsewhere, estimated time and cost	Low
2. Portable seams	Containers, Terraform/OpenTofu, OpenTelemetry, OIDC, Postgres-compatible databases, S3-compatible APIs behind adapters	Moderate
3. Segmented multi-cloud	Different workloads on different clouds, each native	Moderate to high: two skill sets, egress
4. Active-passive across clouds	Warm standby on a second cloud with replicated data	High: duplicate infra, replication, drills
5. Active-active across clouds	Same workload serving from both	Very high; lowest-common-denominator services, data consistency problems

Recommend the lowest level that satisfies the driver. Level 5 is rarely justified outside a few global-scale companies.

Lock-in scoring

Score each dependency 1 to 5 on exit difficulty and on value delivered.

Dependency	Exit difficulty	Value	Notes
Managed Postgres (RDS, Cloud SQL, Azure Database)	2	4	Standard engine; dump and restore or logical replication
DynamoDB, Firestore, Cosmos DB native APIs	4	4	Data model rewrite; wrap access in a repository layer
Serverless functions with provider triggers	3	4	Business logic portable if handlers stay thin
Proprietary analytics warehouse	3	5	SQL dialect and pipelines; export as Parquet or Iceberg
Cloud IAM and workload identity	4	5	Unavoidable; standardize on OIDC federation at the edges
Kubernetes (EKS, GKE, AKS)	2	3	Portable API, but load balancers, storage classes and IAM differ

High value plus high exit difficulty: keep it, wrap it behind an interface, and document the migration path. Low value plus high difficulty: avoid adopting it.

Portable seams worth having anyway

• Infrastructure as code for every resource (Terraform or OpenTofu modules per provider, not one abstract module pretending providers are the same).
• Containers with images in a registry you can mirror.
• OpenTelemetry for traces, metrics and logs so observability backends can change.
• OIDC workload identity federation for CI and cross-cloud access instead of static keys.
• Data in open formats (Parquet, Iceberg, Postgres dumps) with automated exports to a location outside the primary provider.
• Application code that reaches storage, queues and email through small adapters.

Costs that kill multi-cloud plans

• Egress: data leaving a cloud is billed per GB; replicating a busy database or serving cross-cloud API calls can exceed the compute bill. Model it with real traffic numbers.
• People: two clouds mean two IAM models, two networking models, two on-call skill sets and two security baselines.
• Lowest common denominator: active-active forces you to skip the managed services that made the primary cloud productive.
• Discount dilution: splitting spend lowers commitment discounts and enterprise tiers.
• Testing: a failover path that is not drilled at least twice a year does not work.

Workflow

• Write down the driver and the success criterion in one sentence each
• Inventory workloads and score dependencies
• Choose a portability level per workload, not one level for the company
• Estimate cost: infra delta, egress, people, tooling, lost discounts
• Define RTO and RPO for any cross-cloud failover and how it is drilled
• Draft the exit plan: data export, rebuild order, DNS cutover, estimated duration
• Record the decision as an ADR and set a review date
• Get sign-off from the owner of the driver (compliance, sales, board) before spending

Exit plan template

## Exit plan: <system> from <provider>
- Trigger conditions: <provider failure, contract end, regulatory order>
- Target: <alternative provider or on-prem>, level of readiness: <exit-ready | warm standby>
- Data: <stores, export format, location of latest export, export frequency, size>
- Rebuild order: <network -> identity -> data -> services -> DNS>
- Proprietary dependencies and replacements: <table>
- Estimated duration and cost: <weeks, $>, last validated: <date, drill result>
- Owners: <names or roles>

Decision memo output

## Multi-cloud decision: <scope>
**Driver:** <regulation / contract / capability / acquisition / resilience>
**Recommendation:** Level <n> for <workloads>; Level <m> for the rest
**Why not higher:** <cost, complexity, egress estimate>
**Why not lower:** <requirement it would fail>
**Costs:** infra +$X/mo, egress +$Y/mo, people <n FTE>, lost discounts $Z
**Risks and mitigations:**
**Exit plan status:** <exists / to be written by date>
**Review date:**

Verification

• Every recommendation traces to a stated driver; nothing justified by “lock-in” alone.
• Egress estimate uses measured traffic, not guesses.
• Failover or exit runbooks have a scheduled drill with an owner.
• Data exports exist outside the primary provider and a restore has been tested.

Gotchas

• Abstracting every cloud API behind your own layer often costs more than the migration it hopes to avoid. Abstract only data access and messaging seams.
• Kubernetes everywhere does not make you portable if you depend on cloud load balancer annotations, storage classes and IAM bindings. Count those as lock-in.
• A second cloud used only for backups still needs separate credentials, monitoring and access reviews; stale access there is a security risk.
• Multi-region within one provider covers most outage scenarios at a fraction of the cost; check whether that already satisfies the driver.