Neutral Multi-Cloud Deep Dive Portal

A practical, vendor-neutral comparison of Oracle Cloud Infrastructure, Amazon Web Services, Microsoft Azure, and Google Cloud - for architects and enterprise teams choosing services by workload, not by brand.

4 clouds, side by side Searchable service matrix Match & similarity ratings Workload decision matrix No "best cloud" claims

Last reviewed: July 2026 Cloud services change frequently - verify with current vendor documentation before production use.

THE CORE PRINCIPLE: NEUTRALITY

This portal does not favor any cloud. There is no "best cloud" overall - only "best for this workload, under these conditions." We rate how closely services map (Exact / Close / Partial / Conceptual / No direct / Provider-specific), name the real differences and gotchas, and tie every strength and weakness to a concrete condition. Where a mapping is weak, we say so rather than invent a false equivalent.

How to read this portal

The heart of the portal is the Service Comparison Matrix (section 1): a searchable, filterable table mapping each capability across all four clouds with a match rating and the key difference. The comparison sections (2-14) go deeper by domain; the decision sections (15-17) help you choose by workload; and the reference sections (18-19) cover troubleshooting and learning paths.

Match types

Exact Equivalent functionally the same, reason about it the same way Close same purpose, minor model differences to learn Partial overlaps part of the capability, or split across services Conceptual similar problem, genuinely different model - map intent, not mechanics No direct no real counterpart; rebuild from other primitives Provider-specific a capability that stands out on one cloud

Similarity levels

High = you can largely reason the same way | Medium = meaningful differences to learn | Low = design changes significantly | N/A = not comparable

The four clouds

Oracle Cloud (OCI)

Oracle Database estate, Exadata/Autonomous, bare metal, enterprise Oracle/EBS, multicloud DB partnerships.

Amazon Web Services

Breadth and maturity of services, large ecosystem/marketplace, deep serverless and data services.

Microsoft Azure

Microsoft ecosystem integration (Entra, Windows, SQL Server, M365), hybrid, enterprise governance.

Google Cloud

Data analytics (BigQuery), global network, Kubernetes/Cloud Run, AI/ML, developer-friendly cloud native.

These are context, not rankings

The lines above name common areas of fit, not verdicts. Any of the four can be the right choice depending on workload, existing investment, skills, compliance, cost model, and migration goals. Use the workload decision matrix (section 15) rather than a headline.

Reading the callouts

Architect note

Design-time trade-offs and decisions.

DBA note

Database-specific behavior and responsibilities.

Security note

Exposure, least privilege, and audit.

Cost note

Where money is spent and wasted.

Common mistake

Errors teams make, including fake equivalency.

1 - Matrix 2 - Foundation 3 - IAM 4 - Networking 7 - Databases 15 - Workloads 16 - Strengths 19 - Learning

Accuracy, neutrality & independence

This is an independent educational resource, not affiliated with or endorsed by Oracle, Amazon, Microsoft, or Google. Mappings are engineering judgments as of July 2026 and are deliberately conservative - a weak mapping is labeled weak. Service names, availability, limits, and pricing change frequently. Verify against each vendor's official documentation before any design, migration, or purchasing decision.

1. Multi-Cloud Service Comparison Matrix

A searchable, filterable map of capabilities across OCI, AWS, Azure, and Google Cloud - with a match rating, similarity level, key difference, common use case, and gotcha for each. Click any row to expand the detail.

Last reviewed: July 2026 Mappings are engineering judgments - verify with current vendor docs.

ExactClosePartialConceptualNo directProvider-specific

Capability	OCI	AWS	Azure	Google Cloud	Match

Showing services side by side does not imply they are interchangeable. Read the match rating and the "key difference" - a Conceptual or Partial mapping means the architecture changes when you move.

2. Cloud Foundation Comparison

The account, identity, billing, and governance model of each cloud - the first thing that breaks a mental model when you cross clouds, because the isolation boundary sits in a different place in each.

Last reviewed: July 2026 Verify hierarchy limits and landing-zone guidance with current vendor docs.

TL;DR

All four clouds have a hierarchy, but the isolation boundary is placed differently. OCI keeps you in one tenancy and isolates inside it with compartments. AWS and GCP push isolation outward into many accounts / projects. Azure separates who you are (Entra tenant) from what you pay for (subscription) from where resources live (resource group). Get this right before production - restructuring later is painful on all four.

The hierarchy, side by side

Boundary	OCI	AWS	Azure	Google Cloud
Identity boundary	Tenancy (+ Identity Domains)	AWS account / IAM Identity Center	Entra tenant	Cloud Identity / Organization
Billing boundary	Tenancy	Account (+ payer/Organizations)	Subscription	Billing account (spans projects)
Deployment boundary	Compartment (in tenancy)	Account	Subscription	Project
Governance grouping	Compartments (nested)	Organizations + OUs	Management groups	Folders
Lifecycle grouping	Compartment	(tags / stacks)	Resource group	(project / labels)
Policy/constraint engine	Security Zones + Quotas	Service Control Policies (SCPs)	Azure Policy	Organization Policy
Access engine	IAM policies	IAM (JSON)	Azure RBAC (+ Entra roles)	Cloud IAM bindings

Architect note - the key difference

The number of top-level accounts differs by design. On AWS and GCP, a multi-account / multi-project strategy is the norm (isolation, blast radius, and quota live at that boundary). On OCI, you typically stay in one tenancy and use compartments. On Azure, you use many subscriptions under management groups, with resource groups for lifecycle. Copying one cloud's account strategy onto another (e.g. one giant subscription, or dozens of tenancies) is a common and costly mistake.

Hierarchy diagrams

Common design mistakes (all clouds)

Foundation mistakes

Everything in one account/project/subscription/root compartment - least privilege and cost attribution collapse together.
Copying another cloud's boundary strategy - e.g. dozens of tenancies (OCI), or one giant subscription (Azure), or too few accounts (AWS).
Skipping the landing zone and retrofitting governance, network hub, and central logging later.
Granting access high in the hierarchy so broad rights inherit everywhere including production.
No naming/tagging standard, breaking automation and chargeback.

Verify before production

Decide the hierarchy, landing zone, identity model, and network/CIDR plan before the first production workload on any cloud. These are the decisions that are expensive to reverse everywhere.

Vendor landing-zone references: OCI, AWS Control Tower, Azure CAF, GCP Cloud Foundation →

3. IAM and Security Model Comparison

How each cloud grants access, gives identity to workloads, and enforces least privilege - with a neutral view of where each model is simpler, stronger, harder, or riskier.

Last reviewed: July 2026 IAM features (PIM/JIT, deny, conditions) evolve - verify with current vendor docs.

TL;DR

All four grant access by binding a principal to a role/policy at a scope, and all provide keyless workload identity (the single biggest security win). The models differ: AWS JSON policies are powerful but have a learning curve; Azure splits Entra directory roles from Azure RBAC (a frequent confusion); OCI uses human-readable policy statements; GCP binds roles on the resource hierarchy and adds VPC Service Controls for data exfiltration. No model is universally better.

IAM capabilities, side by side

Capability	OCI	AWS	Azure	Google Cloud
Human roles	Groups + IAM policies	IAM users/roles + policies	Entra roles (directory) + Azure RBAC (resources)	IAM roles (basic/predefined/custom) + bindings
Workload identity (keyless)	Instance / Resource Principals	IAM roles (instance profile, IRSA)	Managed identities	Service accounts (attached) + Workload Identity Federation
External app identity	(users / dynamic groups)	IAM roles / OIDC federation	App registrations + service principals	Service accounts + Workload Identity Federation
Dynamic/attribute grouping	Dynamic groups	Tags + conditions	Dynamic groups (Entra) + conditions	IAM Conditions + tags
Federation / SSO	Identity Domains / SAML-OIDC	IAM Identity Center / SAML-OIDC	Entra ID (native IdP) + external	Cloud Identity / Workforce Identity Federation
MFA + conditional sign-in	Domain sign-on policies + MFA	MFA + Identity Center policies	Conditional Access (rich) + MFA	Context-Aware Access + MFA
Just-in-time privilege	Scoped policy + audit	Temporary assumed roles	PIM (turnkey JIT)	IAM Conditions / Privileged Access Manager
Explicit deny	(implicit deny; no deny stmts)	Deny statements + SCPs	Deny assignments + Policy	Deny policies + Org Policy
Data-exfil perimeter	Network + IAM controls	SCP + endpoints + policy	Private Link + Policy	VPC Service Controls
Audit	Audit	CloudTrail	Entra sign-in + Activity Log	Cloud Audit Logs

How each is simpler, stronger, harder, or riskier (neutral)

OCI IAM

Simpler: human-readable policy statements; one tenancy reduces cross-boundary friction. Harder: Identity Domains model and multi-domain planning. Riskier: broad manage all-resources or tenancy-level policies. Watch: native JIT/PIM maturity - verify.

AWS IAM

Stronger: very expressive JSON policies, conditions, permission boundaries, SCPs. Harder: the JSON policy learning curve; cross-account role assumption. Riskier: over-broad * policies; long-lived access keys.

Entra + RBAC

Stronger: Conditional Access + PIM are mature JIT/Zero-Trust tools; deep enterprise identity. Harder: the Entra-role vs RBAC split; control-plane vs data-plane roles. Riskier: standing Owner without PIM; app secrets not rotated.

Google IAM

Simpler: clean role bindings on the hierarchy. Stronger: VPC Service Controls for data isolation. Harder: basic vs predefined roles discipline. Riskier: basic roles (Owner/Editor); org-level grants; downloaded SA keys.

Cross-boundary access

	OCI	AWS	Azure	GCP
