The Basics of OCI VCN

If you're coming from AWS, OCI networking feels familiar until it doesn't. The mental model is close enough to lull you into skipping the docs, and different enough in a handful of load-bearing places to bite you in production. This is a plain-English tour of the OCI Virtual Cloud Network (VCN), one building block at a time, with the AWS VPC equivalents noted where they help — and flagged where they mislead.

The components at a glance

A VCN is a regional, software-defined network you own. Inside it you carve out subnets, attach gateways, steer traffic with route tables, and filter it with two overlapping rule systems. Here's the whole stack:

• VCN — the container
• CIDR block — the address space
• Internet Gateway — the door to the public internet
• Subnet — a slice of the CIDR (regional or AD-scoped)
• Route Table — the map
• VNIC — the network interface on every resource
• Reserved Public IP — a stable, floating public address
• Security List — subnet-level firewall rules
• Network Security Group (NSG) — VNIC-level firewall rules
• NAT Gateway — outbound internet for private subnets
• Service Gateway — the private path to Oracle services
• Local / Remote Peering — connecting VCNs together
• Dynamic Routing Gateway (DRG) — the transit hub
• Site-to-Site VPN / FastConnect — the on-prem links
• Flow Logs — who talked to whom
• Path Analyzer — the "why is this blocked?" tool

How the pieces relate to one another:

Now, one at a time.

VCN — the container

The Virtual Cloud Network is the AWS VPC's OCI counterpart. It lives in a single region and is your private, isolated slice of Oracle's network. You define its address space when you create it, and almost everything else — subnets, gateways, route tables — lives inside it.

One early gotcha: a VCN's original CIDR cannot be resized after creation. You can add additional CIDR blocks later (a relatively recent capability), but the block you start with is the block you keep. Size for headroom on day one.

CIDR block — the address space

A VCN covers a single contiguous IPv4 CIDR block, anywhere from /16 (65,533 usable addresses) down to /30. Most teams pick something in the RFC 1918 ranges — 10.0.0.0/16, 172.16.0.0/16, 192.168.0.0/24.

A few things that differ from AWS:

• OCI allows the full /16–/30 range rather than the narrower /28 minimum AWS imposes.
• You can attach multiple CIDR blocks to one VCN, which helps when you've grown out of your original range or need overlapping-free peering.
• Plan around the 64,000 private-IP cap per VCN; if you're anywhere near it, you're probably modelling the boundary wrong.

Internet Gateway (IGW)

The Internet Gateway is the AWS IGW, full stop. It's a horizontally-scaled, managed component that lets resources with public IPs reach — and be reached from — the internet.

It doesn't make anything public by itself. A resource is internet-reachable only when all of these are true: it has a public IP, its subnet's route table points 0.0.0.0/0 at the IGW, and the security rules permit the traffic. Get any one wrong and it stays dark.

Subnet — a slice of the CIDR

Subnets partition the VCN's CIDR into smaller ranges. Here's where OCI diverges from AWS in a way that actually matters:

• Regional subnets span the entire region across all Availability Domains.
• AD-specific subnets are pinned to a single Availability Domain.

AWS subnets are always AZ-scoped. OCI started that way too, but regional subnets are now the recommended default — they survive an AD failure without you re-architecting, and they simplify capacity planning because you don't have to carve parallel subnets per AD. Use AD-specific subnets only when a workload genuinely must live on one domain.

"Public" and "private" aren't subnet properties in OCI the way the AWS console implies — a subnet is public or private based purely on whether its route table points 0.0.0.0/0 at the Internet Gateway.

Route Table — the map

Route tables behave like AWS route tables: a set of destination/next-hop rules attached to subnets. Each subnet uses one route table, and a route table can be shared across many subnets.

The mental model is identical. What's worth knowing is OCI's next-hop vocabulary — routes point at named gateways (Internet Gateway, NAT Gateway, Service Gateway, DRG, Local Peering Gateway) rather than at cryptic IDs. It reads more cleanly when you're auditing a big network.

VNIC — the network interface

Where AWS has the Elastic Network Interface (ENI), OCI has the Virtual Network Interface Card (VNIC). Every compute instance gets a primary VNIC at launch, and you can attach secondary VNICs for multi-homed topologies, additional private IPs, or separate interfaces for control vs. data planes.

This is the attachment point that matters: it's where security rules are evaluated, where private IPs live, and where you bind a public IP. If you're debugging connectivity, "which VNIC does this traffic hit?" is usually the first question.

Reserved Public IP — the floating address

AWS calls these Elastic IPs. OCI calls them Reserved Public IPs, and the idea is identical: a stable public address you can allocate, hold independently of any resource, and attach to (or move between) VNICs.

Note OCI also has an Ephemeral Public IP option — a public address tied to the lifetime of a specific instance. Use Reserved when the address must survive a rebuild; use Ephemeral when it's disposable.

