Oracle Cloud Networking Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking, Edge, and Connectivity

1. Introduction

Oracle Cloud Networking (within Oracle Cloud Infrastructure, OCI) is the set of foundational services that let you design private networks in the cloud, connect them to the internet and to on-premises environments, and control traffic flow and security at multiple layers.

In simple terms: Networking is how you create your cloud “data center network” in Oracle Cloud—you build a Virtual Cloud Network (VCN), carve it into subnets, decide which routes exist, and define what traffic is allowed in or out.

Technically, Oracle Cloud Networking provides software-defined networking (SDN) primitives—VCNs, subnets, route tables, gateways (Internet Gateway, NAT Gateway, Service Gateway), Dynamic Routing Gateway (DRG), peering, and security controls (Security Lists, Network Security Groups)—that together define your network topology, connectivity, segmentation, and packet filtering. You attach compute, load balancers, and managed services to these networks and apply consistent routing and security.

The problem it solves: secure, scalable, repeatable network design for cloud workloads—whether you’re building a simple web app, a multi-tier enterprise platform, or hybrid connectivity to on-premises networks—without needing to manage physical routers, firewalls, and cabling.

Service name check: In Oracle Cloud/OCI, “Networking” is the umbrella category used across console and documentation for VCN and related connectivity services. Core constructs like Virtual Cloud Network (VCN) and Dynamic Routing Gateway (DRG) are active and current. Some older patterns (for example, AD-specific subnets) still exist but Oracle recommends regional subnets for most new designs—verify current best practices in the official docs.

2. What is Networking?

Oracle Cloud Networking is OCI’s core networking stack that lets you:

Create isolated private networks (VCNs) in a region
Segment them into subnets
Control packet flow with route tables
Provide connectivity via gateways (internet, NAT, service gateway)
Connect networks together (peering) and connect to on-premises (IPSec VPN, FastConnect) typically via DRG
Enforce network security using Security Lists and Network Security Groups (NSGs)
Observe and troubleshoot traffic with tools like VCN Flow Logs and VTAP (traffic mirroring)

Official purpose (practical framing)

Networking provides the connectivity and security foundation required by nearly every other OCI service. Without Networking, you can’t place compute instances in private address space, control ingress/egress, or integrate hybrid connectivity.

Core capabilities

Virtual Cloud Networks (VCNs): Your private, software-defined network boundary
Subnets: Regional segments where you attach compute and other resources
Routing: Route tables that decide where traffic goes (e.g., to IGW/NAT/DRG)
Gateways: Internet, NAT, Service Gateway, plus peering gateways
Hybrid connectivity: IPSec VPN and FastConnect (commonly anchored via DRG)
Security controls: Security Lists (subnet-level) and NSGs (VNIC-level)
Addressing: IPv4 private addressing, public IPs, secondary IPs; IPv6 support exists (verify current constraints by region and feature set)
Observability: Flow logs, traffic mirroring (VTAP), and integration with OCI Logging/Monitoring

Major components (high-level)

Component	What it is	Typical use
VCN	Regional virtual network	Primary network container for workloads
Subnet (public/private)	Segment of a VCN	Tier separation (web/app/data), isolation
Route table	Routing rules for subnets	Direct traffic to IGW/NAT/DRG, etc.
Internet Gateway (IGW)	Public internet routing target	Public inbound/outbound for public subnets
NAT Gateway	Outbound internet without inbound	Private subnets needing updates/package installs
Service Gateway	Private access to OCI services	Access Object Storage, etc., without public internet
DRG	Virtual router for VCN edge	Hub for VPN/FastConnect/peering/transit routing
LPG / RPC	Peering constructs	Connect VCNs in-region or cross-region
Security List	Subnet-level firewall rules	Baseline controls (stateful)
NSG	VNIC-level firewall rules	App-centric segmentation, preferred for many designs
Public/Private IPs	Addresses for VNICs	Public exposure, internal services
DHCP options	DNS/search domain settings	Control resolver/search domain behavior
Flow Logs / VTAP	Traffic visibility	Troubleshooting, security monitoring

Service type

Networking is an IaaS foundational service (software-defined networking). Many constructs are configuration objects (often low or no direct cost), while some connectivity services have usage-based pricing (for example, NAT Gateway, DRG, VPN/FastConnect, and especially data egress).

Scope (regional/global/compartment)

VCNs are regional in OCI.
Most Networking resources are regional and created within a compartment in your tenancy.
Policies and governance are tenancy-wide but can be scoped to compartments.

How it fits into the Oracle Cloud ecosystem

Networking underpins: – Compute (instances require VNICs in a subnet) – Load Balancing (LBs attach to subnets) – Kubernetes (OKE) (pods/services rely on VCN/subnets, CNI behavior depends on OKE networking mode) – Database services (DB Systems, Exadata Cloud Service, etc. are placed into VCN/subnets) – Security and monitoring (Audit, Logging, Monitoring, Cloud Guard signals often depend on network telemetry)

Official documentation entry points (start here): – OCI Networking overview: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm – VCN: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/virtualcloudnetwork.htm – DRG: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingDRGs.htm (verify latest DRG docs section names)

3. Why use Networking?

Business reasons

Faster time to market: Build network environments in minutes rather than procuring physical gear.
Standardization: Use reusable blueprints (VCN patterns, Terraform modules) across teams.
Hybrid readiness: Many enterprises need secure connectivity to on-prem; DRG + VPN/FastConnect provide a structured approach.

Technical reasons

Isolation: Each VCN is an isolated address space and routing domain.
Segmentation: Subnets + NSGs enable tiered architectures and least-privilege network policies.
Control of ingress/egress: You decide what is public, what is private, and how traffic flows.
Scalable routing: Hub-and-spoke patterns with DRG simplify multi-VCN connectivity.

Operational reasons

Repeatability: Infrastructure-as-code (Terraform/OCI CLI) supports consistent builds.
Observability: Flow logs and traffic mirroring help troubleshoot connectivity issues faster.
Change control: Route tables and security rules can be audited and versioned (with IaC).

Security/compliance reasons

Policy-driven access: OCI IAM policies govern who can change network topology.
Private service access: Service Gateway reduces reliance on public internet for OCI service access.
Compartmentalization: Separate environments (dev/test/prod) into compartments with independent network policies.

Scalability/performance reasons

Regional VCN design: Avoid availability-domain-specific networking constraints (where possible) and support multi-AD or multi-fault-domain deployments.
Private backbone: OCI provides regional connectivity and private access to OCI services (where supported) to reduce exposure and improve reliability.

When teams should choose it

You need any OCI workload beyond the most basic public service usage.
You are building multi-tier apps, private databases, or hybrid connectivity.
You need segmentation (NSGs), controlled egress, and auditable network changes.

When teams should not choose it (or should keep it minimal)

If your workload is entirely SaaS and doesn’t require OCI compute/network placement.
If you only need a managed service endpoint and no private compute (rare in OCI architectures).
If you’re prototyping and want to minimize complexity: start with the simplest VCN + subnets pattern, then iterate.

4. Where is Networking used?

Industries

Financial services: Segmented networks, strict egress control, hybrid connectivity.
Healthcare: Compliance-driven isolation and logging.
Retail/e-commerce: Public web tiers + private app/data tiers, global operations.
Manufacturing/IoT: Hybrid connectivity to factories, private telemetry pipelines.
Public sector: Compartmentalized multi-environment design and governance.