Cross-boundary model	Cross-compartment (in-tenancy) is low friction; cross-tenancy needs policies	Cross-account IAM role assumption (real friction)	Cross-subscription within a tenant is straightforward; cross-tenant is B2B/Lighthouse	Cross-project IAM in one org is straightforward; cross-org needs care
Implication	One-tenancy sharing feels seamless	Plan account topology up front - retrofitting is painful	Plan subscriptions/tenants; Lighthouse for managed access	Plan project/folder topology; org boundary matters

Security note - common to all four

Use groups (never individual users), keyless workload identity (never long-lived keys/secrets), the least role at the lowest scope, and federate human identity to your corporate IdP. Keep break-glass accounts, and eliminate standing privileged access (JIT where the cloud supports it). These principles are identical everywhere; only the mechanics differ.

Common IAM mistakes across clouds

Broad admin (Owner / * / manage all-resources); grants high in the hierarchy; long-lived keys/secrets instead of workload identity; mixing human and workload identities; not federating; no JIT for privileged roles; ignoring a data-exfiltration perimeter for sensitive data.

Vendor IAM references: OCI IAM, AWS IAM, Entra/Azure RBAC, Google IAM →

4. Networking Comparison

The software-defined network of each cloud, how private access to managed services differs, and where hub-and-spoke and hybrid designs map cleanly or diverge.

Last reviewed: July 2026 Verify gateway SKUs, limits, and private-access behavior with current vendor docs.

TL;DR

The core network object is nearly the same everywhere - except scope: OCI VCN, AWS VPC, and Azure VNet are regional, while GCP VPC is global (one VPC spans regions; subnets are regional). AWS subnets are AZ-bound. Private access to managed services is where models diverge most (Service Gateway vs per-service PrivateLink/Private Endpoint/PSC). Peering is non-transitive everywhere - use a transit hub. Plan non-overlapping CIDRs before anything else, on all four.

Core networking, side by side

Capability	OCI	AWS	Azure	Google Cloud
Virtual network	VCN (regional)	VPC (regional)	VNet (regional)	VPC (global)
Subnet scope	Regional or AD-specific	AZ-bound (one per AZ)	Regional	Regional (in global VPC)
Host/subnet firewall	Security Lists + NSGs	Security Groups (stateful) + NACLs (stateless)	NSGs + ASGs	VPC firewall rules
Managed network firewall	Network Firewall	Network Firewall	Azure Firewall	Cloud NGFW
Outbound NAT	NAT Gateway	NAT Gateway	NAT Gateway	Cloud NAT
Private service access	Service Gateway (all OCI svcs)	VPC Endpoints / PrivateLink (per service)	Private Endpoint / Service Endpoint (per service)	Private Google Access / PSC (per service)
VPC/VNet peering	Local/Remote Peering (DRG)	VPC Peering	VNet Peering	VPC Network Peering
Transit hub	DRG	Transit Gateway	Virtual WAN	Network Connectivity Center
Dedicated hybrid link	FastConnect	Direct Connect	ExpressRoute	Cloud Interconnect
DNS (public/private)	OCI DNS / Private DNS	Route 53	Azure DNS / Private DNS	Cloud DNS
Global LB / edge	Load Balancer (regional)	CloudFront + ALB/NLB + Global Accelerator	Front Door + App Gateway + LB	Cloud Load Balancing (global) + CDN
Reachability tooling	Network Path Analyzer, VCN Flow Logs	VPC Reachability Analyzer, Flow Logs	Network Watcher (IP Flow Verify, effective routes)	Connectivity Tests, Network Analyzer

Where concepts map cleanly - and where they don't

Maps cleanly (High similarity)

The base VPC/VCN/VNet + subnets + stateful firewall + NAT + peering + dedicated hybrid link are close across clouds. If you understand one, you understand the shape of the others; you mostly relearn names and limits.

Diverges significantly (Low similarity) - verify

Network scope: GCP's global VPC changes multi-region design; AWS's AZ-bound subnets force a subnet-per-AZ pattern the others don't need.
Private service access: OCI's one Service Gateway vs per-service endpoints on the others (and Azure Private Endpoint's mandatory Private DNS linkage) is the biggest source of "it connected but doesn't route/resolve."
Global load balancing / edge: single-anycast global LB (GCP), Front Door (Azure), CloudFront+Global Accelerator (AWS) differ a lot from OCI's more regional model.
AWS stateless NACLs have no direct equivalent - easy to lock yourself out.

Hub-and-spoke, side by side

Hub-and-spoke exists on all four, but the hub object and transit model differ (DRG / TGW / vWAN / NCC or Shared VPC). Peering is non-transitive everywhere.

Private connectivity to managed services - verify per service

The trickiest area to port. On AWS/Azure/GCP you generally create a private endpoint per service (and on Azure you must link a Private DNS zone or resolution fails). On OCI a single Service Gateway covers the OCI services network. When migrating a design, re-model the private-access layer explicitly - it rarely maps 1:1.

Vendor networking references: OCI VCN, AWS VPC, Azure VNet, Google VPC →

5. Compute Comparison

Virtual machines, bare metal, autoscaling, spot, GPUs, and serverless compute across the four clouds - with neutral workload-fit guidance.

Last reviewed: July 2026 VM families, SKUs, and pricing change often - verify with current vendor docs.

TL;DR

Core IaaS VMs are equivalent across clouds; the differences are in sizing units (OCI OCPU = 1 core ~ 2 vCPUs; others quote vCPUs), bare-metal breadth (OCI broad; others narrower), flexible sizing (OCI flexible shapes / GCP custom types vs AWS/Azure predefined families), and the serverless options. Autoscaling, spot, GPUs, and reservations exist everywhere with different names. Choose by workload fit, ecosystem, and cost model - not by a headline.

Compute, side by side

Capability	OCI	AWS	Azure	Google Cloud
Virtual machines	Compute (VM)	EC2	Virtual Machines	Compute Engine
Sizing unit	OCPU (= 1 core ~ 2 vCPU)	vCPU	vCPU	vCPU
Bare metal	Broad, everyday shapes	.metal instances (narrower)	Specialized SKUs	Bare Metal Solution (separate)
Flexible / custom sizing	Flexible shapes	(fixed families; some flex)	(fixed series; constrained vCPU)	Custom machine types
Autoscaling group	Instance Pools + Autoscaling	Auto Scaling Groups	VM Scale Sets	Managed Instance Groups
Spot / interruptible	Preemptible	Spot Instances	Spot VMs	Spot VMs
Dedicated hosts	Dedicated VM Hosts	Dedicated Hosts	Dedicated Hosts	Sole-tenant nodes
GPU / accelerators	GPU shapes (NVIDIA)	GPU instances (+ Trainium/Inferentia)	N-series GPU	GPU + TPU
Confidential computing	Confidential VMs	Nitro Enclaves	Confidential VMs	Confidential VMs
Keyless admin access	Bastion service	SSM Session Manager / EC2 Connect	Azure Bastion	IAP TCP / OS Login
Serverless containers	Container Instances	Fargate	Container Apps	Cloud Run
FaaS	Functions	Lambda	Azure Functions	Cloud Functions
Web PaaS	(compute + LB)	Elastic Beanstalk / App Runner	App Service	App Engine / Cloud Run

Where each is stronger / has limitations (neutral)

OCI

Strong when: bare metal and flexible shapes matter (licensing/perf), or Oracle-adjacent workloads. Verify: regional/GPU-SKU availability and third-party image ecosystem breadth.

AWS

Strong when: you want the broadest instance catalog, mature serverless (Lambda/Fargate), and custom silicon (Graviton/Trainium/Inferentia). Watch: instance-family sprawl and cost complexity.

Azure

Strong when: Windows/SQL/Microsoft workloads (Hybrid Benefit), App Service PaaS, and hybrid via Arc. Watch: SKU/series naming and zone availability by region.

GCP

Strong when: custom machine types, live-migration transparency, Cloud Run serverless, and TPU workloads. Watch: enterprise ISV image familiarity in some industries.

Workload-fit guidance (neutral)

Workload	Neutral guidance
Web / middleware	Any cloud; prefer serverless containers/PaaS (Cloud Run, Container Apps, App Runner, App Service) or autoscaled VM groups. Choose by ecosystem/skills.
Databases (self-managed)	Memory-optimized VMs + high-IOPS disks on any cloud; but evaluate the managed DB first (section 7).
Oracle workloads	OCI is often a strong fit (bare metal, licensing, Exadata); Oracle-on-VM or DB@Azure/@Google are valid depending on ecosystem.
Microsoft workloads	Azure is often a strong fit (Hybrid Benefit, integration); valid elsewhere with BYOL.
SAP	All four are SAP-certified on specific SKUs; verify certification, HANA sizes, and support per cloud.
Batch / HPC	Spot/preemptible + managed batch on any cloud; GPU/TPU availability differs.
AI/ML	GPU everywhere; TPU is GCP-specific; custom AI silicon on AWS. Evaluate the managed AI platform (section 10).
Cost-sensitive dev/test	Burstable/small shapes + auto-shutdown + spot on any cloud; commitments for baseline.

Cost note - normalize before comparing

Compute price comparisons are meaningless without normalizing (OCI OCPU vs vCPU), applying the right commitment/discount model, and accounting for licensing (Hybrid Benefit, BYOL) and egress. The cheapest option depends on the workload shape and your existing licenses - not on list price.

Vendor compute references: OCI Compute, AWS EC2, Azure VMs, Google Compute Engine →

6. Storage Comparison

Block, object, file, and archive storage across the four clouds - scope, performance, replication, and the security and cost gotchas that repeat everywhere.

Last reviewed: July 2026 Verify disk SKUs, redundancy options, and retrieval behavior with current vendor docs.

TL;DR

