Step 8 · Day 5 · 08

Multi-Cloud Enablement — Future-Ready Guide

STEP 8 · DOCUMENT 8 OF 9 · DAY 5

Multi-Cloud Enablement — Future-Ready Guide

Decision framework and reference architectures for extending the OCI + Fusion estate to Azure, AWS, or Google Cloud — and the reservations to make TODAY so a second cloud lands without re-architecture

A readiness and strategy document, not a build runbook. Its output is a set of recorded decisions, reservations, and reference patterns. Nothing in it commissions a second cloud — that would be its own engagement, gated by the decision framework in §2.

Day 5 Multi-Cloud Enablement — Future Ready

Field	Value
Document ID	<CUSTOMER>-STR-MC-008
Version	v1.0 (Generic Template)
Execution model	STRATEGY DOCUMENT — execution-agnostic. Where interconnects are eventually built, they follow the same dual-path discipline as Docs 3–4 (manual or Terraform/ORM; stack2 already carries the azure_fastconnect pattern).
Customer	<CUSTOMER> — replace on engagement start
Tenancy	<TENANCY-NAME> / OCID: <TENANCY-OCID>
Prepared by	Cloud Platform Engineering
Review cycle	Per engagement; template annually

1. Purpose and Position in the Series

Docs 1–7 build and operate a single-cloud (OCI) estate with Fusion SaaS. Most customers, however, already live in more than one cloud whether they admit it or not: Microsoft 365 and Entra ID mean Azure adjacency from day one; analytics teams buy elsewhere; acquisitions arrive with AWS accounts. This document does two things: gives the governance board a disciplined way to decide WHEN a second cloud is justified (§2), and lists the low-cost reservations the platform team makes NOW so that decision, whenever it comes, is an extension rather than a re-architecture (§6). The reference patterns in §3–§5 are the shapes such an extension would take.

ALREADY MULTI-CLOUD IN ONE SENSE:If <IDP> is Microsoft Entra ID, the identity control plane already lives in Microsoft’s cloud, and every OCI login transits it. The federation work of Doc 3 §2.4 is therefore the first multi-cloud integration this estate has — treat it as the template: one identity authority, per-cloud enforcement.

2. Decision Framework — When a Second Cloud Is Justified

2.1 Valid drivers (any one may justify; document which)

Driver	Typical shape	Weight
Data gravity / licensed platform elsewhere	Analytics stack on Azure (Fabric/Synapse/Power BI) consuming Fusion data; SaaS products that only ship on AWS.	Strong — you follow the workload, not the fashion.
Microsoft estate depth	Heavy M365/Entra/Power Platform investment; Oracle Database@Azure lets Oracle workloads sit inside Azure DCs.	Strong where the app team lives in Azure.
M&A / inherited estates	Acquired company arrives with production AWS/GCP.	Forced — govern it rather than debate it.
Regulatory / concentration risk	Regulator or board requires demonstrable exit path / second provider.	Valid — but often satisfied by portability evidence, not a live second estate.
Best-of-breed service	A genuinely differentiated service (e.g., a specific AI platform) unavailable on OCI.	Case-by-case; weigh against §2.2 costs.

2.2 The standing costs (must be priced into any yes)

Egress and interconnect: data crossing clouds is metered (OCI↔Azure Interconnect traffic is an honorable exception on the OCI side); chatty cross-cloud architectures bleed money and latency.

Second governance surface: every Doc 1 control (identity, tagging, budgets, posture management, audit) must exist twice, in different native dialects — or through added tooling.

Skills tax: a 2–5 person platform team running two clouds well is rare; assume training or hiring.

Security posture parity: Cloud Guard has no jurisdiction in Azure/AWS — Defender for Cloud / Security Hub must be raised to the same bar, and findings unified somewhere.

DECISION POINT:The Board answers three questions in writing: (1) which driver from §2.1 applies and why the workload cannot reasonably live on OCI; (2) who owns the second cloud’s governance surface (named team, not "IT"); (3) what the egress/latency model is. No second-cloud build starts without this record — the same PRD-first discipline as everything else in this series.

3. Reference Pattern — OCI + Azure

3.1 Connectivity: OCI–Azure Interconnect

Preferred where both regions pair: the Oracle-Microsoft Interconnect links FastConnect (OCI side) to ExpressRoute (Azure side) at partnered regions with ~2ms-class latency, no intermediate provider, and no OCI-side egress charge for the interconnect path. The terraform_lz stack2 azure_fastconnect folders already carry this pattern — nonprod and prod variants — so Option B engagements build it as a reviewed stack, not a console improvisation.

Where regions do not pair: a partner NaaS (Megaport-class) provides FastConnect + ExpressRoute virtual circuits into the same fabric — same pattern as §4.

Topology rule: the interconnect lands on the existing DRG (hub). Azure side lands on an ExpressRoute gateway in a hub VNet. Spoke discipline mirrors on both sides; transitive routing decisions are made deliberately and documented, never left to defaults.

3.2 Identity and access

Entra ID is already the authority (Doc 3): Azure subscriptions consume it natively; OCI consumes it federated. One joiner/mover/leaver process covers both clouds — extend the group standard with a per-cloud prefix (OCI-* / AZ-*) and keep the SoD matrix (Doc 1 §11) cloud-agnostic.

Oracle Database@Azure and similar co-located services authenticate against OCI IAM but are operated from Azure — record explicitly which console/plane administers what, extending the two-plane boundary rule to a three-plane table.

3.3 Typical Azure-adjacent workloads for this estate

