Cloud-Native Networking: VPC Design, Transit Gateways, and Service Meshes Working in Concert
TL;DR VPC design with segmented subnets is the foundation of every secure cloud architecture. Transit Gateway connects hundreds of VPCs and on-premises networks via a central hub. PrivateLink enables access to services …
TL;DR
- VPC design with segmented subnets is the foundation of every secure cloud architecture.
- Transit Gateway connects hundreds of VPCs and on-premises networks via a central hub.
- PrivateLink enables access to services without internet exposure.
- Kubernetes Network Policies implement microsegmentation at the pod level.
- Multi-account strategies – with separate VPCs per environment – limit blast radius.
Network design in the cloud is fundamentally different from on-premises. Instead of physical switches and routers, you define virtual networks as code – more flexible, yet more prone to error. Misconfigured security groups, overly broad CIDR blocks, and missing segmentation are the most common causes of cloud security incidents. Get your VPC design right, and you’ve completed 80% of your security work.
VPC Design: Laying the Foundations Correctly
A VPC (Virtual Private Cloud) is an isolated network within the cloud. Design decisions made during its creation determine security and flexibility for years to come. Three core rules: First, plan CIDR blocks generously – a /16 (65,536 IPs) per VPC, and a /24 per subnet. Expanding them later is severely limited. Second, strictly separate public and private subnets. Only load balancers and bastion hosts belong in public subnets. Third, deploy across at least three Availability Zones for high availability.
Multi-account strategies – using AWS Organizations or Azure Management Groups – physically isolate environments (Production, Staging, Dev) into separate accounts, each with its own VPC. A breach in the Dev environment cannot propagate to Production.
Transit Gateway: The Central Network Hub
In enterprise environments with 50-500+ VPCs, peer-to-peer networking becomes unmanageable. AWS Transit Gateway, Azure Virtual WAN, and GCP Network Connectivity Center act as central hubs: All VPCs and on-premises networks connect to the hub, not directly to each other.
Transit Gateway enables: centralized routing between VPCs; VPN termination for on-premises connectivity; inter-region peering for multi-region deployments; and route tables for granular traffic steering. Pricing starts at USD 0.05/hour plus data processing fees – more cost-effective and operationally simpler than managing hundreds of individual VPC peering connections.
PrivateLink and VPC Endpoints
By default, API calls to AWS services (S3, DynamoDB, SQS) traverse the public internet. VPC Endpoints and PrivateLink keep that traffic entirely within the AWS backbone. Gateway Endpoints (free for S3 and DynamoDB) and Interface Endpoints (for all other services) provision private IP addresses inside your VPC.
PrivateLink also enables private access to third-party services – and to your own services hosted in other AWS accounts – without internet exposure, without NAT gateways, and without public IPs. For compliance-critical workloads, PrivateLink is mandatory.
DNS and Service Discovery in the Cloud
Route 53 Private Hosted Zones (AWS), Azure Private DNS, and GCP Cloud DNS Private Zones support internal DNS resolution within VPCs. Services are addressed by DNS name – not IP address – essential in dynamic cloud environments where IPs change frequently.
In Kubernetes, CoreDNS handles service discovery: Every service automatically receives a DNS name (e.g., service-name.namespace.svc.cluster.local). ExternalDNS automatically synchronizes Kubernetes services with Route 53 or Cloud DNS to enable external reachability.
Network Security: Defense in Depth
Cloud network security follows a layered model: Security Groups (stateful firewall at the instance level) → Network ACLs (stateless firewall at the subnet level) → WAF (application-layer protection at the load balancer) → Network Policies (pod-to-pod enforcement in Kubernetes) → Service Mesh (mTLS and authorization between microservices).
The cardinal rule: Deny by default. Every security group starts with zero inbound rules. Every Network Policy blocks all traffic until explicit allow rules are defined. Only expose what is strictly required.
Read more on cloudmagazin.com
- Data Mesh in Practice: Decentralized Data Architecture for Cloud-Native Enterprises
- Cloud-Native Identity: OAuth 2.1, Passkeys, and the Future of Authentication
- AI Boom Drives Cloud Service Market – Europe Lags Behind
More on the topic: More articles on mybusinessfuture
Frequently Asked Questions
How many VPCs should an organization have?
At minimum, three: Production, Staging, and Development – ideally deployed in separate AWS accounts. Large enterprises often operate 50-500+ VPCs, organized by business unit, environment, and compliance requirements. More VPCs mean stronger isolation – but also greater operational overhead.
What does a NAT Gateway cost?
AWS NAT Gateway: USD 0.045/hour (~USD 33/month), plus USD 0.045/GB for data processing. With high outbound traffic volumes, costs can escalate quickly. Alternatives include NAT Instances (lower cost, but self-managed), VPC Endpoints (eliminate NAT for AWS service traffic), or dual-stack IPv6 (no NAT required).
Is Transit Gateway necessary for small deployments?
No. For 2-5 VPCs, VPC Peering (free, direct connection) is sufficient. Transit Gateway becomes cost-effective and operationally justified starting at ~10+ VPCs – or when on-premises connectivity and centralized routing are required.
How do you segment networks in Kubernetes?
Network Policies (via Calico, Cilium, etc.) define which pods may communicate with which others. Namespace-based isolation is the natural entry point: Pods in different namespaces cannot communicate unless an explicit Network Policy permits it.
What’s the difference between Security Groups and Network ACLs?
Security Groups are stateful (return traffic is automatically allowed), operate at the instance level, and support only allow rules. Network ACLs are stateless (return traffic must be explicitly allowed), operate at the subnet level, and support both allow and deny rules. In practice, Security Groups suffice for most use cases.
Header Image Source: Pexels / Brett Sayles
