Amazon VPC Architecture

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

Lesson Overview

Networking Fundamentals for AWS gave you CIDRs and flows on paper. This lesson builds the Amazon Virtual Private Cloud those flows require: VPCs, subnets, route tables, internet gateways, NAT gateways, and VPC endpoints, wired across two Availability Zones for TechLearningPro’s progress API. When the paper plan meets the console, missing route associations and single-AZ NAT habits show up as timeouts that IAM cannot explain.

You will design and document a two-AZ VPC architecture, explain route behavior for public and private subnets, and prepare the network canvas that Security Groups, NACLs and VPC Connectivity will filter and that compute lessons will populate. Account boundaries from lesson 2 still apply: build in sandbox first, never in the Organizations management account, and never with production learner data.

Planning assumptions:

• Implement in a sandbox account with budget alerts—NAT gateways and interface endpoints incur charges.
• Use the Region from lesson 1; create subnets in at least two AZs.
• Prefer infrastructure as code later; console/CLI learning is acceptable here with ruthless cleanup.
• Verify CLI flags and console labels against current AWS documentation; do not invent options.

Learning Objectives

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

1. Create or specify a VPC with a non-overlapping CIDR suitable for TechLearningPro.
2. Place public and private subnets across two AZs with clear tier intent.
3. Associate route tables that correctly target IGW, NAT, local, and gateway endpoints.
4. Explain how an Internet Gateway enables public subnet internet connectivity.
5. Design NAT gateway placement for private outbound and describe AZ failure behavior.
6. Choose VPC endpoints for S3 (and optionally interface endpoints for SSM/other APIs) to reduce NAT dependence.
7. Document route behavior with a table that predicts packet targets for common destinations.
8. Build a two-AZ architecture diagram tied to the progress API and database placement.
9. Apply tags, budgets, and cleanup as first-class architecture tasks.
10. Avoid anti-patterns: single-AZ “HA,” default VPC dependency for production, and orphaned NAT.
11. Connect VPC design to IAM and identity: instance roles still need network paths to STS/instance metadata and AWS APIs.
12. Hand lesson 7 a VPC ready for security group matrices.

Prerequisites

• Lessons 1–5 completed conceptually; especially CIDR plan from lesson 5.
• CLI profile working with get-caller-identity against sandbox.
• Permission to manage VPC resources in sandbox (lab role).
• Budget alert configured.

Detailed Core Concepts

What a VPC is

A VPC is a logically isolated virtual network in an AWS Region. You choose its IPv4 CIDR (and optionally IPv6). Resources inside communicate using private IPs according to route tables and filters. The VPC does not automatically span Regions; multi-Region means multiple VPCs and an explicit connectivity story.

Default VPCs exist in accounts for convenience. Production landing zones often avoid depending on the default VPC for application architecture because its CIDR and subnet layout may not match enterprise IPAM. Some organizations delete default VPCs; others leave them but forbid their use via policy. Decide deliberately.

Subnets and AZ binding

Each subnet lives in exactly one AZ. Multi-AZ HA means multiple subnets in different AZs for each tier that needs presence there. You cannot stretch one subnet across AZs. When Auto Scaling or managed services ask for subnets, provide the set across AZs you intend.

Route tables and associations

A route table contains routes; subnets are associated with a route table (or use the main route table). Mis-association is a classic outage: a “private” subnet accidentally associated with a public route table may receive public IP behavior you did not want depending on addressing; more commonly, a private subnet left without NAT/endpoint routes cannot reach required APIs.

Main route table defaults deserve scrutiny—do not dump all experimental routes there.

Internet Gateway

Attach one IGW per VPC that needs public internet connectivity. Update public subnet route tables: 0.0.0.0/0 → igw-…. Without IGW attachment and routes, public subnets are not public in practice.

NAT Gateway

