The OCI Subnet Decision You'll Regret Six Months Later

All your nightmares begin with a clean slate, a green light, and innocent-looking OCI subnet configuration. Open up the Oracle Cloud Infrastructure console, break open that new Terraform file, and start churning out some Virtual Cloud Network infrastructure.

The deployment deadlines are tight, the business is pushing for results, and the networking setup feels like a straightforward, checkbox task.

Your subnets are there, an internet gateway has been applied, a default security list slammed in — and before you know it, your compute instances will be glowing nicely in a cheerful green "Running" state. App traffic flowing and, after a bit of a pause, your database will be up and kicking as the migration is stamped in history as a success.

Then, Day 180 arrives.

Designing an OCI network isn't about making things work today; it's about ensuring your architecture doesn't trap you tomorrow. Let's look at the foundational subnet decisions that look innocent during a deployment phase but frequently break down under the weight of enterprise production.

When you create a subnet in OCI, the very first binary choice you face is selecting whether it will be public or private. This single toggle defines the fundamental accessibility of every resource that will ever attach to that subnet.

Figure 1 · Public vs. private subnet decision in OCI

The convenience trap

By wanting convenience, you may want to make managing public subnets easier. For example, if a certain node or database is in a public subnet, troubleshooting becomes easier. Engineers can give a public IP, make an ingress rule, and SSH into the machine. External repositories can be accessed for software updates, and no internal gate or proxy has to be made. This process can be perceived as efficient and frictionless.

Why Oracle recommends private by default

Oracle's Maximum-Security Architecture dictates a fundamentally opposing rule: everything should be private by default unless it absolutely must accept direct, unproxied connections from the public internet. A private subnet explicitly prevents any VNIC (Virtual Network Interface Card) spawned within its boundaries from holding a public IP address. Even if an engineer accidentally opens a security list rule to 0.0.0.0/0, the underlying architecture physically blocks direct external routing. Security becomes structural rather than policy-dependent.

Security risks of public subnets

Putting internal application components, middleware, databases, etc., on a public subnet puts your infrastructure at risk. Using only Security Lists or Network Security Groups (NSGs) to protect public-facing assets puts the entire system at risk if there is just one configuration mistake.

Automated web scanners can quickly find all the open ports to your system. In the case where a component like a database or API is on the public subnet, it may become available to the public simply due to an ingress rule created to debug the component.

Which workloads belong in public subnets?

Public subnets should be treated as highly restricted, heavily monitored DMZ layers. The only resources that genuinely belong here are edge components:

