DevOps Networking

Networking is the invisible backbone of every DevOps system. Applications communicate over networks, traffic flows through load balancers, DNS resolves service names, and firewalls control access. A DevOps engineer who understands networking can troubleshoot connectivity issues, design secure architectures, and configure cloud infrastructure with confidence.

Core Networking Concepts

IP Addresses

Every device on a network has an IP address — a unique identifier. IPv4 addresses look like 192.168.1.100. IPv6 addresses are longer: 2001:db8::1. In cloud environments, servers typically have two addresses:

• Private IP: Used for internal communication within the VPC (e.g., 10.0.1.45). Never exposed to the internet.
• Public IP: Used for internet-facing communication (e.g., 54.200.100.30). Only for resources that need to be reachable externally.

CIDR Notation

CIDR (Classless Inter-Domain Routing) defines a range of IP addresses. The number after the slash indicates how many bits are fixed:

10.0.0.0/8       # 16,777,214 addresses (10.0.0.1 – 10.255.255.254)
10.0.0.0/16      # 65,534 addresses (10.0.0.1 – 10.0.255.254)
10.0.1.0/24      # 254 addresses (10.0.1.1 – 10.0.1.254) — typical subnet
10.0.1.0/28      # 14 addresses — small subnet for a few servers
0.0.0.0/0        # All IP addresses (used in security groups for "any")

DNS (Domain Name System)

DNS translates human-readable domain names into IP addresses. When a browser navigates to myapp.com, DNS resolves it to an IP like 54.200.100.30. Key DNS record types:

Ports and Protocols

Ports identify specific services on a server. Protocols define the rules for communication. Common ports every DevOps engineer knows:

TCP vs UDP

Load Balancing

A load balancer distributes incoming traffic across multiple servers. This prevents any single server from being overwhelmed and provides high availability — if one server fails, traffic routes to the others.

Load Balancing Algorithms

• Round Robin: Sends each request to the next server in sequence. Simple and fair for equal servers.
• Least Connections: Sends traffic to the server with the fewest active connections. Better for requests with varying duration.
• IP Hash: Routes the same client IP always to the same server. Useful when session stickiness is required.
• Weighted Round Robin: Servers with higher capacity receive proportionally more traffic.

Layer 4 vs Layer 7 Load Balancing

• Layer 4 (Transport): Forwards traffic based on IP address and TCP port. Fast but no application-level intelligence.
• Layer 7 (Application): Reads HTTP headers, paths, and cookies to make routing decisions. Routes /api/ to backend servers and /static/ to storage. AWS ALB and Nginx operate at Layer 7.

Nginx as Reverse Proxy and Load Balancer

upstream webapp_backend {
    least_conn;
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
    server 10.0.1.12:3000;
}

server {
    listen 80;
    server_name myapp.com;

    # Redirect all HTTP to HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name myapp.com;

    ssl_certificate     /etc/ssl/certs/myapp.crt;
    ssl_certificate_key /etc/ssl/private/myapp.key;

    location / {
        proxy_pass http://webapp_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /static/ {
        root /var/www/;
        expires 30d;
    }
}

TLS/SSL – Encrypting Traffic

TLS (Transport Layer Security) encrypts data in transit. HTTPS = HTTP over TLS. Every production application must use HTTPS. Plain HTTP is unacceptable — passwords, tokens, and data sent over plain HTTP can be intercepted.

How TLS Works (Simplified)

1. Client connects to server and asks for its certificate.
2. Server sends its TLS certificate (issued by a trusted Certificate Authority).
3. Client verifies the certificate is valid and trusted.
4. Both sides negotiate an encryption key using asymmetric cryptography.
5. All subsequent communication is encrypted with that key.

Cert-Manager – Automated Certificates in Kubernetes

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: myapp-tls
  namespace: production
spec:
  secretName: myapp-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - myapp.com
    - www.myapp.com

Cert-Manager automatically requests, renews, and manages Let's Encrypt certificates — free TLS certificates that auto-renew every 90 days.

VPC Networking in AWS

A Virtual Private Cloud (VPC) is a logically isolated network in AWS. All resources — EC2 instances, RDS databases, ECS containers — live inside a VPC.

Standard Three-Tier VPC Design

VPC: 10.0.0.0/16
│
├── Public Subnets (internet-facing)
│   ├── 10.0.1.0/24 (us-east-1a) — Application Load Balancer, NAT Gateway
│   └── 10.0.2.0/24 (us-east-1b) — Application Load Balancer (HA)
│
├── Private App Subnets
│   ├── 10.0.11.0/24 (us-east-1a) — EC2 / ECS application servers
│   └── 10.0.12.0/24 (us-east-1b) — EC2 / ECS application servers (HA)
│
└── Private DB Subnets
    ├── 10.0.21.0/24 (us-east-1a) — RDS primary
    └── 10.0.22.0/24 (us-east-1b) — RDS read replica / standby

Internet Gateway vs NAT Gateway

• Internet Gateway: Allows resources in public subnets to communicate with the internet directly (both inbound and outbound).
• NAT Gateway: Allows resources in private subnets to make outbound internet requests (e.g., download packages) without being directly reachable from the internet. Inbound traffic is blocked.

Network Troubleshooting Commands

# Test connectivity to a host
ping 8.8.8.8

# Trace the route packets take to a destination
traceroute google.com

# Check DNS resolution
nslookup myapp.com
dig myapp.com A

# Test if a port is open on a remote host
telnet 10.0.1.10 3306
nc -zv 10.0.1.10 3306

# View active connections and listening ports
netstat -tuln
ss -tuln

# Capture network packets (powerful for debugging)
tcpdump -i eth0 port 80 -n

# Make an HTTP request and see full headers
curl -v https://myapp.com/health

Service Discovery in Kubernetes

In Kubernetes, services find each other by name — not by IP address. Kubernetes runs an internal DNS server (CoreDNS). Every Service object gets a DNS name automatically:

# Service name format:
# service-name.namespace.svc.cluster.local

# A pod in the "production" namespace can reach the payment service at:
http://payment-service.production.svc.cluster.local:8080

# Within the same namespace, just the service name works:
http://payment-service:8080

Summary

• IP addresses, CIDR ranges, ports, and protocols are fundamental networking knowledge for every DevOps engineer.
• DNS translates domain names to IP addresses — understanding record types helps debug routing issues.
• Load balancers distribute traffic across servers for performance and high availability.
• TLS encrypts all production traffic — Cert-Manager automates certificate management in Kubernetes.
• VPCs with public, private app, and private DB subnets form the standard secure cloud network architecture.
• Network troubleshooting commands — ping, dig, curl, netstat, and tcpdump — are daily tools for diagnosing connectivity issues.