OCI to Multi-Cloud Learning Portal

A deep reference for Oracle Cloud professionals learning AWS, Azure, GCP, and other clouds

You already understand OCI. This portal answers, service by service: what is the equivalent in AWS, Azure, and Google Cloud? How does it actually work in each? What maps cleanly, what does not, what exists only in OCI, and what will trip you up when you cross clouds. Anchored on OCI, written for real project work - not marketing.

Last reviewed June 2026OCI-anchoredArchitecture-firstVendor-neutral

HOW TO USE THIS

Start at the Service Map to find any OCI service's counterpart in AWS/Azure/GCP with a match rating - it is searchable and filterable, and each row expands to the explanation, the important difference, and a common use case. Use Concept Translation for the vocabulary (tenancy, compartment, VCN, dynamic group, policy). The deep-dive, unique-per-cloud, architecture-pattern, decision-matrix, and learning-path sections land in the next passes.

Match levels used throughout

Two services are never called "the same" unless they truly are close. Every mapping carries one of these ratings:

Rating	Meaning
Exact	Functionally equivalent - same job, near-identical model. You can reason about it the same way.
Close	Same purpose, minor model/behaviour differences you must learn (limits, scope, defaults).
Partial	Overlaps but only covers part of the OCI service, or splits it across several services.
Conceptual	Solves a similar problem with a genuinely different model - map the intent, not the mechanics.
No direct	No real counterpart. Either OCI-only, or you rebuild it from other primitives.

The four clouds at a glance (for orientation only)

Cloud	Org model	Network anchor	Identity anchor	Where it is strongest for an OCI person
OCI	Tenancy → Compartments	VCN (regional)	OCI IAM + Dynamic Groups	Oracle DB (Autonomous/Exadata), bare metal, flat network model, price/perf, multicloud DB partnerships.
AWS	Organization → Accounts	VPC (regional, AZ-scoped subnets)	IAM (policies + roles)	Breadth, maturity, serverless/Lambda, S3 ecosystem, partner marketplace.
Azure	Tenant → Mgmt Group → Subscription → Resource Group	VNet (regional)	Microsoft Entra ID	Microsoft enterprise (AD, Windows, SQL Server, M365), hybrid (Arc), governance (Policy).
GCP	Organization → Folder → Project	VPC (global!)	Cloud IAM + Service Accounts	Data/analytics (BigQuery), AI (Vertex/Gemini), Kubernetes (GKE), global VPC.

OCI person, remember this first

The three model differences that cause the most confusion when you leave OCI: (1) Compartments have no clean equivalent - AWS/GCP use separate accounts/projects for isolation, Azure uses subscriptions + resource groups. (2) OCI's network is regional and flat; AWS subnets are AZ-scoped and GCP VPCs are global. (3) OCI security lists are stateful and subnet-level; AWS splits stateless NACLs (subnet) from stateful security groups (instance). Get these three and most of the rest follows.

Accuracy & freshness

Cloud services change weekly. Ratings and mappings reflect June 2026. Where something is fast-moving or I could not confirm a current behaviour, it is marked "verify with current docs." Always confirm exact limits, region availability, and pricing in the official documentation before committing an architecture.

OCI to Other Clouds Service Map

Every major OCI service and its closest counterpart in AWS, Azure, and Google Cloud, with a match rating. Search any field; filter by domain or match level. Click a row to expand the explanation, the important difference, and a common use case.

Match: ExactClosePartialConceptualNo direct Clouds: OCIAWSAzureGCP

Tip: click any row to expand. Tables are copy-friendly for pasting into runbooks.

OCI Service	AWS	Azure	Google Cloud	Match

Concept Translation Guide

The vocabulary that changes when you cross clouds. These are the foundational nouns - get them wrong and every diagram you draw is wrong. Not one-line mappings; the real differences.

Tenancy (OCI)

In OCI, the tenancy is your entire root account - one global container for everything, with a home region. AWS: the closest is an Organization whose management (payer) account is the root; but day-to-day isolation is done by creating many member Accounts, not by staying in one. Azure: splits it into an Entra ID tenant (identity boundary) plus one or more Subscriptions (billing/quota boundary) under Management Groups. GCP: an Organization node at the top, with Projects as the working unit.

OCI person should remember

OCI keeps you in one tenancy and isolates with compartments. AWS/GCP push you toward many accounts/projects. Azure separates who you are (tenant) from what you pay for (subscription). Do not assume "one account = one tenancy."

Compartment (OCI)

OCI compartments are logical, nestable containers for resources that IAM policies target - the primary isolation and governance unit inside one tenancy. AWS: No direct - AWS isolates with separate Accounts (grouped by Organizations OUs); tags + IAM approximate grouping but not the boundary. Azure: Partial - Resource Groups group resources, Management Groups group subscriptions; neither nests the same way. GCP: Partial - Projects (hard isolation) inside Folders map best, but a Project is a heavier boundary than a compartment.

Common mistake

Treating an AWS Account or a GCP Project as "just a compartment." They are billing + hard-isolation boundaries; spinning up dozens like compartments creates account/project sprawl and quota headaches. Design the account/project hierarchy deliberately.

VCN (OCI)

OCI VCN = Close AWS VPC / Azure VNet / GCP VPC - all software-defined private networks. Key model difference: OCI VCN and AWS VPC are regional with subnets that can be regional (OCI) or AZ-scoped (AWS); Azure VNet is regional; GCP VPC is global - one VPC spans all regions, subnets are regional. That single fact changes multi-region design.

Dynamic Group (OCI)

OCI dynamic groups let resources (instances, functions) authenticate and be granted policy - identity for workloads. AWS: Close - IAM Roles assumed by services/instance profiles. Azure: Close - Managed Identities (system/user-assigned). GCP: Close - Service Accounts attached to resources.

Policy (OCI)

OCI policies are human-readable statements ("allow group X to manage Y in compartment Z"). AWS: Close - JSON IAM policies (identity- and resource-based) plus SCPs at the org level. Azure: Partial - RBAC role assignments for access and Azure Policy for guardrails (two different systems). GCP: Close - IAM bindings (member + role on a resource), plus Org Policy for constraints.

More translations coming

The next pass expands this with availability domains vs AZs vs zones, fault domains, service gateway vs private endpoints vs private service access, instance principals, and the storage/database vocabulary.

Deep Dive: Identity & Organization

The account/identity model is the first thing that breaks an OCI mental model, because the isolation boundary is in a different place in every cloud.

TL;DR FOR OCI PEOPLE

OCI gives you one tenancy and you isolate 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). Once you accept that the boundary moved, the rest of IAM is close.

How each cloud structures an account

Layer	OCI	AWS	Azure	GCP
Top container	Tenancy	Organization (management account)	Entra tenant + Management Group	Organization node
Isolation unit	Compartment (logical, nestable)	Account (hard boundary)	Subscription + Resource Group	Project (hard boundary), Folder to group
Identity store	OCI IAM (or federated to Entra/IdP)	IAM Identity Center / IAM users	Microsoft Entra ID	Cloud Identity / Workspace
Authorization	Policies (human-readable)	IAM policies (JSON) + SCPs	RBAC role assignments + Azure Policy	IAM bindings + Org Policy
Workload identity	Dynamic groups / instance principals	IAM roles / instance profiles	Managed identities	Service accounts

Where it maps cleanly