Create NAT gateways in public subnets with Elastic IPs. Point private subnet 0.0.0.0/0 to the NAT in the same AZ for resilient design. Shared NAT across AZs is a cost/availability trade-off you must write down. Delete NATs in cleanup—they are frequent orphan bills.

VPC endpoints

S3 gateway endpoint: add to route tables of subnets that need S3 without NAT. Interface endpoints: place ENIs in subnets (often private), secure with security groups, and update private DNS as documented. For foundations labs, an S3 gateway endpoint is a high-value, lower-surprise starting point. Interface endpoints for SSM appear when you adopt Session Manager fully in lesson 7.

DNS attributes

VPC settings such as DNS support and DNS hostnames affect whether instances receive DNS names and how private resolution behaves. Enable the combinations AWS documents for your use case (commonly both enabled for typical public hostname needs). Verify rather than assume tutorial defaults.

Secondary CIDRs and expansion

VPCs can add secondary CIDRs within rules AWS documents. Prefer initial headroom over emergency expansion during enrollment week. Secondary CIDRs interact with route tables and security planning—treat as a change project.

Connectivity options beyond this lesson

Peering, Transit Gateway, VPN, Direct Connect, PrivateLink to customer services—Module 5. Your VPC should still be cleanly designed so those attachments have non-overlapping CIDRs and clear route domains.

Tagging and naming

Name subnets with tier and AZ (tlp-prod-app-a). Tag env, tier, owner, project. Future automation and cost allocation depend on this hygiene.

Relationship to managed services

RDS subnet groups, ELB subnet selections, ECS awsvpc networking, and Lambda VPC configs all consume your subnet design. A VPC that only “works for EC2” but cannot place a multi-AZ load balancer is unfinished for TechLearningPro.

Shared VPCs preview

Some enterprises share subnets across accounts with VPC sharing. That model changes ownership of the network versus the workload. Foundations assume dedicated VPC per account workload pattern first; revisit sharing only with Module 5 guidance.

Control plane versus data plane in networking

Creating a subnet is control plane. Packets are data plane. During rare control-plane issues, existing routes still carry traffic. Designs that constantly rewrite routes for normal operation are fragile.

Metadata service and routing

Instances use link-local metadata endpoints for credentials when using instance profiles. Network ACLs and routes rarely break that path, but security tooling might. Know metadata exists so you do not invent “AWS stole our routes” stories when roles fail for other reasons. Prefer IMDSv2 per current EC2 guidance when you harden compute in lesson 8.

Example route behavior table

Fill with your real CIDRs.

Two-AZ progress API architecture narrative

Public subnets host the load balancer (and NAT). App subnets host API tasks across AZ-a and AZ-b. Data subnets host the multi-AZ database’s network presence as required by the managed service. S3 course assets leave via gateway endpoint. Operators use Session Manager paths later without public SSH. The Monday board does not query the OLTP from a public IP; analytical access is a different path and often a different account.

Cost drivers to name

NAT hourly + processing, interface endpoint hourly + processing, data transfer across AZs, Flow Logs storage, unused Elastic IPs. Gateway endpoints for S3/DynamoDB have a different commercial model—confirm on the current price card. Label classroom estimates illustrative.

IaC foreshadow

Terraform and CloudFormation should own VPCs soon. Manual console VPCs become snowflakes. If you build manually here, export a diagram and plan migration to IaC in Module 3 rather than living forever in click-ops.

Architecture and Design Diagrams

mermaidCopy
flowchart TB
  subgraph region [Region]
    IGW[IGW]
    subgraph aza [AZ a]
      PubA[Public subnet]
      AppA[App subnet]
      DataA[Data subnet]
      NATA[NAT Gateway]
    end
    subgraph azb [AZ b]
      PubB[Public subnet]
      AppB[App subnet]
      DataB[Data subnet]
      NATB[NAT Gateway]
    end
    S3VPCE[S3 Gateway Endpoint]
  end
  Users --> IGW --> PubA
  IGW --> PubB
  PubA --> NATA
  PubB --> NATB
  AppA --> NATA
  AppB --> NATB
  AppA --> S3VPCE
  AppB --> S3VPCE
  AppA --> DataA
  AppB --> DataB