Team types

Cloud/platform engineering teams building landing zones
Network engineering teams extending enterprise networks
DevOps/SRE teams owning environment reliability
Security teams implementing segmentation and monitoring
Application teams deploying into shared VCNs (with guardrails)

Workloads

Web applications (public + private tiers)
Microservices on OKE
Oracle and non-Oracle databases in private subnets
Batch processing needing outbound access via NAT
Hybrid workloads spanning on-prem and OCI

Architectures

Single-VCN simple deployment (dev/test)
Multi-tier VCN (web/app/data) for production
Hub-and-spoke multi-VCN topology with DRG as transit hub
Multi-region with remote peering, disaster recovery, and replicated services
Shared services VCN (DNS, bastion, logging collectors) plus application VCNs

Real-world deployment contexts

Production: Strong segmentation, dedicated route tables, DRG-based hybrid, flow logs, tagging, change management.
Dev/test: Minimal topology, tighter cost controls, simplified rules; often still uses private subnets and NAT to mimic production.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Networking is the enabling foundation.

1) Build a secure two-tier web application

Problem: Web tier must be public; app tier must be private.
Why Networking fits: Public subnet + IGW for load balancer/web; private subnet + NAT for app egress; NSGs for tier rules.
Example: Public LB forwards to web instances; web talks to private app instances on TCP 8080; DB in private subnet.

2) Private database with controlled egress

Problem: Database servers must not have public IPs but need OS patching.
Why it fits: Private subnet + NAT Gateway for outbound; no IGW route on DB subnet.
Example: Oracle Linux DB nodes pull updates via NAT; inbound only from app NSG.

3) Hybrid connectivity to on-premises via IPSec VPN

Problem: Extend corporate network to OCI securely.
Why it fits: DRG provides attachment point; IPSec VPN offers encrypted tunnels.
Example: On-prem CIDR routes to VCN CIDR through VPN; apps access on-prem AD/LDAP.

4) Dedicated private connectivity via FastConnect

Problem: Need predictable bandwidth/latency and avoid public internet for enterprise traffic.
Why it fits: FastConnect integrates with DRG and enterprise WAN.
Example: ERP system uses FastConnect to reach OCI databases with consistent performance.

5) Multi-VCN hub-and-spoke transit routing

Problem: Multiple application VCNs must connect to shared services and on-prem without full mesh complexity.
Why it fits: DRG as hub; route tables and attachments create scalable connectivity.
Example: Shared services VCN hosts DNS and logging collectors; spokes host apps per BU.

6) Microsegmentation with NSGs

Problem: Subnet-level rules are too coarse; need app-centric controls.
Why it fits: NSGs apply to VNICs; rules reference NSGs (not IP ranges).
Example: Only payment service pods/instances can talk to DB port 1521.

7) Secure outbound-only subnets for build agents

Problem: CI runners need to download dependencies but must not accept inbound.
Why it fits: Private subnet + NAT; no public IPs; tight NSG egress rules.
Example: Build agents pull from package repos and push artifacts to OCI Object Storage.

8) Isolate environments with compartments and separate VCNs

Problem: Reduce blast radius between dev/test/prod.
Why it fits: Separate VCNs per environment; IAM policies per compartment.
Example: Prod VCN has DRG + VPN; dev VCN has internet-only access and stricter budgets.

9) Cross-region connectivity for disaster recovery

Problem: Need app failover between regions.
Why it fits: Remote peering (via DRG) supports inter-region VCN connectivity patterns.
Example: Primary region services replicate to DR region; private traffic stays on Oracle backbone.

10) Traffic visibility for incident response

Problem: Need packet/flow insight without installing agents everywhere.
Why it fits: VCN Flow Logs and VTAP help observe traffic patterns and investigate anomalies.
Example: Enable flow logs on subnets; mirror suspicious VNIC traffic to an IDS sensor.

11) Private access to OCI services without internet exposure

Problem: Workloads must access OCI services without routing to public internet.
Why it fits: Service Gateway routes to OCI Services Network.
Example: Private compute writes logs to Object Storage while remaining non-public.

12) Secure admin access pattern using a bastion/jump host

Problem: Admin SSH/RDP must not be open to the internet for private servers.
Why it fits: Public subnet jump host; private subnets for targets; NSGs restrict SSH to jump host only.
Example: Only jump host has public IP; admins SSH to jump then to private instances.

6. Core Features

This section focuses on current, commonly used OCI Networking features. Some features vary by region—verify availability in official docs and your tenancy.

Virtual Cloud Network (VCN)

What it does: Creates a private, isolated network in a region with your chosen CIDR blocks.
Why it matters: It’s the top-level boundary for routing, segmentation, and security.
Practical benefit: You can mirror on-prem network concepts (subnets, routing, firewalling) in OCI.
Caveats: Plan CIDRs carefully to avoid overlaps with on-prem or other VCNs (important for peering/hybrid).

Regional subnets (recommended)

What it does: A subnet spans the whole region (not tied to a single availability domain).
Why it matters: Simplifies high availability patterns and reduces operational complexity.
Practical benefit: You can deploy resources across availability domains without changing subnet design.
Caveats: OCI still supports AD-specific subnets in some contexts; Oracle’s guidance generally favors regional subnets for new deployments—verify current guidance in VCN docs.

Route tables

What it does: Defines routes for traffic leaving a subnet (destination CIDR/service + next hop).
Why it matters: Most connectivity issues are routing-related; route tables make traffic flow explicit.
Practical benefit: Separate route tables per tier (public vs private) for clearer intent.
Caveats: Route rules must align with gateways and security rules; avoid overly broad “0.0.0.0/0 everywhere” in private tiers.

Internet Gateway (IGW)

What it does: Enables public internet routing for a VCN.
Why it matters: Required for public subnets to send/receive internet traffic.
Practical benefit: Public-facing workloads (LB, web) become reachable.
Caveats: IGW alone doesn’t make instances public; they also need public IPs and security rules.

NAT Gateway

What it does: Allows instances in private subnets to initiate outbound connections to the internet without accepting inbound connections.
Why it matters: Common for patching, package downloads, and external API calls without exposing servers.
Practical benefit: Stronger security posture for private tiers.
Caveats: NAT Gateway typically has hourly and/or data processing charges (verify current pricing). Also, your egress traffic is still subject to data transfer pricing.

Service Gateway

What it does: Enables private access from a VCN to selected OCI services via the OCI Services Network.
Why it matters: Reduces internet exposure and can simplify compliance posture.
Practical benefit: Private workloads can reach services like Object Storage without traversing the public internet.
Caveats: Not all services are available through Service Gateway; availability is region-dependent. Verify supported services list in docs.

Dynamic Routing Gateway (DRG)

What it does: Acts like a virtual edge router for VCNs; central point for attachments (VCNs, IPSec VPN, FastConnect, remote peering).
Why it matters: Enables scalable hybrid and multi-VCN designs.
Practical benefit: Hub-and-spoke topologies become manageable; simplifies routing domains.
Caveats: DRG is often billable (hourly). Routing configuration requires careful design (route tables on both VCN side and DRG side).

Local peering and remote peering