The four storage classes map closely: block (VM/DB disks), object (buckets - backups/lakes/static), file (NFS/SMB shares), and archive (cheap, delayed restore). S3 has the deepest object-storage ecosystem and is a de-facto API standard. Key portable warnings: object storage is not a filesystem, archive has a restore delay, public buckets are a top breach cause, and cross-region replication + snapshot sprawl add cost. Redundancy models (zonal/regional/multi-region) differ - verify per service.

Storage, side by side

Type	OCI	AWS	Azure	Google Cloud
Block	Block Volume	EBS	Managed Disks (Premium SSD v2 / Ultra)	Persistent Disk / Hyperdisk
Object	Object Storage (S3-compatible)	S3	Blob Storage	Cloud Storage
File	File Storage (FSS)	EFS / FSx	Azure Files / NetApp Files	Filestore
High-perf NAS	(FSS / NetApp on OCI)	FSx for NetApp/Lustre/Windows	Azure NetApp Files	(Filestore / partner)
Archive	Archive Storage	S3 Glacier tiers	Blob Archive tier	Archive class
Object tiers	Standard / IA / Archive	Standard / IA / Glacier	Hot / Cool / Cold / Archive	Standard / Nearline / Coldline / Archive
Lifecycle / immutability	Lifecycle + Retention	Lifecycle + Object Lock	Lifecycle + Immutable + soft delete	Lifecycle + Bucket Lock + versioning
Backup service	Backup policies / Full Stack DR	AWS Backup	Azure Backup	Backup and DR
Redundancy model	Local/regional; cross-region copy	AZ/Region; S3 = regional durable	LRS / ZRS / GRS / GZRS	Regional / dual / multi-region

Scope: zonal, regional, or global

Architect note - know the scope of each store

Availability depends on scope, which differs by service and cloud. Block volumes are generally zonal (with regional/replicated options on some clouds). Object storage is typically regional-durable with optional multi-region. File services vary (zonal vs regional/enterprise tiers). Do not assume a store survives a zone or region loss - check the redundancy setting (e.g. Azure LRS vs ZRS vs GZRS) and design HA/DR accordingly.

Warnings that repeat on every cloud

Portable storage warnings

Object storage is not a file system - no random writes or POSIX locking; use file storage for that.
Archive tiers have a restore/rehydration delay (hours) - never for immediately-needed data.
Public bucket exposure is a top breach cause - disable public access and enforce it by policy on all four.
Signed URLs / SAS / presigned URLs are bearer credentials - keep them short-lived and revocable.
Cross-region replication increases cost and adds RPO lag - a lagging copy is not DR.
Snapshot sprawl gets expensive - set retention and clean up.
Choosing the wrong redundancy / tier leaves data under-protected or over-priced - match to the data's value.

Cost note

Object-storage cost is storage + operations + retrieval (colder tiers) + egress. Block cost follows capacity and performance SKU. The frequently-underestimated items are egress, cross-region replication, and retrieval from cold/archive. Lifecycle policies to cold tiers are the highest-ROI storage optimization on every cloud.

Vendor storage references: OCI, AWS S3/EBS/EFS/FSx, Azure, Google Cloud →

7. Database Services Comparison

The deepest comparison - relational, Oracle, NoSQL, cache, and warehouse services across clouds, with a neutral decision matrix by workload. Not all "managed databases" are equal.

Last reviewed: July 2026 DB features, licensing, and Oracle DB@Azure/@Google availability change - verify with current vendor docs.

TL;DR

Managed relational OSS engines (PostgreSQL/MySQL) exist everywhere but vary in depth (Aurora, AlloyDB are enhanced engines). Oracle is deepest on OCI (Exadata, Autonomous, RAC), managed-but-limited on AWS RDS, and Oracle-operated via partnership on Azure/GCP. SQL Server is deepest on Azure. NoSQL, global, and warehouse services (Spanner, BigQuery; DynamoDB, Redshift; Cosmos DB) differ in model, not just name - migrations are re-modeling exercises. Match the service to the workload; do not treat all managed DBs as equal.

Relational & Oracle

NoSQL & cache

Warehouse

Relational and Oracle

Category	OCI	AWS	Azure	Google Cloud
Managed PostgreSQL	PostgreSQL / (HeatWave)	RDS / Aurora PostgreSQL	Azure DB for PostgreSQL (Flexible)	Cloud SQL / AlloyDB
Managed MySQL	MySQL HeatWave	RDS / Aurora MySQL	Azure DB for MySQL (Flexible)	Cloud SQL
Managed SQL Server	SQL Server on VM	RDS for SQL Server	Azure SQL DB / Managed Instance	Cloud SQL for SQL Server
Oracle Database	Base DB / Exadata / Autonomous / RAC	RDS for Oracle (limited)	Oracle DB@Azure (partnership)	Oracle DB@Google (partnership)
Globally distributed relational	Globally Distributed DB / Autonomous	Aurora Global	(Cosmos DB - multi-model)	Spanner
DBA still manages	Schema/SQL/tuning (Autonomous = least); patch/HA vary by service	Schema/SQL; RDS/Aurora manage patch/HA	Schema/SQL; PaaS manages patch/HA	Schema/SQL; PaaS manages patch/HA

DBA note - Oracle and SQL Server are the differentiators

For Oracle: OCI offers the only native Autonomous/Exadata/RAC managed experiences; AWS RDS for Oracle is managed but feature-limited; Azure/GCP run Oracle-operated Exadata via partnership (verify availability/terms). Oracle-to-Postgres on any cloud is a conversion, not lift-and-shift. For SQL Server: Azure has the deepest integration (SQL DB, Managed Instance, Hybrid Benefit); others offer managed SQL Server with varying compatibility. Licensing frequently decides the cheapest cloud.

NoSQL, key-value, document, and cache

Category	OCI	AWS	Azure	Google Cloud
Key-value / wide-column	NoSQL Database	DynamoDB	Cosmos DB (Table/Cassandra)	Bigtable
Document	NoSQL (JSON) / Autonomous JSON	DynamoDB / DocumentDB	Cosmos DB (NoSQL/Mongo)	Firestore
Graph	(Graph in Oracle DB)	Neptune	Cosmos DB (Gremlin)	(Spanner Graph / partner)
Time-series	(Oracle DB / OpenSearch)	Timestream	Azure Data Explorer	Bigtable
Cache (Redis)	Cache	ElastiCache	Azure Cache for Redis	Memorystore

Common mistake - fake NoSQL equivalency

DynamoDB, Cosmos DB, Bigtable, and Firestore all say "NoSQL," but their data models, consistency, throughput units, and key/partition design differ substantially. Moving between them is a re-modeling exercise, not a migration. Choose by access pattern and consistency need, and design the partition/row key for the specific service - it is the least portable decision in databases.

Data warehouse

Category	OCI	AWS	Azure	Google Cloud
Cloud data warehouse	Autonomous Data Warehouse	Redshift	Synapse / Microsoft Fabric	BigQuery
Architecture	Autonomous (Exadata-backed)	Cluster (RA3) / serverless	Dedicated/serverless pools; Fabric capacity	Serverless, storage/compute separated
Cost model	OCPU + storage (autoscale)	Node/RA3 or serverless	DWU/capacity or serverless bytes	Bytes scanned (on-demand) or slots

Data engineering note - warehouse cost models differ fundamentally

The warehouse choice reshapes both architecture and cost. BigQuery bills by bytes scanned (query design directly drives cost, partition/cluster to prune); Redshift and Synapse dedicated bill by provisioned compute; ADW by autoscaling OCPU. These are not interchangeable - the same workload can be cheap on one model and expensive on another. GCP is frequently strong for serverless analytics; verify against your query patterns and volumes.

Database decision matrix (neutral)

Workload	Neutral guidance & what to evaluate
Oracle enterprise	OCI is often a strong fit where Exadata/Autonomous/RAC or Oracle licensing dominate. AWS RDS for Oracle, Oracle-on-VM anywhere, or Oracle DB@Azure/@Google can be valid depending on ecosystem and migration goals. Verify feature parity and licensing.
SQL Server	Azure (SQL DB / Managed Instance / Hybrid Benefit) is often a strong fit. Managed SQL Server exists on AWS/GCP; SQL-on-VM anywhere for full control. Evaluate compatibility and licensing.
PostgreSQL	All strong. Evaluate Aurora (AWS) and AlloyDB (GCP) for higher performance; Flexible Server (Azure); Cloud SQL/OCI for standard. Pick by ecosystem and needed features (HTAP, vector).
MySQL	All strong (RDS/Aurora, Cloud SQL, Azure Flexible, HeatWave). HeatWave adds in-DB analytics; Aurora adds performance. Evaluate feature needs.
Global transactional	GCP Spanner for strong global consistency; Cosmos DB for multi-model global; Aurora Global for cross-region reads. Different models - verify consistency semantics.
High-scale key-value	DynamoDB, Bigtable, Cosmos DB are all strong at scale; choose by access pattern and consistency. Key design is non-portable.
Data warehouse	BigQuery (serverless, GCP), Redshift (AWS), Synapse/Fabric (Azure), ADW (OCI). Match the cost model to your query pattern.
Reporting	Any warehouse + BI (Looker, QuickSight, Power BI, OAC); or a read replica of the OLTP DB. Evaluate the BI stack you already use.
Cache	Managed Redis on all four - close equivalents; choose by cloud you're already on.
AI / vector search	Vectors in a managed DB (23ai/AlloyDB/pgvector/Cosmos) or a dedicated search/ANN service. Keep vectors near governed data where possible; evaluate scale/latency.

Verify before choosing

Database is the domain where "managed" varies most and where licensing, HA/DR model, patching control, and data-model portability differ sharply. Before committing: confirm feature parity for your exact requirements, the real operational responsibility split, DR/backup behavior, and the licensing impact - on the specific service, in the specific region.

Vendor database references: OCI, AWS, Azure, Google Cloud →

