Network Security in the Cloud

Network Security in the Cloud

In traditional data centers, the network perimeter was a physical firewall at the building edge. In the cloud, that model collapses: every service can reach every other service by default unless you explicitly prevent it. Network security in the cloud is therefore a deliberate, policy-driven act — you must segment, constrain, and monitor every traffic path, or attackers who compromise one pod or function will pivot freely across your entire estate.

This lesson covers the three pillars of cloud network security: segmentation (who may talk to whom), private endpoints (keeping data paths off the public internet), and egress control (preventing outbound exfiltration or C2 callbacks). We close with a production zero-egress architecture diagram.

Segmentation: Micro-Perimeters at Every Layer

Segmentation means dividing your network into zones where each zone has the minimum connectivity it needs. In AWS, the building blocks are VPCs, subnets, Security Groups (SGs), and Network ACLs (NACLs). In Kubernetes, the equivalent is Network Policies enforced by a CNI plugin (Cilium, Calico, or AWS VPC CNI with Kubernetes Network Policy support).

The segmentation hierarchy in a mature AWS environment looks like this:

• Account-level isolation — production, staging, and tooling live in separate AWS accounts under an AWS Organization. Cross-account traffic routes through Transit Gateway or PrivateLink, never the public internet.
• VPC segmentation — each environment gets its own VPC. Peering is explicit and route-table-scoped; full-mesh peering is a sign of missing design.
• Subnet segmentation — public (load balancers), private application (compute), and isolated data (RDS, ElastiCache, OpenSearch) subnets. Data subnets have no route to the internet, period.
• Security Group rules — the instance-level micro-firewall. Stateful, default-deny. Reference SG IDs rather than CIDRs for internal traffic so rules don't break when IPs rotate.
• Kubernetes Network Policies — pod-level firewall inside the cluster.

Here is a production-grade Kubernetes Network Policy that gives a payments pod only the ingress it needs — traffic from the api-gateway namespace on port 8443 and from Prometheus for scraping:

Private Endpoints: Keeping Data Off the Public Internet

When an EC2 instance calls the S3 API, by default that traffic leaves your VPC, traverses the public internet, hits an S3 public IP, and returns. This means your data crosses infrastructure you don't control, your egress bandwidth is metered, and you need to open outbound HTTPS in your Security Group to 0.0.0.0/0 — the worst possible rule.

VPC Endpoints (AWS) solve this. A Gateway Endpoint keeps S3 and DynamoDB traffic inside the AWS backbone, free of charge. An Interface Endpoint (PrivateLink) provisions an ENI in your subnet for almost every other AWS service — SQS, SSM, ECR, Secrets Manager, RDS Data API, CloudWatch Logs, and more. The traffic never leaves the Amazon network, latency drops, and you can lock down Security Groups to deny outbound 443 to the internet entirely.

Egress Control: The Last Line Before Exfiltration

Egress filtering is the most commonly skipped network control in cloud environments — and the one attackers rely on most. Ransomware staging, cryptominer C2 callbacks, and data exfiltration all require outbound connectivity. If you allow unrestricted outbound HTTPS from compute, a compromised container can silently call home for months.

Production egress architecture:

• All outbound internet traffic is forced through a managed egress proxy (AWS: NAT Gateway + a DNS-based filtering layer such as AWS Network Firewall or a self-managed Squid cluster; GCP: Cloud NAT + Cloud Armor; Azure: Azure Firewall with FQDN rules).
• The proxy enforces an allowlist of FQDNs — not IP CIDRs, since major cloud providers rotate IPs constantly. Only the specific hostnames your services actually need are permitted.
• Kubernetes workloads that need no internet access get Network Policies that deny all egress except to cluster-internal services and VPC endpoints. Workloads that legitimately need internet access are isolated in a dedicated node pool / namespace with extra audit logging.

Implementing the Zero-Egress Pattern

Here is the AWS Network Firewall Terraform rule group that enforces the FQDN allowlist at the VPC level. This is a stateful rule group — it inspects SNI in TLS handshakes, so it works for HTTPS without decryption:

Production Failure Modes

• Missing kube-dns egress in Network Policy — pods cannot resolve service names. Always include UDP/53 egress to kube-dns in any custom policy or resolution silently fails.
• Interface Endpoint in wrong AZ — if your endpoint ENI is only in us-east-1a but your pods run in us-east-1b, cross-AZ latency spikes and costs accumulate. Deploy endpoints in every AZ your nodes use.
• FQDN allowlist not covering CDN hostnames — vendors often serve SDK updates from rotating CDN FQDNs (*.cloudfront.net, *.fastly.net). Wildcard rules on Network Firewall must be used deliberately and scoped as narrowly as possible.
• Security Group egress 0.0.0.0/0 left open — the Terraform AWS provider creates this rule by default. Use create_before_destroy lifecycle blocks and explicit egress rules to remove it.