A VCN is the one OCI object you cannot casually rebuild. Compartments can be reorganised, instances re-provisioned, policies rewritten — but a VCN's address space is baked into every route table, every peering relationship, every on-premises firewall rule and every partner's network diagram the moment it starts carrying traffic. This article is the OCI instantiation: what the objects actually are, which ones are decided once and which stay editable, and where the model diverges from the AWS and GCP habits most people arrive with. The vendor-neutral theory beneath it — address planning, stateful versus stateless filtering, MTU, the general shape of overlay networks — lives in cloud networking architecture, and the tenancy and compartment model this all sits inside is assumed here and explained in the OCI overview.
The VCN is regional, and its address space is the decision you live with
A VCN is a regional resource. It exists in one region, spans every availability domain in that region automatically, and lives in exactly one compartment. There is no global VCN in OCI, so a multi-region design is always several VCNs joined by peering or a routing hub — never one object stretched across regions.
You give the VCN one or more CIDR blocks. Blocks can be added and, subject to constraints, removed later, but the original block is effectively load-bearing: peering requires non-overlapping ranges on both sides, so a VCN that took 10.0.0.0/16 because it was the console default will collide with the next team that did the same, and the fix is a rebuild rather than an edit. Plan ranges across the whole estate — including on-premises and any partner networks you might one day connect — before the first VCN exists.
Inside a VCN, everything can reach everything at the routing layer. OCI installs an implicit local route covering the VCN's own CIDRs; it is not a rule you can see, edit or delete. This is the sharpest single contrast with AWS VPC, where the equivalent local route is a visible entry in every route table. The consequence is the same either way — intra-VCN isolation is a security-rule problem, never a routing problem — but on OCI there is no route table entry to point at when someone asks how two subnets are talking.
A VCN also carries a DNS label, which fixes its private DNS domain permanently at creation time. It is a small field with a long half-life.
Subnets — regional by default, AD-specific by legacy
A subnet is a contiguous carve-out of a VCN CIDR, and it is where most of the per-resource configuration attaches: a route table, one or more security lists, DHCP options, and a public-or-private flag. Two properties are set at creation and cannot be changed afterwards: the CIDR block itself and whether the subnet is public or private.
OCI offers two subnet scopes. A regional subnet spans all availability domains in the region; an AD-specific subnet is pinned to one. Regional is the modern default and the right answer for almost everything — it lets an instance pool, an OKE node pool or a load balancer place capacity in whichever AD has room without you pre-partitioning address space three ways. AD-specific subnets are a holdover from the earliest OCI design and survive mostly in old templates. If you inherit them, note that AD failure planning becomes an address-space problem, which is exactly the coupling regional subnets removed.
The public/private flag controls whether VNICs in the subnet may be assigned a public IP at all. A private subnet is not merely a subnet with no internet route — the public IP assignment is refused outright, which makes the flag a genuine guard rather than a convention. OCI also reserves the first two addresses and the last address of every subnet CIDR for its own use, so a /30 — the smallest subnet OCI permits — leaves exactly one usable address, and small subnets waste proportionally far more than the arithmetic suggests.
Route tables attach to subnets, and only non-local traffic consults them
Each subnet has exactly one route table. Because intra-VCN traffic is handled by the implicit local route, a route table's entire job is deciding which gateway receives traffic bound for somewhere outside the VCN. A rule is a destination plus a target: the destination is a CIDR or, for the service gateway, a service CIDR label; the target is a gateway object — internet, NAT, service, dynamic routing, or a local peering gateway. Matching is longest-prefix, so a specific /24 pointed at a DRG beats a 0.0.0.0/0 pointed at a NAT gateway.
A useful discipline is one route table per subnet role rather than per subnet. Public subnets share a table with a default route to the internet gateway; private application subnets share one with a default route to the NAT gateway plus a service label route; database subnets often have no default route at all. Sharing tables across subnets of the same role means a new egress path is added once, not eleven times, and a subnet whose table diverges from its role is immediately visible.
OCI also supports route tables attached to gateways rather than subnets — commonly called ingress routing. A table on the internet gateway or on a DRG attachment can force traffic entering the VCN through a firewall or intrusion detection appliance before it reaches the workload subnet. Without it, inbound traffic goes straight to the destination VNIC and any inline inspection appliance is trivially bypassed.
Internet gateway and NAT gateway — two different meanings of public
An internet gateway is bidirectional. Attaching one to a VCN and routing 0.0.0.0/0 at it is necessary but not sufficient: the VNIC must also sit in a public subnet and hold a public IP, and security rules must permit the traffic. Miss any one of the four and the symptom is the same silent timeout, which is why the internet gateway is the most common source of first-day OCI confusion. The checklist — public subnet, public IP, route rule, security rule — resolves it almost every time.
A NAT gateway is outbound-only by construction. Instances in private subnets reach package repositories and third-party APIs through it; nothing on the internet can initiate a connection back. It is a VCN-level object, not something that lives inside a subnet, and it presents an OCI-managed public IP that downstream partners sometimes ask to allowlist — worth knowing before you promise anyone a stable source address. The gateway is also blockable: a NAT gateway can be set to block traffic as a single switch, which is a blunt but effective containment action during an incident.
The general design reasoning — why outbound-only egress is the default posture, how NAT interacts with connection tracking and port exhaustion — belongs to managed NAT gateway architecture. What is OCI-specific is only the object model above.
The service gateway and the Oracle Services Network
Object Storage, Autonomous Database, monitoring and logging endpoints and a long list of other OCI services have public DNS names. Reaching them from a private subnet through a NAT gateway works, but it sends the traffic out to the internet edge and back — which many compliance regimes disallow and which puts a shared egress path in the data plane of your own storage traffic.
The service gateway removes that. It is a VCN-level gateway whose route rules take a service CIDR label as the destination rather than an ordinary CIDR — a symbolic handle that OCI keeps current as service address ranges change, so you are not maintaining an IP allowlist against a moving target. Two labels matter in practice: one covering all services in the region's Oracle Services Network, and a narrower one covering only regional Object Storage. Pick the narrow one when Object Storage is genuinely all you need.
Two properties define its security posture. Traffic never leaves the Oracle backbone, and connections can only be initiated from the VCN toward the service — the gateway gives the Oracle Services Network no path back into your network. That makes it safe to route at without treating it as an inbound exposure. The general pattern it instantiates, and the reasons to prefer it over public endpoints everywhere, are covered in private connectivity.
Security lists and network security groups — the rules are a union
OCI has two virtual firewall mechanisms and they operate at different scopes. A security list attaches to a subnet and applies to every VNIC in it. A network security group attaches to individual VNICs, which you add to the group as a membership property of the resource. Both express ingress and egress rules that are stateful by default, with an explicit stateless option when you want connection tracking out of the path.
The critical semantics: when a VNIC is covered by both, the effective rule set is the union. An allow from either mechanism admits the traffic. There is no deny rule and no precedence order to reason about — which is simpler than a priority-ordered ACL, but it also means you can never use an NSG to tighten something a security list already permits. If a subnet's security list allows 0.0.0.0/0 on port 22, no NSG on earth will stop it.
NSGs are usually the right default because their rules can name another NSG as source or destination. Instead of writing the application tier's CIDR into the database tier's rules, the database NSG allows the application NSG on port 1521, and the relationship survives every re-address and re-scale. Security lists can only name CIDRs and service labels. The practical pattern is a deliberately minimal security list per subnet — often nothing but the shared essentials — and all real intent expressed in NSGs.
Who may edit them is an IAM question, not a networking one. NSG membership is a property of a VNIC, so a principal that can launch instances into a subnet may be able to place them in a group whose rules they did not write. OCI IAM policy syntax and dynamic groups is where that boundary is drawn.
Local peering and remote peering
Two VCNs in the same region connect through a pair of local peering gateways — one on each VCN, explicitly connected, with a route rule and security rules on both sides. Only one side needs to initiate the connection, but the other side's administrator must have a policy permitting it, which is how cross-compartment and cross-tenancy peering stays consensual.
Across regions the object is a remote peering connection, which is not a standalone gateway: an RPC is created on the DRG at each end and the two are connected. Traffic crosses Oracle's backbone rather than the public internet. The configuration burden is the same — routes and security rules on both sides — with the added consideration that inter-region latency is now inside your application's critical path, so peering does not make two regions one region.
Both mechanisms share the two constraints that catch people. CIDRs must not overlap, and the relationship is non-transitive: peering A to B and B to C does not let A reach C. Transit needs an explicit routing hub, which on OCI means a DRG. The general reasoning about why non-transitivity is a deliberate property rather than a limitation is in VPC peering architecture.
The DRG, and what the upgraded DRG changed
The dynamic routing gateway is OCI's routing hub. It is a standalone object rather than a component of a VCN, and things connect to it as attachments: VCN attachments, IPSec tunnel attachments, FastConnect virtual circuit attachments, and remote peering connections. One DRG therefore terminates on-premises connectivity, cross-region connectivity and multiple VCNs at a single point.
The upgraded DRG — the generation OCI moved customers onto after the original design — is what makes that hub genuinely useful. It carries its own route tables and, crucially, route distributions: import and export policies that control which prefixes each attachment learns from the others. That mechanism is what enables transit between attachments, so a VCN can reach on-premises through the DRG, and two VCNs attached to the same DRG can reach each other without a local peering gateway between them. The legacy DRG had no such capability and attached to a single VCN.
The design consequence is worth stating plainly. In an estate of any size, a full mesh of local peering gateways grows quadratically and every new VCN means editing every existing one. A DRG hub with route distributions makes each new VCN a single attachment plus a distribution statement. Hub-and-spoke on OCI means a DRG, and the route distribution is where the policy actually lives — not in the attachments.
FastConnect and Site-to-Site VPN
Both on-premises connectivity options terminate as DRG attachments, which means the routing story above applies unchanged regardless of which physical path the packets took.
Site-to-Site VPN — IPSec over the public internet — is the fast one to stand up: no provider contract, redundant tunnels per connection, and BGP or static routing on your customer-premises equipment. Its ceiling is the internet itself: throughput and latency are whatever the path gives you that day, and no amount of tuning changes that.
FastConnect is a dedicated private circuit. It comes in several provisioning models — through a connectivity partner, through a colocation cross-connect in a FastConnect location, or through a third-party provider — and the logical object you configure is a virtual circuit. Two peering types exist: private peering, which reaches your VCN's private addresses through the DRG, and public peering, which reaches OCI public service endpoints privately without touching the internet. Most designs need private peering; public peering is for the case where on-premises systems talk to OCI regional services directly. The circuit-level detail lives in OCI FastConnect.
The mature pattern runs both: FastConnect as the primary path and a VPN as standby, with route preference on the DRG and on your own routers arranged so failover is automatic. A backup path that requires a human to activate it is not a backup path.
Private DNS — resolvers, views, and reaching on-premises names
Every VCN gets a DNS resolver automatically, and every VCN carries a private DNS domain derived from the DNS label chosen at creation. Instances resolve each other by hostname within that domain without any configuration, which covers the simple case entirely.
Beyond that, OCI's private DNS is built from three pieces. Private zones hold your own records. Views group zones and can be attached to more than one resolver, which is how several VCNs share one authoritative picture of internal names instead of each keeping a divergent copy. Endpoints connect the resolver to the world outside it: a forwarding endpoint sends queries out to on-premises or another resolver, and a listening endpoint accepts queries arriving from them. Conditional forwarding rules decide which queries take which path, usually by domain suffix.
A hybrid estate almost always needs both endpoint types — OCI workloads resolving on-premises names, and on-premises systems resolving OCI ones — and the endpoints are VNICs in your subnets, so they need reachability and security rules on UDP and TCP port 53 like any other host. DNS is where a technically correct routing design most often appears broken to users, and it is worth designing at the same time as the DRG rather than after it.
VCN flow logs and seeing what the network actually did
Every mechanism above is a statement of intent. VCN flow logs are the record of what happened, and without them a connectivity failure is guesswork across four independent layers — routing, security lists, NSGs, and the workload itself.
Flow logs are not a networking feature with its own console corner; they are a log category in the OCI Logging service, enabled per subnet or scoped more narrowly, and they land in a log group alongside your audit and service logs. Each record describes a flow with its five-tuple and, decisively for debugging, whether it was accepted or rejected. A rejected flow that reached the logs proves routing worked and the problem is a security rule; the absence of any record for a flow you expected usually means routing never delivered it. That single distinction resolves most incidents faster than reading configuration.
Two operational caveats. Records are aggregated over an interval before being written, so flow logs are a forensic tool rather than a real-time monitor — alarms belong on metrics. And volume is substantial on a busy subnet, so route logs onward with a service connector to object storage or a streaming target and set retention deliberately rather than by default. OCI monitoring covers the metrics and alarm side of the same problem.