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.

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

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.

Foundations: account, identity & network

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.

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.

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.

Physical layout & availability

Region (OCI)

OCI Region = Exact AWS Region / Azure Region / GCP Region - a geographic area you deploy into, and your data-residency boundary. The word travels perfectly; what differs is what sits inside it (see Availability Domain).

Availability Domain (OCI)

An OCI Availability Domain (AD) is one or more isolated data centres inside a region. AWS: Close - Availability Zone (AZ). Azure: Close - Availability Zone. GCP: Close - Zone. The catch that bites OCI newcomers to other clouds (and vice-versa): many OCI regions have only one AD, while AWS/Azure/GCP regions almost always expose 3+ zones.

Fault Domain (OCI)

A Fault Domain is an anti-affinity hardware grouping inside an AD (exactly 3 per AD, roughly "a rack"). AWS: Partial - the nearest is partition / spread placement groups, but that is opt-in, not a built-in 3-way split. Azure: Close - Fault Domains inside Availability Sets / scale sets (same name, same idea). GCP: No direct - you lean on zones plus spread placement policies.

Networking building blocks

Subnet (OCI)

OCI subnets are usually regional (span the whole region); AD-specific subnets exist but are legacy. AWS: Partial - a subnet is bound to one AZ, so you create one per AZ. Azure: Close - subnets are regional inside a VNet. GCP: Close - subnets are regional inside the global VPC.

Internet & NAT Gateway (OCI)

OCI Internet Gateway (two-way public for resources with public IPs) and NAT Gateway (outbound-only for private subnets) = Close everywhere. AWS: Internet Gateway + NAT Gateway. Azure: explicit outbound - NAT Gateway, Standard Load Balancer outbound rules, or a Public IP on the NIC (new VNets are private by default in API versions after 31 March 2026). GCP: default internet gateway route + Cloud NAT. Same two mental buckets: two-way public vs outbound-only.

Service Gateway (OCI)

OCI's Service Gateway gives a private subnet backbone access to the entire Oracle Services Network (Object Storage, Autonomous DB, etc.) through a single object, no internet. AWS: Partial - Gateway VPC Endpoints (S3/DynamoDB) plus Interface Endpoints / PrivateLink per service. Azure: Partial - Service Endpoints and Private Endpoints per service. GCP: Partial - Private Google Access plus Private Service Connect per service.

Dynamic Routing Gateway / DRG (OCI)

The DRG is OCI's routing hub for on-premises (VPN / FastConnect) and VCN-to-VCN / cross-region traffic. AWS: Close - Transit Gateway (plus Virtual Private Gateway for a single VPN). Azure: Close - Virtual WAN hub / VPN & ExpressRoute gateways. GCP: Partial - Cloud Router + HA VPN, orchestrated by Network Connectivity Center. Private circuits: OCI FastConnect = AWS Direct Connect / Azure ExpressRoute / GCP Cloud Interconnect (Close).

Local / Remote Peering (OCI)

OCI Local Peering Gateway (same region) and Remote Peering Connection (cross-region) = Close - VPC / VNet peering everywhere (AWS VPC Peering, Azure VNet Peering, GCP VPC Network Peering). Modern OCI routes both through the DRG hub rather than the legacy LPG.

Load Balancer (OCI)

OCI Load Balancer (L7, HTTP-aware) and Network Load Balancer (L4) = Close. AWS: ALB (L7) / NLB (L4). Azure: Application Gateway (L7) / Load Balancer (L4). GCP: the Cloud Load Balancing family (Application vs Network LBs). Same split - route on content (L7) vs pass-through (L4).

Identity for workloads

Instance Principal (OCI)

An instance principal is how a specific compute instance authenticates to OCI APIs with short-lived, auto-rotated credentials (via its dynamic group) - no keys on disk. AWS: Close - an IAM role via the instance profile, credentials fetched from IMDS. Azure: Close - a system-assigned Managed Identity, token from IMDS. GCP: Close - the attached Service Account, token from the metadata server. Same pattern everywhere: the machine is the identity, and stored API keys are the anti-pattern.

