Oracle Cloud Infrastructure Overview — Enterprise Cloud With Distinctive Pricing

What starting a decade late actually bought

OCI's "second generation" framing is not marketing; it describes a rebuild. Oracle's first cloud attempt inherited the industry's original assumption that the hypervisor should also be the network. OCI abandoned it. The work that turns a physical NIC into a tenant's virtual NIC -- encapsulation, security-rule evaluation, route lookup, bandwidth accounting -- runs on dedicated hardware sitting in the network path, not in software on the host CPU. AWS arrived at the same conclusion with Nitro (see aws/aws_nitro_system), but OCI started there, which is why the consequences reach further into the product.

Three things fall out of that one choice. Bare metal instances need no special plumbing, because there was never any host-side plumbing to remove: the same virtual NIC, the same block volume attachment and the same VCN semantics apply whether the instance is a fraction of a host or the entire host. The performance profile of networking and storage stops depending on what the guest is doing to the host CPU. And tenant isolation stops depending on hypervisor correctness, which is precisely what makes handing an unvirtualized machine to a customer defensible in the first place.

The second late-mover advantage is organizational rather than physical: a tenancy model designed once, up front, instead of an account model that grew its organizational features years after people had already built on it.

Tenancy and compartments: the primitive with no AWS equivalent

A tenancy is the root of everything you own. It maps roughly onto an AWS account or a GCP organization: it is the billing root, the identity root, and the thing a support contract attaches to. That is where the analogy stops being useful.

Inside the tenancy, every resource lives in exactly one compartment. Compartments nest, forming a tree whose root is the tenancy itself -- which is why the tenancy is also called the root compartment, and why a policy written at that level reaches everything below it. Compartments are logical, not physical. A compartment is not a region, not a network, not an environment; the same compartment can hold instances in Ashburn and Frankfurt at once, because compartments are global IAM objects mastered in your home region while the resources inside them stay regional.

The mistake almost everyone makes on the way in is treating a compartment as a folder for tidiness. It is not a folder. It is the object that authorization, cost reporting and consumption limits all address, simultaneously.

Compartments are three boundaries at once

Authorization. Policy statements are scoped to a compartment and inherit downward. Allow group Developers to manage instance-family in compartment Dev grants nothing in a sibling compartment and everything in Dev's children, and the verbs form a ladder -- inspect, read, use, manage -- rather than an arbitrary action list. The policy language itself, along with dynamic groups and instance principals, belongs to cloud/oci_iam_deep.

Cost. Every resource carries its compartment on the billing record. The compartment tree is therefore a chargeback breakdown you get for free, before anyone has agreed on a tagging convention -- which, in practice, is the only cost attribution most organizations ever actually maintain.

Consumption. Compartment quota policies are their own small statement language, something like set compute-core-count quota standard-e4-core-count to 200 in compartment Dev. They cap usage below the tenancy-wide service limit, which is the difference between a hard ceiling on a team's spend and an alert that arrives after the spend.

Because all three ride the same tree, the compartment layout you sketch in week one becomes your permission model, your cost report and your blast radius at the same time. Most resource types support being moved between compartments, but it is a genuine migration with policy and OCID consequences, not a rename.

Region, availability domain, fault domain: three levels, not two

AWS gives you two levels of physical placement: region and availability zone. OCI gives you three, and the middle one is not always present.

A region contains either one or three availability domains. Never two. An availability domain is a datacenter, or a tight cluster of them, with independent power, cooling and internal networking, joined to its siblings by low-latency intra-region links -- functionally the same construct as an AZ. The catch is the single-AD region. Many OCI regions, particularly in smaller markets and newer geographies, have exactly one. An HA design that assumes it can spread replicas across availability domains does not fail loudly in those regions; it silently collapses into a single-datacenter deployment that still passes its own health checks.

Below the AD sits the fault domain, and this is the level the other major clouds do not surface as a first-class placement control. Each availability domain contains exactly three fault domains: groupings of hardware inside the datacenter that do not share a power feed, a top-of-rack switch, or a maintenance window. Oracle patches and reboots infrastructure one fault domain at a time. You can pin an instance to a fault domain at launch, or let an instance pool spread its members across all three.

