01 · Introduction
A Virtual Cloud Network (VCN) may have as many as five CIDR blocks — although if added at a later stage, they will not be contiguous. The difficulty arises when trying to summarize non-contiguous CIDRs during routing advertisements to your firewall teams.
Why do so many OCI deployments hit a wall at month three — long after they can't turn back?
For the very simple reason that the network was made in less than an hour. Someone just put up a default VCN, did not care about anything else other than setting a quick CIDR, left DNS behind, and started putting in workloads. The plan worked. Then, the people from the on-premises setup complained that they were unable to resolve OCI hostnames. Then, CIDRs overlapped in production setups.
None of this is inevitable. Every one of these failures has a best-practice answer that takes twenty minutes to understand — and hours of pain to retrofit after the fact.
Let's walk through what Oracle's own network architects recommend, using the actual architectures they've published.
Most OCI failures at month three trace back to a VCN provisioned in under an hour with no DNS or CIDR planning.
Subnet type, regional vs AD-specific placement, and DNS labels cannot be changed after creation — wrong choices mean re-provisioning, not reconfiguring.
Hub-and-spoke with a DRG, hybrid DNS, and generous CIDR sizing are the three decisions that pay off most when made on day one.
02 · Question 1: When Should You Design Your OCI Network?
Before the first VM. Not after.
At first, this seems quite apparent; however, when you realize how often it is not done, then it will become much clearer to you. The most frequent diagnosis made by Oracle is that the network infrastructure was built reactively, one subnet after another, as the demand arose for it. The VCN will have CIDRs overlapping with the ones used on premises. Subnets will be public instead of private.
It is a process-oriented method and not a technology-oriented one. It is imperative to have some buffer time during the project planning stage for designing the network taking into consideration its topology, VCNs, subnets, DNS configurations, and the ability to access data centers as well as the cloud infrastructure.
Some OCI network elements can't be changed after creation:
- Subnet type (public vs private) cannot be changed.
- Regional vs AD-specific subnet placement cannot be changed.
- Resources inside those subnets must be terminated and re-provisioned if you got it wrong.
That's not a config change — that's an outage.
Figure 1 · Architecture · OCI Network Design Diagram
03 · Question 2: Does Naming Really Matter?
More than you think — some names can't be changed.
You would be creating dozens of Oracle Cloud Infrastructure networking assets in a live environment. From VCNs to subnets to security lists to route tables to DRGs, each of them requires naming. Without an approach, you would look at something like "Subnet-1", "Subnet-2", "test-vcn", "vcn-new" after six months and wonder why those were created.
Oracle recommends building the resource type directly into the name: vcn-prod-ashburn, drg-ashburn, web-sn-sl. Simple, scannable, and self-documenting.
DNS label cannot be changed after creation. The VCN name can only be changed via CLI — not the console. Get these right at provisioning time, not after your first production deployment.
Naming Convention Reference
| Resource Type | Pattern | Example |
|---|---|---|
| VCN | vcn-{env}-{region} |
vcn-prod-ashburn |
| Subnet | {tier}-sn-{env} |
web-sn-prod |
| DRG | drg-{region} |
drg-ashburn |
| Security List | {subnet}-sl |
web-sn-sl |
| Route Table | {subnet}-rt |
web-sn-rt |
| Internet Gateway | igw-{vcn} |
igw-prod |
| NAT Gateway | nat-{vcn} |
nat-prod |
04 · Question 3: One VCN or Many?
For anything beyond a POC: many. Arranged in a hub-and-spoke.
The single-VCN model feels simpler at first. Then you realise you can't cleanly separate prod from non-prod. Then a security team wants a firewall to inspect all traffic. Then a new team needs their own isolated environment. You end up adding more subnets to a single VCN and losing any meaningful isolation.
Oracle's recommended best practice for Oracle Cloud Infrastructure: Hub-and-spoke architecture using the DRG. This can handle up to 300 attachments on the DRG. In the hub network, all services, including DNS, logging, firewall, and bastion host, are hosted. Spokes are isolated by default and are connected based on requirement.
Figure 2 · Architecture · Hub-and-Spoke VCN Design with DRG
DRG at the centre · Hub hosts shared services · Spokes remain isolated by default · On-premises connects through the same DRG
- Adding a new spoke VCN later is trivial — create the VCN, attach it to the DRG, add a route entry.
- Traffic between spokes doesn't flow unless you explicitly allow it.
- Isolation is the default. You opt-in to connectivity, not out of it.
Running a simple POC with one team and no inter-environment concerns? A single VCN is fine. The hub-and-spoke complexity only pays off when you have multiple environments, security zones, or teams to isolate.
05 · Question 4: Why Can't My On-Prem Servers Resolve OCI Hostnames?
Because you haven't designed your DNS.
This is the number-one connectivity complaint that arrives after deployment.
By default, OCI resolves DNS internally using the oraclevcn.com domain — but only within that VCN. Your on-premises resolvers have no idea it exists. OCI can't resolve your corporate DNS either. The two networks are connected at layer 3, but blind to each other at DNS.
OCI Private DNS fixes this with a hybrid DNS architecture. You create custom DNS zones, wire up resolvers in each direction, and suddenly every hostname resolves everywhere — OCI to on-prem, on-prem to OCI, VCN to VCN.
Figure 3 · Architecture · OCI Private DNS
OCI forwards corp.example.com queries to on-prem · On-prem forwards oci.example.com queries back to OCI · Both sides resolve everything
Custom Domain vs Default oraclevcn.com
| Approach | Pros | Cons |
|---|---|---|
| Default oraclevcn.com | Maintained automatically by OCI; hostnames appear as resources are created | Not corporate-branded; requires forwarder setup for on-prem resolution |
| Custom domain (oci.example.com) | Cleaner names; aligns with corporate DNS standards | Requires manual record management; changing later means updating every VCN and on-prem forwarder |
Choose your direction early — changing it later means updating DNS records across every VCN and every on-premises forwarder.
06 · Question 5: Public or Private Subnet?
Default to private. Always.
Public subnets assign a public IP to every resource placed inside them — unless you explicitly opt out. That means a misconfigured instance, a forgotten test VM, or a newly onboarded team's workload can end up internet-facing without anyone intending it.
The Oracle recommendation is clear: only place resources in public subnets if they have a specific, deliberate requirement for inbound internet access. Load balancers, bastion hosts, API gateways — maybe. Application servers, databases, internal services — never.
| Subnet Type | Default Route | Typical Workloads |
|---|---|---|
| Public | Internet Gateway | Load balancers, bastion hosts, API gateways |
| Private | NAT Gateway or DRG | Application servers, databases, internal services |
Four Rules for Every Subnet You Create
- Use regional subnets by default.Regional subnets span all Availability Domains in a region. AD-specific subnets tie resources to a single AD — only use them when your workload architecture specifically requires it.
- Create a unique route table per subnet.Public subnets route default traffic to an Internet Gateway. Private subnets route to a NAT Gateway or DRG. If they share a route table, you can't express this difference — and you will need to.
- Create a unique security list per subnet.Shared security lists mean a rule added for one subnet applies to all. Separate lists mean you can allow a specific port to a specific tier without opening it everywhere.
- Enable VCN flow logs on every subnet.Flow logs are off by default. Turn them on when you create each subnet. When a connectivity issue or a security incident land in your lap, flow logs are the first place you look — and you want the history, not just from the day you remembered to enable them.
07 · Question 6: How Big Should Your CIDR Be?
Bigger than you think you need. Right now.
The classic CIDR error is to start out small, as it seems that is all you will need now. With a /24, you can have up to 256 IP addresses, which seems like enough for your POC network. But before you know it, your POC goes into production, and then into disaster recovery mode, and more people get access to the network... and now you've run out of addresses.
A Virtual Cloud Network (VCN) may have as many as five CIDR blocks, although if added at a later stage, they will not be contiguous. The difficulty arises when trying to summarize non-contiguous CIDRs during routing advertisements to your firewall teams.
The RFC 1918 Rule and One Address Range to Avoid
| CIDR | Usable IPs | Good For | Risk |
|---|---|---|---|
/24 |
~251 | POC, single small workload | Outgrows fast |
/22 |
~1,019 | Single-environment production | Tight for DR + growth |
/20 |
~4,091 | Multi-tier production VCN | Solid default |
/16 |
~65,531 | Hub VCN, large enterprise estate | Generous headroom |
08 · The Short Version — 6 Things to Do Before You Touch the Console
Six decisions. Twenty minutes to understand. Hours of pain if you skip them.
- Design first.Block time in your project plan. Get VCN topology, CIDR sizing, and DNS strategy agreed before provisioning anything.
- Use hub-and-spoke with a DRG.One VCN is a starting point, not a production architecture. Isolate environments into separate VCNs, connect through the DRG.
- Design hybrid DNS from day one.OCI Private DNS lets OCI and on-premises resolve each other's hostnames — but only if you set it up intentionally.
- Default to private subnets.Only put resources in public subnets if they specifically need inbound internet access. Everything else: private.
- One route table and one security list per subnet.Sharing them across subnets means losing granular control — which always costs you later.
- Size your CIDRs generously and name everything deliberately.Both are nearly impossible to fix after workloads are running on top of them.
Learn OCI networking the way architects actually design it
The patterns in this guide — hub-and-spoke DRG topology, hybrid DNS, subnet isolation, and CIDR planning — are exactly what we teach in the ExaGuru OCI Architect program. Not as theory, but as hands-on labs where you build, break, and rebuild real VCNs before touching a production tenancy.
- VCN lab environments — design hub-and-spoke from scratch, attach spokes to a DRG, and configure route tables per subnet.
- Hybrid DNS workshops — wire OCI Private DNS to on-premises resolvers and resolve hostnames in both directions.
- Architecture review practice — defend your CIDR plan, naming convention, and subnet strategy as you would in a real design review.
- OCI Architect certification path — Associate and Professional exams aligned with the networking depth this article describes.
09 · Conclusion
Twenty minutes now, or hours of retrofit later
The month-three wall is predictable. A default VCN, a quick CIDR, DNS ignored, workloads deployed — and then on-prem can't resolve hostnames, CIDRs overlap with production, and subnet types can't be changed without tearing everything down.
Every failure described in this guide has a best-practice answer. The only variable is whether you apply it before the first VM — or after the outage.
Design the network in your project plan. Use hub-and-spoke with a DRG. Wire hybrid DNS from day one. Default to private subnets with dedicated route tables and security lists. Size CIDRs generously. Name everything deliberately. These are not advanced techniques — they are the baseline Oracle's own architects publish, and they take twenty minutes to understand.