What it does: Connects VCNs privately (within region via local peering; across regions via remote peering).
Why it matters: Avoids hairpinning traffic through the internet; supports shared services and DR.
Practical benefit: Private IP connectivity between VCNs.
Caveats: CIDR overlap is not allowed; route tables and security rules must explicitly allow traffic.

Security Lists (subnet-level)

What it does: Stateful virtual firewall rules applied at subnet level.
Why it matters: Basic security layer for controlling ingress/egress.
Practical benefit: Simple baseline for small environments.
Caveats: Coarse-grained—harder to manage at scale when many apps share a subnet.

Network Security Groups (NSGs) (VNIC-level)

What it does: Stateful security rules applied to VNICs (instances, LBs, etc.).
Why it matters: Enables microsegmentation independent of subnet membership.
Practical benefit: Easier least-privilege: allow “app servers” to talk to “db servers” without hardcoding IPs.
Caveats: Requires disciplined NSG design and naming; avoid rule sprawl.

Public IPs and private IPs (VNIC/IP management)

What it does: Assigns public IPs (ephemeral or reserved) and private IPs (primary/secondary) to VNICs.
Why it matters: Public reachability and internal service addressing depend on it.
Practical benefit: You can keep servers private and only expose LBs or bastions.
Caveats: Track public IP usage to avoid accidental exposure; reserved public IPs may be preferred for stable endpoints.

DHCP options and DNS behavior

What it does: Controls DNS server type (VCN resolver), search domain, and options.
Why it matters: Name resolution issues can look like connectivity issues.
Practical benefit: Standardize DNS/search domain across subnets.
Caveats: Custom DNS requirements may involve additional OCI DNS capabilities—verify requirements.

VCN Flow Logs

What it does: Captures flow metadata (source/destination/ports/accept/deny) for traffic in a VCN/subnet.
Why it matters: Critical for troubleshooting and security investigations.
Practical benefit: Identify which rule blocked traffic, see unexpected egress destinations.
Caveats: Generates logging volume (cost). Plan retention and filtering.

VTAP (traffic mirroring)

What it does: Mirrors traffic from a VNIC to a target (e.g., IDS appliance).
Why it matters: Deep packet inspection and advanced troubleshooting.
Practical benefit: Supports security tooling without inline deployment.
Caveats: Adds operational complexity and potential cost; ensure privacy/compliance review.

7. Architecture and How It Works

High-level architecture

OCI Networking is software-defined. You define configuration objects (VCN, subnets, route tables, gateways, security rules). OCI enforces those rules in the data plane.

Key concept: Security and routing are independent. – Routing decides where packets go. – Security Lists/NSGs decide whether packets are allowed.

Control flow vs data flow

Control plane: You create/modify networking resources via OCI Console, OCI CLI, SDKs, or Terraform. IAM policies govern who can do what.
Data plane: Packets flow between VNICs, gateways, and attachments according to route tables and security rules.

Typical request flow examples

Example A: Public web request to a public instance 1. Client on the internet sends traffic to a public IP. 2. Internet Gateway is the route target for 0.0.0.0/0 on the public subnet route table. 3. Security List/NSG ingress rules must allow the port (e.g., 443). 4. Instance receives traffic on its VNIC.

Example B: Private instance outbound to internet 1. Private instance sends traffic to 0.0.0.0/0. 2. Private subnet route table sends 0.0.0.0/0 to NAT Gateway. 3. NAT Gateway performs source NAT and sends traffic to internet. 4. Return traffic is allowed due to stateful tracking.

Example C: Private instance to on-prem 1. Private instance sends traffic to on-prem CIDR (e.g., 10.10.0.0/16). 2. Subnet route table sends that CIDR to DRG. 3. DRG forwards to IPSec VPN or FastConnect attachment based on DRG route rules. 4. On-prem receives and returns traffic.

Integrations with related OCI services

Compute: Instances attach via VNICs to subnets and NSGs.
Load Balancer: Attaches to subnets; NSGs/security lists control frontend/backends.
OKE (Kubernetes): Uses VCN subnets and security rules; design depends on OKE networking mode.
Logging/Monitoring: Flow logs and metrics integrate with OCI Logging and Monitoring services.
IAM: Policies define who can manage network objects (virtual-network-family).

Dependency services

IAM for access control and compartments
Logging/Monitoring for observability (recommended)
Compute for hands-on validation (instances to test connectivity)

Security/authentication model

API calls to manage Networking require OCI API authentication (Console user session, API keys, instance principals, etc.).
IAM policies define permissions such as manage virtual-network-family.
Network security enforcement is done using stateful firewall rules (security lists and NSGs).

Networking model (key behaviors)

Subnet routing is controlled by route tables attached to subnets.
Security Lists apply to all VNICs in the subnet; NSGs apply to specific VNICs.
Many OCI networking rules are stateful by default (return traffic allowed).

Monitoring/logging/governance considerations

Enable VCN Flow Logs on critical subnets (or selectively) and ship to a central log group.
Use tags (defined tags/free-form tags) for cost allocation and governance (e.g., env, app, owner, cost-center).
Use compartments and IAM guardrails to separate responsibilities (network team vs app team).
Track service limits (VCNs per region, route rules per route table, NSGs per VNIC, etc.)—see OCI Service Limits.

Simple architecture diagram

flowchart LR
  Internet((Internet))
  IGW[Internet Gateway]
  NAT[NAT Gateway]
  VCN[VCN: 10.0.0.0/16]
  PubSubnet[Public Subnet\n10.0.1.0/24]
  PrivSubnet[Private Subnet\n10.0.2.0/24]
  Web[Compute: Web/Bastion\nPublic IP]
  App[Compute: App\nPrivate IP]

  Internet --> IGW --> PubSubnet --> Web
  PrivSubnet --> NAT --> Internet
  Web --> App
  VCN --- PubSubnet
  VCN --- PrivSubnet

Production-style architecture diagram (hybrid + multi-tier)

flowchart TB
  OnPrem[On-Prem Network\n10.10.0.0/16]
  VPN[IPSec VPN or FastConnect]
  DRG[Dynamic Routing Gateway]
  VCNHub[Hub VCN\nShared Services]
  VCNApp[App VCN\nProd]
  VCNDev[App VCN\nDev/Test]

  subgraph Hub[Hub VCN]
    HubPub[Public Subnet\nIngress]
    HubPriv[Private Subnet\nShared Services]
    Bastion[Bastion / Admin Access]
    DNS[DNS/Resolvers\n(if used)]
  end

  subgraph Prod[Prod VCN]
    WebSubnet[Public Subnet\nLB/Web]
    AppSubnet[Private Subnet\nApp]
    DbSubnet[Private Subnet\nDB]
    LB[Load Balancer]
    AppNodes[App Nodes]
    DB[DB System]
    NATP[NAT Gateway]
    SvcG[Service Gateway]
  end

  OnPrem <--> VPN <--> DRG
  DRG --- VCNHub
  DRG --- VCNApp
  DRG --- VCNDev

  LB --> AppNodes --> DB
  AppSubnet --> NATP --> Internet((Internet))
  AppSubnet --> SvcG --> OCI_Services[OCI Services Network\nObject Storage, etc.]

  Bastion --> AppNodes
  HubPub --> Bastion

8. Prerequisites

Tenancy/account requirements