Users, groups, and "a principal is allowed an action on a resource" exist everywhere.
Federation to an external IdP (SAML/OIDC) is standard in all four; OCI and Azure both lean on Entra naturally.
Workload identity (no static keys) is a first-class concept everywhere - just named differently (dynamic group / role / managed identity / service account).

Where it does not map

Compartments have no clean equivalent

A compartment is a soft, nestable boundary inside one billing account. AWS/GCP's nearest equivalent (Account/Project) is a hard billing + isolation boundary. If you model "one compartment = one account/project," you get dozens of accounts, cross-account IAM complexity, and quota fragmentation. Model it as: OCI compartment tree → AWS OU+Account tree / GCP Folder+Project tree / Azure Management-Group+Subscription+Resource-Group, and expect fewer, coarser boundaries.

Policy is two systems in Azure

In OCI one policy statement both grants access and can be a guardrail. In Azure, RBAC grants access and Azure Policy enforces rules (allowed regions, required tags) - separate engines. In AWS the split is IAM policies (access) vs SCPs (org guardrails); in GCP it is IAM bindings vs Org Policy. Learn both halves.

Terminology quick-swap

OCI	AWS	Azure	GCP
Instance principal	Instance profile (role)	System-assigned managed identity	Attached service account
Resource principal (functions)	Lambda execution role	Function managed identity	Function service account
Home region	(no direct - IAM is global)	Tenant is global; resources regional	(IAM global)
Auth token / API key	Access key + secret	Service principal secret/cert	Service account key (avoid) / Workload Identity Federation

OCI person, remember

In AWS/GCP, "give this thing access to that thing across the boundary" often means cross-account roles or cross-project IAM - there is real friction you do not feel inside a single OCI tenancy. Plan your account/project topology up front; retrofitting it later is painful.

Deep Dive: Networking

The domain where the mental models diverge the most. "VCN = VPC = VNet = VPC" is true only at the poster level; the behaviour underneath differs in ways that change your architecture.

TL;DR FOR OCI PEOPLE

Three facts do most of the damage: (1) GCP VPC is global, OCI/AWS/Azure networks are regional. (2) AWS subnets live in one AZ; OCI regional subnets span availability domains, so your HA pattern differs. (3) OCI security lists are stateful and subnet-level; AWS separates stateless subnet NACLs from stateful instance security groups. Internalise these and the rest is vocabulary.

The network object model

Concept	OCI	AWS	Azure	GCP
Private network	VCN (regional)	VPC (regional)	VNet (regional)	VPC (global)
Subnet scope	Regional (spans ADs) or AD-specific	Single AZ	Regional	Regional
Availability construct	Availability Domain (AD) + Fault Domain	Availability Zone (AZ)	Availability Zone	Zone
Route control	Route table per subnet	Route table per subnet	Route table (UDR) per subnet	Routes (VPC-wide, priority)
Stateful firewall	NSG (on VNIC)	Security Group (on ENI)	NSG (on NIC/subnet)	Firewall rule (by tag/SA)
Stateless firewall	Security List (subnet, can be stateless)	Network ACL (subnet)	(NSG only)	(firewall only)

CIDR & subnet planning

All four use RFC1918 CIDRs you assign; all four forbid overlapping ranges between networks you want to peer, so plan a non-overlapping address plan across clouds from day one if you will ever interconnect. The behavioural difference is subnet-to-AZ binding: in AWS you must create one subnet per Availability Zone and spread instances across them for HA. In OCI a regional subnet already spans availability domains, so a single subnet + fault domains often gives you HA without the per-AZ subnet sprawl. GCP subnets are regional (span zones) like OCI; Azure subnets are regional too. So the "one subnet per zone" habit is an AWS-specific tax.

Gateways and egress

Need	OCI	AWS	Azure	GCP
Public in/out	Internet Gateway	Internet Gateway	Public IP / LB / NAT (no IGW object)	Default internet route
Outbound-only	NAT Gateway	NAT Gateway	NAT Gateway	Cloud NAT (no instance)
Reach cloud services privately	Service Gateway (whole Oracle Services Network)	VPC Endpoints / PrivateLink (per service)	Service/Private Endpoints (per service)	Private Google Access / PSC
Hub / transit	DRG (Dynamic Routing Gateway)	Transit Gateway	Virtual WAN / peering	Network Connectivity Center

Where OCI is simpler

OCI's Service Gateway gives private access to the whole Oracle Services Network in one object. In AWS/Azure/GCP you create a separate private endpoint per service (S3, then DynamoDB, then KMS...), which is more granular but multiplies objects, DNS, and policy. Coming from OCI this feels like busywork - it is the price of finer control.

Firewalls: the trap

Do not map Security List to NACL

OCI security lists are stateful by default and applied at the subnet. AWS has two things: NACLs (subnet, stateless - you must allow return traffic explicitly, and they process rules in number order) and Security Groups (instance/ENI, stateful). The correct mapping is: OCI NSG → AWS Security Group (both stateful, resource-level), and treat NACLs as an extra stateless subnet layer AWS people use sparingly. GCP has no NACL equivalent - just stateful firewall rules keyed by network tags or service accounts. Azure NSGs are stateful and can attach at subnet or NIC.

Load balancing & DNS

OCI splits Load Balancer (L7) and Network Load Balancer (L4); AWS splits ALB (L7) / NLB (L4); Azure splits Application Gateway (L7, includes WAF) / Load Balancer (L4). GCP is the outlier: its global external load balancer uses a single anycast IP that fronts backends in many regions - there is no OCI equivalent, and it changes global web design. DNS is close everywhere (public + private zones); AWS Route 53's routing policies (latency, geo, weighted, failover, health-checked) are the richest - OCI's Traffic Management Steering Policies cover the common cases.

Private connectivity to on-prem

Site-to-site VPN is near-identical across all four (IPSec + BGP). Dedicated private circuits: OCI FastConnect / AWS Direct Connect / Azure ExpressRoute / GCP Cloud Interconnect. ExpressRoute has the deepest Microsoft (M365, private peering) story; Direct Connect the widest partner footprint; FastConnect is competitively priced. In OCI, VPN and FastConnect both terminate on the DRG.

Common mistakes for OCI people

(1) Building one-subnet-per-AZ everywhere because an AWS tutorial said so - unnecessary in OCI/GCP/Azure. (2) Assuming a GCP VPC is regional and creating one per region - it is global, you create subnets per region. (3) Forgetting AWS NACLs are stateless and locking yourself out. (4) Expecting a single "service gateway" in AWS/Azure/GCP instead of per-service endpoints.

OCI person, remember

Your instinct that "the network is regional and mostly flat" is an OCI/Azure/AWS instinct. GCP will violate it (global VPC), and AWS will violate the flat part (AZ-bound subnets, stateless NACLs). Draw the availability model first - AD/AZ/zone - before you draw subnets.

Deep Dive: Compute

The closest-mapping domain. VMs are VMs. The differences are in sizing units, bare-metal availability, and how you express "make more of these."

TL;DR FOR OCI PEOPLE

EC2 / Azure VM / Compute Engine are all Exact peers of OCI Compute. Watch two things: OCI's flexible shapes (dial OCPU + RAM freely) are more granular than fixed instance families, and OCI counts in OCPUs (1 physical core) while the others count vCPUs (usually a hyperthread) - so "4 OCPU" ≈ "8 vCPU." Do not compare price per "CPU" without normalising this.

The core mapping

