AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 5“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Networking Fundamentals for AWS

Signed API calls from [AWS CLI, SDKs and Infrastructure Access](/learn/aws-cloud-devops-engineering/aws-cli-sdks-and-infrastructure-access) still need a path. On the Friday before

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Networking Fundamentals for AWS

AWS Cloud & DevOps Engineering · Lesson 05 · AWS Cloud Foundations

Lesson Overview

Signed API calls from AWS CLI, SDKs and Infrastructure Access still need a path. On the Friday before enrollment week, TechLearningPro’s staging progress API could resolve DNS, presented a valid certificate, and still timed out from the load balancer. The security group allowed the port. The route table for the app subnet had no default route to a NAT gateway for package pulls during boot, and a mistaken mental model of “private subnet means no routing needed” left the ASG replacing instances forever. The Monday board was not even in scope; the player itself was dark for internal testers.

This lesson rebuilds the networking vocabulary AWS VPC design assumes: IP addressing, CIDR notation, subnetting, routing, DNS, NAT, gateways, and segmentation. You will plan address ranges and traffic flows for a three-tier application that hosts the lesson player APIs and keeps databases off the public internet. Amazon VPC Architecture turns the plan into VPC objects. Security Groups, NACLs and VPC Connectivity attaches filters. Here you learn enough IP and routing to refuse magical thinking.

Planning assumptions:

Primary Region from lesson 1; at least two AZs for production-shaped designs.
RFC1918 private addressing for VPC CIDRs; no overlapping CIDRs across accounts you intend to connect later.
Illustrative address plans use common private ranges; adapt to your company’s IPAM rules.
Do not invent AWS quota numbers; check Service Quotas when limits matter.

Learning Objectives

By the end of this lesson you will be able to:

Explain IPv4 addressing and CIDR prefix lengths well enough to size subnets for TechLearningPro tiers.
Separate public versus private connectivity intent before placing resources.
Describe how routing decisions use longest prefix match and why a missing default route breaks private subnets differently than public ones.
Explain DNS resolution roles for learners, for service discovery inside a VPC, and for AWS API endpoints.
Distinguish NAT gateways, internet gateways, and VPC endpoints by the problem each solves.
Sketch east-west versus north-south traffic for the progress API and the Monday board paths.
Plan a non-overlapping CIDR strategy compatible with future peering or Transit Gateway.
Identify segmentation boundaries: edge, application, data, and management.
Anticipate cost and availability implications of NAT and data transfer without quoting unverified prices.
Produce a three-tier address and flow plan that lesson 6 can implement.
Avoid common subnetting mistakes that strand AZs or exhaust IP space for load balancers and scaling.
Connect networking fundamentals to IAM: allow on the wire is not allow on the API.

Prerequisites

Lessons 1–4: Regions/AZs, accounts, IAM, CLI identity checks.
Comfort with binary thinking at a high level (powers of two) for subnet sizing—not a CCNA requirement.
Willingness to draw diagrams before opening the console.
Optional: basic Linux networking curiosity (ip route, DNS lookups) helps labs later.

Detailed Core Concepts

Why networking fundamentals belong in a cloud course

Cloud consoles hide cables; they do not hide routing. Every VPC you create asks for a CIDR. Every subnet consumes a slice. Every private workload that needs outbound internet depends on NAT or endpoints. Teams that skip fundamentals create /16 VPCs per microaccount until they cannot peer, or /28 subnets that cannot hold a load balancer’s ENIs across AZs during scale-out. TechLearningPro’s landing zone must remain connectable as accounts multiply in Module 5.

IPv4 addresses and CIDR

An IPv4 address is 32 bits, usually written as four decimals. A CIDR prefix like 10.0.0.0/16 means the first 16 bits are the network portion. Larger prefix numbers mean smaller networks (/24 is smaller than /16). Host count is roughly 2^(32-prefix) minus reserved addresses that AWS subnets hold back for its own use—always leave headroom; do not plan to use “every IP.”

Private ranges commonly used in VPCs come from RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Public addresses are reachable on the internet when associated correctly with internet gateways and public subnets. Elastic IPs are a related public addressing concept for static public IPv4 in AWS—verify current behaviors and costs in docs and price cards.

