My personal website 1

Introduction

When deploying software to a public cloud like Oracle Cloud Infrastructure (OCI), AWS, or GCP, virtual machines do not start out connected to the internet. By default, they are completely isolated inside an enclosed, private environment.

For an engineer transitioning from local development into production operations (and moving along the path toward DevSecOps), understanding how a server transitions from isolation to public visibility is a fundamental networking requirement.

This post details the underlying infrastructure architecture required to provision, route, and safeguard a cloud Virtual Private Server (VPS) so it can reliably serve web traffic.

1. The Foundation: The Virtual Cloud Network (VCN)

Before a virtual machine can exist, a network framework must be established. In modern cloud environments, this is known as a Virtual Cloud Network (VCN) or Virtual Private Cloud (VPC).

A VCN is a software-defined, isolated network environment provisioned within a cloud provider’s data center. It utilizes Classless Inter-Domain Routing (CIDR) blocks (such as 10.0.0.0/16) to divide a large, private block of internal IP addresses into smaller allocations called Subnets.

To make a virtual machine public, it must be attached to a designated Public Subnet. This attachment is executed via a Virtual Network Interface Card (VNIC) linked directly to the compute instance.

2. The Core Infrastructure Mechanics

To bridge a private VCN to the global internet backbone, three separate networking components must be bound together:

[ Public Internet ] ◄────► [ Internet Gateway (IGW) ] ◄────► [ Route Table (0.0.0.0/0) ] ◄────► [ Public Subnet / VM ]

 

A. The Internet Gateway (IGW)

An Internet Gateway is a highly available, software-defined router element attached to the edge of the VCN. It acts as the physical exit and entry point for all network traffic. Without an IGW, packages sent from a VM have no path to leave the cloud provider's physical data center.

B. Route Table Modification

A public subnet must know where to send traffic destined for the outside world. This is achieved by appending an explicit rule to the subnet's Route Table:

• Destination CIDR: 0.0.0.0/0 (representing all possible external IPv4 addresses).

• Target: Internet Gateway.

This rule acts as a default gateway instruction: any network traffic not destined for a machine inside the internal VCN is automatically directed out through the Internet Gateway.

C. Static Network Address Translation (Static NAT)

When the VM is provisioned, the cloud orchestration engine assigns it a private IP from the subnet pool (e.g., 10.0.0.x). To communicate externally, the VNIC must be assigned a globally routable Public IPv4 Address.

The cloud provider implements Static NAT, mapping the public IP directly to the VM’s private IP at the gateway layer. The operating system inside the VM remains completely unaware of its public IP; it handles internal packets, while the cloud infrastructure seamlessly manages the external translations.

3. Perimeter Security: State-Based Firewalls

Exposing a machine directly to the internet makes it an immediate target for automated scans. Security must be enforced outside the operating system layer. Cloud providers handle this using Security Lists or Network Security Groups (NSGs).

A Security List acts as an external firewall operating at the network transport layer (Layer 4). It intercepts every incoming and outgoing packet before it ever reaches the VM's virtual hardware interface.

Production Security List Architecture

For a standard web-serving infrastructure, the Security List enforces a strict protocol filter using a set of Ingress Rules (traffic coming in). In this architectural blueprint, the source is set to 0.0.0.0/0 (the entire internet), and specific destination ports are targeted:

• Port 22 (SSH): Allows secure administrative CLI access. In an enterprise environment, this is strictly locked down to a trusted corporate IP range rather than being left fully public.

• Port 80 (HTTP) & Port 443 (HTTPS): Standard ports exposed to the public internet to accept incoming web traffic.

• Port 81: Reserved for administrative proxy dashboards.

• Port 5000: Exposed during the initial testing phases to verify application responses directly.

The Power of Stateful Inspection

Most cloud security lists are stateful. This means when an ingress rule permits an incoming connection (such as a user hitting port 443), the firewall automatically remembers that connection state. It allows the return traffic to flow back out to the user freely, completely bypassing the egress rules.

Conclusion: Defense in Depth

By engineering my perimeter using software-defined cloud firewalls, I practice a fundamental DevSecOps principle: Defense in Depth.

Even if I accidentally spins up an unhardened service inside the operating system, unauthorized external users cannot exploit it because the cloud security list drops the malicious packets at the network boundary, far away from my running server.

Comment