8. Containers, Kubernetes, and Serverless Comparison

Managed Kubernetes, serverless containers, and functions across clouds - and a neutral view of when to use each, plus the operational and cost trade-offs.

Last reviewed: July 2026 Verify managed-K8s modes, serverless limits, and pricing with current vendor docs.

TL;DR

Managed Kubernetes exists everywhere (OKE, EKS, AKS, GKE) and Kubernetes skills transfer - the cloud integration layer (networking, identity, ingress) does not. AWS ECS is a distinctive non-K8s orchestrator. Serverless containers (Fargate, Container Apps, Cloud Run, Container Instances) and functions (Lambda, Azure Functions, Cloud Functions, OCI Functions) remove cluster ops. Choose Kubernetes only when you need orchestration; otherwise serverless containers or functions are usually simpler and cheaper.

Containers & serverless, side by side

Capability	OCI	AWS	Azure	Google Cloud
Managed Kubernetes	OKE	EKS	AKS	GKE (Autopilot/Standard)
Non-K8s orchestrator	-	ECS	-	-
Serverless containers	Container Instances	Fargate	Container Apps	Cloud Run
Functions (FaaS)	Functions	Lambda	Azure Functions	Cloud Functions
Container registry	OCIR	ECR	ACR	Artifact Registry
Workload identity	Instance/Resource Principals	IAM Roles for Service Accounts (IRSA)	Entra Workload Identity	GKE Workload Identity
Ingress / LB integration	OCI LB via K8s service	ALB/NLB via controllers	App Gateway (AGIC) / LB	Cloud LB via Ingress/Gateway
Service mesh	(OSS / partner)	App Mesh / (Istio)	(OSS Istio / OSM)	Cloud Service Mesh (Istio)
Event routing	Events	EventBridge	Event Grid	Eventarc
Supply-chain security	Scanning (OCIR)	ECR scanning + Signer	Defender for Containers	Artifact Analysis + Binary Authorization

When to use which (neutral decision table)

Requirement	OCI	AWS	Azure	GCP	Trade-off
Orchestrated microservices, K8s ecosystem	OKE	EKS	AKS	GKE	Most control + most ops; needs K8s skills
Containers without a cluster, scale to zero	Container Instances	Fargate (App Runner)	Container Apps	Cloud Run	Less control; simplest ops; usually cheaper for small
Non-K8s orchestration	(serverless)	ECS	(Container Apps)	(Cloud Run)	ECS is AWS-specific and doesn't port
Event-driven short code	Functions	Lambda	Functions	Cloud Functions	Duration/concurrency limits; cold starts
Full OS control / GPUs at fine control	Compute	EC2	VMs	Compute Engine	Most ops; use when platforms don't fit

Architect note - neutral guidance

The decision is the same shape on every cloud: serverless containers/functions for most stateless work (least ops), managed Kubernetes when you need the orchestration ecosystem (fleets, mesh, operators, complex scheduling), and VMs when platforms don't fit. GKE (esp. Autopilot) and AKS are widely regarded as very mature Kubernetes; Cloud Run and Container Apps are strong serverless-container options; Lambda has the deepest FaaS ecosystem. Match to skills and workload, not brand.

Cost note

A Kubernetes cluster carries baseline node/control-plane cost on every cloud - don't run one for a couple of containers. Serverless containers/functions bill per usage and scale to zero, which is usually cheaper for small or spiky workloads. Use spot/preemptible node pools for fault-tolerant K8s work everywhere.

Vendor references: OKE, EKS/ECS/Fargate, AKS/Container Apps, GKE/Cloud Run →

9. Analytics and Data Platform Comparison

Data lakes, warehouses, lakehouse patterns, ETL, streaming, and governance across clouds - tying strengths to actual data patterns, not generic claims.

Last reviewed: July 2026 Data platforms evolve fast (Fabric, Iceberg, serverless) - verify with current vendor docs.

TL;DR

All four land data in object storage and process with managed Spark + ETL orchestration + a warehouse + BI. The warehouse is where architectures diverge most: BigQuery (serverless, bytes-scanned) is distinctive; Redshift + Lake Formation; Synapse/Fabric + Purview + Power BI. Databricks is a common cross-cloud lakehouse choice. Spark and open formats (Iceberg/Delta/Parquet) transfer skills; the platform integration and cost model do not.

Data platform, side by side

Capability	OCI	AWS	Azure	Google Cloud
Data lake storage	Object Storage	S3 (+ Lake Formation)	ADLS Gen2 / OneLake	Cloud Storage
Data warehouse	Autonomous Data Warehouse	Redshift	Synapse / Microsoft Fabric	BigQuery
Serverless SQL on lake	(ADW external tables)	Athena	Synapse serverless	BigQuery external / BigLake
Managed Spark	Data Flow	EMR / Glue	Synapse Spark / Databricks	Dataproc / Databricks
ETL / ELT orchestration	Data Integration	Glue	Data Factory	Dataflow / Data Fusion
Streaming ingestion	Streaming	Kinesis / MSK	Event Hubs	Pub/Sub
Stream processing	(Data Flow / GoldenGate)	Kinesis Data Analytics / Flink	Stream Analytics	Dataflow
CDC replication	GoldenGate	DMS	(Data Factory / Fabric)	Datastream
Governance / catalog	Data Catalog	Lake Formation / Glue	Microsoft Purview	Dataplex
BI / reporting	Oracle Analytics Cloud	QuickSight	Power BI	Looker / Looker Studio
Lakehouse / open format	(Iceberg on Object Storage)	Iceberg on S3 (Athena/EMR)	Delta (Fabric/Databricks)	BigLake (Iceberg) / Delta

Which cloud is strong for which pattern (neutral)

Data pattern	Neutral guidance
Serverless analytics warehouse	GCP BigQuery is frequently a strong fit (serverless, separation of storage/compute); Snowflake (multi-cloud), Redshift serverless, and Synapse/Fabric serverless are valid. Verify against query patterns and cost model.
Microsoft-centric analytics + BI	Azure (Fabric + Power BI + Purview) integrates tightly for Microsoft shops. Valid elsewhere with Power BI on other clouds.
Spark/lakehouse at scale	Databricks is a common cross-cloud choice; native options are EMR (AWS), Dataproc (GCP), Synapse Spark (Azure), Data Flow (OCI).
Oracle-centric analytics	OCI (Autonomous DW + GoldenGate + OAC) fits Oracle-heavy estates; GoldenGate is strong for CDC from Oracle.
Streaming ingestion	Pub/Sub + Dataflow (GCP), Kinesis/MSK (AWS), Event Hubs + Stream Analytics (Azure), Streaming (OCI). Kafka is portable if that matters.
Governed lake	Purview (Azure, broadest reach), Dataplex (GCP), Lake Formation (AWS), Data Catalog (OCI). Govern from day one.

Data engineering note - where skills transfer

SQL, Spark, and open table formats (Iceberg, Delta, Parquet) transfer well across clouds. What does not transfer cleanly: the warehouse's cost/scaling model, the native governance tool, the streaming service semantics, and the BI/semantic layer. Using open formats and Databricks/Spark reduces lock-in; deeply-integrated native stacks (BigQuery, Fabric) trade portability for productivity.

Cost note - warehouse cost traps

The biggest analytics cost surprises are consistent across clouds: unpartitioned/full scans (esp. bytes-scanned billing), always-on clusters for spiky workloads, cross-region data movement, and logging/streaming ingestion. Design for the specific warehouse's cost model - the same query can be cheap on one and expensive on another.

Vendor data references: OCI, AWS analytics, Azure Fabric/Synapse, Google BigQuery →

10. AI, ML, and Generative AI Comparison

Foundation models, RAG, vector search, and MLOps across clouds - with the governance warnings that apply identically everywhere.

Last reviewed: July 2026 AI moves fastest of all - verify model/region availability, quotas, pricing, and data-retention terms before design.

TL;DR

Every cloud has a managed foundation-model service (OCI GenAI, Bedrock, Azure OpenAI / AI Foundry, Vertex AI / Gemini), managed RAG, an MLOps platform, and vector search. They differ most in model catalog (Bedrock = many providers; Azure = OpenAI/GPT; Vertex = Gemini + open) and ecosystem depth (SageMaker, Vertex broadest). Choose by required models, region availability, and governance - not hype. The governance pattern (governed serving layer, security-trimmed retrieval, no raw OLTP access) is identical on all four.

AI/ML, side by side

Capability	OCI	AWS	Azure	Google Cloud
Managed foundation models	OCI Generative AI	Bedrock	Azure OpenAI / AI Foundry	Vertex AI / Gemini
Model catalog breadth	Curated	Many providers (Anthropic, Meta, etc.)	OpenAI/GPT + catalog	Gemini + open + partner
Managed RAG / agents	GenAI Agents	Bedrock Knowledge Bases / Agents	AI Search + Foundry agents	Vertex AI Search / Agent Builder
ML platform / MLOps	Data Science	SageMaker	Azure Machine Learning	Vertex AI
Vector search	AI Vector Search (23ai) / OpenSearch	OpenSearch / Aurora pgvector / Kendra	AI Search / Cosmos / pgvector	Vertex Vector Search / AlloyDB / BigQuery
Enterprise search	OpenSearch	Kendra / OpenSearch	Azure AI Search	Vertex AI Search
Document AI	Document Understanding	Textract	AI Document Intelligence	Document AI
Speech / Vision / Language	AI Services	Transcribe / Rekognition / Comprehend	AI Speech / Vision / Language	Speech / Vision / Natural Language
Content safety / guardrails	(guardrails)	Bedrock Guardrails	AI Content Safety	Safety filters / Model Armor
Private networking	Private endpoints	PrivateLink / VPC	Private Endpoints	PSC / Private Service Connect
AI in the data warehouse	(Autonomous + Select AI)	Redshift ML	(Fabric + OpenAI)	BigQuery ML