IPv6 exists in AWS VPC designs and matters for some public-facing strategies; this foundations lesson focuses on IPv4 because most enterprise landing zones still center there. When you adopt IPv6, treat it as an explicit ADR, not an accidental checkbox.

Subnetting for tiers and AZs

A subnet is a contiguous CIDR inside the VPC, tied to one Availability Zone. Design pattern for TechLearningPro three-tier:

Public subnets (one per AZ) for load balancers and NAT gateways (if used).
Private application subnets (one per AZ) for progress API tasks/instances.
Private data subnets (one per AZ) for databases.

Example teaching plan (illustrative only):

VPC 10.20.0.0/16
Public AZ-a 10.20.0.0/24, Public AZ-b 10.20.1.0/24
App AZ-a 10.20.10.0/24, App AZ-b 10.20.11.0/24
Data AZ-a 10.20.20.0/24, Data AZ-b 10.20.21.0/24
Reserve more /24s for future endpoints, firewalls, or shared services.

Why /24 often appears: it is large enough for many ENIs yet small enough to keep mental math easy. Some designs use /20 for app tiers that scale widely. Undersized subnets fail at the worst time—scale-out. Oversized single subnets waste little in IPv4 private space but can confuse security zoning if you place mixed tiers together.

AWS reserved addresses in each subnet reduce usable host counts; plan capacity with margin. Look up the current reserved count in VPC documentation when you need precision rather than memorizing a blog.

Public versus private subnets (intent)

In AWS, “public subnet” conventionally means a subnet whose route table sends 0.0.0.0/0 to an Internet Gateway (IGW). Instances there may have public IPs or be fronted by public load balancers. “Private subnet” means no direct default route to an IGW; outbound internet, if required, goes through a NAT gateway (or NAT instance) in a public subnet, or through VPC endpoints for AWS APIs without general internet.

Private is not “unroutable.” Private is “not directly internet-addressable by design.” East-west routes between private subnets via the VPC local router still work.

Routing and longest prefix match

Route tables contain destinations and targets (local, IGW, NAT gateway, peering, Transit Gateway, VPC endpoint prefix lists, and others). The most specific matching prefix wins. The implicit local route covers the VPC CIDR. If a private subnet lacks a default route to NAT or endpoints for needed traffic, packages and API calls fail while same-VPC database calls may still succeed—producing confusing partial health.

Internet gateway and NAT gateway

Internet Gateway attaches to a VPC and provides bidirectional internet connectivity for resources with appropriate public addressing and routes.

NAT Gateway allows instances in private subnets to initiate outbound internet connections (for example, to download patches or call third-party APIs) without accepting unsolicited inbound connections from the internet. NAT gateways are AZ-scoped resources typically placed in public subnets; for production, design NAT per AZ to avoid cross-AZ dependency for outbound. They have hourly and data processing charges—check current pricing; prefer VPC endpoints for heavy AWS API traffic when appropriate to reduce NAT dependence.

VPC endpoints (conceptual)

Gateway endpoints (notably S3 and DynamoDB) use route table entries. Interface endpoints (PrivateLink) use ENIs in your subnets for many AWS APIs. Endpoints keep traffic on the AWS network and can remove the need for NAT for those APIs. Lesson 6 and lesson 50 deepen endpoint design. Fundamentals: know they exist before you pay for NAT solely to reach S3.

DNS essentials

Learners resolve learn.techlearningpro.example via public DNS (often Route 53). Inside a VPC, Amazon-provided DNS (or custom DNS) resolves instance names and private hosted zones. Misconfigured DNS produces failures that look like network partitions. Split-horizon DNS can serve different answers privately and publicly—powerful and easy to get wrong. For foundations, document which names are public and which are private, and test resolution from the same subnet as the caller.

MTU, TCP handshakes, TLS, and application timeouts all sit above IP routing. A “network issue” ticket should specify which layer failed: ARP/neighbor, route, TCP connect, TLS, HTTP. Precision shortens outages.

Segmentation and zero trust adjacent thinking

Segmentation reduces blast radius: compromise of an edge component should not equal free lateral movement to data stores. Combine subnet placement, security groups (next lessons), and IAM. Network segmentation without identity controls is incomplete; identity without network segmentation over-relies on perfect IAM.

East-west versus north-south