Security List — subnet-level rules

Here's the first place AWS intuition actively misleads you.

A Security List is a rule set attached to a subnet, applying to every VNIC in that subnet. It supports both stateful and stateless rules, toggled per rule — and the default security list ships stateful, which is usually what you want.

# A stateful rule: responses to allowed inbound traffic are auto-allowed.
stateful  allow source=10.0.0.0/16 protocol=tcp dest-port=443

# A stateless rule: you must explicitly allow the return traffic.
stateless allow source=0.0.0.0/0 protocol=udp dest-port=123

The AWS mapping is messy on purpose: a Security List sits somewhere between an AWS Security Group (stateful) and an AWS Network ACL (stateless). The crucial differences are that rules use OR logic across all the security lists and NSGs that apply to a VNIC, and that both stateful and stateless modes exist in the same construct.

Network Security Group (NSG) — VNIC-level rules

The Network Security Group is the finer-grained sibling: a rule set you attach to specific VNICs rather than whole subnets. Like Security Lists, NSG rules can be stateful or stateless per rule.

Two facts that shape how you should use them:

1. There is no default NSG — you opt in entirely.
2. Oracle recommends NSGs over Security Lists for application-tier control, because they decouple your security posture from the subnet layout.

A common, sane pattern: keep a minimal Security List for broad subnet defaults (deny-all plus a couple of organisational baselines), then do the real workload-specific filtering in NSGs. Remember the OR logic: traffic is allowed if any applicable rule allows it, so don't leave permissive rules in both layers.

NAT Gateway — outbound for private subnets

The NAT Gateway is AWS's managed NAT, again essentially identical. It gives resources in private subnets outbound internet access — for patching, package fetches, calling third-party APIs — without exposing them to inbound connections.

Point the private subnet's 0.0.0.0/0 route at the NAT Gateway and you're done. It's highly available within a region and scales without intervention.

Service Gateway — the private path to Oracle services

This one has no clean AWS analogue. The Service Gateway lets your VCN reach Oracle's public services — most importantly Object Storage — over Oracle's backbone instead of the public internet, without an Internet Gateway or NAT Gateway.

If you're pulling objects from private subnets, the Service Gateway is both more secure and cheaper than routing through NAT. Route the All-<region>-Services-In-Oracle-Services-Network CIDR at it and traffic stays on Oracle's network the whole way.

Local & Remote Peering — connecting VCNs

AWS VPC Peering maps to two OCI constructs:

• Local Peering Gateway (LPG) connects two VCNs in the same region.
• Remote Peering connects VCNs across regions, through a DRG on each side and a peered connection between them.

Peering is non-transitive, just like AWS — if A peers with B and B peers with C, A cannot reach C through B. You either peer every pair directly or you graduate to a hub.

Dynamic Routing Gateway (DRG) — the transit hub

The Dynamic Routing Gateway is OCI's answer to the AWS Transit Gateway: a regional hub that lets one VCN talk to many networks — other VCNs (via attachments), on-prem networks (over VPN or FastConnect), and remote regions.

When your topology outgrows point-to-point peering, the DRG becomes the centre of the wheel. Route once to the DRG and it handles the fan-out. This is the component that turns a pile of peered VCNs into an actual network architecture.

Site-to-Site VPN & FastConnect — the on-prem links

• Site-to-Site VPN = AWS Site-to-Site VPN. IPSec tunnels over the public internet, terminated on a DRG.
• FastConnect = AWS Direct Connect. A private, dedicated circuit into OCI, with the predictable latency and bandwidth that implies.

Both land on a DRG. The usual progression is VPN first (hours to stand up), FastConnect later (weeks to provision, but it's what you want for steady production traffic).

VCN Flow Logs

Flow Logs are the OCI analogue of VPC Flow Logs: captured records of accepted and rejected IP traffic, shipped to Object Storage for analysis. Turn them on for any subnet you might ever need to debug.

If you've used the AWS version, the output format is the main difference — parse once, query forever. They're the single best source of truth for "did this conversation even happen?"

Path Analyzer

OCI's Path Analyzer is the spiritual cousin of AWS's Reachability Analyzer: give it a source and destination and it traces the forwarding path, telling you where traffic is permitted and where a route or rule drops it.

When a Security List and an NSG disagree and you can't tell which is winning, Path Analyzer is faster than trial-and-error. Reach for it before you start adding allow rules out of desperation.

Putting it together

A production-grade VCN usually looks something like this:

The building blocks are individually simple. The skill — same as in AWS — is knowing which ones to combine, where the defaults are safe, and where your old instincts need adjusting. In OCI, the two places that catch people most are stateful vs. stateless security rules and the regional-vs-AD subnet choice. Get those right and the rest follows.