mermaidCopy
flowchart LR
  subgraph rt_private [Private app route table]
    R1[local VPC CIDR]
    R2[S3 prefix list to VPCE]
    R3[0.0.0.0/0 to NAT]
  end

Technical Explanation

Creation order that reduces mistakes

1. Create VPC with CIDR and DNS settings.
2. Create subnets in each AZ for each tier.
3. Create and attach IGW.
4. Create public route table; add IGW default route; associate public subnets.
5. Allocate Elastic IPs; create NAT gateways in public subnets; create private route tables per AZ with NAT defaults; associate private subnets.
6. Create S3 gateway endpoint; attach to private (and public if needed) route tables.
7. Tag everything; verify with route table descriptions and a reachability plan.
8. Only then place compute.

Skipping to launch instances first produces debugging theater.

Validating routes with CLI (shapes)

bashCopy
aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-EXAMPLE
aws sts get-caller-identity

Replace IDs with yours. Interpret targets carefully.

Failure behavior stories

• AZ-a fails: AZ-b public/app/data and NAT-b should continue for capacity placed there; database multi-AZ failover behaves per service docs.
• NAT-a fails but AZ-a compute remains: AZ-a private outbound via NAT-a breaks if no failover route—another reason endpoints help for AWS APIs.
• IGW issues: public ingress fails; private east-west may continue.
• Accidental route deletion to S3 endpoint: S3 access may shift to NAT or fail.

Subnet route table propagation

Some attachments propagate routes (TGW). In foundations without TGW, you manage static routes yourself. When TGW arrives, know propagation can surprise you—Module 5.

Network ACLs default state

New custom NACLs deny all until you add rules; default NACL allows all. Lesson 7 details. For VPC buildout, leave default NACL unless you have a written reason.

Security group default state

New security groups deny inbound, allow outbound (typical). Instances won’t accept LB traffic until lesson 7 rules exist—expect that.

Practical Implementation or Design Walkthrough

Step 0

Budget alert on. Sandbox account. get-caller-identity shows sandbox.

Step 1–8

Implement the creation order above with your lesson 5 CIDRs, or write an IaC draft without apply if permissions are restricted. Capture screenshots/CLI of route tables.

Prove route behavior on paper

For destinations local, S3, 1.1.1.1 (example external), and peer AZ subnet, write the matched route and target. Peer-review.

Optional ping path

If you launch tiny instances temporarily: confirm private IP connectivity app-to-app across AZs (ICMP may be blocked by SG—use carefully), confirm outbound through NAT to check IP via a safe echo service, confirm S3 API access. Terminate instances same day.

Cleanup checklist

Delete instances, NAT gateways, release Elastic IPs, delete endpoints, delete subnets, detach/delete IGW, delete VPC, delete unused route tables. Confirm billing dashboard. Missing cleanup fails the exercise.

Enterprise Real-World Scenarios

Scenario A: Default VPC in production

Teams launched prod into the default VPC with /20 public subnets and no private tiers. A ransomware scan found SSH open on public instances.

Fix. Purpose-built VPC, private tiers, SSM, rebuild path.

Scenario B: Orphan NAT fleet

Every hackathon created a NAT. Monthly bill surprised finance.

Fix. Budgets, tags, automated detectors, IaC with destroy.

Scenario C: One route table for all private subnets via NAT-a

AZ-a outage broke outbound for the Region’s private estate.

Fix. Per-AZ private route tables and NATs.

Scenario D: Missing S3 endpoint under inspection

Data transfer costs rose; all S3 went through NAT.

Fix. Gateway endpoint + route audit.

Scenario E: Subnet mis-association

A data subnet associated to public route table during “temporary debug.”

