OCI Architecture
VCN Design Patterns on OCI
The virtual cloud network is the layer of an OCI estate that punishes early mistakes hardest, because changing it under running workloads is slow and risky. These are the patterns that scale.
The virtual cloud network is the layer of an OCI estate that punishes early mistakes hardest, because changing it under running workloads is slow and risky. These are the patterns that scale.
Of all the layers in an OCI estate, the network is the one you least want to get wrong, because it is the one that is hardest to change later. Compartments can be reorganised, identity can be tidied, workloads can be resized, but re segmenting a network under live workloads means coordinating downtime, re addressing resources and unpicking dependencies that have grown around the original layout. The virtual cloud network, OCI's term for a software defined network, is where connectivity and isolation are decided, and the patterns you choose at the start tend to be the patterns you live with. This article sets out the ones that scale.
A virtual cloud network, usually shortened to VCN, is made of a small set of building blocks, subnets, route tables, gateways and security controls, and good design is mostly about arranging those blocks in patterns that isolate by default and grow by extension. The sections below cover the building blocks, the patterns that work, and the segmentation decisions that matter most. It fits within the broader foundation in the cluster pillar, OCI Landing Zone and Architecture: A Complete Guide.
A VCN is a private network space you define with an address range, and inside it you create subnets that carve that range into segments. Route tables decide where traffic from each subnet goes. Gateways connect the VCN to the outside, an internet gateway for public traffic, a NAT gateway for outbound only access, a service gateway for OCI services without traversing the internet, and a dynamic routing gateway for connections to other networks. Security lists and network security groups control which traffic is allowed. Good design is the art of arranging these so the network is both connected where it needs to be and closed everywhere else.
| Component | Role | Design note |
|---|---|---|
| Subnet | Segment of the address space | Public or private, choose private by default |
| Route table | Where traffic goes | One per subnet tier keeps intent clear |
| Internet gateway | Public inbound and outbound | Only for subnets that truly need it |
| NAT gateway | Outbound only for private subnets | Lets private resources reach out safely |
| Service gateway | Reach OCI services privately | Avoids egress and exposure |
| Network security group | Fine grained traffic control | Prefer over broad security lists |
The foundational pattern is to separate resources that need to be reachable from the internet from those that do not. Load balancers and bastions sit in public subnets, while application servers and databases sit in private subnets that have no direct inbound path from the internet. Outbound access for private resources runs through a NAT gateway, and access to OCI services runs through a service gateway so it never touches the public internet. This single pattern eliminates a large class of exposure, because the resources that matter most are simply not reachable from outside.
Beyond public and private, mature designs segment by function, with separate subnets for the web tier, the application tier and the data tier. Each tier gets its own route table and its own security controls, so traffic between tiers is explicit and anything not explicitly allowed is denied. This containment means that a compromise of one tier does not automatically reach the others, and it makes the network's intent legible, because you can read the segmentation and understand how the application is meant to communicate.
OCI offers two ways to control traffic, security lists that apply to whole subnets and network security groups that apply to sets of resources. Network security groups are usually the better choice because they let you define rules around the role a resource plays rather than the subnet it happens to sit in, which keeps rules precise and portable. Security lists still have their place for subnet wide defaults, but leaning on network security groups for the specific rules keeps the design fine grained and easier to reason about as it grows.
Address space is one of those decisions that is trivial to get right at the start and painful to fix later. Choose a range large enough for the estate you will have, leave room between subnets for growth, and avoid overlapping ranges with networks you might one day connect to, whether on premises or in another cloud. Overlapping address space is one of the most common reasons a later connection becomes difficult, and it is entirely avoidable with a few minutes of planning before the first subnet is created.
A single VCN suits a single workload or a small estate, but as the estate grows you end up with many VCNs that need to share services and communicate. Connecting them in a mesh quickly becomes unmanageable, which is why mature estates route shared connectivity through a central hub, a pattern set out in Hub and Spoke Networking on OCI. Designing the individual VCNs with that future hub in mind, particularly by planning address space carefully, makes the eventual transition far smoother. For estates that span regions, the networking extends further, as covered in Multi Region Architecture on OCI.
Network design does not stand alone. It is the enforcement layer for much of an estate's security, because a private subnet and a deny by default posture are among the strongest controls available, a theme in Security by Design on OCI. It is also central to resilience, because how subnets and gateways are arranged across availability domains decides whether the network survives a failure, as covered in Designing for High Availability on OCI. The network is the connective tissue that the security and reliability of the whole estate depend on.
The recurring errors are a flat network with everything in one subnet, public subnets used where private would do, address space chosen too small or overlapping with networks you later need to connect, broad security lists where precise network security groups belong, and a single VCN stretched far past the point where a hub and spoke design was needed. Each makes the network harder to secure, scale or connect, and each is far cheaper to avoid than to fix once workloads depend on the flawed layout.
The choice of gateways is where a VCN's exposure is largely decided, and the guiding idea should be least exposure, giving each subnet only the connectivity it genuinely needs. An internet gateway opens a subnet to inbound and outbound public traffic and belongs only where public reachability is truly required. A NAT gateway lets private resources reach out without being reachable from outside, which is what most application and database tiers actually need. A service gateway lets resources reach OCI services such as object storage over the OCI backbone rather than the public internet, which both reduces exposure and avoids egress charges. Choosing the most restrictive gateway that meets each subnet's real requirement is one of the simplest and most effective security decisions in the whole network.
Name resolution is easy to overlook in network design and awkward to fix once workloads depend on a particular setup. A VCN provides private DNS so resources can resolve each other by name within the network, and as the estate grows to multiple networks and connections to on premises, the question of how names resolve across all of them becomes a design decision in its own right. Planning DNS as part of the network design, deciding where authoritative resolution lives and how it is shared across networks, avoids the situation where applications work in isolation but fail to find each other once the networks are connected. In a hub and spoke estate, DNS is one of the shared services that naturally belongs in the hub, which is a good reason to think about it early.
Designing the network is core to our OCI Networking practice and a central part of the landing zone work in our OCI Consulting and Advisory engagements. We design VCNs that isolate by default, plan address space for the estate you will grow into, and lay the groundwork for hub and spoke before you need it. Because the network is the layer that is hardest to change, getting it right at the start is one of the highest value decisions in the whole build.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.