Resource Principal (OCI)

A resource principal is the same idea for managed / serverless resources (Functions, Data Science, Autonomous DB, OKE workloads). AWS: Close - execution roles (Lambda execution role, ECS task role, IRSA on EKS). Azure: Close - a Managed Identity on the service. GCP: Close - the service's runtime Service Account (incl. Workload Identity on GKE).

Compute

Shape & OCPU (OCI)

An OCI shape is an instance type; you size it in OCPUs (and, for flexible shapes, memory). AWS / Azure / GCP: Partial - all use instance types / sizes measured in vCPUs. The number that must be normalised: 1 OCPU = 1 physical core; that is 2 vCPUs on x86 (Intel/AMD) and on Ampere A2/A4, but only 1 vCPU on Ampere A1. OCI flexible shapes (dial OCPU + memory independently) map loosely to AWS/GCP custom machine types.

Bare Metal (OCI)

OCI offers bare metal as an everyday, broadly available shape. AWS: Partial - .metal instance types (a narrower, niche set). Azure: No direct - only specialised BareMetal / SAP / Oracle SKUs. GCP: Partial - Bare Metal Solution (a separate offering, largely for Oracle). Breadth of bare metal is a genuine OCI differentiator.

Instance Pool & Autoscaling (OCI)

OCI Instance Configuration + Instance Pool + Autoscaling = Close - AWS Launch Template + Auto Scaling Group, Azure VM Scale Sets, GCP Instance Template + Managed Instance Group. The same three-part template / group / scale pattern in every cloud.

Storage vocabulary

Block Volume (OCI)

Close - AWS EBS, Azure Managed Disk, GCP Persistent Disk. Network-attached block storage you format and mount. OCI tunes performance with VPU per GB; the others use disk types / tiers (gp3/io2, Premium/Ultra SSD, pd-ssd/pd-extreme).

Object Storage (OCI)

Close - AWS S3, Azure Blob Storage, GCP Cloud Storage. Buckets and objects (not a filesystem). Tiers line up: OCI Standard / Infrequent Access / Archive ↔ S3 Standard / IA / Glacier ↔ Blob Hot / Cool / Archive ↔ GCS Standard / Nearline / Coldline / Archive. OCI Object Storage is also S3-API compatible, which eases tooling reuse.

File Storage / FSS (OCI)

Close - AWS EFS, Azure Files, GCP Filestore. Managed shared NFS filesystems mounted by many hosts at once.

Archive Storage (OCI)

Close - AWS S3 Glacier tiers, Azure Archive tier, GCP Archive class. Cheapest to store, with a restore delay before you can read. Same trade-off everywhere: never park anything you might need immediately in archive.

Database vocabulary

Base Database Service (OCI)

Managed Oracle Database on VM / bare metal (single-node or 2-node RAC). AWS: Partial - RDS for Oracle (managed, but fewer options and no OS/RAC control). Azure & GCP: Partial - Oracle Database@Azure / @Google (Oracle-operated inside those clouds) or self-managed Oracle on IaaS.

Autonomous Database (OCI)

Self-driving, self-tuning, self-patching Oracle DB (OLTP / DW / JSON / APEX). AWS: No direct - Aurora is a different engine; serverless DBs (Aurora Serverless) share only the autoscale idea, not the Oracle engine or the "autonomous" operations. Azure / GCP: No direct - reachable only as Autonomous via Oracle Database@Azure / @Google. This is an OCI-defining service.

Exadata Database Service (OCI)

No direct - Exadata is Oracle-only engineered hardware + software (RAC, Smart Scan, storage cells). AWS RDS Custom is a pale partial; the real thing outside OCI is Exadata Database Service on Oracle AI Database@AWS / @Azure / @Google Cloud. Nothing non-Oracle reproduces Smart Scan.

Data Guard & RAC (OCI)

