🌐 OCI Networking Series: Part 2 – Designing and Managing VCNs

 

Objective: Deep dive into VCN architecture 

Here, will see practical guidance for creating/managing VCNs, choosing public vs private subnets, working with route tables & security lists/NSGs, CIDR sizing and planning, plus subnetting best practices.

Quick primer — what a VCN is (Virtual Cloud Network)

A Virtual Cloud Network (VCN) is your private network inside OCI — think of it as a virtual datacenter where you define IP ranges, subnets, route rules and gateways that control traffic for your cloud workloads. You can create VCNs from the Console, CLI or via IaC (Terraform/Pulumi). 

Creating & managing VCNs :- 

Console (VCN Wizard) :

The easiest way for hands-on learning is the VCN Wizard (Console) — it can create a VCN with public + private subnets, route tables, internet/NAT/service 

gateways and default security lists in a few clicks.

CLI / API / IaC :

You can create VCNs using oci network vcn create, the REST API, or via Terraform / Pulumi providers (all documented). Use CLI for automation or scripts; 

use Terraform for reproducible deployments. 

You can also use quick wizard for automated VCN deployment but its not recommnded for actual production grade purpose. Its ok for learning purpose. The above describe 2 methods mostly used for deploying network in the OCI tenancy.

Important facts to keep in mind

• A VCN can include multiple non-overlapping IPv4 CIDR blocks. 
• You can update a VCN to add CIDR blocks (subject to limits and constraints) but CIDR changes must follow rules (no overlap, must not include addresses used by existing subnets.

Public vs Private Subnets — when & why

Public Subnet :- 

Resources in a public subnet typically have a public IP (or assigned public IP on the VNIC) and route outbound/inbound traffic via an Internet Gateway (IGW).  Public subnets are used for load balancers, bastion hosts, public-facing web servers, etc. Only one IGW is needed per VCN (but access still depends on route rules + security rules).

Private Subnet :-

Resources in private subnets do not have public IPs. If they need outbound internet access (patching, updates), use a NAT Gateway to provide outbound-only access while blocking inbound connections from the internet. This is the recommended pattern for backend servers/databases. 

Design rules of thumb

• Place edge-facing services (web tier, bastion) in public subnets and backend tiers (app, DB, caches) in private subnets. 
• Control egress for private subnets via NAT or through a proxy/firewall appliance. This pattern simplifies security posture and auditing.

Route Tables: Default vs Custom (how routing works)

Default route table :- 

Each VCN automatically has a default route table. Subnets inherit the VCN’s default route table unless you explicitly assign a custom one. 

Custom route tables :- 

Use custom route tables when you need different outbound targets for different subnets (for example: public subnet → IGW; private subnet → NAT or firewall; hybrid subnet → DRG).  Create a route rule with destination CIDR and target (IGW, NAT, DRG, Service Gateway, local peering, etc.).

Best practices

Give each logical tier (web, app, db) its own route table where it makes sense — this improves clarity and reduces risk of accidental route changes affecting multiple tiers. 

In the above diagram, There are 3 subnets - one public and 2 private subnets. Each subnets have their own route table and security list. Public subnet is reaching to the internet via internet gateway, whereas private subnet B is reaching internet via NAT gateway. 

Both subnets have different purpose and different routes so better to have separate route table for each subnets. The 3rd private subnet is reaching to the object storage - it may be for backup and it get there via service gateway.

Security: Security Lists vs Network Security Groups (NSGs)

Security Lists :-

Security lists are applied at subnet level — every VNIC in the subnet is subject to the security-list rules. The default security list comes with initial stateful rules to enable things like SSH by default; you should tighten these for production.

Network Security Groups (NSGs) :-

NSGs are applied to VNICs (instance-level micro-segmentation). They act like a virtual firewall for a group of resources that share the same security posture. Use NSGs when you want finer-grained control without segregating into separate subnets.

Stateful vs Stateless

Individual security rules can be stateful (default) or stateless. Stateful rules use connection tracking so responses are automatically allowed; stateless rules require you

to allow both directions explicitly.

When to use which

• Use security lists for broad, subnet-wide rules and NSGs for dynamic, instance-level or micro-segmentation use cases (e.g., allow only specific app servers to reach DB). 
• You can use both — they are additive. 

    

Each security rule have the option of stateless or stateful as highlighted in above diagram. Each have separate use cases on when to use what. 

CIDR block sizing & planning strategies (do this before you launch)

VCN IPv4 CIDR block size must be in the range /16 through /30; a VCN can contain multiple non-overlapping IPv4 CIDR blocks. Regardless of number of CIDR blocks, Oracle documents an upper bound on the number of private IPs (for many tenancy configs the practical limit is ~64K addresses per VCN. Plan accordingly. 

CIDR blocks must not overlap with on-premises network CIDRs or with peered VCNs. When you add/remove CIDR blocks, follow the documented CLI/API constraints 

(order, non-overlapping, work request state).

Practical planning tips

• Start with a /16 (10.0.0.0/16) if you anticipate many subnets/hosts; break it into /24s for tiers (10.0.1.0/24 for web, 10.0.2.0/24 for app, 10.0.3.0/24 for db). 
• If you expect lots of VCN peering or large-scale Kubernetes/containers, plan larger or multiple VCN CIDRs.
• Avoid RFC1918 overlap with on-prem: Coordinate with network team and reserve ranges for future peering/FastConnect/IPSec. 
• Leave headroom: Don’t allocate every available /24 right away — leave spare subnets for scaling and for service-specific needs (monitoring, jump hosts, analytics). 

The above table shows how many addresses comes with specific CIDR notation. All IP's are not usable for the subnet as first 2 and last IP address is used for internal networking purpose per subnet.

Subnetting best practices specific to OCI

• Use regional subnets (recommended by Oracle) — they are more flexible than AD-specific subnets and simplify distributing compute across ADs for HA. 
• Name and tag subnets and route tables consistently: <env>-<tier>-<region>-<purpose> (e.g., prod-app-mum-private). Good naming helps automation and audits. 
• Separate route tables for private vs public subnets — easier to reason about and reduces blast radius when updating routes. 
• Prefer NSGs for micro-segmentation if your environment is dynamic (auto-scaling, ephemeral VMs) — NSGs move with the VNIC. Use security lists for stable, static network tiers. 

Example quick checklist before you create your production VCN

• Confirm your CIDR plan and avoid overlap with on-prem or other VCNs. 
• Decide regional vs AD-specific subnet strategy (Oracle recommends regional subnets for flexibility). 
• Prepare security policy: NSGs vs Security Lists and stateful/stateless rules. 
• Plan route tables per tier (public vs private vs hybrid). 
• Create tagging + naming conventions so automation & audits are simple.

What's Next :- 

Hands-on: Use the OCI Free Tier to spin up a VCN via the Console wizard, create one public + one private subnet, attach an IGW and NAT, launch a compute instance in each, 

and test connectivity. 

See you in the next one!!!