Amey-Thakur Cloud networking
Default-deny is the design stance: nothing reaches the internet, another VPC, or your data stores unless a rule you wrote says so. Everything else is plumbing to make that stance livable.
Method
- Plan address space before the first VPC. Non-overlapping CIDRs across VPCs, regions, and the office/VPN ranges, sized with 4x growth headroom, recorded in one registry. Overlaps discovered at peering time cost re-IP projects; ten minutes of spreadsheet now prevents them.
- Tier subnets by exposure. Public subnets hold only entry points (load balancers, NAT); private subnets hold compute; isolated subnets hold data stores with no internet path at all. Workloads never get public IPs; inbound flows through the LB, outbound through NAT (watch its processing cost; see cloud-cost-optimization).
- Prefer identity rules over IP rules. Security groups referencing other security groups ("db-sg allows app-sg on 5432") survive autoscaling and re-IPs; CIDR-based rules rot. Keep NACLs at coarse subnet guardrails; per-flow logic lives in security groups where state is handled for you.
- Reach managed services privately. Private endpoints/Private Link for object storage, queues, and third-party SaaS keep traffic off the public internet and let isolated subnets function; they also carry per-GB cost, so hubs share endpoints where volume justifies.
- Scale inter-VPC with a hub, not a mesh. Two or three VPCs: peering is fine. Beyond that, a transit hub (transit gateway pattern) centralizes routing, on-prem VPN/Direct Connect attachment, and egress inspection; peering meshes grow O(n^2) route tables that nobody can audit.
- Treat DNS as the service map. Private zones per environment
(
svc.internal), records managed by IaC alongside the services; split-horizon so internal names never leak to public resolvers. Connectivity debugging order: DNS resolution, then security group, then route table, then endpoint policy; flow logs answer the "is it even arriving" question.
Boundaries
- This is L3/L4 topology; service-to-service authn/z and mTLS live a layer up (see service-mesh-tradeoffs, zero-trust-basics), and network segmentation does not replace them.
- Kubernetes overlays its own networking (CNI, services, ingress) on top of this; pod-level policy is a separate control plane (see kubernetes-workloads).
- Multi-region topology (failover, data locality) is driven by multi-region-design; do not build global network plumbing ahead of a decided architecture.