Where each is often strong (neutral)

OCI

In-database AI Vector Search (23ai) and Select AI keep vectors/AI next to Oracle data; curated GenAI. Verify model catalog breadth and region availability.

AWS

Bedrock's multi-provider model catalog and the mature SageMaker ecosystem; custom AI silicon. Broad but complex.

Azure

Azure OpenAI (GPT family) with enterprise controls, AI Foundry, and tight M365/Copilot integration. Verify model/region availability and quota.

GCP

Gemini models, Vertex AI breadth, BigQuery ML (AI in the warehouse), and strong data-plus-AI integration.

Enterprise patterns (same shape on all clouds)

Pattern	Neutral implementation
Chat with documents	Object storage + chunk/embed + vector store + managed RAG + a foundation model, behind a governed serving API. Same on all four.
Chat with database / NL-to-SQL	Retrieve from curated views; model proposes validated, read-only, parameterized SQL. Never raw prod OLTP.
Enterprise RAG	Security-trimmed retrieval (entitlement-filtered) + grounding + audit + content safety.
Document processing	Document AI/Textract/Doc Intelligence → extract → warehouse; human review of low-confidence.
Contact center AI	Speech + language + LLM + bot; grounding + human escalation.
MLOps pipeline	SageMaker/Vertex/Azure ML/Data Science pipelines + registry + monitoring; OpenTelemetry for portability.
AI over the warehouse	BigQuery ML / Redshift ML / Autonomous Select AI - run models where the data lives.

Governance warnings (identical on every cloud)

Do not do these - on any cloud

Do not connect LLM agents directly to production OLTP databases without a governed serving layer.
Avoid uncontrolled dynamic SQL - NL-to-SQL must be validated, parameterized, read-only, against a curated schema.
Do not expose production credentials to agents - use the cloud's workload identity + secret store, never keys in prompts/code.
Add auditability - log prompts, retrieved context IDs, and responses so answers are explainable.
Use curated datasets, APIs, or read-only reporting layers as the AI's data surface - not raw production tables.
Validate output before business use - treat model output as a draft until a human or deterministic check confirms it.
Monitor prompt injection and data leakage - use the cloud's content-safety/guardrail tooling; sanitize retrieved and user content.
Check model availability, region availability, pricing, and data-retention terms before design - these differ by cloud and change frequently.

Verify before choosing an AI cloud

The differentiators are the available models (and in which regions), quota/throughput, data-handling/retention terms, and governance tooling - all of which move fast. Do not choose an AI platform on a benchmark or announcement; verify the specific models and terms you need are available in your region today.

Vendor AI references: OCI GenAI, AWS Bedrock/SageMaker, Azure OpenAI/Foundry, Google Vertex AI →

11. Security Services Comparison

Posture management, threat detection, key/secret management, WAF/DDoS, and data protection across clouds - what each service does, what it does not, and a portable production checklist.

Last reviewed: July 2026 Security service tiers and coverage change - verify plan contents with current vendor docs.

TL;DR

Every cloud has the same security building blocks - CSPM (posture), threat detection, KMS/HSM, secrets, WAF/DDoS, audit logs, and data discovery. They differ in maturity, integration, tiering, and what's included vs. paid. The security principles (least privilege, keyless identity, private access, encryption with controlled keys, centralized logging, preventive policy) are identical everywhere; the tooling names and coverage differ. No cloud is universally more secure - security is mostly your configuration.

Security services, side by side

Capability	OCI	AWS	Azure	Google Cloud
Posture management (CSPM)	Cloud Guard + Security Zones	Security Hub + Config	Defender for Cloud	Security Command Center
Threat detection	Cloud Guard	GuardDuty	Defender for Cloud (plans)	SCC / Event Threat Detection
SIEM / SOAR	(Logging Analytics / partner)	Security Lake + partner SIEM	Microsoft Sentinel	Google SecOps (Chronicle)
Key management (KMS/HSM)	Vault (KMS + HSM)	KMS / CloudHSM	Key Vault / Managed HSM	Cloud KMS / Cloud HSM
Secrets management	Vault (secrets)	Secrets Manager / SSM	Key Vault (secrets)	Secret Manager
Certificate management	Certificates service	ACM	Key Vault certs	Certificate Manager / CA Service
WAF	WAF	AWS WAF	WAF (App Gateway/Front Door)	Cloud Armor
DDoS protection	(platform)	Shield	DDoS Protection	Cloud Armor / (platform)
Vulnerability scanning	Vulnerability Scanning	Inspector	Defender (VA)	SCC / Artifact Analysis
Sensitive-data discovery	Data Safe (DB)	Macie (storage)	Purview / Defender	Sensitive Data Protection (DLP)
Bastion / private admin access	Bastion	SSM Session Manager	Azure Bastion	IAP
Data-exfil perimeter	(network + IAM)	(SCP + endpoints)	(Private Link + Policy)	VPC Service Controls

What each does - and does not - do (neutral)

Security note - the tools find and enforce; you still design

CSPM tools (Cloud Guard, Security Hub, Defender, SCC) detect misconfiguration and threats; they do not fix your IAM or network design. WAFs need tuning (detection before prevention). KMS gives you key control only if you enable CMK and protect the keys. None of these remove your responsibility for least privilege, private access, and data classification. Maturity and integration differ (Sentinel, GuardDuty, and SCC are strong in their ecosystems), but the security outcome is driven by your configuration.

Production security checklist (portable across clouds)

Federate human identity; enforce MFA/conditional sign-in; access via groups, not users.
No broad admin (Owner / * / manage all-resources); least role at lowest scope; JIT for privileged where supported.
Workloads use keyless identity (instance/resource principals, IAM roles, managed identities, service accounts) - no long-lived keys/secrets.
Preventive policy on (deny public IPs/buckets, restrict regions, require tags/logging).
CSPM + threat detection enabled org-wide; findings triaged; secure score tracked.
Sensitive services on private endpoints; public access disabled; databases private.
Public HTTP behind WAF + DDoS; backends private.
Sensitive data encrypted with customer-managed keys; keys protected (purge protection/soft-delete).
Secrets in the secret store; nothing sensitive in code/config/images.
Audit logs enabled (incl. data-access where needed) and centralized to an immutable store; SIEM ingesting.
Data-exfiltration perimeter for high-value data (VPC-SC on GCP; equivalent designs elsewhere).
Backups immutable; DR tested including key availability in the DR region.
Break-glass accounts protected and monitored.

Vendor security references: OCI, AWS, Azure Defender/Sentinel, Google SCC →

12. Observability and Operations Comparison

Metrics, logs, tracing, alerting, and audit across clouds - how logs are collected and centralized, and how multi-account/subscription/project monitoring works.

Last reviewed: July 2026 Verify agent, query-language, and export details with current vendor docs.

TL;DR

All four provide metrics + alerts, central logging, control-plane audit, and tracing/APM. They differ in query language (CloudWatch, KQL, MQL), guest-metric agents, and how you centralize across accounts/subscriptions/projects. The universal truths: install the agent for guest metrics (memory), alert on symptoms, route by severity, avoid noise, and centralize audit logs from day one. OpenTelemetry is the portable path for app tracing/metrics.

Observability, side by side

Capability	OCI	AWS	Azure	Google Cloud
Metrics + alerts	Monitoring + Alarms	CloudWatch	Azure Monitor	Cloud Monitoring
Central logging	Logging + Logging Analytics	CloudWatch Logs	Log Analytics (KQL)	Cloud Logging
Control-plane audit	Audit	CloudTrail	Activity Log	Cloud Audit Logs
Config/change tracking	(Cloud Guard / inventory)	AWS Config	Change Tracking / Policy	Asset Inventory
Tracing / APM	APM	X-Ray	Application Insights	Cloud Trace
Error reporting	(Logging)	(CloudWatch)	App Insights	Error Reporting
Managed Prometheus/Grafana	(partner)	AMP + AMG	Azure Monitor managed Prometheus + Grafana	Managed Service for Prometheus
Guest metrics agent	Management Agent	CloudWatch Agent	Azure Monitor Agent	Ops Agent
DB / ops insights	Operations Insights / DB Mgmt	DevOps Guru / Performance Insights	SQL Insights / Advisor	Cloud SQL Insights / Active Assist
Query language	MQL / Log queries	CloudWatch Logs Insights	KQL (Kusto)	Logging query / MQL

Centralizing across accounts / subscriptions / projects

	OCI	AWS	Azure	GCP
Central log pattern	Service Connector Hub → central log/bucket/SIEM	Cross-account CloudWatch / central logging account + S3	Diagnostic settings → central Log Analytics (via Policy)	Aggregated log sinks → central logging project / BigQuery
Enforcement	Policy / connectors	SCP + Config rules	Azure Policy (deployIfNotExists)	Org policy + sink at org/folder

Operations note - the same three lessons everywhere

(1) Install the agent - guest memory/disk/process metrics aren't collected by default on any cloud. (2) Centralize audit + logs to one place (per-account/subscription/project logs are useless in an incident) - enforce with policy at the top of the hierarchy. (3) Alert on symptoms, route by severity, prune noise - alert fatigue is universal. Use OpenTelemetry to keep app instrumentation portable across clouds.

Vendor observability references: OCI, AWS CloudWatch/CloudTrail, Azure Monitor, Google Cloud Ops →

13. Migration and Disaster Recovery Comparison

Migration and DR capabilities across clouds - which tools are mature, which workloads need special handling, and what must be tested before cutover.

Last reviewed: July 2026 Verify supported sources and DR-tool maturity with current vendor docs.

TL;DR