North-south: client ↔ edge ↔ app. East-west: app ↔ app, app ↔ data, app ↔ cache. Chatty east-west across AZs has latency and data transfer implications. Design services to prefer local caches and to minimize cross-AZ chatter when possible, while still running multi-AZ for availability—lesson 1 already framed that tension.

CIDR planning across accounts

If tlp-prod-app and tlp-prod-data both use 10.0.0.0/16, future connectivity hurts. Allocate unique CIDRs per VPC from a company spreadsheet or IPAM tool. Leave spare space for growth. Document allocations in the same place as the Organizations OU tree.

IPv4 exhaustion and public IP scarcity

Public IPv4 addresses are constrained and may incur charges depending on AWS pricing policies over time—verify current rules. Prefer load balancers and private networking over assigning public IPs to every instance. Elastic IPs allocated but unused can incur charges—cleanup matters.

Connectivity to on-premises (preview)

VPN and Direct Connect extend private routing to corporate networks. They do not replace CIDR discipline; overlapping on-prem and VPC ranges break hybrid dreams. Lesson 51 covers hybrid depth. Fundamentals: ask for the on-prem CIDR list before finalizing VPC CIDRs.

Observability primitives

VPC Flow Logs, Reachability Analyzer, and traceroute-like mental models help. Flow Logs show accepts/rejects without payloads. Use them when fundamentals meetings disagree about whether a packet arrived.

Security groups preview without stealing lesson 7

Stateful allow-lists on ENIs filter after routing. You can route correctly and still time out on a closed security group. Keep planes separate in diagnosis.

Worked sizing exercise

Suppose each app subnet must hold up to 100 tasks/ENIs today and 4× growth, plus room for interface endpoints. A /24 (minus AWS reservations) may suffice early; a /22 may be safer for growth. Write the math in the ADR with the date you will revisit. Do not silently pick /28 because a tutorial did.

Three-tier flow narrative for TechLearningPro

Learner → Internet → IGW → public subnet load balancer.
Load balancer → private app subnet progress API.
Progress API → private data subnet database.
Progress API → S3 via gateway endpoint (preferred) or NAT.
Operator → Session Manager via interface endpoints (lesson 7), not SSH from the world.
Monday board path may read from a data account via controlled pipelines—not from public internet into the OLTP database.

Draw these six arrows before creating resources.

Common CIDR anti-patterns

One huge subnet for everything.
Overlapping VPCs “temporary.”
Public databases with security group “protection” only.
Single NAT in one AZ for multi-AZ apps.
Exhausting /28 then recreating VPC because you cannot resize subnet CIDRs freely—subnet CIDRs are not casually expandable in place; plan ahead (verify current constraints in docs).

Linking back to shared responsibility

AWS provides the virtual network fabric. You choose CIDRs, routes, exposure, and logging. A packet leaving through an IGW because you attached a public IP is your design, not an AWS surprise.

Architecture and Design Diagrams

mermaid
flowchart TB
  subgraph vpc [VPC 10.20.0.0/16]
    subgraph pub [Public subnets]
      IGW[Internet Gateway]
      NAT[NAT Gateway per AZ]
      ALB[Load balancer]
    end
    subgraph app [Private app subnets]
      API[Progress API]
    end
    subgraph data [Private data subnets]
      DB[(Database)]
    end
  end
  Learner --> IGW --> ALB --> API --> DB
  API --> NAT
  API -->|gateway endpoint| S3[S3]

mermaid
flowchart LR
  Packet[Packet] --> RT[Route table longest prefix]
  RT -->|0.0.0.0/0 public| IGW2[IGW]
  RT -->|0.0.0.0/0 private| NAT2[NAT]
  RT -->|VPC CIDR| Local[Local VPC routing]
  RT -->|Prefix list| VPCE[Gateway endpoint]

Technical Explanation

How a packet crosses tiers

The load balancer ENI in a public subnet receives a client connection via the IGW path. It opens a new connection to a private IP in an app subnet. The VPC local route delivers that packet within the VPC. The database connection is another new connection from app to data subnet. Return traffic for each TCP connection follows state at security groups and routes back via local routing. No NAT is required for east-west inside the VPC.

