AWS / Basic: cloud scope and core boundaries / Lesson 3
VPC routing and network controls
Trace addressing, routes, gateways, stateful security groups, and stateless subnet controls as separate connectivity decisions.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of vpc routing and network controls.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
A subnet has placement and routing context
A VPC defines a virtual network boundary with addressing and routing configuration. Subnets occupy Availability Zones under the selected VPC model, and route-table association helps determine reachable destinations. Public and private describe a routing design, not an automatic trust or data classification. A resource in a subnet called public is not necessarily reachable from the internet, and a private subnet still needs deliberate egress and service access. Record address family, caller context, destination, route association, and intended protocol before changing a rule. The lesson uses ordinary commercial VPC concepts rather than every specialized networking offering.
Separate a route from internet exposure
For ordinary IPv4 internet reachability, route, gateway, addressing, and traffic controls must align. An internet-gateway route alone does not assign a public address or open a listener. A NAT path can enable outbound initiation from private workloads under its configured offering and does not generally publish those workloads for unsolicited inbound connections. IPv6 and egress-only designs have different assumptions. The first synthetic path record states each boundary without creating a gateway. Confirm the chosen NAT or endpoint mode, placement, resilience, and charging dimensions in current documentation rather than applying one topology to all services.
caller: synthetic-private-application
destination: approved-public-HTTPS-dependency
address_family: IPv4
path: private-route-to-reviewed-NAT-design
required: DNS-routes-security-controls-return-path-and-TLS
inbound_publication: not-established
The record lists requirements and deliberately makes no real connectivity claim. NAT design and pricing are not inferred, and no network resource is created.
Read security groups and ACLs differently
Security groups are stateful resource-level allow controls, while network ACLs are ordered subnet-level allow and deny controls with stateless return-path considerations. A security group rule does not replace a route, DNS result, operating-system firewall, or application listener. A group reference has documented semantics and is not a universal proxy for every traffic path. The second matrix distinguishes initial flow and response evidence. Review both directions for stateless controls and the actual ports used by the client and server. Do not solve a narrow failure by opening every address and port to the internet.
boundary question
route table is there an intended destination path?
security group is the resource flow allowed?
network ACL do ordered rules permit both stateless directions?
process and local OS is the intended listener available?
IAM or service policy is the requested operation authorized?
A pass at one layer does not prove the others. Security-group state tracking and ACL rule evaluation require their documented context, not identical rule copying.
Include DNS and service endpoints
VPC DNS settings, private hosted zones, resolver paths, and endpoint-specific private DNS can change which address a name returns. VPC endpoints can provide private access to supported services, but endpoint type, routes, security controls, policy, and service support matter. Reaching an AWS service privately does not automatically grant IAM permission or KMS access. A correct TLS identity remains necessary at the application protocol layer. Diagnose name resolution, transport, and authorization separately. Flow logs can provide selected traffic metadata when configured, but they are not packet payloads or a complete explanation of every missing connection.
Verify a bounded connection contract
Define allowed source, destination, protocol, port, identity, and user outcome, then verify both intended and prohibited paths in an authorized isolated environment. Preserve safe context before repair and keep network policy changes in review. This course performs no resolver lookup, packet capture, flow-log query, port test, cloud request, or route modification. Static records cannot prove actual reachability. A network diagram is useful only when its assumptions about address, route, controls, return traffic, and service authorization are explicit and current; naming a subnet private is not a security assessment or an availability guarantee.
Common errors and fixes
A gateway route is called public access
- Why it happens
- Address assignment and other controls were omitted.
- How to fix it
- Trace the complete intended flow and listener.
- Prevent it next time
- Document route, address, and control assumptions separately.
Return traffic fails through a subnet ACL
- Why it happens
- Stateless response rules were not considered.
- How to fix it
- Review ordered inbound and outbound rules with actual ports.
- Prevent it next time
- Test expected responses as well as initiation.
A private endpoint is assumed to grant data access
- Why it happens
- Network path and service authorization were conflated.
- How to fix it
- Inspect endpoint, identity, resource, and encryption policies.
- Prevent it next time
- Separate connectivity and permission evidence.
Check your understanding
1. A private instance uses a NAT path for outbound HTTPS. Is it thereby an inbound public web server?
Show worked solution
No. Outbound initiation and unsolicited inbound publication are separate contracts. Verify the exact NAT offering, route, addresses, and controls. Public application exposure normally needs a separately reviewed ingress design and application authorization.
2. DNS succeeds but TCP times out. Should IAM be widened first?
Show worked solution
Not from that evidence. Inspect the selected destination, routes, security groups, ACLs, listener, and return path within authorized scope. IAM changes do not generally repair a missing transport connection and can add unnecessary privilege while leaving the original fault intact.
Key takeaways
- A VPC defines a virtual network boundary with addressing and routing configuration.
- Security groups are stateful resource-level allow controls, while network ACLs are ordered subnet-level allow and deny controls with stateless return-path considerations.
- Define allowed source, destination, protocol, port, identity, and user outcome, then verify both intended and prohibited paths in an authorized isolated environment.