Need	OCI	AWS	Azure	GCP
Virtual machine	Compute (flexible/fixed shapes)	EC2 (instance families)	Virtual Machines (VM series)	Compute Engine (machine types, incl. custom)
Bare metal	BM shapes (broad, first-class)	EC2 .metal (specific sizes)	BareMetal Infra (Oracle/SAP-focused)	Bare Metal Solution (specialized)
Dedicated hardware	Dedicated VM Host	Dedicated Hosts	Dedicated Host	Sole-tenant nodes
Autoscaling group	Instance Pool + Autoscaling	Auto Scaling Group	VM Scale Set	Managed Instance Group
Arm option	Ampere A1 (very cheap)	Graviton	Cobalt / Ampere	Axion / Tau
GPU	GPU shapes (A100/H100/...)	P/G instances	N-series	A-series / accelerator-optimized

Sizing: the OCPU trap

OCPU is not a vCPU

1 OCI OCPU = 1 physical core = generally 2 vCPU-equivalent (with hyperthreading). AWS/Azure/GCP quote vCPUs (usually one hardware thread). So an 8-vCPU EC2 is roughly a 4-OCPU OCI shape. Every price and performance comparison must normalise this or it is meaningless. OCI's Ampere A1 (Arm) is often the price-performance king for scale-out and is a common reason OCI wins on cost.

Autoscaling nuances

The concept is identical: a template + a group + scaling rules. AWS ASG is the most feature-rich (mixed instance types, warm pools, predictive scaling, capacity-optimized spot). OCI Autoscaling supports metric- and schedule-based rules on Instance Pools - enough for most tiers, fewer knobs than ASG. GCP MIGs add health-based autohealing and regional (multi-zone) MIGs. Azure VMSS supports flexible orchestration and spot.

Common mistake

Comparing OCI and AWS on "cost per instance" using vendor list price without (a) normalising OCPU↔vCPU and (b) accounting for OCI's frequently lower egress and included performance. The headline core count lies.

OCI person, remember

Bare metal is an everyday OCI primitive; elsewhere it is a niche SKU. If your value prop is "run this on dedicated iron for licensing/perf," OCI and (for Oracle/SAP) the partner bare-metal offerings are your friends - do not assume EC2/Azure give you the same bare-metal breadth.

Deep Dive: Storage

Block, object, file, archive - the four storage classes map cleanly by name. The gaps are in ecosystem depth (object storage) and specialized file systems.

TL;DR FOR OCI PEOPLE

Block/object/file/archive all have direct peers. The one place to respect: Amazon S3 is not just object storage, it is an ecosystem (events, Lambda triggers, analytics, S3 Vectors, thousands of tools). OCI Object Storage does the storage job and is S3-API-compatible for basics, but you cannot assume the surrounding automation exists. Plan the glue yourself when you leave OCI... and plan for less glue when you arrive at OCI.

The four storage classes

Class	OCI	AWS	Azure	GCP
Block	Block Volume (auto-tune perf)	EBS (gp3/io2)	Managed Disks	Persistent Disk / Hyperdisk
Object	Object Storage	S3	Blob Storage	Cloud Storage
File (NFS)	File Storage (FSS, NFSv3)	EFS / FSx	Azure Files / NetApp Files	Filestore
Archive	Object Storage - Archive	S3 Glacier / Deep Archive	Blob Archive tier	Coldline / Archive
Bulk transfer	Data Transfer Appliance/Disk	Snow family	Data Box	Transfer Appliance

Where it maps cleanly

Block volumes: attach, resize, snapshot, clone, encrypt - identical concepts. OCI's elastic performance (dial VPUs) parallels gp3/Hyperdisk decoupling IOPS from size.
Object storage buckets, tiers, lifecycle policies, versioning, pre-authenticated/pre-signed URLs - all present everywhere.
Archive tiers all trade retrieval latency for cost; all require a restore/rehydrate step.

Where it does not map

S3 gravity

Half of AWS integrates through S3 - event notifications trigger Lambda, Athena queries it, analytics services read it, S3 Vectors stores embeddings. Object Storage in other clouds is "just storage" by comparison. When you design on AWS, S3 is a hub; when you design on OCI, Object Storage is a bucket and you wire the automation (Events + Functions) yourself.

Specialized file systems

OCI FSS is solid NFSv3. AWS FSx (for NetApp ONTAP, Windows, Lustre) and Azure NetApp Files add SMB, high-performance, and enterprise-NAS features FSS does not have. If your workload needs Lustre/ONTAP/SMB, that is an AWS/Azure strength.

OCI person, remember

OCI Object Storage exposes an S3-compatible API - handy for tools, but "S3-compatible" covers the storage verbs, not S3's event/analytics ecosystem. Don't promise a migrating team that "it's just S3" if they depend on S3 event-driven pipelines; those must be rebuilt on OCI Events + Functions.

Deep Dive: Databases

This is where OCI is strongest and where the "equivalent service" question is most misleading. An OCI person must separate Oracle Database from everything else.

TL;DR FOR OCI PEOPLE

