Designing Subnets on OCI: Public, Private, Regional, and Sizing Decisions

Subnets are where a Virtual Cloud Network stops being an abstract address range and starts holding real workloads. Get the subnet design right and everything that follows, routing, security, and growth, becomes straightforward. Get it wrong and you find yourself renumbering networks or fighting overlapping address ranges months later, usually at the worst possible time. This guide walks through the decisions that matter when you design subnets on OCI, so the network you build today still works when the estate is three times the size.

Subnets sit one level below the VCN itself, so start with our pillar guide to OCI networking for the wider picture. The routing hub that connects subnets across networks is covered in the DRG explained, and the security controls that protect them are in network security best practices.

Public compared with private subnets

The first decision for every subnet is whether it is public or private. A public subnet can hold resources that have a public IP address and reach the internet directly through an internet gateway. A private subnet holds resources that have no public IP and reach the internet, if at all, only through a NAT gateway for outbound traffic. The principle to follow is simple. Put as little as possible in public subnets. Load balancers and bastion hosts may belong there, but application servers and databases almost never should.

The gateways that give each subnet its connectivity, the internet gateway, the NAT gateway, and the service gateway, are worth understanding in their own right. We cover how to choose between them in service gateway and NAT on OCI.

Regional compared with availability domain specific subnets

OCI lets you create subnets that span an entire region or that are scoped to a single availability domain. A regional subnet stretches across all availability domains in the region, which means resources in it can move between domains without changing subnet, and it simplifies high availability designs. An availability domain specific subnet is confined to one data centre. For almost every modern design the regional subnet is the better default, because it makes spreading workloads across availability domains for resilience much easier.

CIDR planning and sizing

The most consequential and least reversible subnet decision is addressing. Each VCN gets one or more CIDR blocks, and each subnet carves a slice out of those blocks. Two rules dominate. First, never let address ranges overlap with any network you might one day connect to, whether another VCN, an on premises network, or a partner. Overlapping ranges make clean routing impossible and are painful to fix. Second, leave room to grow. A subnet that is exactly sized for today leaves no headroom for tomorrow, and resizing is disruptive.

Plan the whole address space once, for the whole estate, before you build a single subnet. Reserve ranges for future regions, future environments, and future workloads. This discipline is the same one that underpins VCN peering and cross region designs, where overlapping ranges are the single most common reason connectivity fails.

How big should a subnet be

Size subnets to the workload plus generous headroom. A subnet hosting a small set of management hosts can be modest. A subnet that will hold an autoscaling fleet of application servers needs enough addresses for the fleet at its maximum, plus the addresses OCI reserves in every subnet, plus room for growth. It is far cheaper to allocate a larger range now than to renumber later, so err on the side of generosity within a coherent overall plan.

Routing and security per subnet

Each subnet is associated with a route table that decides where its traffic goes, and with security controls that decide what traffic is allowed. Route tables point at gateways, the internet gateway for public subnets, the NAT and service gateways for private subnets, and the DRG for traffic to other networks. Security lists and network security groups then filter traffic at the subnet and resource level. A common and dangerous mistake is to assume that because the DRG routes traffic, it will arrive. It will not if a security rule blocks it. Design routing and security together, not separately.

A subnet design framework

1. Plan the entire address space for the whole estate first, with no overlaps and room to grow.
2. Default to regional subnets so high availability across domains stays simple.
3. Separate public and private subnets, and keep public subnets as small and as empty as possible.
4. Group resources with similar trust levels and routing needs into the same subnet, and separate those that differ.
5. Size each subnet for the maximum workload plus reserved addresses plus headroom.
6. Define the route table and the security controls for each subnet together, and document both.

Follow this and your subnets become a stable foundation rather than a source of recurring friction. A clean addressing plan in particular pays back every time you add a region, peer a network, or connect on premises.

Common mistakes

• Overlapping CIDR ranges that block future peering and on premises connectivity.
• Sizing subnets too tightly, forcing a disruptive renumber when the workload grows.
• Placing application or database servers in public subnets when a private subnet with a NAT gateway would be safer.
• Designing routing without designing security, so traffic is routed but then silently dropped by a rule.
• Using availability domain specific subnets by habit and making cross domain high availability harder than it needs to be.

If you want a subnet and addressing plan that will hold up as the estate grows, our team designs these as part of every OCI networking and landing zone engagement. See the OCI networking solution for how we approach it, and the pillar guide to OCI networking for how subnets fit the rest of the network.