VCN Fundamentals on OCI

The virtual cloud network is the foundation that every other networking decision on OCI rests on, and it is the decision you are least able to revisit once workloads are running. A VCN is your own private, software defined network inside an OCI region, and almost everything you build, compute, databases, load balancers, lives inside one. Because it is the foundation, the choices you make when you create a VCN have a long reach, and the most consequential of them, the address range, is the one people most often make casually. This guide covers what a VCN actually is, the decisions that matter when you create one, and the mistakes that are cheap to avoid now and expensive to fix later.

The reason VCN fundamentals deserve their own treatment is leverage. Get the foundation right and the rest of the network, covered across our complete networking guide, follows cleanly. Get it wrong, particularly the address range, and you create constraints that shape everything you build for years.

What a VCN actually is

A VCN is a private network you define within a single OCI region. You give it one or more address ranges, and within those ranges you create subnets, attach gateways, and write routing and security rules. It is regional, meaning it spans the availability domains within a region, which is what lets you build for resilience across them. Nothing inside a VCN is reachable from outside it unless you deliberately create a path through a gateway, which makes the VCN a private island by default and puts you in control of every connection into and out of it.

The address range decision

When you create a VCN you assign it an address range, and this is the decision that matters most. The range has to coexist with every other network you will ever connect to, your on premises data centre, other VCNs, other clouds. If it overlaps with any of them, you cannot route between them cleanly, and fixing an overlap means renumbering a live network, which is among the most painful operations in infrastructure. The discipline is to plan your address space across your whole estate before you create the first VCN, allocating non overlapping ranges deliberately. This connects to the peering patterns in our peering guide, because peering is impossible between VCNs with overlapping ranges.

Decisions when creating a VCN

Subnets within the VCN

Inside the VCN you divide the address space into subnets, and the key property is whether a subnet is public or private. Public subnets can hold resources reachable from the internet, private subnets cannot. The right default is private, exposing only what genuinely must be public and routing the rest through gateways. Our subnet design guide covers how to lay subnets out for both resilience and security. The fundamental point is that the public private divide is not a detail, it is the structure that determines what an attacker can reach.

Gateways and routing in brief

A VCN on its own is an island. Gateways are the controlled paths in and out, an internet gateway for public traffic, a NAT gateway for private outbound, a service gateway for OCI services, and a dynamic routing gateway for everything beyond. Our service gateway and NAT guide and our dynamic routing gateway guide cover these in depth. When you create a VCN you are creating the container, and the gateways are how you then decide, deliberately, what that container is allowed to talk to.

Getting the foundation right

A VCN created this way is a foundation you can build on for years without fighting it. The discipline is front loaded, the planning happens before the first resource exists, but that is precisely why it pays off, because the foundation is the one thing you cannot easily change once the estate depends on it. The wider context is in our complete networking guide, and we design VCN foundations for clients as part of our OCI networking solution.

Regional and availability domain awareness

A VCN is a regional construct, which means it spans the availability domains within its region. This is the property that lets you build for resilience, by placing resources across availability domains so that the failure of one does not take your workload down. When you lay out subnets, doing so with availability domains in mind, distributing resources across them rather than concentrating them, is what turns the VCN from a single point of failure into a resilient foundation. The detail of how to do this is in our subnet design guide, but the principle belongs at the fundamentals stage, because resilience is a property you design in from the start, not one you add later.

Security at the VCN level

The VCN is also where your network security posture begins. Within it you write security rules that control what can talk to what, you decide which subnets are public and which are private, and you control every path in and out through gateways. A VCN designed with security in mind keeps almost everything private, exposes the minimum, and routes the rest through controlled and inspected paths. This connects to the packet level controls in our NSGs versus security lists guide and the deeper inspection in our network firewall guide. The fundamental point is that security is not a layer you add on top of the VCN, it is a property of how the VCN is structured, and the structure is decided at creation.

Planning before you build

The thread running through everything in this guide is that the VCN rewards planning and punishes haste. The address range, the subnet layout, the gateway strategy, the availability domain distribution, all of these are far cheaper to get right before the first resource exists than to change once workloads depend on them. The half hour spent planning the address space across your estate saves the painful renumbering project later. The deliberate subnet layout saves the security gap that a careless one would create. This is unglamorous work, but it is the highest leverage work in the whole network, precisely because the foundation is the one thing you cannot easily redo.