RAC (in-site node HA) and Data Guard / Active Data Guard (cross-site standby for DR) are Oracle-native. AWS / Azure / GCP: Conceptual - Multi-AZ deployments, read replicas, and failover groups solve similar HA/DR problems with genuinely different mechanics. Map the intent (RAC = uptime, Data Guard = DR / data loss), not the mechanism.

Security & key management

Vault - Keys & Secrets (OCI)

Close - AWS KMS + Secrets Manager, Azure Key Vault, GCP Cloud KMS + Secret Manager. OCI Vault holds keys, secrets, and certificates in one service; AWS and GCP split keys and secrets into two. Customer-managed keys and HSM protection exist in all four.

Bastion (OCI)

Close - AWS SSM Session Manager / EC2 Instance Connect, Azure Bastion, GCP IAP TCP forwarding / OS Login. Time-boxed, audited, keyless admin access to private hosts with no standing jump box.

Cloud Guard & Security Zones (OCI)

Close - AWS Security Hub + GuardDuty + Config, Azure Defender for Cloud + Azure Policy, GCP Security Command Center + Org Policy. Two jobs everywhere: detect misconfiguration / threats (Cloud Guard) and prevent them (Security Zones).

WAF & Network Firewall (OCI)

Close - AWS WAF + Network Firewall, Azure WAF + Azure Firewall, GCP Cloud Armor + Cloud NGFW. Layer-7 web protection plus a managed stateful network firewall.

Automation & governance

Resource Manager (OCI)

Managed Terraform - stacks, stored state, plan/apply, drift detection. AWS: Partial - native CloudFormation (or Terraform you host yourself). Azure: Partial - ARM / Bicep. GCP: Partial - Infrastructure Manager (managed Terraform) / legacy Deployment Manager. OCI standardises on Terraform, which is the most portable of these across clouds.

Budgets, Quotas & Tags (OCI)

Close - Budgets map to AWS/Azure/GCP Budgets (alert, not block). Compartment Quotas map to AWS Service Quotas / Azure Quotas / GCP Quotas - but OCI quotas can also block resource creation per compartment as a policy. Defined tags + tag defaults map to tag policies / tag enforcement everywhere; the enforcement is what makes cost attribution and chargeback work.

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.

How each cloud structures an account

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

Terminology quick-swap

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.

The network object model

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

Firewalls: the trap

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.

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."

The core mapping

Sizing: the OCPU trap

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.

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.

The four storage classes

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

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.

Oracle Database options

Everything else (open-source, NoSQL, warehouse)

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.

Containers

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

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.

The mapping

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.

The mapping

Where models differ

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.)

The mapping

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.

The mapping

Pricing shape - what actually moves the bill

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.

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.

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.

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.

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)

2. Oracle-database-backed enterprise application

3. Object-storage data lake

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

6. GenAI assistant over private enterprise data (RAG)

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.

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.

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.

Stage 0 - Foundations (all three targets share this)

Stage 1 - Network (the biggest mental reset)

Stage 2 - Compute + storage

Stage 3 - Database (play to your strength)

Stage 4 - The genuinely new territory

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.

Sources & how to verify

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

Primary documentation

• OCI: OCI documentation · Oracle Architecture Center · Oracle Database@Azure · Oracle Database@Google Cloud · Oracle Database@AWS
• AWS: AWS documentation · AWS Architecture Center · Well-Architected Framework
• Azure: Azure documentation · Azure Architecture Center · Cloud Adoption Framework
• GCP: Google Cloud documentation · Architecture Framework

Cross-cloud comparison references

• Vendor service-comparison pages - useful but written from each vendor's viewpoint; cross-check: Azure for AWS professionals · Azure for GCP professionals · Google's AWS/Azure-to-GCP service comparison
• AI-platform status pages used for the AI/ML rows (verified 10 August 2026): OCI Generative AI release notes · Bedrock supported models · Microsoft Foundry docs · Gemini Enterprise Agent Platform release notes
• Each cloud's pricing calculator for real cost comparisons - model egress and data-processing charges explicitly: OCI · AWS · Azure · Google Cloud

How to keep this current

Re-check the "Last verified" 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.