An Oracle Cloud (OCI) tenancy with permission to create Networking resources.
A compartment to organize lab resources (recommended).
Billing: While many networking constructs are free, Compute instances and data egress can incur costs. Use Always Free eligible shapes where available (verify Always Free eligibility in your region).

Permissions / IAM policies

At minimum for the lab, your user/group should be allowed to manage: – Networking resources (VCN, subnets, gateways, NSGs) – Compute instances (to validate connectivity)

Example policy statements (adjust compartment names): – Allow group NetworkAdmins to manage virtual-network-family in compartment <compartment> – Allow group NetworkAdmins to manage instance-family in compartment <compartment>

If your organization separates duties, you might only get use permissions for networking and manage for instances. For official IAM syntax and best practices, verify IAM docs: – IAM overview: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/overview.htm

Tools

You can do the lab entirely in the OCI Console. Optional tools: – OCI Cloud Shell (recommended for CLI commands without local setup): https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cloudshellintro.htm – OCI CLI docs: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm – SSH client: – macOS/Linux: ssh – Windows: PowerShell/OpenSSH or PuTTY

Region availability

VCN and core networking are broadly available across OCI regions.
Specific connectivity offerings (FastConnect locations, some service gateway service lists, IPv6 features, etc.) can vary—verify in official docs for your region.

Quotas/limits

OCI enforces service limits (per region/tenancy/compartment).
Before production builds, review limits for:
number of VCNs, subnets, route tables
route rules per route table
NSGs and rules
DRG attachments
Service limits: https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm

Prerequisite services

For the hands-on tutorial, you’ll use: – Networking (VCN, subnets, gateways, NSGs) – Compute (2 instances for validation)

9. Pricing / Cost

Oracle Cloud Networking pricing is a mix of: – No-charge configuration objects (commonly VCNs, subnets, route tables, NSGs, security lists) – Usage-based connectivity services (commonly NAT Gateway, DRG, IPSec VPN, FastConnect) – Data transfer charges (especially outbound data egress to the internet)

Because pricing can vary by region and may change, use official sources: – OCI Pricing page (Networking section): https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html (verify current URL/availability) – OCI Free Tier overview: https://www.oracle.com/cloud/free/

Pricing dimensions (typical)

Verify exact SKUs in the pricing page for your region, but expect dimensions such as: – Per hour: NAT Gateway, DRG, VPN connections (often hourly), FastConnect port charges – Per GB processed: NAT Gateway data processing, possibly other gateway services – Data transfer (egress): – Internet egress is commonly billable per GB beyond any free allowances – Intra-region traffic pricing rules vary by service and path—verify in pricing docs

Free tier considerations

Many foundational configuration objects cost $0.
Always Free may include limited compute capacity suitable for labs.
Data egress and certain gateway services may still incur cost even in a “free-ish” lab if you generate traffic.

Direct cost drivers

NAT Gateway hours (if enabled)
DRG hours (if used)
VPN connection hours
FastConnect port and provider charges (enterprise)
Data egress to internet (updates, downloads, API calls, user traffic)
Logging volume (Flow Logs stored in Logging can incur ingestion/storage costs—verify)

Hidden or indirect costs

Flow logs retention: storing large volumes of logs
Packet mirroring (VTAP): can increase network traffic and downstream capture storage/processing
Cross-region traffic: disaster recovery replication can be expensive
Public load balancers: separate service with its own pricing

How to optimize cost (without breaking security)

Use Service Gateway where applicable to access OCI services without public internet exposure (cost impact depends on service and data transfer rules—verify).
Keep NAT Gateways only in environments that need them; consider scheduling non-prod environments.
Restrict outbound traffic (NSG egress) to reduce accidental data transfer.
Right-size log collection: enable Flow Logs where needed, tune retention.

Example low-cost starter estimate (no fabricated numbers)

A minimal lab commonly includes: – 1 VCN, 2 subnets, route tables, NSGs (typically $0) – 2 small compute instances (Always Free eligible if available) – Optional NAT Gateway (hourly + data processing charges—verify current rates) – Light outbound traffic for OS updates (possible egress costs depending on your region and free allowances)

Use the official cost estimator and plug in: – region – NAT Gateway hours (if used) – estimated monthly outbound GB

Example production cost considerations

In production, recurring cost often comes from: – DRG + attachments (hourly) – VPN/FastConnect (hourly + port/provider) – Significant internet egress from user traffic – Centralized flow logging and long retention – Multi-region replication traffic

10. Step-by-Step Hands-On Tutorial

Objective

Build a secure VCN in Oracle Cloud Networking with: – One public subnet (bastion/jump host) – One private subnet (private app host) – Internet Gateway for public subnet – NAT Gateway for private subnet outbound-only internet access – NSGs to enforce least privilege – Validation using SSH and outbound connectivity checks – Full cleanup at the end

This lab is designed to be low-risk and low-cost. Use Always Free compute shapes if available in your region.

Lab Overview

You will create: – VCN: 10.0.0.0/16 – Public subnet: 10.0.1.0/24 (has route to IGW) – Private subnet: 10.0.2.0/24 (has route to NAT) – Compute instance bastion01 in public subnet (has public IP) – Compute instance app01 in private subnet (no public IP) – NSGs: – nsg-bastion: allow inbound SSH from your IP – nsg-app: allow inbound SSH only from nsg-bastion – Optional: Enable a basic Flow Log on one subnet (optional step, cost-aware)

Expected outcome: – You can SSH from your laptop to bastion01. – You can SSH from bastion01 to app01 over private IP. – app01 can reach the internet outbound via NAT (but cannot be reached inbound from the internet).

Step 1: Create (or choose) a compartment

In the OCI Console, open the navigation menu → Identity & Security → Compartments.
Click Create Compartment.
Name: lab-networking
Parent compartment: your root compartment (or as per your org)
Click Create Compartment

Expected outcome: A dedicated compartment exists for cleanup and access control.

Step 2: Create a VCN with public and private subnets

You can use the wizard, but to learn the pieces, create it manually (more educational).

Go to Networking → Virtual Cloud Networks.
Select the compartment lab-networking.
Click Create VCN.
Choose VCN Only (or similar manual option).
Enter: – Name: vcn-lab – CIDR Block: 10.0.0.0/16
Click Create VCN

Now create subnets:

Create the public subnet

Open vcn-lab.
Click Subnets → Create Subnet.
Enter: – Name: subnet-public – Subnet Type: Regional (recommended) – CIDR Block: 10.0.1.0/24 – Route Table: create new rt-public – Security Lists: default is fine for now (we’ll prefer NSGs) – “Public subnet” setting: enable public IP assignment if prompted (auto-assign public IPv4 address)
Click Create Subnet

Create the private subnet

Click Create Subnet again.
Enter: – Name: subnet-private – Type: Regional – CIDR: 10.0.2.0/24 – Route Table: create new rt-private – Auto-assign public IP: disable
Click Create Subnet

Expected outcome: VCN exists with two subnets and two separate route tables.

Step 3: Create gateways (IGW + NAT) and attach route rules

Create an Internet Gateway

In vcn-lab, click Internet Gateways → Create Internet Gateway.
Name: igw-lab
Click Create Internet Gateway
Ensure it is Enabled.

Add route rule to public route table