When the app calls an external payment webhook on the public internet, the private subnet route sends 0.0.0.0/0 to a NAT gateway in the same AZ’s public subnet (if designed that way). NAT translates the private source IP to a public IP on the NAT gateway. Responses return to NAT and back to the instance. If the NAT is in another AZ, you introduce a cross-AZ dependency for outbound—sometimes accepted, often avoided for production.

DNS resolution path

Application config uses hostnames. The resolver returns addresses depending on private hosted zone associations and resolver rules. Wrong VPC DHCP option sets or overwritten resolvers break STS and S3 calls in subtle ways. When CLI calls fail with connection errors after IAM looks correct, test DNS.

Prefix lists and routes

Gateway endpoints install prefix list routes targeting the endpoint. If someone replaces the route table and drops those routes, S3 traffic may fall through to NAT or blackhole. Protect route tables with change control and IaC.

MTU and encapsulation previews

VPN and some overlay networks reduce effective MTU. Foundations rarely need deep MTU tuning, but if hybrid appears later with mysterious truncation, remember this bullet.

Addressing for load balancers

Load balancers consume ENIs/IPs across subnets you select. Always place LB subnets in at least two AZs for HA designs. Undersized public subnets are a common reason LB creation fails—read the error; free IPs.

IPv4 vs hostname mental model

Prefer hostnames in configs. IPs change when instances replace. Security group references beat IP allows for the same reason.

Practical Implementation or Design Walkthrough

Budget alert

Set AWS Budgets before creating NAT gateways or other billable networking components in later implementation. This lesson’s primary deliverable can be a design document without billable resources.

Deliverable: three-tier address and flow plan

Choose VPC CIDR unique in your org map.
Allocate public, app, and data subnets across two AZs with headroom notes.
Draw north-south and east-west flows including S3 and operator access.
Decide NAT per AZ versus endpoints-first for AWS APIs; document cost sensitivity qualitatively.
List DNS names involved.
List future hybrid CIDRs to avoid.
Peer review with someone who owns another account’s VPC CIDR.

Optional read-only CLI

bash
aws ec2 describe-vpcs --profile tlp-lab
aws ec2 describe-subnets --profile tlp-lab

Do not create NAT gateways until you are ready to clean them up in lesson 6 labs.

Negative planning tests

What fails if AZ-a NAT dies and app subnets in AZ-a point only there?
What fails if app subnet is /28 and LB or tasks need more ENIs?
What fails if DNS for the database hostname points at the wrong address?
What fails if Monday board ETL uses the same constrained NAT as interactive traffic during a spike?

Enterprise Real-World Scenarios

Scenario A: Overlapping CIDRs after acquisition

An acquired startup VPC used 10.0.0.0/8. Peering to TechLearningPro failed. Migration required renumbering—expensive.

Lesson. Allocate uniqueness early; acquisitions get an address review.

Scenario B: Single NAT for “savings”

All private subnets routed outbound through one NAT in AZ-a. AZ-a impairment broke patching and third-party calls for AZ-b app nodes.

Lesson. NAT per AZ for production-shaped availability, or eliminate need via endpoints.

Scenario C: Public database “temporary”

A PostgreSQL instance landed in a public subnet with a security group allow from 0.0.0.0/0 on 5432 during a hackathon and remained.

Lesson. Data tier private by default; automated detection later with Config/GuardDuty lessons.

Scenario D: Subnet IP exhaustion at scale-out

Enrollment week scale-out failed launching ENIs. Subnet too small.

Lesson. Size for peak plus margin; monitor available IPs.

Scenario E: DNS split-brain

Private hosted zone not associated to the VPC; instances used public DNS answers that pointed to the wrong environment.

Lesson. Test resolution from the caller’s VPC; document associations.

Best Practices

Plan unique CIDRs across connectable VPCs.
Separate public, app, and data subnets across ≥2 AZs.
Size subnets for peak ENIs plus growth.
Prefer endpoints for AWS API traffic when suitable; design NAT deliberately.
NAT per AZ for HA outbound when NAT is required.
Document flows before implementation.
Keep databases private.
Monitor IP utilization.
Treat route table changes as production changes.
Align networking ADRs with account ADRs.
Budget-alert before NAT/endpoints labs.
Separate interactive and heavy ETL path capacity planning.

Common Mistakes and Anti-Patterns