Fix. Strict associations via IaC; detective controls.

Best Practices

1. Non-default, IPAM-aligned VPC CIDRs.
2. Subnets per tier per AZ (≥2 AZs).
3. Separate route tables for public and per-AZ private.
4. IGW only where public intent exists.
5. NAT per AZ when NAT is required.
6. S3 gateway endpoints for private S3 access patterns that fit.
7. Tag and name consistently.
8. Budget alerts and cleanup.
9. Document route behavior tables.
10. Move to IaC quickly.
11. Do not use management account for VPCs.
12. Plan LB subnet capacity.

Common Mistakes and Anti-Patterns

1. Production on default VPC.
2. Single AZ called highly available.
3. Shared NAT across AZs without ADR.
4. No cleanup of NAT/EIP.
5. Wrong route table associations.
6. Overlapping CIDRs.
7. Public data subnets.
8. Manual snowflake VPCs forever.
9. Ignoring DNS attributes.
10. Creating interface endpoints in every subnet without cost plan.

Troubleshooting and Design Review

No outbound from private. NAT, routes, SG outbound, EIP on NAT, AZ mismatch.

S3 AccessDenied vs timeout. IAM vs endpoint/NAT path—distinguish.

Cannot delete VPC. Remaining ENIs, endpoints, instances, security group dependencies—delete in order.

Design review

• Two AZs for each required tier?
• Route tables match intent?
• Endpoint strategy documented?
• Cleanup and budgets?
• CIDR uniqueness?
• Ready for security group matrix?

Interview Questions and Answers

Q1. What is a VPC?

A regional logically isolated virtual network where you control IP addressing, subnets, routing, and gateways.

Q2. Why can’t one subnet span AZs?

AWS binds each subnet to a single AZ for isolation and placement; HA needs multiple subnets.

Q3. How does a public subnet reach the internet?

IGW attached plus route to IGW plus appropriate public addressing for the resource.

Q4. How do private subnets get outbound internet?

Typically NAT gateway routes, or avoid general internet via VPC endpoints for AWS APIs.

Q5. Why per-AZ NAT?

So AZ impairment does not remove outbound for surviving AZs.

Q6. What is a gateway endpoint?

A route-table-based VPC endpoint for supported services like S3/DynamoDB without interface ENIs.

Q7. What is the main route table risk?

Unintended associations and experimental routes affecting many subnets.

Q8. Why tag VPC resources?

Cost, cleanup, automation, and incident response.

Q9. How does VPC design interact with IAM?

Network path must exist for API calls; IAM then authorizes. Both required.

Q10. What evidence shows correct routing?

Describe-route-tables output, Reachability Analyzer, and empirical tests from instances.

Q11. Why prefer IaC for VPCs?

Reproducibility, review, disaster recovery of network config, and drift detection.

Q12. What do you delete first in cleanup?

Dependent resources: instances/ENIs, NAT/EIP, endpoints, then subnets/IGW/VPC—follow dependency order.

Hands-On Exercises

Lab cost warning. NAT gateways and interface endpoints cost money. Budget alert mandatory. Delete within the lab window.

Exercise: Build a two-AZ VPC architecture and document route behavior

Problem. In sandbox, create a VPC with public/app/data subnets in two AZs, IGW, NAT per AZ (or document a cheaper endpoints-first variant your instructor approves), S3 gateway endpoint, and a route behavior table.

Tasks.

1. Budget alert verified; get-caller-identity sandbox.
2. Create VPC resources per plan; tag Project=tlp-lesson06.
3. Populate route behavior table with real IDs redacted if sharing.
4. Optional: launch and terminate a test instance proving outbound and S3 access.
5. Capture evidence.
6. Full cleanup; confirm no NAT/EIP left; record timestamp.

Challenge. Add interface endpoints for Systems Manager prerequisites and prove no inbound SSH is required for a shell session (may continue into lesson 7). Track endpoint costs.