Go to rt-public.
Add Route Rules: – Target Type: Internet Gateway – Destination CIDR Block: 0.0.0.0/0 – Target: igw-lab
Save changes.

Create a NAT Gateway

In vcn-lab, click NAT Gateways → Create NAT Gateway.
Name: nat-lab
Click Create NAT Gateway

Add route rule to private route table

Go to rt-private.
Add Route Rules: – Target Type: NAT Gateway – Destination CIDR Block: 0.0.0.0/0 – Target: nat-lab
Save changes.

Expected outcome: – Public subnet has internet route via IGW. – Private subnet has outbound default route via NAT.

Step 4: Create NSGs (recommended security approach)

Create NSG for bastion

In vcn-lab, go to Network Security Groups → Create Network Security Group.
Name: nsg-bastion
Create.

Add ingress rule to allow SSH from your IP: 1. Open nsg-bastion → Security Rules → Add Ingress Rules. 2. Configure: – Stateless: off (stateful) – Source Type: CIDR – Source CIDR: your public IP/32 (find via https://ifconfig.me from your browser) – IP Protocol: TCP – Destination Port Range: 22 3. Add.

Create NSG for app

Create NSG: nsg-app
Add ingress rule to allow SSH only from bastion NSG: – Source Type: Network Security Group – Source NSG: nsg-bastion – Protocol: TCP – Port: 22

Optionally add an ingress rule for your application port (example 8080) from bastion only or from a load balancer NSG later.

Expected outcome: Security policy is app-centric: only bastion is reachable from your IP; app host is reachable only from bastion.

Step 5: Create SSH key pair

On your local machine (or Cloud Shell), generate keys. Local is best for SSH from your laptop:

ssh-keygen -t ed25519 -f ~/.ssh/oci_lab_key -C "oci-networking-lab"

This creates: – Private key: ~/.ssh/oci_lab_key – Public key: ~/.ssh/oci_lab_key.pub

Expected outcome: You have keys ready to paste into instance creation.

Step 6: Create compute instance in the public subnet (bastion01)

Go to Compute → Instances → Create Instance.
Name: bastion01
Compartment: lab-networking
Placement: pick defaults (any AD/FD options as presented)
Image: Oracle Linux (or Ubuntu if preferred)
Shape: choose an Always Free eligible shape if available in your region (verify)
Networking: – VCN: vcn-lab – Subnet: subnet-public – Assign public IPv4 address: Yes – Network Security Groups: select nsg-bastion
Add SSH key: paste contents of ~/.ssh/oci_lab_key.pub
Click Create

Wait until the instance is Running.

Expected outcome: bastion01 has a public IP and is reachable via SSH from your IP.

Step 7: Create compute instance in the private subnet (app01)

Create Instance again.
Name: app01
Image/Shape: same as above
Networking: – VCN: vcn-lab – Subnet: subnet-private – Assign public IPv4 address: No – NSG: select nsg-app
SSH key: use the same public key
Click Create

Wait until Running.

Expected outcome: app01 has only a private IP and no public exposure.

Step 8: SSH to bastion, then to the private instance

SSH to bastion from your laptop

Find the public IP of bastion01 in the instance details and run:

chmod 600 ~/.ssh/oci_lab_key
ssh -i ~/.ssh/oci_lab_key opc@<BASTION_PUBLIC_IP>

(If you used Ubuntu image, the user is typically ubuntu instead of opc.)

Expected outcome: You get a shell on bastion01.

From bastion, SSH to the private instance

From the OCI Console, copy the private IP of app01. Then from bastion:

ssh -i ~/.ssh/oci_lab_key opc@<APP01_PRIVATE_IP>

Expected outcome: You can log into app01 from bastion01, proving private subnet routing + NSG rules work.

Step 9: Validate outbound internet from the private instance via NAT

On app01, run:

curl -s https://ifconfig.me && echo

or:

curl -I https://www.oracle.com

Expected outcome: The request succeeds. This indicates app01 has outbound access through NAT Gateway.

Now confirm inbound from internet is not possible: – app01 has no public IP, so you should not be able to SSH to it directly from your laptop.

Step 10 (Optional, cost-aware): Enable VCN Flow Logs for the private subnet

Flow logs are extremely useful but can generate logging costs. Use briefly for learning and then disable or delete.

High-level steps (exact console labels can vary): 1. Go to Observability & Management → Logging. 2. Create a Log Group in compartment lab-networking (e.g., lg-networking-lab). 3. Go back to Networking → your subnet (subnet-private) → look for Flow Logs (or Logs). 4. Create a flow log: – Source: subnet-private – Destination: your log group – Name: flowlog-subnet-private

Generate a test deny event by trying a blocked port from bastion to app (e.g., curl http://<app_private_ip>:80 if no rule allows it).

Expected outcome: Flow log entries appear in Logging, showing accept/deny metadata.

If you can’t find Flow Logs in your region/tenancy UI, verify in official docs; availability and UI placement can change.

Validation

Use this checklist:

Public subnet routing works – SSH from laptop → bastion01 succeeds.
Private subnet isolation works – Laptop → app01 direct SSH fails (no public IP).
Private subnet reachability through bastion works – SSH from bastion01 → app01 succeeds.
NAT egress works – On app01, curl https://ifconfig.me returns a public IP (NATed).
Security rules are least-privilege – Only your IP can reach TCP/22 on bastion. – Only bastion NSG can reach TCP/22 on app.

Troubleshooting

Common issues and fixes:

Issue: SSH to bastion fails (timeout)

Check: Your local IP changed; NSG ingress rule uses the wrong /32.
Fix: Update nsg-bastion ingress source CIDR to your current IP.

Issue: SSH to bastion fails (permission denied)

Check: Wrong username (opc vs ubuntu).
Fix: Confirm image type and use correct user.

Issue: SSH from bastion to app fails (timeout)

Check: nsg-app ingress does not allow TCP/22 from nsg-bastion.
Fix: Add/verify NSG rule and ensure both instances are attached to correct NSGs.

Issue: app01 cannot reach internet

Check routing: rt-private must have 0.0.0.0/0 → NAT Gateway.
Check NAT status: NAT Gateway must exist and be available.
Check security: Egress rules in NSG/security list must allow outbound (default egress is often allowed, but verify).
Check DNS: If DNS resolution fails, try curl https://1.1.1.1 (should fail due to TLS/SNI but can indicate raw connectivity). Better: nslookup oracle.com (install tools if needed).

Issue: Confusion between Security Lists and NSGs

Rule: Security Lists apply to subnet; NSGs to VNIC. Both can affect traffic.
Fix: For clarity in labs, keep security lists permissive (or default) and manage access with NSGs—but do this intentionally and document it.

Cleanup

To avoid ongoing charges (especially NAT Gateway hours), delete resources in this order:

Terminate compute instances: – app01 – bastion01
Delete optional logging resources: – Flow log – Log group (if created for lab)
Delete gateways: – NAT Gateway nat-lab – Internet Gateway igw-lab
Delete NSGs: – nsg-app – nsg-bastion
Delete subnets: – subnet-private – subnet-public
Delete route tables (if they aren’t default and not automatically removed): – rt-private – rt-public
Delete VCN: – vcn-lab

Expected outcome: Compartment is empty (or only contains what you intentionally kept).

11. Best Practices

Architecture best practices

Design CIDR with growth and connectivity in mind
Avoid overlaps with on-prem and other VCNs to enable peering/hybrid.
Reserve ranges for future subnets (e.g., /24 per tier, /16 overall).
Use multiple route tables
Separate public, private, and database routing intent.
Keep route rules minimal and well-commented via IaC.
Prefer NSGs over Security Lists for scalable segmentation
Treat NSGs as “application security groups”.
Reference NSGs in rules instead of IPs to reduce brittle configs.
Adopt a hub-and-spoke pattern for enterprises
Use DRG as a routing hub for on-prem and shared services.
Keep app VCNs simpler and isolated.

IAM/security best practices

Least privilege policies
Separate “network operators” from “app deployers”.
Use compartments per environment and per team where appropriate.
Guardrails
Restrict who can create IGWs, public IPs, or wide-open security rules in production compartments.
Tagging standards
Enforce tags for ownership and cost tracking: env, owner, app, data-classification.

Cost best practices

Minimize always-on billable gateways
NAT Gateway and DRG can be recurring; use only where necessary.
Control data egress
Cache dependencies, use private service access where applicable, and restrict outbound destinations.
Tune logs
Flow logs are valuable but can be expensive at scale—scope carefully and set retention policies.

Performance best practices

Keep traffic private where possible
Use private IPs for east-west traffic.
Use service gateway/private connectivity for OCI service access when applicable.
Avoid unnecessary middleboxes
Each hop adds complexity and potential bottlenecks; design for simplicity.

Reliability best practices

Plan for multi-AD / fault-domain deployment
Use regional subnets and redundant instances/load balancers.
Document network intent
Route tables, NSGs, and subnet purposes should be documented and reviewed like code.

Operations best practices

Use flow logs for critical tiers
Enable for subnets that host internet-facing or sensitive systems.
Standardize troubleshooting
Maintain a runbook: check route table → check NSG/security list → check NACL equivalents (OCI uses security lists/NSGs) → check host firewall → check DNS.
Automate with Terraform
Treat VCN topology as code to reduce drift.

Governance/naming best practices

Name consistently: vcn-<env>-<region>-<purpose>, subnet-<tier>-<env>, nsg-<app>-<tier>.
Keep separate compartments for prod, nonprod, shared, security.
Use defined tags where your org needs reporting and policy enforcement.

12. Security Considerations

Identity and access model

OCI IAM controls who can:
create/modify VCNs, subnets, route tables, gateways
attach DRGs and configure VPN/FastConnect
create NSGs and change rules
Use compartment-scoped policies and avoid granting broad permissions in the root compartment.

Encryption

Networking components are control-plane constructs; encryption concerns typically apply to:
IPSec VPN (encryption in transit over public internet)
TLS for application traffic
For private traffic within OCI, use application-layer encryption where required by compliance.

Network exposure risks

Accidental public exposure usually happens via:
public IP assignment to instances
route table sending 0.0.0.0/0 to IGW for a subnet that should be private
overly permissive NSG/security list rules (e.g., 0.0.0.0/0 on SSH/RDP)
Mitigation:
restrict who can create IGWs/public IPs
use NSGs with tight sources
run periodic audits of public IPs and ingress rules

Secrets handling

Networking doesn’t store secrets, but hybrid setups often involve: – VPN shared secrets / certificates – API keys for automation Best practices: – Use OCI Vault for secrets where applicable (separate service). – Avoid hardcoding secrets in Terraform state or scripts; use secure variables and secret references.

Audit/logging

OCI Audit logs record API actions (who changed a route table/NSG).
Flow logs help you see traffic decisions (allow/deny).
Centralize logs into a security compartment and limit access.

Compliance considerations

Define data classification and network zones (e.g., “public”, “internal”, “restricted”).
Enforce segmentation between tiers and environments.
Validate that private access patterns (Service Gateway, private endpoints where applicable) meet compliance requirements—verify service-specific controls in docs.

Common security mistakes

Using only security lists and sharing subnets broadly across unrelated apps.
Leaving SSH open to 0.0.0.0/0.
Treating “no public IP” as the only control (it’s important, but not sufficient).
Forgetting egress controls—data exfiltration can occur via outbound traffic.

Secure deployment recommendations

Use private subnets by default; only expose load balancers or bastions.
Use NSGs with app-based grouping and minimal ingress.
Use NAT for controlled outbound, and restrict egress destinations when feasible.
Enable flow logs on high-risk subnets with planned retention.
Implement change control around route tables, IGWs, and DRG routing.

13. Limitations and Gotchas

Limits and behaviors can change; verify in official docs and your region.

Known limitations / quotas

Service limits on:
number of VCNs/subnets per region
route rules per route table
NSGs and rules
DRG attachments and route tables
Action: review and request limit increases early for production.

Regional constraints

FastConnect availability depends on location/provider.
Some features (IPv6 options, certain service gateway service lists, observability features) may vary—verify before designing.

Pricing surprises

NAT Gateway hourly/data processing costs can surprise teams that assumed “networking is free”.
DRG and VPN can be recurring costs.
Internet egress can dominate costs for data-heavy workloads.
Flow logs can generate significant logging ingestion/storage.

Compatibility issues

CIDR overlap prevents peering and complicates hybrid routing.
Migrating from one network model to another (e.g., changing CIDRs) is difficult—plan upfront.

Operational gotchas

Security Lists and NSGs both apply; a permissive NSG doesn’t help if a restrictive security list blocks (and vice versa).
Route tables are attached to subnets; moving an instance between subnets changes its routing/security context.
DNS misconfiguration can look like network failure—always test both IP connectivity and name resolution.

Vendor-specific nuances (OCI patterns)

Regional VCN/subnet model differs from some clouds where subnets are zonal.
DRG-based transit routing is central to many OCI enterprise architectures; learn DRG route tables and attachments carefully.

14. Comparison with Alternatives

Oracle Cloud Networking is OCI’s native SDN layer. Alternatives include other OCI services that complement it, other cloud providers’ VPC equivalents, and self-managed SDN in private clouds.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Networking (VCN + gateways + DRG + NSG)	Any OCI workload, especially hybrid/enterprise	Deep integration with OCI services, strong segmentation, DRG for hub-and-spoke	Requires solid routing/security design; some features/costs can surprise	You run workloads on Oracle Cloud and need reliable connectivity and control
OCI Load Balancing	App delivery layer	Managed L4/L7 load balancing	Separate cost/service; not a full networking replacement	You need scalable inbound traffic distribution
OCI Network Firewall (separate service)	Advanced L7 inspection, centralized policy	Strong security controls	Added cost/complexity	You need centralized firewall controls beyond NSG/Security Lists
AWS VPC	AWS-native workloads	Mature ecosystem, many integrations	Different semantics; not portable 1:1	You’re primarily on AWS
Azure Virtual Network (VNet)	Azure-native workloads	Strong enterprise integration (AD, etc.)	Different constructs and governance	You’re primarily on Azure
Google Cloud VPC	GCP-native workloads	Global VPC model (different design), strong tooling	Different routing model than OCI	You’re primarily on GCP
Self-managed SDN (e.g., OpenStack Neutron)	Private cloud, strict control	Full control, on-prem deployment	High ops burden	You must operate in your own data center with full control requirements

15. Real-World Example

Enterprise example: Hybrid ERP platform with segmented tiers

Problem: A large enterprise runs ERP workloads on Oracle Cloud. The app must integrate with on-prem identity systems and data feeds, while meeting security requirements (private DB tier, controlled egress).
Proposed architecture:
VCN with public LB subnet, private app subnet, private DB subnet
DRG connected to on-prem via FastConnect (primary) and IPSec VPN (backup)
NSGs for tier-to-tier rules (LB → web/app → DB)
NAT Gateway for limited outbound from private tiers
Service Gateway for private access to OCI services (where applicable)
Flow logs enabled on public and sensitive subnets with centralized retention
Why Networking was chosen: OCI Networking provides the exact primitives needed for hybrid routing (DRG), private segmentation (NSGs), and controlled internet exposure.
Expected outcomes:
Reduced attack surface (DB private, least-privilege rules)
Predictable connectivity to on-prem
Clear routing domains and easier troubleshooting with flow logs

Startup/small-team example: Secure SaaS MVP with minimal ops

Problem: A small team needs to launch a SaaS MVP quickly while keeping production safe (no public DB, simple admin access).
Proposed architecture:
One VCN with:
- public subnet for a load balancer or a single web node
- private subnet for app workers and a managed DB
NAT Gateway for private outbound updates
NSGs: only allow SSH to a single bastion from founders’ IPs; app nodes private
Why Networking was chosen: It’s required for compute placement and allows a secure baseline without buying appliances.
Expected outcomes:
Fast deployment with clear “public vs private” separation
Lower risk of accidental exposure
Ability to evolve to multi-VCN and DRG later as the company grows

16. FAQ

1) Is “Networking” in Oracle Cloud the same as VCN?
Networking is the broader service area; VCN is the core building block within Networking. Networking also includes gateways, DRG, VPN/FastConnect connectivity, peering, NSGs, and visibility features.

2) Are VCNs global or regional in OCI?
VCNs are regional. You typically design per-region networks and connect regions via remote peering or other patterns.