That combination gives single-AD regions a real answer for hardware failure and planned maintenance -- distribute the quorum across fault domains and accept that whole-datacenter loss needs a second region -- and gives multi-AD regions two nested axes. The pattern that survives contact is AD for the outer spread, fault domain for the inner one, with quorum sizes chosen so that losing one member of either level still leaves you a majority.

Realms are the ceiling above regions

Above region sits a level with no directly exposed equivalent elsewhere: the realm. A realm is a wholly separate instance of OCI -- its own identity plane, its own service endpoints, its own object storage namespaces, and no network path between realms. The commercial realm, oc1, is what most people mean when they say OCI. Government, defence and sovereign realms are independent deployments of the same software with no shared control plane.

The isolation is categorical in a way that region isolation is not. Two regions in the same realm share an identity plane: a user in your tenancy can be granted access to any region you have subscribed to, and IAM objects replicate outward from your home region. Two regions in different realms cannot see each other at all. You cannot peer their networks, cannot federate one identity across them, and cannot ask a service to copy an object from one to the other. What you have is two tenancies, two bills, and two operational surfaces that happen to speak the same API.

This is the right level to reason at if you are selling into public sector or building against data-residency law. The engineering cost is rarely the sovereign region itself -- it is that every pipeline credential, every Terraform state file, every monitoring integration and every on-call runbook now exists twice, with nothing shared between the copies except your discipline in keeping them in step.

OCIDs are the control plane's real identifier

Every resource carries an Oracle Cloud Identifier, and the structure repays reading instead of being treated as an opaque blob:

ocid1.instance.oc1.iad.anuwcljtxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  |      |      |   |    |
  |      |      |   |    +-- opaque, unique, resource-specific
  |      |      |   +------- region  (iad = Ashburn)
  |      |      +----------- realm   (oc1 = commercial)
  |      +------------------ resource type
  +------------------------- OCID version

ocid1.user.oc1..aaaaaaaaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
               ^^
               empty region segment -- this object is global

Three consequences follow. An OCID is self-locating: a script handed one knows which realm and which regional endpoint to call without any out-of-band context, which is why cross-region automation in OCI needs less configuration plumbing than the equivalent elsewhere. The empty region segment is the reliable way to tell a global IAM object -- user, group, policy, compartment -- from a regional resource, and that set is exactly the set that lives in your home region and replicates outward.

Finally, the OCID is the only stable handle a resource has. Display names are mutable, are not required to be unique, and are not unique in practice: two instances in sibling compartments happily share the name web-1. Any automation that matches on display name is a latent incident waiting for the day someone creates the second one. The SDKs, the CLI and the Terraform provider all key on OCIDs for that reason, and resource-name lookups in your own tooling should resolve to an OCID once and then hold it.

An OCPU is not a vCPU, and comparisons that conflate them are wrong

The single most common error in cross-cloud costing is putting OCPU and vCPU in the same column. On Intel and AMD shapes, one OCPU is one physical core with both of its hyperthreads, so a single OCPU presents to the guest operating system as two vCPUs. On Ampere Arm shapes, where there is no simultaneous multithreading, one OCPU is one core is one vCPU.

So a four-OCPU x86 instance and a four-vCPU instance somewhere else are not comparable machines: the OCI one has twice the physical cores. Any per-unit price table that lines those two numbers up is off by a factor of two on x86 before it begins. The same arithmetic runs the other way for anything licensed per core -- Oracle Database, several commercial JVM and analytics products -- where the unit you are billed by the software vendor is the physical core, and the OCPU is already the right unit to reason in.

Flexible shapes make the distinction useful rather than merely confusing. Shape names are a grammar: VM.Standard.E4.Flex parses as virtual machine, standard family, fourth-generation AMD EPYC, flexible. A Flex shape lets you choose OCPU count and memory independently, within a permitted ratio band, instead of climbing a fixed ladder where doubling the cores also doubles the RAM whether or not you needed it. For a memory-hungry JVM heap or an in-memory cache that is the difference between paying for the memory you want and paying for the cores that happened to come attached to it. The shape catalogue itself is cloud/oci_compute_shapes.

The shape of the pricing model, without quoting numbers