Workload	Pattern
Analytics on Fusion data	FDI/ADW remains the certified source; curated extracts flow OCI → Azure over the interconnect (never direct Fusion extracts from Azure — the two-plane rule holds); Power BI reads the curated layer.
Oracle Database@Azure	Exadata/ADB physically in Azure DCs, OCI control plane; use when the application tier is committed to Azure but the database must stay Oracle-grade.
File/event exchange	OIC remains the integration authority; Azure Service Bus / Storage events integrate through OIC connectors — one error-hospital, not two.

4. Reference Pattern — OCI + AWS / Google Cloud

Connectivity: no first-party interconnect equivalent — use a partner fabric (Megaport-class NaaS): FastConnect virtual circuit on the OCI side, Direct Connect (AWS) or Partner Interconnect (GCP) on the other, meeting in the provider fabric. The stack2 megaport_fastconnect folders are the OCI half of exactly this pattern. Latency is fabric-dependent — measure before promising anything.

Oracle Database@AWS / @Google Cloud: same co-location model as §3.3 — Oracle-managed database services inside the hyperscaler’s DCs where the app estate lives there.

Identity: same one-authority rule — Entra/Okta federates AWS IAM Identity Center / Google Cloud Identity; per-cloud group prefixes (AWS-*, GCP-*); no cloud-local human users anywhere, break-glass excepted per cloud.

Integration: OIC remains the broker for Fusion-adjacent flows; direct point-to-point between hyperscaler services and Fusion is the anti-pattern this series exists to prevent.

5. Governance Parity Across Clouds

Doc 1 control	OCI mechanism	Azure equivalent	AWS equivalent
Structure	Compartments	Management groups / subscriptions / resource groups	Organizations / OUs / accounts
Tags	<CUSTOMER> namespace, defaults enforced	Azure Policy tag enforcement	Tag policies + SCPs
Budget guard-rails	Budgets + quotas	Cost Management budgets + Azure Policy	Budgets + SCP/service quotas
Posture	Cloud Guard + Security Zones	Defender for Cloud + Azure Policy initiatives	Security Hub + Config rules
Audit	Audit service, 365d, log sinks	Activity Log → Log Analytics	CloudTrail → S3/CloudWatch
IaC + pipeline	Terraform via ORM (Doc 3 §7)	Same repos/pipeline family, azurerm provider, state per cloud	Same, aws provider

One tag SCHEMA across clouds (same keys, same LOVs) even though enforcement mechanics differ — cost and ownership reporting must join across clouds on identical keys.

One pipeline discipline: separate repos per cloud (<customer>-azure-terraform-*, …) but the same branch model, review gates, and Phase 1 GitHub → Phase 2 GitLab progression from Doc 3 §7 — reviewers change, the process does not.

One findings review: per-cloud posture tools feed one triage (SIEM or the security team’s queue) so severity language and SLAs (Doc 5 §4) stay uniform.

6. Future-Ready Reservations — Do These TODAY

Every item below is cheap now and expensive later. This checklist is the actionable core of the document; run it once during the primary build and re-verify annually.

CIDR reservations: extend the Doc 3 §5.1 registry with non-overlapping blocks reserved per future cloud (e.g., 10.60.0.0/14 Azure, 10.64.0.0/14 AWS, 10.68.0.0/14 GCP) alongside the DR reserve. Never let a second cloud pick its own ranges. Record in the design registry even though nothing is built.

DRG as hub: keep the DRG the single hybrid hub (Doc 3 §5.4); any future interconnect is one more DRG attachment, not a new topology. Confirm DRG attachment capacity in limits reviews.

Partner-capable FastConnect: where hybrid connectivity is being procured anyway, prefer a NaaS partner (Megaport-class) whose fabric also reaches ExpressRoute/Direct Connect — the cross-connect exists before the decision does.

DNS namespace plan: reserve per-cloud private zones now (<env>.<customer>.oci · .az · .aws) and keep resolver rules explicit — split-brain DNS is the classic multi-cloud wound.

Identity: keep ALL authorization flowing through IdP groups (already the Doc 3 rule); reserve the per-cloud group prefix convention in the naming standard (Doc 1 §8 note).

Tag schema: declare in Doc 1 that the tag namespace schema is the cross-cloud standard; add a Cloud key (LOV: OCI·Azure·AWS·GCP) to the namespace now, defaulted OCI — reports become multi-cloud-ready with zero migration.

Egress awareness: any new integration design records its cross-cloud data volume assumption (even if "none") — the review question that keeps chatty architectures from creeping in.

Portability evidence (for the regulatory driver): keep the Terraform repos + this runbook series as the documented exit/rebuild path; that evidence often satisfies concentration-risk requirements without building anything.

VERIFY:Future-ready gate: CIDR + DNS + group-prefix + Cloud-tag reservations recorded in the design registry and Doc 1 adaptation; DRG confirmed as hub; partner-fabric question answered in the connectivity procurement; §2 decision framework adopted by the Board. Re-verify annually with the governance review.

7. Decision Register (template)

ID	Decision	Status	Owner / notes
MC-01	Second-cloud driver assessment (§2) — is any driver live?	OPEN	Board, annual review
MC-02	Reserved CIDR blocks per cloud	<DATE>	Network; registry updated
MC-03	Cloud tag key added to namespace	<DATE>	Security admin
MC-04	Interconnect partner capability (NaaS vs direct)	OPEN	With hybrid procurement
MC-05	Posture-parity tooling choice (per-cloud native + unified triage vs CSPM product)	OPEN	Security; decide only when MC-01 goes live
MC-06	Oracle Database@Azure/@AWS applicability	OPEN	Revisit when app-estate strategy lands

Revision History

Version	Date	Description
1.0	<DATE>	Generic template — multi-cloud future-ready strategy edition.