3) What makes a subnet “public” in OCI?
A subnet is effectively public when: – it has a route rule 0.0.0.0/0 pointing to an Internet Gateway, and – the instance has a public IP, and – security rules allow inbound traffic.

4) If an instance has no public IP, is it fully secure?
It’s safer from direct internet inbound, but not “fully secure.” You still need correct NSGs/security lists, OS hardening, and egress controls.

5) Should I use Security Lists or NSGs?
For most scalable designs, use NSGs for app-centric segmentation. Security Lists can serve as baseline subnet-level controls.

6) Do NSG rules override Security Lists?
No. Both can apply. Traffic must be allowed by the effective set of rules. If either layer blocks, traffic is blocked.

7) What is a DRG used for?
DRG is the edge routing hub for connecting VCNs to on-prem (VPN/FastConnect) and for advanced routing topologies.

8) Do I need a DRG for a simple internet-facing web app?
Not necessarily. A simple app can use VCN + subnets + IGW/NAT. DRG is more for hybrid and multi-VCN transit routing.

9) What is the difference between NAT Gateway and Internet Gateway?
– Internet Gateway enables inbound/outbound internet for public subnets and public IPs. – NAT Gateway enables outbound-only internet for private instances without allowing inbound internet traffic.

10) Can private subnets access OCI services without internet?
Often yes, via Service Gateway (for supported services). Verify supported services per region in official docs.

