A virtual network provides an isolated address and routing domain. Subnets divide that domain by location and purpose. Route tables decide where packets can travel, while gateways and security controls govern connections to other networks. A sound design starts with required flows, assigns non-overlapping addresses, and makes public reachability explicit.
Who this is for: Application developers and platform engineers who need to design or review a practical cloud network without becoming network specialists.
- Model required traffic flows before choosing subnet names, address ranges, or gateways.
- Use routing for reachability and security controls for permission; neither replaces the other.
- Reserve address capacity and test return paths so future growth does not require emergency renumbering.
Start with packets and boundaries
A virtual cloud network gives resources private addresses and a controlled routing environment. An address range written in CIDR notation defines how many addresses belong to it. A subnet takes a smaller range from that network and usually belongs to one zone. Subnets are useful boundaries for placement, routing, and applying consistent controls to groups of resources.
Public and private are architectural properties, not reliable names. A subnet becomes internet-reachable only when routes, a gateway, resource addressing, and security rules all permit the flow. Conversely, a private workload may still initiate outbound connections through managed translation or reach cloud services through private endpoints. Document the complete path in both directions.
Plan addresses for change
Choose a network range that does not overlap networks it may later connect to, including offices, partners, other cloud environments, and acquired systems. Divide space by environment, zone, and workload purpose with room for growth. Managed services can consume more addresses than expected during scaling or maintenance, so do not size solely from today's instance count.
Keep an address plan with owners and allocation status. Avoid scattering arbitrary ranges across project files. IPv4 scarcity may influence the plan, while IPv6 introduces different addressing and egress patterns that require explicit controls. Use provider calculators or reviewed tooling for CIDR arithmetic instead of mental estimates in a production change.
Read a route decision
A route table matches a destination address and selects a target such as the local network, internet gateway, translation gateway, peering connection, transit service, or private endpoint. More specific routes generally win. A route creates a possible path; it does not by itself grant application permission or prove that the return path exists.
Troubleshooting should follow the packet. Record source address, destination address, port, protocol, expected route, security policy, name resolution, translation, and return route. Asymmetric paths can break stateful firewalls. Overlapping ranges can make the intended destination unreachable. Flow logs help confirm accepted and rejected traffic but should be handled according to logging and privacy policy.
Design controlled connectivity
Place internet-facing entry points in deliberately routed subnets and keep application or data resources without direct public paths unless a documented requirement says otherwise. Prefer private service endpoints when they reduce unnecessary traversal. Apply least-privilege security groups or equivalent controls based on workload identity and required ports, not broad address ranges copied from examples.
Validate changes in stages. Review the proposed route and policy diff, test from a disposable client, confirm expected connections, and confirm a prohibited connection remains blocked. Never remove an active route or gateway as a casual diagnostic. Have console access, rollback steps, and an owner available before modifying the path used to administer the environment.
Lay out a small three-tier network
A team needs public HTTPS entry, private application workers, and a database with no direct internet route across two zones.
- List required flows: users to load balancer, load balancer to application, application to database, and controlled outbound updates.
- Allocate non-overlapping subnet ranges for each tier in both zones and leave unassigned address space for expansion.
- Attach only entry subnets to an internet route, give workers approved egress, and keep database subnets on local and required private routes.
- Apply narrow security rules, then test allowed and denied flows from controlled clients while checking route and flow-log evidence.
Network flow matrix
Use this matrix before creating routes or opening ports.
- Source workload, source subnet, destination workload, destination address, port, and protocol.
- Business reason, data sensitivity, direction, expected frequency, and accountable owner.
- DNS name, route-table match, gateway or endpoint, translation, and return path.
- Security rule, logging location, validation command, and expected allowed or denied result.
- Address allocation, future capacity, overlap check, and decommission trigger.
Common mistakes
- Calling a subnet private based only on its name while it still has a complete public path.
- Using overlapping address ranges that later prevent routing between environments.
- Opening a broad inbound range to solve a route problem without tracing the actual packet path.
Try one
An application cannot reach a private database after a network change. Describe a safe troubleshooting order that distinguishes routing from permission failures.
A good answer records source and destination details, verifies name resolution, checks the matching forward and return routes, then checks workload and subnet security controls plus flow logs. It uses a controlled test client and read-only inspection first. It does not add a public route or allow all traffic as an exploratory fix.
Sources
- Amazon VPC documentationOfficial AWS introduction to virtual networks, subnets, routing, gateways, and network controls.
- Kubernetes Services documentationOfficial Kubernetes explanation of stable network endpoints and Service discovery for Pods.