Concrete two-AZ build sequence with verification gates

After each major step, stop and verify before continuing. After VPC create: confirm CIDR and DNS attributes. After subnets: confirm AZ placement and available IP counts. After IGW: confirm attachment state. After public routes: confirm association only to public subnets. After NAT create: confirm connectivity type/public subnet placement and Elastic IP association. After private routes: confirm each private subnet’s default target NAT is in its AZ. After S3 endpoint: confirm prefix list routes appear on intended tables. Verification gates prevent the “build everything then debug for hours” pattern.

Route behavior workbook for TechLearningPro

Create a spreadsheet with columns: source subnet, destination example, matched CIDR, target ID type, expected success/fail, test method. Rows should include: app to DB private IP; app to S3; app to public internet update mirror; public LB subnet to internet; data subnet to internet (expect fail if designed so); app AZ-a to NAT-b (should not be the normal path). Fill during the lab; attach to the change ticket.

Default VPC exit plan

If TechLearningPro still has workloads on a default VPC, write an exit plan: inventory resources, create destination VPC, migrate by service, update DNS, delete leftovers, prevent recreation via SCP intent or policy. Default VPC comfort is how public SSH becomes normal. Date the exit.

Endpoint-first variant for cost-conscious sandboxes

Instructors may authorize an endpoints-first sandbox: S3 gateway endpoint plus interface endpoints for SSM, with no NAT gateway, accepting that general internet outbound from private subnets will fail. That variant teaches private dependency design and saves NAT hourly charges. Document which package mirrors become unavailable and how AMIs with preinstalled tooling compensate. Do not silently omit NAT in production-shaped staging if third-party webhooks are required—call the dependency out.

Cross-account network preview

When tlp-prod-app and tlp-prod-data are separate accounts, each has a VPC. Connectivity will later use PrivateLink, TGW, or peering with non-overlapping CIDRs. Building both VPCs with 10.20.0.0/16 today creates a future incident. Coordinate CIDRs even if you only build one VPC in this lab.

Operational runbook snippet: cannot delete VPC

List remaining ENIs, instances, load balancers, endpoints, NAT gateways, peering connections, and security groups. Delete or detach dependents first. Students often forget a network interface from a terminated instance stuck in available with attachment residue—describe-network-interfaces helps. Patience beats force; follow AWS dependency errors literally.

Enrollment week network freeze

Consider a change freeze on route tables and security-group wide opens during enrollment week except emergency break-glass. Most Monday outages from “quick route fixes” are self-inflicted. Pre-create capacity in both AZs instead of rewriting routes under load.

Evidence pack for lesson completion

Submit: VPC ID (sandbox), subnet table, route tables exported, endpoint IDs, NAT IDs or written waiver for endpoints-first, budget alert ID, cleanup timestamp, and the route behavior workbook. Without cleanup evidence, the lab is incomplete regardless of diagram quality.

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.

Additional architecture note 26

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 26 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 27

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 27 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 28

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 28 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 29

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 29 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 30

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 30 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 31

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 31 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 32

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 32 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 33

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 33 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 34

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 34 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 35

For TechLearningPro, treat every VPC change as a product change with an owner, a rollback, and a cost note. Note 35 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

Amazon VPC architecture materializes TechLearningPro’s network plan into subnets, route tables, gateways, and endpoints across AZs. Public and private intents are route-table truths, not labels. NAT and endpoints are deliberate choices with availability and cost consequences. Document routes, tag resources, alert on budgets, and clean up. Next, Security Groups, NACLs and VPC Connectivity places stateful filters on the paths you just built, and compute lessons place the progress API onto the canvas without flattening your tiers.

Further Reading

• Amazon VPC User Guide
• Internet gateways
• NAT gateways
• Gateway VPC endpoints
• AWS Budgets
• Current pricing for NAT, endpoints, and data transfer before forecasting costs