• Public-facing OCI Flexible Load Balancers.
• Network Virtual Appliances (like firewalls or reverse proxies).
• Dedicated Bastion hosts or NAT instances (though OCI's native Bastion service often eliminates the need for persistent public bastion VMs).

Which workloads should always remain private?

The remainder of your corporate architecture belongs behind the private line. This includes:

• Web and application servers that sit behind a load balancer.
• All database architectures (Autonomous, Base Database, Exadata).
• Microservices, containerized pods, and caching tiers.
• Build pipelines, CI/CD runners, and internal management tools.

Early in your OCI journey, you must decide how your subnets span the physical layout of Oracle's data centers. OCI offers two structural types: Regional Subnets and Availability Domain-Specific (AD-specific) subnets.

Figure 2 · Regional vs. AD-specific subnet topology

What regional subnets are

A regional subnet spans the entirety of an OCI region, across all of its physical Availability Domains (ADs). When you launch a resource inside a regional subnet, you simply specify which AD you want the specific instance to sit in, but it draws its networking configurations, security profiles, and IP allocation from the exact same regional pool.

What AD-specific subnets are

An AD-specific subnet isolates its IP allocation and infrastructure footprint to a single, explicit Availability Domain within a region. A resource inside an AD-specific subnet cannot naturally float or scale into another AD without crossing a subnet boundary.

Oracle's recommendation

Oracle strongly recommends using Regional Subnets for almost every architecture scenario. They simplify management, streamline security, and form the foundation of resilient, modern cloud systems.

High availability considerations

If you use regional subnets, building high-availability application pools is highly efficient. You can place your primary application instances in AD 1 and your standby instances in AD 2, while keeping them inside the exact same regional subnet.

They share the same route tables, security rules, and network context. If you need to scale your application out via an instance pool across multiple ADs, a regional subnet accommodates this with zero additional configuration.

If you rely on AD-specific subnets, you are forced to create separate subnets for every single AD (e.g., Subnet-App-AD1, Subnet-App-AD2). This doubles or triples your management burden, as you now have to maintain identical route tables, duplicate security lists, and handle complex cross-subnet traffic routing for components that perform the exact same business function.

Regional subnets let you scale across ADs without multiplying subnets, route tables, and security lists. AD-specific subnets are a legacy pattern — not a modern default.

When AD-specific subnets are actually justified

Are AD-specific subnet allocations totally outdated then? No, but they have very specialized applications. In situations where you're dealing with old, clustered software designs whose network configuration is based on a hard-coded network topology within a certain geographical area, or when your network architecture requires precise hardware configurations and cannot be scaled within the data center environment, AD-specific subnets may become quite useful. But when delivering applications for regular enterprise use, it is not recommended at all.

IP address allocation is where many initial cloud deployments show their age. It is easy to misjudge the sheer volume of IP addresses modern cloud services consume, leading to severe network constraints later on.

Figure 3 · Subnet CIDR sizing and IP exhaustion planning

Why small subnets cause problems

Teams coming from traditional on-premises mindsets often treat IP addresses like scarce resources, carving up their VCN into tiny fragments like /28 or /29 blocks to minimize "waste."

This strategy breaks down quickly in a dynamic cloud environment. Once a subnet runs out of IP addresses, you cannot expand its CIDR block on the fly if it conflicts with adjacent networks. You are stuck.

OCI IP reservations

When calculating subnet size, you must account for the infrastructure tax. OCI reserves exactly three IP addresses in every single subnet, regardless of its size:

• The first IP address in the CIDR block (the network address).
• The second IP address in the CIDR block (the default gateway).
• The very last IP address in the CIDR block (the broadcast address).

If you build a /28 subnet, you start with 16 addresses. Subtract Oracle's 3 reserved IPs, and you are left with just 13 usable slots.

Growth planning and microservices

Such math plays a crucial role when it comes to implementation of the new generation architecture like Oracle Container Engine for Kubernetes (OKE). In case you use the native VCN pod networking plug-in, all pods created in nodes get assigned an actual IP address from the subnet you have specified.

When a high-density application scales up, it can run out of a /24 subnet in minutes, leaving you with stopped deployments and applications crashing due to IP exhaustion.

Real-world planning guidance

When planning your network fabric, size your subnets based on future states, not day-one requirements:

• Small/Isolated Tiers (e.g., Public DMZ, Bastion layers): A /26 or /25 provides ample headroom for load balancers to scale horizontally without wasting address space.
• Standard Application Tiers: A /24 should be your baseline minimum, providing 253 usable internal slots.
• Dynamic, Containerized, or Shared Services Tiers (e.g., OKE, Dev/Test pools): Target /23 (509 usable IPs) or /22 (1,021 usable IPs) allocations to accommodate rapid, automated scaling.
• Always ensure your overall VCN allocation (e.g., a /16 block) leaves large blocks of unallocated CIDR space available. This allows you to provision completely new regional subnets down the road when new project teams onboard.

When speed is prioritized over architecture, teams often create one large subnet and dump every tier of an application into it — web frontends, business logic apps, and backend databases all sitting in the same networking space.

Figure 4 · Multi-tier subnet segregation in OCI

The multi-tier architecture breakdown

An enterprise architecture should be organized into clearly segmented layers, with each tier bound to its own dedicated subnet:

• Web/Ingress Tier: Houses public load balancers routing external requests.
• Application/Middleware Tier: Houses the core compute instances, container platforms, and business logic execution.
• Database/Storage Tier: Houses sensitive data stores, managed databases, or object storage endpoints.
• Shared Services Tier: Houses management tools, log forwarders, and security scanners.

Security boundaries and the blast radius

If all components share a single subnet, you lose the ability to enforce strict network boundaries between tiers. In a shared subnet environment, if a web application vulnerability allows an attacker to compromise an application server, they gain immediate lateral network access to your database layer.

By separating workloads into dedicated subnets, you establish distinct security zones. You can configure rules ensuring the database tier only accepts traffic originating explicitly from the application subnet, completely blocking requests from any other source.

Routing control at the subnet level

In OCI, Route Tables are attached at the subnet level, not to individual VNICs. This detail is a common source of architectural regret.

If your application servers and your database instances reside in the exact same subnet, they must share the exact same Route Table. This means if your application servers need a route out to the public internet via a NAT Gateway to download patches, your database instances are forced onto that same routing path.

By segregating your databases into a dedicated private subnet, you can attach a specialized Route Table containing a single route to an OCI Service Gateway. This allows the database to securely back up data directly to OCI Object Storage without exposing it to any internet-facing gateways.

Most cloud networking errors don't stem from poor execution; they are built into the initial plan. Teams often build cloud networks that look identical to their legacy environments, underutilizing OCI's unique architectural features.

The lift-and-shift landmine

Many enterprise teams fall into the trap of copying their on-premises network layouts exactly into OCI without modification. This practice often imports decades of legacy constraints, fragmented routing schemes, and outdated security designs into a modern cloud framework, missing out on OCI's cloud-native efficiency.

Over-reliance on security lists instead of NSGs

A frequent mistake is managing all security rules via subnet-level Security Lists. As your workload grows, these lists expand into massive, unmanageable walls of text.

Because Security Lists apply to every resource within a subnet uniformly, you lose granular control. If Instance A and Instance B sit in the same subnet but require different security access, you are forced to break them apart into different subnets or write overly permissive rules.

OCI Network Security Groups (NSGs) solve this issue by allowing you to apply security rules directly to individual VNICs, independent of the subnet they reside in. Subnets should define your routing boundaries, while NSGs should manage your granular application security rules.

The shared route table trap

When teams use a single, generic Route Table across multiple unrelated subnets to save time during deployment, they create a fragile network fabric. A routine modification intended to route traffic for a new development tool can inadvertently alter production traffic paths, leading to unexpected outages or compliance violations.

To ensure your OCI network fabric remains stable, scalable, and secure over the long term, build your architecture around Oracle's foundational design guidelines:

• Enforce Private by Default: Restrict public subnets strictly to edge load balancers and network appliances. Build all application logic and database layers inside private subnets.
• Standardize on Regional Subnets: Avoid AD-specific subnets unless explicitly required by legacy clustering applications or specific hardware limitations.
• Implement Tiered Segregation: Create separate, dedicated subnets for your web, application, database, and management layers to maintain clean routing boundaries.
• Isolate Subnet Route Tables: Assign a unique, dedicated Route Table to every subnet to prevent configuration changes in one tier from impacting another.
• Decouple Security with NSGs: Use subnet-level Security Lists exclusively for broad, foundational network rules. Leverage Network Security Groups (NSGs) to manage granular, application-specific access controls directly at the VNIC level.
• Plan CIDRs Generously: Size production application and container subnets with /23 or /22 blocks to avoid IP exhaustion as your environment scales.
• Enable OCI VCN Flow Logs Early: Turn on flow logs during initial deployment. Having a clear, searchable record of accepted and rejected network traffic is essential for debugging and security compliance.

6 subnet decisions to get right before deployment:

1. Default to private subnets.Public subnets are immutable DMZ layers for load balancers and edge appliances only — never for apps or databases.
2. Use regional subnets.Span all ADs in one subnet. AD-specific subnets triple your management overhead for no modern benefit.
3. Size for tomorrow, not today./24 minimum for apps; /23 or /22 for OKE and container tiers. Remember OCI reserves 3 IPs per subnet.
4. One tier, one subnet.Segregate web, application, database, and shared services into dedicated subnets with distinct route tables.
5. Subnets route; NSGs secure.Security Lists for broad rules. NSGs for per-VNIC granularity. Never one shared route table across unrelated tiers.
6. Enable flow logs on Day 1.Observability is not a post-production afterthought — it's how you survive the Day 180 audit.

Designing an OCI network isn't about making things work today — it's about ensuring your architecture doesn't trap you tomorrow.

The green "Running" state on Day 1 is deceptive. The real test of your OCI network arrives when compliance audits land, OKE autoscaling kicks in, Exadata gets provisioned, and FastConnect ties you back to on-premises — all on top of a subnet layout you thought was "good enough."

Public or private. Regional or AD-specific. How large. Whether tiers share a subnet. How route tables and NSGs divide responsibility. These are not checkbox decisions — they are structural commitments. Get them right before your first Terraform apply, and your architecture earns the right to grow. Get them wrong, and Day 180 becomes a migration you never planned for.