VM rehost and DB migration tooling exists on all four, but maturity varies (AWS and Azure have long-established dedicated tools; GCP has strong tooling; OCI is strong for Oracle low-downtime via ZDM/GoldenGate). Oracle-to-X and heterogeneous DB moves are conversions, not lift-and-shift, everywhere. DR patterns (backup / pilot-light / warm / hot) are identical concepts; the orchestration tools differ (ASR, AWS DRS, Full Stack DR). The universal rules: match the pattern to RTO/RPO, and DR you don't test is not DR.

Migration & DR, side by side

Capability	OCI	AWS	Azure	Google Cloud
Assess & plan	(Cloud Advisor / partner)	Migration Hub	Azure Migrate	Migration Center
VM rehost	(rehost tooling)	Application Migration Service	Azure Migrate: Server Migration	Migrate to Virtual Machines
Database migration	Database Migration / ZDM	DMS	Database Migration Service	Database Migration Service
Low-downtime DB / CDC	GoldenGate / ZDM (strong for Oracle)	DMS + GoldenGate	DMS + MI link	Datastream
VMware migration	(OCVS)	VMware Cloud on AWS (evolving)	Azure VMware Solution	Google Cloud VMware Engine
DR replication/orchestration	Full Stack DR / Data Guard	Elastic Disaster Recovery	Azure Site Recovery	Backup and DR / patterns
Cross-region data	Cross-region copy / Data Guard	S3 replication / Aurora Global	GRS/GZRS / geo-replication	Multi-region / cross-region replica
Traffic failover	DNS / LB	Route 53 / Global Accelerator	Front Door / Traffic Manager	Global LB / Cloud DNS

Which cloud suits which migration (neutral)

Migration	Neutral guidance
Oracle low-downtime	OCI (ZDM + GoldenGate + Data Guard) is often strong; GoldenGate works to other clouds too. Heterogeneous (Oracle→Postgres) is a conversion anywhere.
SQL Server	Azure (Managed Instance link, DMS) is often strong; managed SQL Server migration exists on AWS/GCP.
Large VM estates	AWS/Azure/GCP have mature dedicated rehost tools; assess dependencies first and test cutover.
VMware	Azure VMware Solution and Google Cloud VMware Engine are established; verify current AWS VMware options.
Data warehouse	Warehouse migrations are re-platforming (schema/SQL/cost-model changes), not lift-and-shift - budget for it.

What to test before cutover (every cloud)

Data consistency - replication lag within RPO; no dropped changes during cutover.
Downtime window - measured, not assumed; rollback plan ready.
Licensing - correctly counted/applied on the target (Oracle, SQL Server, Windows).
DR readiness - failover rehearsed; encryption keys present in the DR region; app repoints correctly.
Performance parity - target sized for real load, not just capacity.

DR: same patterns, different tools

Backup-and-restore, pilot-light, warm-standby, and active/passive-or-active are the same four patterns on every cloud; match them to RTO/RPO per tier. The orchestration tool differs (ASR, AWS DRS, Full Stack DR) - what stays constant is that untested DR fails, and stateful active-active is hard everywhere unless the data service is natively multi-region.

Vendor migration/DR references: OCI, AWS, Azure, Google Cloud →

14. Cost Model Comparison

Why cloud pricing is hard to compare directly, which factors dominate, and a neutral checklist to model true cost by workload. No cloud is cheapest overall.

Last reviewed: July 2026 Pricing changes constantly - verify all rates on each vendor's pricing pages.

TL;DR

There is no cheapest cloud overall - only cheapest for a specific workload shape, discount model, and licensing position. List-price comparisons are misleading. The factors that actually decide cost: workload shape (runtime, CPU/memory pattern), commitments/discounts, licensing (often dominant for databases), network egress + cross-region, and logging/monitoring/data-warehouse (frequently underestimated). Architecture design affects cost more than list price.

Cost levers, side by side

Lever	OCI	AWS	Azure	Google Cloud
Commitment discount	Universal Credits / Annual	Savings Plans / Reserved Instances	Reservations / Savings Plan	Committed Use Discounts
Automatic usage discount	(pricing tiers)	(some)	(some)	Sustained Use Discounts
Interruptible discount	Preemptible	Spot	Spot	Spot / Preemptible
License benefit	Oracle BYOL	BYOL / License Included	Azure Hybrid Benefit (Windows/SQL)	BYOL where supported
Cost management	Cost Analysis + Budgets	Cost Explorer + Budgets	Microsoft Cost Management + Budgets	Cost Management + Budgets + BQ export
Optimization advice	Cloud Advisor	Trusted Advisor / Compute Optimizer	Azure Advisor	Recommender / Active Assist

Why pricing is hard to compare

Cost note - what actually moves the number

Workload shape: runtime hours, CPU/memory ratio, and burstiness change which cloud/SKU wins. Normalize units (OCI OCPU vs vCPU) first.
Discounts flip the answer: commitments, sustained-use, and spot can change the cheapest option by a lot - compare post-discount, not list price.
Licensing can dominate: Oracle/SQL Server/Windows licensing (BYOL, Hybrid Benefit) often outweighs infrastructure cost for database workloads.
Network is underestimated: internet egress, cross-region, and inter-AZ traffic add up; chatty architectures cost more everywhere.
Logging/monitoring/warehouse: log ingestion, and bytes-scanned or cluster warehouse cost, are common surprises.
Managed-service premiums: firewalls, gateways, NAT, and load balancers have their own hourly + data costs.

Neutral cost-modeling checklist

To compare clouds honestly for a workload, model all of these - not just compute list price:

Workload profile (what it is, how it runs).
Runtime hours (24x7 vs scheduled vs bursty).
CPU and memory pattern (steady vs spiky; normalized units).
Storage type + growth (block/object/file, tier, redundancy).
Backup retention + snapshot policy.
Data transfer (egress, cross-region, inter-AZ).
HA and DR requirements (zone/region redundancy, standby cost).
Logging + monitoring volume (ingestion, retention).
Security tooling tiers (CSPM/WAF/DDoS/SIEM plans).
Database licensing (BYOL / Hybrid Benefit / included).
Discount model (commitments, sustained-use, spot).
Marketplace/ISV software costs.
Support tier.
Operational staffing (skills, ops effort per platform).

Do not claim a cheapest cloud

The honest output of a cost comparison is "for this workload, under these assumptions, cloud X is cheaper - and here is what changes the answer." Discounts, licensing, and architecture usually matter more than the sticker rate. Re-model when the workload shape or commitment strategy changes.

Vendor cost references: OCI, AWS Cost Explorer, Azure Cost Management, Google Cost Management →

15. Enterprise Workload Decision Matrix

By workload, which clouds are strong candidates and why - and where they may not fit. Balanced wording: strong candidates are named, but any of the four can be valid depending on architecture, migration goals, ecosystem, and cost.

Last reviewed: July 2026 Fit depends on your specifics - verify feature parity, licensing, and region availability.

How to read this

"Strong candidate" means a cloud has natural advantages for that workload under common conditions - not that others are wrong. Example: OCI may be a strong fit for Oracle-Database-heavy workloads, especially where Exadata, Autonomous, or Oracle licensing dominate; AWS, Azure, and GCP can still be valid depending on architecture, migration goals, ecosystem, and managed-service requirements. Apply that balance everywhere.

Workload	Strong candidate(s)	Why they fit	Where they may not fit / verify
Oracle Database	OCI (others valid)	Exadata, Autonomous, RAC, Oracle licensing/BYOL, DB@Azure/@Google partnerships	If the estate is small/non-Oracle-centric or you want a specific non-Oracle ecosystem; verify DB@Azure/@Google availability
Oracle EBS	OCI (others valid)	Certified Oracle stack, DB + app-tier fit, licensing	Check certification on any target; app-tier can run elsewhere with the DB via partnership
SQL Server	Azure (others valid)	SQL DB / Managed Instance, Hybrid Benefit, deep integration	Managed SQL Server exists on AWS/GCP; SQL-on-VM anywhere - verify compatibility
Microsoft enterprise apps	Azure	Entra, Windows, M365, hybrid via Arc	Non-Microsoft-centric orgs may prefer another ecosystem
SAP	All four (certified)	Certified HANA SKUs on each	Verify certification, HANA sizes, and support; ecosystem/skills differ
Kubernetes platform	GCP, Azure (all strong)	GKE (Autopilot) and AKS maturity; EKS/OKE valid	Any cloud works; choose by integration + skills
Serverless application	AWS, GCP (all valid)	Lambda ecosystem; Cloud Run/Container Apps	All four have serverless; verify limits for your workload
Global web application	GCP, Azure, AWS	Global LB/anycast (GCP), Front Door (Azure), CloudFront+GA (AWS)	OCI is more regional for global edge - verify
Data lake	All four	Object storage + catalog + Spark everywhere	Choose by warehouse/BI + governance ecosystem
Data warehouse	GCP (BigQuery), others valid	Serverless analytics; Redshift/Synapse/ADW valid	Match cost model to query pattern; Snowflake is multi-cloud
Streaming analytics	GCP, AWS, Azure	Pub/Sub+Dataflow; Kinesis; Event Hubs+Stream Analytics	Kafka portable if needed; verify throughput/semantics
AI/ML platform	AWS, GCP (all valid)	SageMaker, Vertex breadth	All four have platforms; verify GPU/TPU + models
Generative AI	All four (verify models)	Bedrock (many models), Azure OpenAI (GPT), Vertex (Gemini), OCI GenAI	Choose by required models/region/quota/terms - changes fast
Regulated workloads	All four (verify)	Compliance certifications + data-residency options on each	Verify specific certifications, regions, and sovereign options
Government workloads	All four (gov/sovereign clouds)	Gov regions/clouds (AWS GovCloud, Azure Gov, Google Assured, OCI Gov)	Verify authorization level and service availability in gov regions
Hybrid cloud	Azure (Arc), GCP (Anthos)	Arc extends Azure control plane; Anthos/GKE Enterprise for K8s	AWS Outposts is hardware-based; choose by strategy
Edge workloads	All four (verify)	Edge/local zones/appliances differ per cloud	Verify edge offerings and coverage for your locations
VMware workloads	Azure (AVS), GCP (GCVE)	Established VMware-as-a-service	Verify current AWS VMware options; plan modernization
Cost-sensitive dev/test	All four	Spot + auto-shutdown + small shapes everywhere	Dev/Test pricing (Azure); commitments for baseline
HPC	All four (verify)	HPC SKUs, RDMA/cluster networking, spot	Verify interconnect, GPU/TPU, and scheduler support
Disaster recovery	All four	Backup/replication + traffic failover on each	Match pattern to RTO/RPO; test; keys in DR region