Overlapping VPC CIDRs. Breaks future connectivity.
One subnet to rule them all. Destroys segmentation.
Undersized subnets. Fails at scale-out.
Public data tiers. Expands blast radius.
Single-AZ NAT for multi-AZ apps. Hidden availability bug.
Assuming private means no routes. Breaks outbound and sometimes mental models of east-west.
Ignoring DNS. Misdiagnosed as IAM or “AWS down.”
No IPAM ownership. Chaos across teams.
Creating NAT for S3-only workloads. Unnecessary cost when gateway endpoints fit.
Copying tutorial CIDRs that collide with corp network. Hybrid pain later.

Troubleshooting and Design Review

Timeouts to internet from private subnet. Check NAT presence, route 0.0.0.0/0, NAT AZ, security group outbound, NACL ephemeral rules later.

Works in one AZ only. Asymmetric routes or single NAT.

Cannot create load balancer. Subnet IP space or missing public subnet across AZs.

Design review questions

Are CIDRs unique and documented?
Are tiers separated across AZs?
What outbound path does the app use for AWS APIs? For third parties?
What happens if one AZ’s NAT fails?
Where does DNS resolve for each hostname?
How will Monday board traffic differ from player traffic?

Interview Questions and Answers

Q1. What does /24 mean in CIDR?

The first 24 bits are network prefix; the rest host bits—about 256 addresses before reservations, with usable hosts fewer in AWS subnets.

Q2. What makes a subnet public in AWS vernacular?

A route to an Internet Gateway for destinations that need internet, typically 0.0.0.0/0 → IGW, plus appropriate public addressing for resources that need it.

Q3. Why place NAT gateways in public subnets?

They need a path to the IGW to translate private outbound sessions to the internet.

Q4. Why prefer VPC endpoints for S3 from private subnets?

Keep traffic on AWS networking, potentially simplify outbound, and reduce reliance on NAT for that API path—verify fit and pricing for your design.

Q5. How does longest prefix match affect troubleshooting?

A more specific route can override a default; leftover specific routes from experiments blackhole traffic.

Q6. Why unique CIDRs across accounts?

So future peering/TGW connections do not collide.

Q7. What is east-west traffic in the learning platform?

App-to-database and service-to-service inside the VPC/estate, versus client north-south.

Q8. Why multi-AZ subnets per tier?

So load balancers and data stores can place capacity in more than one AZ for HA.

Q9. How do networking failures differ from IAM AccessDenied?

Timeouts/connect errors versus explicit API authorization errors—usually.

Q10. What is a three-tier plan?

Edge/public, application private, data private, with documented routes and flows.

Q11. Why not use 10.0.0.0/8 as a single VPC for everything?

Operability and blast radius; also complicates security zoning and often reflects lack of account strategy.

Q12. What should an ADR include for networking?

CIDRs, subnet map, IGW/NAT/endpoint choices, DNS, HA assumptions, cost notes, and rejected alternatives.

Hands-On Exercises

Lab cost warning. Prefer design-only. If you create NAT gateways or endpoints, set budget alerts first and delete same day.

Exercise: Plan address ranges and traffic flows for a three-tier VPC

Problem. Produce a networking plan for TechLearningPro progress API + database + edge LB across two AZs.

Tasks.

Verify budget alert strategy for upcoming implementation labs.
Write VPC and subnet CIDR table with usable host estimates and growth notes.
Draw flow diagrams for learner traffic, outbound patching, S3 access, and operator access.
Document NAT vs endpoint decision with qualitative cost/availability rationale (check current price card before any real budget claim).
List CIDRs that must never overlap (corp, other accounts).
Peer review with a classmate or colleague; capture feedback.
Cleanup: ensure no billable resources created; if any, delete and record evidence.

Challenge. Add a constraint: no general internet outbound from data subnets; only specific paths to backups. Adjust routes and endpoint plans.

Worked CIDR plan for TechLearningPro staging

Staging should mirror production topology with smaller address appetites. An illustrative staging VPC 10.30.0.0/16 keeps clear distance from a production 10.20.0.0/16 and from common lab 10.0.0.0/16 collisions. Public /24s in two AZs host staging load balancers and NAT. App /24s host API tasks. Data /24s host staging databases with synthetic learners only. Reserve 10.30.100.0/24 and 10.30.101.0/24 for interface endpoints so SSM and other private APIs do not consume app IP space during scale tests.