11) What are the common causes of “can’t connect” in OCI networking?
Most issues come from: – missing/incorrect route rules – NSG/security list missing rules – host firewall (iptables/firewalld) blocking – wrong subnet choice (public vs private) – DNS misconfiguration

12) How do I troubleshoot blocked traffic effectively?
Use a consistent checklist: 1) route table next hop
2) NSG/security list ingress/egress
3) instance OS firewall
4) verify DNS vs IP connectivity
5) use VCN Flow Logs for evidence

13) Does OCI support IPv6 in VCNs?
OCI has IPv6 capabilities, but details vary by feature/region and require careful planning. Verify the current IPv6 docs before designing production IPv6.

14) Is traffic between VCNs encrypted by default?
VCN-to-VCN private traffic is private within OCI’s network, but encryption-at-transport is typically an application concern. Use TLS/IPSec where required by policy.

15) What is the safest way to provide admin access to private instances?
Common patterns include: – a hardened bastion host in a public subnet with strict SSH ingress rules, or – using OCI Bastion service (separate service) to avoid public SSH exposure (verify current product and region availability).

16) How do compartments help networking?
Compartments let you separate environments and apply IAM policies and budgets per environment/team, reducing blast radius and supporting governance.

17) What should I automate with Terraform first?
Start with VCN, subnets, route tables, NSGs, gateways, and compute test instances. Automating these reduces drift and improves repeatability.

17. Top Online Resources to Learn Networking

Resource Type	Name	Why It Is Useful
Official documentation	OCI Networking Overview — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/overview.htm	Canonical entry point for Networking concepts and components
Official documentation	Virtual Cloud Network (VCN) — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/virtualcloudnetwork.htm	Deep coverage of VCNs, subnets, routing, gateways
Official documentation	Security Lists — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/securitylists.htm	Subnet-level security model and rule behavior
Official documentation	Network Security Groups — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/networksecuritygroups.htm	Best practice for scalable segmentation
Official documentation	DRG (Dynamic Routing Gateway) — https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingDRGs.htm	Hybrid/transit routing foundational doc (verify latest DRG guide pages)
Official documentation	IPSec VPN — https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingIPsec.htm	Hybrid connectivity setup and concepts
Official documentation	FastConnect — https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnect.htm	Private connectivity option and architecture
Official pricing	OCI Price List — https://www.oracle.com/cloud/price-list/	Official pricing source for NAT/DRG/VPN and data transfer rules
Official cost tool	OCI Cost Estimator — https://www.oracle.com/cloud/costestimator.html	Helps model recurring gateway and data transfer costs (verify URL availability)
Official getting started	OCI Tutorials/Labs (Landing page) — https://docs.oracle.com/en-us/iaas/Content/GSG/Concepts/baremetalintro.htm	Entry point to hands-on OCI learning paths (networking labs may be linked from here)
Official CLI docs	OCI CLI Concepts — https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm	Essential for scripting and repeatable networking changes
Official architecture	OCI Architecture Center — https://docs.oracle.com/solutions/	Reference architectures including network topologies and patterns
Official free tier	Oracle Cloud Free Tier — https://www.oracle.com/cloud/free/	Understand Always Free constraints for labs
Trusted community	Oracle Cloud Infrastructure on GitHub — https://github.com/oracle/oci-cli	CLI source, issues, and examples (official repository)

18. Training and Certification Providers

The following training providers may offer courses or corporate training related to Oracle Cloud Networking and broader DevOps/cloud engineering. Verify current curricula and schedules on their websites.

