Learning bite
VPC networking and DNS
Trace VPC routes, traffic controls, and DNS before choosing compute or storage.
AWS
Predict before you try
Checkpoint: can you prove a subnet is public by its name?
Try it: Turn a network drawing into reachable paths →On this page
Turn a network drawing into reachable paths
A VPC is a logically isolated regional virtual network. Its CIDR range describes an address block, such as the illustrative 10.40.0.0/16. A subnet occupies one Availability Zone and receives part of that range. Plan non-overlapping ranges when networks may later connect; a convenient subnet name does not establish connectivity or privacy.
A route table decides where traffic for a destination goes. An internet gateway connects a VPC to the internet. For the usual IPv4 design, a public subnet has a route to that gateway, but an instance also needs suitable addressing and traffic permissions to be directly reachable. A route alone does not publish every resource.
A private application's outbound internet traffic can use a NAT gateway, depending on its routing design. NAT is not an application firewall or free unlimited egress. VPC endpoints can provide private paths to supported AWS services; endpoint policy and service permissions still apply.
Separate routing from traffic permission
Security groups are stateful allow-rule controls associated with resources through network interfaces. Network ACLs apply at subnet level and are stateless, with ordered allow and deny rules. Return traffic therefore needs different reasoning for each mechanism. Neither replaces TLS, IAM, or database authentication.
Work through this proposed application path without deploying it:
| Caller | Destination | Intended access |
|---|---|---|
| Browser | Public application entry | HTTPS on 443 |
| Load balancer | API instances | Only the application's listening port |
| API | Database | Database port from the intended application callers |
| API | Messaging API | HTTPS with an authorized service identity |
A database need not accept traffic from the whole internet just because the application has public users. A security-group reference can express a permitted resource group, while routing must independently provide a path. Write both decisions on your diagram.
DNS names do not carry network permissions
Route 53 provides DNS hosting and related routing features. A record maps a name to an answer; it does not open a security group, create an application listener, or make an unhealthy target healthy. An alias record can point to supported AWS targets without treating a load balancer's changing IPs as permanent addresses.
For a failed request, ask in order: did the name resolve to the intended destination, is there a route, do network controls allow the exchange, is a process listening, and does the application accept the request? A successful DNS lookup answers only the first question.
Inspect or annotate
With the authorized learning profile, choose your actual permitted Region and substitute it for YOUR_REGION:
aws ec2 describe-vpcs --profile learning --region YOUR_REGION
aws ec2 describe-subnets --profile learning --region YOUR_REGION
These are reads, requiring the corresponding permissions. Match each subnet's VPC ID, CIDR, and zone. An empty response may be legitimate. A denied response is a limit on observation, not evidence that no network exists. Without access, draw two subnets in different zones and label the design as proposed.
Checkpoint: can you prove a subnet is public by its name? No; inspect routing and then the resource's addressing and controls. Can a route to S3 prove the application may read a bucket? No; network reachability and authorization are separate.
Next, place compute and a load balancer into this drawing. Leave creation for later deliberately scoped infrastructure work.
References: VPC fundamentals↗, security groups↗, network ACLs↗, and Route 53 alias records↗.
Additional primary references: S3 object model↗, EBS volumes↗.
Prove what you learned
Inspect the result
Retain account/region or the explicit local/design label, the intended path and a denied or missing check.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one caller, region or proposed dependency on paper and identify which checks must change.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Turn a network drawing into reachable paths”.
- Retain account/region or the explicit local/design label, the intended path and a denied or missing check.
- Explain the transfer challenge and retain the same verification question.
Hint
Name the environment enforcing each identity and permission decision.
Answer guide: compare after predicting
No; inspect routing and then the resource's addressing and controls. Can a route to S3 prove the application may read a bucket
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall DNS, routing and effective identity from Systems Foundations. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.