For open-source and NoSQL databases, all four clouds are close peers. For Oracle Database, OCI is in a class of its own: Autonomous Database and Exadata have no direct equivalent elsewhere - the only way to get real Oracle DB / Exadata on Azure or Google is the Oracle Database@Azure and Oracle Database@Google Cloud partnerships (Exadata physically installed in the partner's data center). AWS RDS for Oracle is a restricted, managed Oracle - not the same thing.

Oracle Database options

OCI	AWS	Azure	GCP	Match
Autonomous Database	Aurora (different engine)	Oracle DB@Azure - Autonomous	Oracle DB@Google - Autonomous	No direct (except partnerships)
Exadata Database Service	RDS Custom (partial)	Exadata DB@Azure	Exadata DB@Google	No direct (except partnerships)
Base Database Service (VM/BM)	RDS for Oracle	Oracle DB@Azure / IaaS	Oracle DB@Google / IaaS	Partial

RDS for Oracle is not OCI Oracle DB

RDS for Oracle is managed and convenient but restricted: no full SYSDBA, limited RAC (none), constrained options/patches, feature caps. If a customer needs RAC, full Data Guard control, Exadata features, or Autonomous, RDS cannot deliver it - and the honest answer for Azure/GCP is "use Oracle Database@Azure / @Google," which runs actual Exadata under the partner cloud with low-latency links to that cloud's services.

Everything else (open-source, NoSQL, warehouse)

Category	OCI	AWS	Azure	GCP
MySQL	MySQL HeatWave (+in-DB analytics/ML)	RDS/Aurora MySQL	Azure DB for MySQL	Cloud SQL for MySQL
PostgreSQL	OCI Database with PostgreSQL	RDS / Aurora PostgreSQL	Azure DB for PostgreSQL	Cloud SQL / AlloyDB
NoSQL (KV/doc)	NoSQL Database	DynamoDB	Cosmos DB	Firestore / Bigtable
Cache	OCI Cache (Redis)	ElastiCache / MemoryDB	Cache for Redis	Memorystore
Warehouse	Autonomous Data Warehouse	Redshift	Synapse / Fabric	BigQuery
Distributed SQL	(Globally Distributed Autonomous DB)	Aurora DSQL	Cosmos DB (SQL)	Spanner

Where OCI is genuinely differentiated

MySQL HeatWave runs OLTP + analytics + ML + GenAI + Lakehouse in one engine - competitors need a separate warehouse (Redshift/BigQuery/Synapse). And AI Vector Search lives inside Oracle Database 26ai, so RAG vectors sit transactionally next to your rows and are joinable in SQL - elsewhere you bolt on a separate vector store.

Where competitors lead

DynamoDB / Cosmos DB (NoSQL maturity, global tables), BigQuery (serverless warehouse scale), Aurora / AlloyDB (distributed-storage Postgres performance), and Spanner (global strong-consistency SQL) are ahead of OCI's equivalents for those specific shapes. If the workload is "planet-scale NoSQL" or "serverless petabyte analytics," do not force OCI.

OCI person, remember

When someone asks "what's the AWS equivalent of Autonomous Database," the correct, non-marketing answer is: "There isn't one - Aurora is a different engine. If they need Oracle Autonomous outside OCI, it's Oracle Database@Azure or @Google." Say that clearly; conflating Aurora with ADB will burn you in a design review.

Deep Dive: Containers & Serverless

Kubernetes is Kubernetes - the managed control planes map cleanly. Serverless is where maturity gaps are real, and Lambda is the benchmark.

TL;DR FOR OCI PEOPLE

OKE / EKS / AKS / GKE are close peers; GKE is the most mature (Autopilot, release channels). For functions, OCI Functions (container-based Fn) works but trails AWS Lambda badly on event sources, cold start, tooling, and ecosystem. If a design leans heavily on event-driven serverless, AWS is the stronger home; on OCI you compensate with Container Instances + Events.

Containers

Need	OCI	AWS	Azure	GCP
Managed Kubernetes	OKE (+ virtual nodes)	EKS (+ Fargate/Auto Mode)	AKS	GKE (Standard / Autopilot)
Serverless containers	Container Instances	Fargate	Container Instances / Container Apps	Cloud Run
Image registry	OCIR	ECR	ACR	Artifact Registry
Non-K8s orchestration	(OKE)	ECS	Container Apps	Cloud Run

Cloud Run is worth calling out: request-driven autoscaling to zero with a container - the simplest "just run my container serverlessly" experience of the four, and a GCP strength. OCI's nearest is Container Instances (no scale-to-zero request model).

Serverless functions

Aspect	OCI Functions	AWS Lambda	Azure Functions	GCP
Runtime model	Container (Fn Project)	Managed runtimes + containers	Managed runtimes + containers	Cloud Run functions
Event sources	Few (Events, API GW, cron)	Dozens (S3, DynamoDB, SQS, Kinesis...)	Many (triggers/bindings)	Many (Eventarc)
Cold start	Heavier (container)	Low (SnapStart for JVM)	Moderate	Moderate
Ecosystem	Small	Huge	Large	Growing

Common mistake

Promising a Lambda-style event-driven architecture on OCI Functions at the same effort. The compute runs; the event plumbing (native triggers from dozens of services) does not exist at Lambda's breadth. Budget extra work on OCI Events + Streaming to wire equivalents.

OCI person, remember

Kubernetes skills transfer almost 1:1 - your OKE knowledge lands you in EKS/AKS/GKE fast. Serverless functions do not transfer as cleanly; treat "learn Lambda" as learning a whole event ecosystem, not just a runtime.

Deep Dive: Observability

Metrics, logs, traces, events, alarms - all four clouds have them. The difference is how unified the pillars are and how strong the query language is.

TL;DR FOR OCI PEOPLE

OCI keeps Monitoring (metrics/alarms), Logging, Logging Analytics, Events, and APM as separate services. AWS CloudWatch and Azure Monitor bundle metrics + logs + alarms (+ more) into one umbrella, which feels more unified. Azure's KQL (Log Analytics) is the strongest ad-hoc log query language of the four. EventBridge is far more capable than OCI Events.

The mapping

Pillar	OCI	AWS	Azure	GCP
Metrics + alarms	Monitoring	CloudWatch (Metrics/Alarms)	Azure Monitor Metrics/Alerts	Cloud Monitoring
Logs	Logging (+ Logging Analytics)	CloudWatch Logs	Log Analytics (KQL)	Cloud Logging
Traces / APM	APM	X-Ray / CloudWatch APM	Application Insights	Cloud Trace / Ops suite
Event bus	Events	EventBridge	Event Grid	Eventarc
Dashboards	Dashboards	CloudWatch Dashboards	Workbooks / Grafana	Dashboards / Grafana

Where AWS/Azure feel more unified

In OCI you consciously choose Monitoring vs Logging vs Logging Analytics vs APM. CloudWatch and Azure Monitor present metrics, logs, alarms, dashboards, and (increasingly) traces under one console and one billing umbrella. Neither is "better," but the single-pane feel reduces cognitive overhead for newcomers.

EventBridge is a level above OCI Events

OCI Events triggers Functions/Notifications/Streams on resource state changes - useful but basic. EventBridge adds a schema registry, partner/SaaS event buses, event replay, and Pipes. If you are building serious event-driven automation, EventBridge is a genuine AWS advantage.

OCI person, remember

OpenTelemetry is becoming the portable layer across all four - invest there. Your OCI Monitoring/Logging concepts transfer, but expect to learn a new query language per cloud (CloudWatch Logs Insights, KQL, Cloud Logging queries). KQL (Azure) is worth learning well; it is powerful and reused across Microsoft security tools.

Deep Dive: Security Services

Keys, secrets, WAF, posture management, vulnerability scanning, secure access - all four clouds cover the checklist. Depth of threat detection and integration is where they separate.

TL;DR FOR OCI PEOPLE

OCI Vault handles both keys and secrets; AWS splits KMS (keys) from Secrets Manager (secrets, with native rotation). For posture + threat detection, Azure Defender for Cloud and GCP Security Command Center are broader than OCI Cloud Guard (workload protection, compliance frameworks, threat intel). All support HSM-backed keys and BYOK.

The mapping

Need	OCI	AWS	Azure	GCP
Encryption keys	Vault (KMS) + HSM	KMS / CloudHSM	Key Vault / Managed HSM	Cloud KMS / Cloud HSM
Secrets	Vault - Secrets	Secrets Manager / SSM Param Store	Key Vault (secrets)	Secret Manager
Certificates	Certificates	ACM	Key Vault Certificates	Certificate Manager
Web app firewall	WAF	AWS WAF	Azure WAF (App GW / Front Door)	Cloud Armor
Posture / CSPM	Cloud Guard	Security Hub + GuardDuty	Defender for Cloud	Security Command Center
Vulnerability scan	Vulnerability Scanning Service	Inspector	Defender for Cloud (vuln)	SCC / Artifact Analysis
Secure instance access	Bastion	SSM Session Manager	Azure Bastion	IAP for TCP

Where models differ

Keys vs secrets split

Coming from OCI Vault (keys + secrets in one place), remember AWS splits them, and AWS Secrets Manager gives you native rotation for RDS/Redshift/DocumentDB credentials that OCI's secret rotation does not automate to the same degree.

Agentless vs bastion access

OCI Bastion and Azure Bastion are managed jump hosts. AWS SSM Session Manager and GCP IAP take a different, arguably better approach: identity-based access to private hosts with no bastion and no open ports, fully audited. Learn that pattern - it is cleaner than a jump host.

Posture depth

Cloud Guard is competent CSPM (detector recipes, responder actions). Defender for Cloud and SCC Premium go further: runtime workload protection, regulatory compliance dashboards, and threat intelligence. On a regulated multi-cloud estate, expect richer built-in compliance reporting on Azure/GCP.

OCI person, remember

The security primitives (keys, secrets, WAF, IAM) transfer conceptually. What differs is (1) where secrets live, (2) how you access private hosts (learn SSM/IAP), and (3) the breadth of built-in compliance/threat tooling. Map controls to your compliance framework per cloud rather than assuming Cloud Guard's coverage exists everywhere by the same name.

Deep Dive: AI / ML

Every cloud now has a foundation-model platform, an agent runtime, applied-AI APIs, and a data-science stack. The differentiators are the model catalog, the silicon, and where the vectors live. (For full per-vendor depth, see the AI Learning Portals.)

TL;DR FOR OCI PEOPLE

The GenAI platforms map cleanly: OCI Generative AI ↔ Bedrock ↔ Microsoft Foundry ↔ Vertex/Gemini. OCI's real AI differentiator is AI Vector Search inside Oracle Database 26ai - vectors live transactionally next to your rows and join in SQL, instead of a separate vector store. AWS wins on model breadth (Bedrock), Azure on OpenAI frontier + M365 reach, GCP on Gemini + TPUs + BigQuery data gravity.

The mapping

Need	OCI	AWS	Azure	GCP
Foundation models	OCI Generative AI (Cohere, Llama, Grok...)	Bedrock (widest catalog)	Foundry Models (GPT-5.x + more)	Model Garden (Gemini + 200+)
Agents	Generative AI Agents	Bedrock AgentCore	Foundry Agent Service	Agent platform (ADK + A2A)
Vector search	In Oracle DB 26ai (native)	OpenSearch / Aurora pgvector / S3 Vectors	Azure AI Search	Vertex Vector Search / AlloyDB
Data science / MLOps	OCI Data Science	SageMaker	Azure ML / Foundry	Vertex AI
Applied AI (vision/lang/speech/docs)	Vision / Language / Speech / Document Understanding	Rekognition / Comprehend / Transcribe / Textract	AI Vision / Language / Speech / Document Intelligence	Vision / Natural Language / Speech / Document AI
AI silicon	NVIDIA GPUs	Trainium / Inferentia + GPUs	Maia + GPUs	TPUs + GPUs

Where OCI is differentiated

If your ground-truth data already lives in Oracle Database, AI Vector Search in 26ai lets RAG retrieval run as SQL joining vectors + relational + JSON in one transactionally-consistent query - no separate vector DB to sync. That is a genuine advantage for Oracle-data-heavy enterprises and hard to replicate elsewhere.

Where competitors lead

Model breadth and agent maturity: Bedrock's catalog + AgentCore, Azure's exclusive OpenAI frontier tiers, and GCP's owned Gemini + TPU economics all outpace OCI's model selection. For frontier-model-centric builds, the hyperscalers lead; OCI's play is data-proximity and enterprise integration.

OCI person, remember

Do not sell OCI Generative AI on "biggest model list" - you will lose to Bedrock. Sell it on data gravity: vectors and RAG next to the Oracle data you already own, under one governance and bill. Match the pitch to the strength.

Deep Dive: Cost & Governance

Every cloud has budgets, cost analysis, tagging, and policy guardrails. The differences are the pricing shape (especially egress and CPU accounting) and how governance is enforced.

TL;DR FOR OCI PEOPLE

OCI's cost story is often about lower egress and OCPU-based value, plus universal-credits simplicity. Governance-wise, remember the split: access (RBAC/IAM) vs guardrails (Azure Policy / SCPs / Org Policy) is two systems in the hyperscalers, versus OCI's more unified policy + compartment + quota model.

The mapping

Need	OCI	AWS	Azure	GCP
Budgets + alerts	Budgets	AWS Budgets	Cost Management budgets	Billing budgets
Cost analysis	Cost Analysis + Usage reports	Cost Explorer + CUR	Cost Management + exports	Billing reports + BigQuery export
Metadata	Defined + free-form tags	Tags + Tag Policies	Tags + Azure Policy	Labels + Tags
Guardrails / policy	IAM policies + compartment quotas	SCPs (Organizations)	Azure Policy + Management Groups	Org Policy constraints
Commitment discounts	Universal Credits / Annual Flex	Savings Plans / Reserved Instances	Reservations / Savings Plans	Committed Use Discounts

Pricing shape - what actually moves the bill

Egress

OCI's egress pricing (large free allowance, lower per-GB) is frequently cheaper than AWS/Azure/GCP egress, which is a common line-item shock for teams leaving those clouds. When you build cross-cloud or data-heavy egress patterns, model egress explicitly per cloud - it is where multi-cloud bills surprise people.

CPU accounting (again)

Because OCI bills in OCPUs (physical cores) and others in vCPUs (threads), a naive "per CPU per hour" comparison overstates OCI cost by roughly 2x. Normalise before you present numbers to anyone.

Governance is two systems elsewhere

OCI compartments + policies + quotas feel unified. In the hyperscalers, separate guardrail engines (SCP / Azure Policy / Org Policy) sit above the access system. Design guardrails deliberately - "deny public buckets," "restrict regions," "require tags" - they are not implied by IAM.

OCI person, remember

Your cost intuition ("egress is cheap, cores are honest") is an OCI intuition. On AWS/Azure/GCP, egress and NAT/data-processing fees can dominate, and vCPU accounting flatters their core counts. Rebuild your cost model per cloud; do not carry OCI assumptions across.

Unique in Oracle Cloud

What OCI does that the others cannot match directly - or where OCI is the natural home. This is your differentiation story; know it precisely.

OCI strength	What it is / why it matters	Closest elsewhere & why it's not the same
Autonomous Database	Self-driving, self-tuning, self-patching Oracle DB (OLTP, JSON, APEX, analytics) - eliminates most DBA toil.	Aurora is a different engine; nothing else is "Autonomous Oracle." Only reachable outside OCI via Oracle DB@Azure/@Google. No direct
Exadata Database Service	Oracle DB on Exadata engineered systems - extreme OLTP + analytics, RAC, Smart Scan.	Exadata is Oracle-only HW+SW. RDS Custom is a pale partial. No direct
Oracle Database@Azure / @Google Cloud	Real Exadata/Autonomous physically in Azure/Google data centers, low-latency to those clouds' services + one bill.	Unique multicloud-database partnership - lets you keep Oracle DB while building app tiers on Azure/GCP. No AWS equivalent (AWS/Oracle relationship is thinner).
MySQL HeatWave	MySQL with in-database analytics + ML + GenAI + Lakehouse in one engine.	Competitors need MySQL + a separate warehouse (Redshift/BigQuery). Partial
Bare metal as a first-class primitive	Broad bare-metal shapes on demand - no hypervisor tax, licensing-friendly.	EC2 .metal is a narrow set of sizes; Azure/GCP bare metal is specialized (Oracle/SAP). OCI's breadth is unusual.
Compartments as a governance model	Nestable logical isolation inside one tenancy - clean org structure without account sprawl.	AWS/GCP force many accounts/projects; Azure uses subscriptions + resource groups. No clean equivalent
Flat, regional network + Service Gateway	Regional subnets (span ADs), one Service Gateway to the whole Oracle Services Network - simpler HA and private access.	AWS AZ-bound subnets + per-service endpoints are more granular but more work.
Oracle enterprise-app fit (EBS, PeopleSoft, JD Edwards, Siebel, Hyperion)	Reference architectures, tooling, and support tuned for Oracle Apps + DB stacks; often the lowest-friction lift-and-shift.	Others run these on IaaS, but without Oracle's engineered-systems + app-aware tooling. OCI is the vendor-aligned home.
Price/performance & egress	OCPU (physical-core) pricing, cheap Arm (Ampere A1), large free egress allowance.	Hyperscaler egress + vCPU accounting often makes them pricier for data-heavy or core-heavy workloads.
Dedicated Region / Compute Cloud@Customer	Full OCI (including Autonomous/Exadata) inside your own data center for sovereignty.	AWS Outposts / Azure Stack are narrower service subsets; OCI Dedicated Region is the whole cloud on-prem.

Learning note

OCI's unique value is vertical (Oracle DB + enterprise apps + engineered systems + multicloud DB) and economic (egress, cores, bare metal). When you cross to another cloud, you are usually trading that vertical depth for horizontal breadth. Know which the workload actually needs.

Unique in AWS

Where AWS has something OCI does not have directly, or is simply far more mature. Mostly a story of breadth, ecosystem, and serverless/data depth.

AWS strength	Closest OCI equivalent	Why it's different / when AWS wins
Service breadth & maturity	OCI's core services	AWS has the widest catalog and the deepest feature sets per service; for niche needs, AWS often has a purpose-built service OCI lacks.
Lambda ecosystem	OCI Functions	Dozens of native event sources, SnapStart, huge tooling. Event-driven serverless is a different league.
S3 as an ecosystem	OCI Object Storage	S3 is the integration hub of AWS (events, analytics, Lambda, S3 Vectors). Object Storage is "just storage" by comparison.
DynamoDB	OCI NoSQL	Global tables, single-digit-ms at any scale, deep ecosystem - far more mature than OCI NoSQL.
Redshift	Autonomous Data Warehouse	Large MPP + serverless warehouse ecosystem; different (Oracle vs Redshift) engine and tooling.
SageMaker	OCI Data Science	Feature store, pipelines, tuning, HyperPod - a much broader MLOps platform.
Bedrock + AgentCore	OCI Generative AI + Agents	Widest managed model catalog and a mature agent runtime.
EventBridge / Step Functions	OCI Events / (no orchestrator)	Event bus with schema registry + a visual state-machine orchestrator OCI has no direct peer for.
Organizations + Control Tower	Compartments + policies	Multi-account governance, landing zones, SCP guardrails - a different (account-centric) model at scale.
EKS/ECS/Fargate maturity	OKE / Container Instances	ECS (non-K8s) + Fargate serverless + huge ecosystem; broader container options.
Graviton & Nitro	Ampere A1 / OCI virtualization	Graviton (Arm) is very mature; Nitro offloads virtualization to dedicated hardware for near-bare-metal VM performance and security.
Marketplace & partner ecosystem	OCI Marketplace	Far larger third-party/ISV catalog and integrations.
CloudFront	(OCI leans on partners)	First-party global CDN + edge compute (Lambda@Edge, CloudFront Functions); OCI has a real gap here.

When OCI may still be better

Oracle DB workloads, bare-metal/licensing-sensitive workloads, egress-heavy or core-heavy cost-sensitive workloads, and Oracle enterprise apps. AWS breadth does not beat OCI's Oracle-vertical depth or economics for those.

Learning note for an OCI person

AWS rewards depth. Start with IAM (very different, condition-key rich), then VPC (AZ-bound subnets, stateless NACLs), then S3-as-a-hub, then Lambda + EventBridge as an ecosystem, not single services. Budget the most learning time for serverless and the account/Organizations model.

Unique in Azure

Azure's edge is the Microsoft enterprise: identity, Windows/SQL Server, M365, hybrid, and governance. If the enterprise runs on Microsoft, Azure has gravity OCI cannot match.

Azure strength	Closest OCI equivalent	Why it's different / when Azure wins
Microsoft Entra ID	OCI IAM (federates to Entra)	The enterprise identity plane for most large orgs; conditional access, seamless SSO to M365 and thousands of SaaS apps.
Microsoft 365 integration	(none)	Teams, SharePoint, Outlook, Copilot - if your users live in M365, Azure/Copilot is where AI meets them.
Azure Arc	(Compute Cloud@Customer, different)	Extends the Azure control plane over on-prem, other clouds, and edge - govern anything as an Azure resource. No OCI equivalent.
Azure Policy	OCI policies + quotas (partial)	A dedicated, powerful guardrail engine (allowed regions, required tags, deny rules) separate from RBAC.
Azure DevOps + GitHub	OCI DevOps	The most complete SDLC platform (Boards, Repos, Pipelines) plus GitHub - far ahead of OCI DevOps.
Microsoft Defender for Cloud	Cloud Guard	Broader CSPM + workload protection + compliance + threat intel, and it can protect multi-cloud/on-prem.
Azure OpenAI / Foundry	OCI Generative AI	Enterprise access to OpenAI frontier models (GPT-5.x) with SLAs + M365 distribution.
Windows Server & SQL Server alignment	(OCI runs them on IaaS)	Hybrid Use Benefit, native SQL Server PaaS (Azure SQL / Managed Instance), deepest Windows tooling.
Power Platform	(APEX is OCI's low-code, different)	Power Apps/Automate/BI low-code suite tightly bound to M365 and Dataverse.
ExpressRoute + hybrid patterns	FastConnect	Deep private peering to M365 and mature hybrid/DR patterns (Azure Site Recovery, Arc).
AKS in a Microsoft estate	OKE	Comparable Kubernetes, but with tight Entra/DevOps/Defender integration for Microsoft shops.

When OCI may still be better

Oracle DB (unless via Oracle DB@Azure, which pairs the two nicely), bare metal, and raw price/performance for compute- or egress-heavy workloads. Azure's strength is Microsoft-estate integration, not Oracle-workload economics.

Learning note for an OCI person

Learn Azure's hierarchy first (Tenant → Management Group → Subscription → Resource Group) and the RBAC-vs-Policy split - they trip up everyone. Then Entra ID, because it is the identity spine everything hangs off. Note the happy path: Oracle Database@Azure lets an OCI/Oracle shop keep Oracle DB and build the app tier natively in Azure.

Unique in Google Cloud

GCP's edge is data, AI, Kubernetes, and a genuinely global network. If the workload is analytics- or AI-centric, GCP often leads.

GCP strength	Closest OCI equivalent	Why it's different / when GCP wins
BigQuery	Autonomous Data Warehouse	Serverless, separates storage/compute, scales to petabytes with no cluster management + native BQML/ML + Gemini-in-BQ. The benchmark warehouse.
Vertex AI / Gemini	OCI Generative AI / Data Science	Google's own frontier Gemini models + full MLOps + TPUs - a full-stack AI story OCI cannot match on models/silicon.
GKE	OKE	The most mature managed Kubernetes (Autopilot, release channels, multi-cluster) - Google invented K8s.
Cloud Run	Container Instances (partial)	Request-driven serverless containers that scale to zero - the simplest "run my container" model.
Global VPC	VCN (regional)	One VPC spanning all regions, plus a global anycast load balancer with a single IP - unique network model.
Spanner	Globally Distributed Autonomous DB (partial)	Globally distributed, strongly-consistent relational DB with horizontal scale - a category GCP pioneered.
AlloyDB	OCI Database with PostgreSQL	PostgreSQL-compatible with distributed storage + big analytical/vector acceleration OCI's managed PG does not match.
Pub/Sub	OCI Streaming / Notifications	Global, auto-scaling messaging with push+pull - a different (planet-scale) model from Kafka-style streaming.
Dataflow	Data Flow (Spark)	Unified batch + streaming on Apache Beam - a different processing paradigm.
Looker	(OAC, different)	Governed semantic-model BI (LookML) embedded across the data stack.
Apigee	OCI API Gateway	Full API-management platform (portal, monetization, analytics) - far beyond a gateway.
Anthos / GDC	(Compute Cloud@Customer, different)	Run GKE + Google services across on-prem and other clouds - hybrid/multi-cloud Kubernetes control plane.

When OCI may still be better

Oracle DB and enterprise Oracle apps, bare metal, and cost for egress/core-heavy workloads. GCP wins on data/AI/Kubernetes/global-network; it is not the Oracle-workload home.

Learning note for an OCI person

The biggest mental reset is the global VPC - unlearn "network = regional." Then invest in BigQuery (it will change how you think about analytics) and GKE (your OKE skills transfer fastest here). GCP's project-centric model is also stricter than compartments - plan the folder/project tree deliberately.

Architecture Pattern Comparison

The same solution, built four ways. Components per cloud, plus where the design genuinely differs and which cloud fits best. These are shapes, not prescriptions - confirm limits in current docs.

1. Highly available web application (LB + auto-scaled app + managed DB)

Layer	OCI	AWS	Azure	GCP
Edge	Load Balancer + WAF	ALB + WAF (+ CloudFront)	App Gateway (WAF) / Front Door	Global HTTPS LB + Cloud Armor
App tier	Instance Pool + Autoscaling across ADs/FDs	ASG across AZs	VMSS across zones	Regional MIG across zones
Data	Autonomous DB / MySQL HeatWave	Aurora / RDS	Azure SQL / PostgreSQL	Cloud SQL / AlloyDB / Spanner
HA unit	Regional subnet + Fault Domains	Multi-AZ (subnet per AZ)	Availability Zones	Multi-zone (regional resources)

Key difference & best fit

OCI/GCP give multi-zone HA with a single regional subnet; AWS needs a subnet per AZ. GCP's global LB simplifies multi-region. Best fit: any cloud does this well - pick by where the DB and team already are.

2. Oracle-database-backed enterprise application

	OCI	AWS	Azure	GCP
DB	Exadata / Autonomous (native)	RDS for Oracle (restricted)	Exadata DB@Azure	Exadata DB@Google
App tier	OCI Compute	EC2	Azure VM / app services	Compute Engine

Best fit

OCI outright, or Oracle DB@Azure/@Google if the app tier must live in Azure/GCP. AWS RDS for Oracle only fits if the DB needs are modest (no RAC, limited features).

3. Object-storage data lake

	OCI	AWS	Azure	GCP
Store	Object Storage	S3	ADLS Gen2	Cloud Storage
Catalog/govern	Data Catalog	Lake Formation + Glue	Fabric / Purview	Dataplex + BigLake
Query	Data Flow (Spark) / ADW	Athena / Redshift	Synapse / Fabric	BigQuery

Best fit

GCP (BigQuery) or AWS (S3 + Athena/Lake Formation) for a governed, query-anywhere lake. OCI works but you assemble more of the governance yourself.

4. Kubernetes microservices

OKE / EKS / AKS / GKE + their registries + service mesh. Skills transfer nearly 1:1. Best fit: GKE for maturity/Autopilot; any cloud is fine; pick by surrounding ecosystem (Entra+DevOps → AKS; data/AI → GKE; Oracle data → OKE).

5. Event-driven / serverless application

	OCI	AWS	Azure	GCP
Compute	Functions / Container Instances	Lambda	Functions / Container Apps	Cloud Run (functions)
Events	Events + Streaming	EventBridge + SQS/SNS	Event Grid + Service Bus	Eventarc + Pub/Sub
Orchestration	(build it)	Step Functions	Logic Apps / Durable Functions	Workflows

Best fit

AWS - Lambda + EventBridge + Step Functions is the most complete event-driven stack. OCI is the weakest here; do not lead with OCI for a serverless-heavy design.

6. GenAI assistant over private enterprise data (RAG)

	OCI	AWS	Azure	GCP
Model	OCI Generative AI	Bedrock	Foundry (Azure OpenAI)	Vertex / Gemini
Vectors	In Oracle DB 26ai	OpenSearch / S3 Vectors	Azure AI Search	Vertex Vector Search
Grounding	Select AI + DB data	Knowledge Bases	On Your Data / AI Search	RAG Engine / grounding

Best fit

If the ground-truth data is in Oracle Database, OCI is uniquely strong (vectors + RAG in-DB). If it's in M365 → Azure; in BigQuery → GCP; anywhere on AWS → Bedrock. Data gravity decides.

7. Disaster recovery (cross-region failover)

OCI Full Stack DR (orchestrates DB + compute + network) / AWS Elastic Disaster Recovery / Azure Site Recovery (very mature) / GCP (Backup & DR + manual). Best fit: OCI for Oracle-stack DR (Data Guard-aware), Azure for broad VM DR (ASR).

8. Hybrid / on-prem connectivity

Private circuit (FastConnect / Direct Connect / ExpressRoute / Cloud Interconnect) + VPN backup, terminating on DRG (OCI) / TGW (AWS) / vWAN (Azure) / NCC (GCP). Control-plane-over-anything: Azure Arc and GCP Anthos are unique; OCI's answer is Dedicated Region / Compute Cloud@Customer. Best fit: Microsoft estate → Azure (ExpressRoute+Arc); Oracle sovereignty → OCI Dedicated Region.

Cross-cutting notes for every pattern

Cost: model egress + NAT/data-processing per cloud (OCI usually cheapest egress). Security: apply guardrails (SCP/Azure Policy/Org Policy) - not implied by IAM. Operations: pick the cloud where your team already has identity, tooling, and skills unless a workload strength (Oracle DB, BigQuery, Lambda) overrides.

Decision Matrix - which cloud for which workload

Best-fit and second-best by workload, with the reasoning and the trap. Anchored to the strengths, not vendor marketing. "Where your data + identity already live" beats a marginal feature edge in almost every row.

Workload	Best fit	Second	Why / trade-off / risk
Oracle Database (RAC/Exadata/Autonomous)	OCI	DB@Azure / @Google	Only OCI (or the partnerships) gives real Exadata/Autonomous. Risk: RDS for Oracle looks tempting but caps features.
Oracle enterprise apps (EBS, JDE, Siebel, PeopleSoft, Hyperion)	OCI	DB@Azure + app on Azure	Vendor-aligned tooling + lowest-friction lift. Trade-off: fewer surrounding SaaS integrations than AWS/Azure.
Microsoft enterprise (AD, Windows, SQL Server, M365)	Azure	AWS	Entra + Hybrid Use Benefit + M365 gravity. Risk: over-buying Microsoft lock-in if not already a Microsoft shop.
Data analytics / warehouse	GCP (BigQuery)	AWS (Redshift) / Azure (Fabric)	Serverless scale, least ops. Trade-off: leaving GCP later means egress + rework.
AI / ML & GenAI	Depends on data	-	Oracle data → OCI; M365 → Azure (OpenAI); BigQuery → GCP (Gemini); anywhere → AWS (Bedrock breadth). Data gravity wins.
Serverless / event-driven	AWS	GCP (Cloud Run) / Azure	Lambda + EventBridge + Step Functions is unmatched. Risk: heaviest lock-in of any pattern.
Kubernetes	GCP (GKE)	Any	Most mature K8s; but skills transfer 1:1, so ecosystem/data proximity often decides instead.
Global web / low-latency edge	GCP	AWS (CloudFront)	Global VPC + anycast LB; AWS CloudFront also strong. Risk: OCI's CDN gap makes it the weakest here.
Cost-sensitive / compute-heavy / egress-heavy	OCI	GCP	OCPU pricing, Ampere Arm, cheap egress. Trade-off: fewer managed niceties; more assembly.
Regulated / sovereign	OCI / Azure	AWS / GCP	OCI Dedicated Region (full cloud on-prem) + Azure's gov/compliance breadth. Verify region + certification per workload.
Hybrid (control plane over on-prem)	Azure (Arc)	GCP (Anthos) / OCI (C3/Dedicated Region)	Arc governs anything as an Azure resource. Trade-off: adds Azure dependency to your on-prem.
Multi-cloud (Oracle DB + other-cloud apps)	OCI + DB@Azure/@Google	-	The partnerships are purpose-built for this. Risk: cross-cloud egress + two control planes to operate.

The meta-rule

For most enterprises the right answer is "the cloud your data, identity, and team already live in" - a marginally better service rarely justifies moving data gravity. The strong exceptions are the Oracle-DB and Microsoft-estate rows, where the vertical fit is decisive.

Hands-on Learning Path for OCI Professionals

A sequenced path that leans on what you already know from OCI. Each stage says what to learn, the OCI concept it maps to, and a concrete hands-on task. Pick one target cloud first; do not learn three at once.

Before you start - use your OCI leverage

You already understand tenancy/compartments, VCNs, IAM policy, block/object storage, load balancing, DB, and IaC. You are not a beginner - you are translating. Every stage below is "same concept, new dialect," so move fast on fundamentals and spend your time on the genuine differences (IAM model, network scoping, serverless, the account/subscription/project hierarchy).

Stage 0 - Foundations (all three targets share this)

Learn	Maps from OCI	Hands-on task
Account structure	Tenancy + compartments	AWS: Organizations + 2 accounts. Azure: Mgmt Group → Subscription → Resource Group. GCP: Org → Folder → Project. Build the tree.
Identity model	OCI IAM policies	Create a role/group with least privilege. Note the shift: AWS role-assumption + policy JSON; Azure RBAC + Entra; GCP roles + service accounts.
CLI + Cloud Shell	OCI CLI	Install/auth the CLI, list resources, launch Cloud Shell.
Free tier / budget	OCI Always Free	Set a budget + alert on day one so labs never surprise-bill you.

Stage 1 - Network (the biggest mental reset)

Learn	Maps from OCI (VCN)	Hands-on task
VPC/VNet + subnets	VCN + subnets	Build a 2-tier network. AWS: notice subnets are AZ-bound + stateless NACLs. Azure: NSGs on subnet/NIC. GCP: the VPC is global - one big reset.
Internet + NAT egress	IGW + NAT GW	Put a private VM behind NAT; reach it via a bastion.
Private service access	Service Gateway	AWS: VPC endpoints (per service!). Azure: Private Endpoint/Service Endpoint. GCP: Private Google Access.

Stage 2 - Compute + storage

Learn	Maps from OCI	Hands-on task
VM + auto-scaling	Instance + Instance Pool	Launch a VM, build an auto-scaling group across zones/AZs behind a load balancer.
Object + block storage	Object Storage + Block Volume	Create a bucket with lifecycle rules; attach a resized block volume.
Managed load balancer	OCI LB	Front the app tier; add a health check + TLS.

Stage 3 - Database (play to your strength)

Learn	Maps from OCI	Hands-on task
Managed relational DB	Autonomous DB / Base DB	Stand up AWS RDS/Aurora, Azure SQL, or GCP Cloud SQL. Compare backup, HA, and read-replica UX to Autonomous.
Oracle DB elsewhere	Autonomous / Exadata	Read the Oracle Database@Azure / @Google docs - this is your bridge, know it cold.
NoSQL	OCI NoSQL	Build a DynamoDB / Cosmos DB / Firestore table; feel the different data model.

Stage 4 - The genuinely new territory

Learn	Why it's new	Hands-on task
Serverless + events	OCI is thin here; the others are deep	AWS: Lambda + EventBridge + Step Functions end-to-end. Azure: Functions + Logic Apps. GCP: Cloud Run + Eventarc.
IaC	You know Resource Manager (Terraform)	Reuse Terraform across clouds; add the cloud-native tool (CloudFormation / Bicep / Deployment Manager) for literacy.
Governance guardrails	Separate from IAM	AWS SCP (Control Tower), Azure Policy, GCP Org Policy - enforce "allowed regions + required tags."
GenAI	Model + vector + grounding	Build a small RAG app: Bedrock / Azure OpenAI / Vertex. If your data is in Oracle DB, do the OCI in-DB-vectors version too.

Stage 5 - Prove it with a capstone

Deploy one real workload end-to-end in your target cloud: VPC + auto-scaled app + managed DB + object storage + load balancer + IaC + a budget alarm + a governance guardrail. Then write down, in your own words, the three things that differ most from OCI. That document is your interview and architecture asset.

Certification path (optional, in this order)

Target-cloud foundational cert (AWS Cloud Practitioner / AZ-900 / GCP Digital Leader) → Associate architect (AWS SAA-C03 / AZ-104 / Associate Cloud Engineer) → then a specialty that matches your OCI edge (database or AI). Do the hands-on stages first; certs validate, they don't teach.

Sequencing advice

Learn one cloud to Stage 5 before touching a second. Recommended first target by goal: AWS for breadth/market demand, Azure if your enterprise is Microsoft/Oracle-DB@Azure, GCP if the work is data/AI. Your OCI depth is the differentiator - keep it sharp while you add the second cloud.

Sources & how to verify

Service mappings and features change monthly. Everything here was reviewed June 2026; treat any mapping marked "verify" as a starting point and confirm against current vendor docs before you design or migrate.

Accuracy stance

This portal is independent and vendor-neutral. Match levels (Exact / Close / Partial / Conceptual / No direct) are engineering judgments about how closely services line up, not vendor claims. Where a mapping is nuanced or fast-moving, it is flagged - do not treat a badge as a substitute for reading the docs.

Primary documentation

OCI: docs.oracle.com/en-us/iaas · Oracle Architecture Center · Oracle Database@Azure / @Google Cloud docs
AWS: docs.aws.amazon.com · AWS Architecture Center · AWS Well-Architected Framework
Azure: learn.microsoft.com/azure · Azure Architecture Center · Cloud Adoption Framework
GCP: cloud.google.com/docs · Google Cloud Architecture Framework

Cross-cloud comparison references

Vendor service-comparison pages (Azure "AWS to Azure" & "GCP to Azure" service maps; Google "AWS/Azure to GCP" maps) - useful but written from each vendor's viewpoint; cross-check.
Each cloud's pricing calculator for real cost comparisons - model egress and data-processing charges explicitly.

How to keep this current

Re-check the "Last reviewed" date. When a mapping matters to a decision, open both vendors' current service pages, confirm the feature still exists and still lines up, and note any new service that closes a former gap (these clouds ship constantly). Treat mappings as directional, not contractual.