Architect note - decide by criteria, not headline

Weigh: existing investment/skills, the specific managed services you need, licensing position, compliance/residency, cost model for your workload shape, ecosystem/marketplace, and migration effort. The right answer is often "different clouds for different workloads" (multi-cloud by design) - but only if you can operate the added complexity.

Pair this with the single-cloud deep-dive portals for depth →

16. Cloud Strengths and Trade-offs

A balanced view of each cloud's natural strengths, common enterprise fit, areas that require careful design, and what to verify - explained by context, not global ranking.

Last reviewed: July 2026 These are general tendencies - verify against your specific requirements and current docs.

No global ranking

Each cloud has areas of genuine strength and areas that need careful design. None is "best" overall. The goal here is to help you match strengths to your workloads and know what to verify - not to declare a winner.

OCI

AWS

Azure

Google Cloud

Oracle Cloud Infrastructure

Natural strengths

Native Oracle Database (Exadata, Autonomous, RAC), Oracle licensing/BYOL economics, broad everyday bare metal, high-performance networking, and multicloud database partnerships (Oracle DB@Azure/@Google).

Common enterprise fit

Oracle-Database-heavy estates, Oracle EBS/Apps, Exadata consolidation, and organizations optimizing Oracle licensing.

Requires careful design / verify

Third-party ISV/marketplace breadth and some managed-service depth vs. the largest clouds; regional and service availability for specific SKUs/GPUs; verify per region.

Common misconceptions

"Only for Oracle" - it runs general workloads well; but its clearest differentiation is Oracle. "Small" - it has a full IaaS/PaaS stack, though the ecosystem is smaller than AWS/Azure.

May not be ideal when

You need the widest third-party ecosystem/marketplace, a specific non-Oracle managed service only mature elsewhere, or the broadest global edge network. Verify service and region coverage for your needs.

Amazon Web Services

Natural strengths

Breadth and maturity of services, the largest ecosystem/marketplace and talent pool, deep serverless (Lambda/Fargate), rich data and container options, custom silicon (Graviton/Trainium/Inferentia), and Bedrock's multi-provider model catalog.

Common enterprise fit

Cloud-native and startups-to-enterprise breadth, broad workload variety, teams wanting the most options and the largest hiring pool.

Requires careful design / verify

Complexity and choice overload; IAM/JSON-policy learning curve; cost sprawl without discipline; governance overhead across many accounts.

Common misconceptions

"Always cheapest" - depends on workload/discounts/licensing. "Simple" - breadth brings complexity; strong governance is required.

May not be ideal when

You want deep native Microsoft integration (Azure) or a serverless data warehouse and global network (GCP), or you lack the governance maturity to manage its breadth. Verify against your team's operating model.

Microsoft Azure

Natural strengths

Microsoft ecosystem integration (Entra ID, Windows Server, SQL Server, M365/Copilot), strong hybrid (Arc, ExpressRoute), mature governance (management groups, Policy, PIM), Azure OpenAI, and enterprise licensing (Hybrid Benefit).

Common enterprise fit

Microsoft-centric enterprises, Windows/SQL Server estates, hybrid-first organizations, and regulated enterprises leveraging existing EA agreements.

Requires careful design / verify

Service naming complexity; subscription/management-group governance design; networking and private-endpoint/Private DNS complexity; verify SKU/zone availability by region.

Common misconceptions

"Only for Windows" - it runs Linux/OSS well. "Entra = Azure RBAC" - they are separate systems (a frequent confusion).

May not be ideal when

You want a serverless bytes-scanned warehouse and global anycast network (GCP), the broadest service catalog (AWS), or the deepest native Oracle (OCI). Verify the specific services and their maturity.

Google Cloud

Natural strengths

Data analytics (BigQuery serverless), a global VPC and network, strong Kubernetes (GKE/Autopilot) and Cloud Run, AI/ML (Vertex AI, Gemini, TPUs), and developer-friendly cloud-native services; VPC Service Controls for data isolation.

Common enterprise fit

Data/analytics-led organizations, cloud-native and Kubernetes-heavy teams, AI/ML workloads, and global web applications.

Requires careful design / verify

Enterprise adoption varies by industry; some enterprises have fewer in-house GCP skills; verify specific enterprise/ISV service familiarity and support.

Common misconceptions

"Only for data/AI" - it has a full enterprise stack. "VPC is regional" - it is global (subnets are regional), which changes design.

May not be ideal when

You need deep native Microsoft integration (Azure), the broadest ecosystem/marketplace (AWS), or the deepest native Oracle (OCI). Verify service familiarity and enterprise support fit for your org.

Architect note

Strengths are starting hypotheses, not conclusions. Validate against your actual requirements: the specific services, their maturity in your region, your licensing position, compliance needs, cost model, and the skills of the team that will operate it. A strength you don't use is not a benefit.

17. Architecture Pattern Comparison

How the same workload is built in each cloud - the services differ, but the shape (edge/WAF, private compute, managed DB, private data access, central logging, DR) is remarkably consistent.

Last reviewed: July 2026 Service choices are examples - verify current best-practice references per vendor.

The pattern is portable; the services are not

Across clouds, a production app looks the same: edge/WAF → load balancer → private compute across zones → managed database on a private endpoint → private access to platform services → secrets in a vault → centralized logging → cross-region DR, inside a governed landing zone. What changes is the service names, the private-access mechanism, and the global-edge model. Below, each pattern maps the same shape to each cloud.

Three-tier / highly-available application

Component	OCI	AWS	Azure	Google Cloud
Edge / WAF	WAF + Load Balancer	CloudFront + WAF	Front Door + WAF	Global LB + Cloud Armor
App tier (private, HA)	Instance Pool across FDs/ADs	ASG across AZs (or Fargate)	VMSS across zones (or App Service)	Regional MIG (or Cloud Run)
Managed DB (private)	Base/Autonomous DB	RDS/Aurora Multi-AZ	Azure SQL zone-redundant	Cloud SQL/AlloyDB HA
Private data access	Service Gateway	VPC Endpoints	Private Endpoints	Private Google Access / PSC
Secrets	Vault	Secrets Manager	Key Vault	Secret Manager
Egress control	NAT + Network Firewall	NAT + Network Firewall	NAT + Azure Firewall	Cloud NAT + Cloud NGFW
Observability	Monitoring + Logging	CloudWatch + CloudTrail	Azure Monitor + Log Analytics	Cloud Monitoring + Logging
DR	2nd region + Data Guard/Full Stack DR	2nd region + Aurora Global / DRS	Front Door + failover group / ASR	Global LB + cross-region replica

The same shape on every cloud - only the service names and the private-access mechanism change.

Other patterns - the portable shape + what differs

Pattern	Portable shape	What differs most across clouds
Simple web app	PaaS/serverless container + managed DB + edge	App Service vs Cloud Run vs App Runner vs OCI compute
Private enterprise app	Private subnets + internal LB + private endpoints + hybrid link + bastion	Private-access mechanism (Service Gateway vs per-service endpoints); Private DNS on Azure
Multi-region DR	Global edge/DNS + multi-region data + tested failover	Global LB model; DB DR (failover group / Aurora Global / Data Guard / cross-region replica)
Hybrid cloud	Dedicated link + hub + hybrid DNS + on-prem management	Arc vs Anthos vs Outposts strategy; transit hub object
Kubernetes platform	Managed K8s + workload identity + registry + ingress + pipeline	Networking/CNI + ingress controller + supply-chain (Binary Auth, Signer)
Serverless / event-driven	Event router + functions/serverless containers + queue + managed data	Event source schemas; FaaS limits; messaging semantics
Data lake / warehouse	Object lake + ETL/Spark + warehouse + governance + BI	Warehouse cost model; governance tool; BI/semantic layer
AI / RAG app	Governed serving layer + vector store + foundation model + audit	Model catalog + vector store + content-safety tooling
Secure landing zone	Hierarchy + preventive policy + hub network + central logging + CSPM	Policy engine + landing-zone accelerator + hub object

Common mistakes when porting a pattern

Assuming the private-access layer maps 1:1 (it rarely does - re-model endpoints + DNS).
Copying the global-edge design (models differ significantly).
Reusing another cloud's account/subscription/project topology (foundation section 2).
Treating NoSQL/warehouse services as drop-in (they are re-modeling exercises).
Forgetting that DR keys must exist in the DR region on every cloud.

Neutral recommendation

Design the shape first (it is portable), then bind it to each cloud's services. This makes multi-cloud reasoning tractable and prevents accidental lock-in in areas (compute, networking basics) where portability is easy - while accepting deeper integration where it pays off (data, AI, identity).

See the single-cloud deep-dive portals for full per-cloud architectures →

18. Troubleshooting Comparison

The same failures happen on every cloud - the diagnostic method is portable, but the tools and console paths differ. For each common issue: what to check on OCI, AWS, Azure, and GCP.

Last reviewed: July 2026 Verify tool names and CLI syntax with current vendor docs.

Portable method