Write usable host estimates after AWS reservations. If each app subnet must absorb a load test that doubles ENIs, say so in the ADR with a revisit date after the next enrollment week. Staging that cannot scale to the test you claim to run is theater.

Path isolation for player versus Monday board

The lesson player’s north-south path is latency-sensitive and must stay healthy when ETL runs. If both share a single NAT gateway and the Monday board’s extract suddenly pulls terabytes through that NAT, interactive outbound calls—license checks, webhook confirmations, package pulls during deploys—contend for the same translator. Prefer endpoints for AWS API traffic on both paths, and consider separate outbound strategies or rate limits for ETL. The networking fundamentals lesson is where you notice the shared fate; later FinOps lessons price it.

DNS decision record template

Capture for each critical name: zone (public/private), owning account, TTL philosophy, target (CloudFront, ALB, private IP via discovery), and who may change it. TechLearningPro’s api.learn… and board.learn… must not silently swap environments because a private hosted zone association was missing. Include a test command that resolves from a sandbox instance and from a laptop VPN path.

Hybrid readiness without building hybrid yet

Ask corporate networking for reserved ranges that must never appear in AWS VPCs, and for ranges already used on-prem. Put them in the IPAM sheet beside Organizations OUs. When Module 5 introduces VPN or Direct Connect, you will not renumber production under incident pressure. If corporate cannot provide a list, escalate—that absence is a program risk, not a trivia miss.

Lab facilitation checklist for instructors

Before a cohort builds VPCs in lesson 6, confirm everyone has unique CIDR assignments from a shared sheet, budget alerts on, and SSO profiles pointed at sandbox. Ban overlapping 10.0.0.0/16 copies. Collect cleanup evidence at end of day. A class that leaves thirty NAT gateways running overnight converts a networking lesson into an unplanned FinOps case study.

Measuring networking design quality

Useful signals: number of VPCs with unique CIDRs; percentage of production databases without public subnets; NAT gateways without per-AZ pairs in HA apps; presence of S3 gateway endpoints on private route tables that talk to S3 heavily; IP utilization alarms on critical subnets; documented flow diagrams less than six months old. Review quarterly with platform engineering.

Interview drill set (practice aloud)

Explain longest prefix match with an example where a leftover /32 host route blackholes an instance. Explain why a /28 public subnet can block load balancer creation. Explain how DNS failure mimics a partition. Explain why multi-AZ compute with single-AZ NAT is not multi-AZ for outbound dependencies. Record yourself and listen for hand-waving.

Capstone preview connections

Project 1’s highly available three-tier app will grade your subnet map and route story. Project 4’s landing zone will grade CIDR uniqueness across accounts. Students who treat this lesson as optional subnet trivia rebuild under time pressure later. Keep the three-tier flow diagram in your notes repo next to the account ADR.

Additional architecture note 1

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 1 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 2

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 2 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 3

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 3 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 4

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 4 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 5

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 5 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 6

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 6 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 7

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 7 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 8

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 8 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 9

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 9 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 10

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 10 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 11

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 11 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 12

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 12 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 13

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 13 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 14

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 14 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 15

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 15 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 16

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 16 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 17

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 17 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 18

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 18 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 19

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 19 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 20

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 20 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 21

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 21 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 22

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 22 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 23

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 23 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 24

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 24 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Additional architecture note 25

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 25 in this series reminds operators that route tables, endpoints, and subnet IP headroom are living capacity controls, not one-time setup. Revisit them when enrollment forecasts change, when a new account is vended, and when a new managed service requires extra ENIs per AZ. Keep budget alerts aligned to the resources this VPC actually runs, including NAT and interface endpoints, and never assume yesterday’s unused Elastic IP is free without checking the current price card.

Lesson Summary

Networking fundamentals turn AWS from a console of buttons into a system of addresses, routes, and paths. TechLearningPro needs unique CIDRs, multi-AZ tiered subnets, deliberate public versus private intent, and clear stories for NAT versus VPC endpoints. DNS and routing bugs masquerade as application outages; precise diagnosis saves Monday. Carry your three-tier plan into Amazon VPC Architecture, where these ideas become VPC, subnet, route table, and gateway resources you can build—and must clean up.