What is genuinely distinctive here is structural, not a discount.

Uniform pricing across commercial regions. A given shape lists at the same price in every commercial region. On AWS and GCP the same instance type varies materially between, say, Northern Virginia and Sao Paulo, which entangles region choice with cost in a way that quietly pushes latency decisions around. On OCI those two decisions separate, and "put it near the users" stops being an argument with finance.

An egress allowance before metering begins. OCI includes a substantial monthly outbound-data allowance per tenancy -- the widely quoted figure is 10 TB per month -- before egress is billed at all. The architectural consequence outlives the number: patterns that are quietly uneconomic elsewhere, such as serving media directly, replicating to another cloud, or shipping large exports to customers, are not disqualified on the first slide. The general economics are in cloud/cloud_egress_cost.

Per-second billing on compute, with a one-minute minimum, so short-lived and bursty workloads are not rounded up to an hour they did not use.

None of this makes OCI cheaper in the general case and you should not model it as if it does. What it removes is three of the places where a cloud bill becomes unpredictable: regional price arbitrage, egress cliffs, and rounding on ephemeral compute. Whether the total actually lands lower is a workload question, and cloud/cloud_finops is the article for that analysis.

Where the depth lives: the rest of the OCI shelf

This page is the map. Each area below is its own article, and that is where the mechanism belongs -- not here.

Networking. VCNs, regional versus AD-local subnets, route tables, security lists against network security groups, and the gateway family (internet, NAT, service, dynamic routing) are cloud/oci_networking and cloud/oci_vcn. Dedicated private circuits are cloud/oci_fastconnect. The vendor-neutral treatment of the same concepts is cloud/cloud_networking.

Compute. cloud/oci_compute for the instance model, cloud/oci_bare_metal for unvirtualized hosts, and cloud/oci_gpu_instances for the GPU shapes and the flat, non-oversubscribed RDMA cluster network that is what makes multi-node training on OCI worth considering at all.

Data. cloud/autonomous_database for the self-managing Oracle Database service that remains OCI's strongest single product, cloud/exadata_cloud for the engineered substrate beneath it, cloud/oci_base_database for the VM-hosted alternative, and cloud/mysql_heatwave for the MySQL analytics variant.

Identity, operations and the rest. cloud/oci_compartments and cloud/oci_iam_deep for policy mechanics; cloud/oci_monitoring, already a full treatment of metrics, the query language and alarms, plus cloud/oci_logging; cloud/oci_object_storage, cloud/oci_block_volume and cloud/oci_file_storage for storage; cloud/oci_functions, cloud/oci_container_instances and cloud/oke_deep for serverless and containers.

Where OCI genuinely competes, and where the gap bites

Oracle Database workloads. This one is not close. If your system of record is Oracle Database, OCI runs it on hardware Oracle designed for that database, under licensing terms Oracle sets, with a managed service that removes most of the day-to-day DBA surface. A competitor can match the hardware. It cannot match the other two.

Core-licensed and bare-metal-shaped work. Off-box virtualization plus whole-host shapes makes OCI a serious venue for anything billed per physical core, and the cluster-network design makes it credible for multi-node GPU training rather than only single-node inference.

Egress-heavy architectures, for the structural reasons above.

Ecosystem breadth is the real gap. The catalogue is narrower, but the thinner third-party surface hurts more: fewer SaaS products ship an OCI integration first, fewer Terraform modules and Helm charts assume it, fewer observability and security tools have a native connector. You will write glue that already exists off the shelf on AWS, and you will maintain it.

Community depth and hiring. When something breaks at two in the morning, the volume of prior art you can search is an order of magnitude smaller, and the pool of engineers who have already debugged your failure is smaller with it. That is a genuine operational cost that appears in no pricing comparison.

Footprint and parity. Not every service is available in every region, and the single-AD regions constrain HA design as described above -- both are questions to settle before a migration plan, not during it.

The honest read is that OCI is a strong second cloud with one dominant anchor workload, not a drop-in substitute for a mature estate somewhere else. cloud/multicloud_strategy covers the general question of running two clouds; the OCI-specific footnote is that the private interconnect between paired OCI and Azure regions exists precisely because Oracle expects to be one cloud of two rather than the only one.