Whatever the cloud, work top-down: identity/API (right account/scope? role/permission? API/provider enabled?) → network (route + firewall both directions + DNS) → host/service (healthy/listening?) → data. Each cloud has a reachability analyzer and an access checker - use them first. The root causes below are the same everywhere; only the tooling differs.

⚑ Identity / permission denied

Root causes	Wrong account/scope; role lacks the action (control vs data plane); grant at wrong scope; explicit deny/policy; JIT not activated; API disabled.
OCI	Policies + group membership; Audit for the denied call; check compartment path + identity domain.
AWS	IAM policy simulator; check assumed role / cross-account trust; CloudTrail; SCP boundaries.
Azure	IAM > Check access; Entra sign-in logs (Conditional Access); PIM eligible-vs-active; deny assignments.
GCP	Policy Troubleshooter; check role bindings + inheritance; Org Policy; service account actAs.

⚑ VM not reachable / SSH-RDP

Root causes	Firewall/security rule; no public IP + no bastion; VM stopped/boot failed; OS firewall; wrong key/user.
OCI	Security lists/NSG + route; serial console; Bastion service; Network Path Analyzer.
AWS	Security group/NACL; use SSM Session Manager; EC2 serial console; Reachability Analyzer.
Azure	NSG (IP Flow Verify) + effective routes; Azure Bastion; boot diagnostics/serial console.
GCP	VPC firewall; IAP/OS Login; serial console; Connectivity Tests.

⚑ Private network / service access issue

Root causes	Missing/mis-scoped private endpoint; DNS resolving to public IP; peering non-transitive; overlapping CIDRs; missing route.
OCI	Service Gateway + route to OSN CIDR; Path Analyzer.
AWS	VPC endpoint (gateway/interface) + endpoint policy + DNS; Reachability Analyzer.
Azure	Private Endpoint + Private DNS zone linkage (top cause); nslookup for private IP.
GCP	Private Google Access / PSC + DNS to private.googleapis.com; Connectivity Tests.

⚑ Load balancer backend unhealthy

Root causes	Firewall blocks the health-probe source; wrong probe port/path/protocol; app on localhost; wrong backend protocol.
OCI	Allow LB subnet/NSG on backend port; align health check.
AWS	Target group health; SG allows the LB; probe path/port; target registration.
Azure	App Gateway backend health; allow probe + management ports (GatewayManager); align probe.
GCP	Allow health-check ranges 35.191.0.0/16 & 130.211.0.0/22; backend service protocol/named port.

⚑ DNS / storage-access-denied / DB connection / VPN down

DNS	All: private zone not linked/attached; missing record; hybrid forwarding absent. Check with nslookup/dig from inside the network.
Storage denied	All: missing data-plane role (not just control-plane); public access disabled (correctly); expired SAS/signed URL; endpoint/firewall restriction. Use the workload identity + data role.
DB connection	All: public access disabled + no private path; DNS not resolving; auth/token; wrong endpoint; add retry logic for transient errors.
VPN / dedicated link	All: IKE/PSK mismatch (VPN); BGP not advertising both ways; circuit/tunnel down; CIDR overlap; gateway SKU bandwidth. Check gateway/circuit status + learned routes.

⚑ Function not triggering / K8s pod not starting / logging missing / cost spike

Function trigger	All: event source/subscription filter; invoke permission; the function's own identity permissions; check invocation logs/metrics.
Pod not starting	All: Pending (capacity / pod-IP exhaustion), ImagePullBackOff (registry pull permission / private-registry reachability), CrashLoopBackOff (config/probes). `kubectl describe/logs`.
Logging missing	All: agent not installed (guest metrics); log/diagnostic setting not enabled; wrong workspace/sink; retention expired. Enforce via policy.
Cost spike	All: check cost analysis by service/tag; common culprits are egress, log ingestion, warehouse scans, always-on clusters, and orphaned resources.

Operations note

Learn each cloud's reachability analyzer (Path Analyzer / Reachability Analyzer / IP Flow Verify+Connectivity Tests) and access checker (policy simulator / Check access / Policy Troubleshooter) - they turn most "cannot reach / access denied" tickets from a long hunt into a quick answer, on every cloud.

See the per-cloud deep-dive portals for full troubleshooting runbooks →

19. Learning Paths by Background

Cross-cloud learning is fastest when you build on what you already know. For each background: what transfers cleanly, what does not, where to start, and the mistakes to avoid.

Last reviewed: July 2026 Pair with the single-cloud deep-dive portals and current vendor training.

The universal transfer map

Transfers well: the mental model (regions/zones, VPC + subnets + firewall, IaaS VMs, object/block/file storage, load balancing, IAM concepts, Kubernetes, IaC/Terraform, OpenTelemetry). Transfers poorly: the account/hierarchy topology, private-access-to-services mechanics, NoSQL/warehouse data models, global-edge design, and each cloud's native governance/identity nuances. Learn the differences, not the whole cloud from scratch.

Cross-cloud (any pro)

Infra / DBA

DevOps / Security

Data / AI

An X-cloud professional learning the other three

Whether you know OCI, AWS, Azure, or GCP, the fastest path to the others is the same three-step move:

Re-anchor the foundation (section 2): the account/hierarchy boundary sits in a different place. Learn where isolation, billing, and governance live in the target cloud first - it reframes everything else.
Map IAM + networking (sections 3-4): the concepts transfer; learn the target's workload-identity mechanism, private-service-access model, and firewall/route specifics.
Learn the differentiated services (7, 9, 10): databases, data platforms, and AI diverge most - these are where you must study the target, not assume.

Mistakes to avoid

Assuming direct equivalence (use the match ratings in section 1); copying your home cloud's account/network topology; expecting NoSQL/warehouse to be drop-in; forgetting the target's private-DNS/endpoint requirements.

Hands-on lab

Build the same three-tier app (section 17) in a second cloud: edge/WAF → private compute across zones → managed DB on a private endpoint → central logging. You will hit exactly the transfer gaps that matter.

Expected outcome: you can read the target cloud's architecture diagrams, know which services to reach for, and know what to verify - without relearning cloud from scratch.

Infrastructure engineer / DBA learning cloud (or another cloud)

Already understand

Servers, networks, storage, HA/DR, and (for DBAs) database internals, backup, replication, and licensing - all of which map to cloud concepts.

Transfers well

VMs, block/object/file storage, load balancing, subnets/firewalls, backup/DR patterns, and the RTO/RPO framing.

Does not transfer cleanly

The account/hierarchy model; managed-database responsibility split (what the cloud patches vs you); private-endpoint/DNS; NoSQL/warehouse data models; cloud IAM for machine identity.

Start with

Foundation (2) → IAM (3) → Networking (4) → Compute (5) → Storage (6) → Databases (7). For DBAs, the database section is the priority - "managed" varies a lot.

DBA note

The biggest shift for DBAs is the responsibility split: managed databases handle patching/backup/HA but restrict OS/instance access, and backup/DR are service-managed artifacts, not files you copy. Oracle-to-Postgres (or SQL-DB) is a conversion, not lift-and-shift. Licensing (BYOL, Hybrid Benefit) often decides the cheapest cloud.

Hands-on labs: deploy a managed database with private endpoint + a failover replica; test a restore; migrate a small DB with the cloud's migration service. Outcome: you can choose and operate a managed database and know exactly what you still own.

DevOps / Security engineer learning multicloud

Transfers well (DevOps)

CI/CD concepts, containers/Kubernetes, IaC (esp. Terraform), GitOps, and observability with OpenTelemetry.

Transfers well (Security)

Zero-trust, least privilege, key/secret management, WAF/DDoS, audit logging, and CSPM concepts.

Does not transfer cleanly

Native IaC (CloudFormation/Bicep don't port - use Terraform); each cloud's IAM/policy nuances; the private-access model; CSPM/SIEM tooling and what each plan includes; JIT/PIM maturity.

Start with

DevOps: IaC + CI/CD in section 1 matrix + containers (8). Security: IAM (3) + Security services (11) + the portable production checklist.

Security note

Standardize on the portable practices - keyless workload identity, least privilege, preventive policy, private endpoints, CMK, centralized immutable audit logs, and a data-exfiltration perimeter for sensitive data - then learn each cloud's tool that implements them. The outcomes are identical; the tooling differs.

Hands-on labs: a Terraform module deployed to two clouds via OIDC (no keys); enable CSPM + central logging on both. Outcome: portable pipelines and a consistent security baseline across clouds.

Data engineer / AI engineer learning multicloud

Transfers well

SQL, Spark, open table formats (Iceberg/Delta/Parquet), streaming concepts, and (for AI) RAG architecture, embeddings, and the governed-serving-layer pattern.

Does not transfer cleanly

The warehouse cost/scaling model (BigQuery bytes-scanned vs cluster); native governance tools; streaming service semantics; NoSQL data models; each cloud's model catalog and vector-search options.

Start with

Data: Analytics (9) + Databases (7). AI: AI (10) + vector-search rows in the matrix (1). Learn the target warehouse's cost model early.

Data engineering note

Design lakes on open formats and use Spark/Databricks to keep skills portable; accept deeper integration (BigQuery, Fabric) where the productivity gain is worth reduced portability. For AI, the governance pattern is identical everywhere - the differentiators are available models, region/quota, and data-retention terms, which you must verify per cloud.

Hands-on labs: load the same dataset into two warehouses and compare query cost; build a governed RAG app (serving layer + vector store + model + audit) on one cloud. Outcome: you can pick a data/AI stack by pattern and cost model, and build governed AI safely.

Final note

Multicloud fluency is not learning four clouds four times - it is learning the portable model once, then learning each cloud's differences. Use the comparison matrix (section 1) as your translation table and the single-cloud deep-dive portals for depth when you need it.

Return to expertoracle.com for the per-cloud deep-dive portals →