DevOpsSchool.com
– Suitable audience: DevOps engineers, SREs, platform teams, cloud beginners to intermediate
– Likely learning focus: Cloud fundamentals, DevOps toolchains, cloud networking basics, automation
– Mode: check website
– Website: https://www.devopsschool.com/
ScmGalaxy.com
– Suitable audience: SCM/DevOps learners, engineers expanding into cloud operations
– Likely learning focus: DevOps practices, CI/CD, operational foundations that pair with cloud networking
– Mode: check website
– Website: https://www.scmgalaxy.com/
CLoudOpsNow.in
– Suitable audience: Cloud operations and platform operations teams
– Likely learning focus: CloudOps practices, monitoring, reliability, operational playbooks (often includes networking fundamentals)
– Mode: check website
– Website: https://www.cloudopsnow.in/
SreSchool.com
– Suitable audience: SREs, operations engineers, reliability-focused teams
– Likely learning focus: SRE practices, incident response, observability—useful for operating OCI Networking in production
– Mode: check website
– Website: https://www.sreschool.com/
AiOpsSchool.com
– Suitable audience: Ops teams adopting AIOps approaches, monitoring/automation engineers
– Likely learning focus: AIOps/automation, event correlation, operational intelligence (complements networking operations)
– Mode: check website
– Website: https://www.aiopsschool.com/

19. Top Trainers

These sites are presented as trainer/platform resources. Verify specific Oracle Cloud Networking coverage directly on each site.

RajeshKumar.xyz
– Likely specialization: DevOps/cloud training and guidance (verify specific offerings)
– Suitable audience: Individuals and teams seeking practical coaching
– Website: https://www.rajeshkumar.xyz/
devopstrainer.in
– Likely specialization: DevOps training programs; may include cloud and infrastructure topics
– Suitable audience: Beginners to intermediate DevOps practitioners
– Website: https://www.devopstrainer.in/
devopsfreelancer.com
– Likely specialization: Freelance DevOps services/training and project support (verify specifics)
– Suitable audience: Teams needing short-term expertise
– Website: https://www.devopsfreelancer.com/
devopssupport.in
– Likely specialization: DevOps support and mentoring; may include cloud operations support
– Suitable audience: Operations teams needing hands-on troubleshooting assistance
– Website: https://www.devopssupport.in/

20. Top Consulting Companies

These companies may provide consulting and implementation support. Descriptions below are intentionally neutral—verify capabilities, references, and statements of work directly with each provider.

cotocus.com
– Likely service area: Cloud/DevOps consulting and engineering support (verify offerings)
– Where they may help: Network design reviews, IaC implementation, environment standardization
– Consulting use case examples:
- Designing a hub-and-spoke VCN/DRG topology
- Implementing Terraform modules for VCN/subnets/NSGs
- Troubleshooting routing/NSG issues in production
- Website: https://www.cotocus.com/
DevOpsSchool.com
– Likely service area: DevOps and cloud consulting/training
– Where they may help: Landing zone creation, CI/CD + infrastructure automation, operations enablement
– Consulting use case examples:
- Building a repeatable OCI network baseline (VCN, subnets, NAT/IGW, NSGs)
- Governance and tagging strategy
- Operational runbooks for networking troubleshooting
- Website: https://www.devopsschool.com/
DEVOPSCONSULTING.IN
– Likely service area: DevOps consulting services (verify specific cloud coverage)
– Where they may help: DevOps transformations that include cloud infrastructure and networking practices
– Consulting use case examples:
- Migrating workloads to OCI with secure subnet design
- Implementing least-privilege NSG models
- Cost optimization for NAT/egress/logging
- Website: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

Networking fundamentals:
IP addressing, CIDR notation
routing vs firewalling
TCP/UDP, ports, stateful vs stateless filtering
NAT concepts
Linux basics for troubleshooting:
ip a, ip r, ss -lntp, curl, dig/nslookup
Cloud basics:
identity and access management concepts
regions/availability domains
infrastructure-as-code fundamentals

What to learn after this service

Hybrid networking deeper dive:
DRG route tables, routing domains, and segmentation patterns (verify latest DRG model)
IPSec VPN design, redundancy, BGP (if applicable in your setup)
FastConnect architecture and operations
Security services around networking:
WAF, Network Firewall, SIEM integrations (separate services)
OKE networking:
Kubernetes networking, service exposure patterns, ingress controllers
Automation:
Terraform for OCI networking
CI/CD for infrastructure changes
Observability and security operations:
Flow logs, centralized logging, alerting, incident runbooks

Job roles that use it

Cloud Network Engineer / Network Architect
Cloud Solutions Architect
DevOps Engineer / Platform Engineer
Site Reliability Engineer (SRE)
Security Engineer / Cloud Security Architect
Cloud Operations Engineer

Certification path (if available)

Oracle offers OCI certifications. The exact names and paths change over time, so verify current tracks on Oracle University: – Oracle University OCI certifications: https://education.oracle.com/

A practical path often looks like: 1. OCI foundations (core concepts) 2. OCI architect or infrastructure track 3. Specialize in networking/hybrid + security

Project ideas for practice

Build a 3-tier VCN (web/app/db) using NSGs only (no security lists).
Implement hub-and-spoke with DRG and two spoke VCNs; test routing and segmentation.
Enable flow logs and build a troubleshooting dashboard/report.
Create a private subnet that reaches Object Storage via Service Gateway (verify supported services and DNS behavior).
Build a “no-public-IP” policy set and audit script to detect violations.

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s IaaS platform; “Oracle Cloud” in this tutorial refers to OCI services.
Networking: OCI service area covering VCNs, routing, gateways, DRG, security controls, and connectivity.
VCN (Virtual Cloud Network): A regional, private network in OCI.
Subnet: A segment of a VCN with its own CIDR range.
Route Table: Rules that define where traffic goes based on destination.
Internet Gateway (IGW): Gateway that enables internet connectivity for public subnets.
NAT Gateway: Allows outbound internet access from private instances without inbound internet exposure.
Service Gateway: Provides private access from a VCN to selected OCI services via OCI Services Network.
DRG (Dynamic Routing Gateway): Virtual router that connects VCNs to on-prem and other networks.
Local Peering: Private connectivity between VCNs in the same region.
Remote Peering: Private connectivity between VCNs in different regions (typically via DRG).
Security List: Subnet-level stateful firewall rules.
NSG (Network Security Group): VNIC-level stateful firewall rules; enables microsegmentation.
VNIC: Virtual network interface card attached to an OCI compute instance.
Public IP: Internet-routable IP address assigned to a resource.
Private IP: Non-internet-routable address inside a VCN.
Flow Logs: Captured metadata about network flows for observability and security analysis.
VTAP: Virtual Test Access Point; traffic mirroring capability.

23. Summary

Oracle Cloud Networking is the foundation for building secure and scalable network topologies in Oracle Cloud under the Networking, Edge, and Connectivity category. It centers on the VCN and extends through subnets, route tables, gateways (IGW/NAT/Service Gateway), and enterprise connectivity via DRG, VPN, and FastConnect.

It matters because nearly every OCI workload depends on it for connectivity, isolation, segmentation, and control. The biggest cost considerations typically come from NAT/DRG/VPN usage and data egress, plus indirect costs like logging volume when flow logs are enabled. Security success depends on least-privilege IAM, careful public exposure controls, and disciplined use of NSGs and routing.

Use Oracle Cloud Networking whenever you deploy compute or private services in OCI, especially when you need multi-tier segmentation or hybrid connectivity. Start next by learning DRG routing patterns, service gateway/private access, and Terraform automation to make your network repeatable and production-ready.

rajeshkumar

Category