Final Architecture Integration

Complete System Overview

The VPC you built encodes several architectural decisions as infrastructure. Reviewing the complete system as a whole cements the reasoning behind each decision.

Data Flow

An inbound HTTP request travels: internet → IGW → public subnet → load balancer (in sg-lb) → private-app subnet → application server (in sg-app) → private-db subnet → database (in sg-db). At each hop, a security group rule permits the connection only from the previous tier. No hop can be bypassed — the routing and security layers enforce the order.

An outbound request from the application tier (e.g., calling an external API) travels: app server → private-app subnet → route table → NAT Gateway (in same AZ public subnet) → IGW → internet. The NAT Gateway translates the private IP to its Elastic IP for the outbound connection, and routes return traffic back to the originating instance.

Failure Paths

If AZ-1 fails entirely, traffic shifts to resources in AZ-2. The AZ-2 route table routes outbound traffic to nat-az2. Resources in AZ-1 subnets are unreachable, but AZ-2 continues serving traffic independently. There is no cross-AZ dependency in this design.

If nat-az1 fails (without an AZ failure), instances in private-app-az1 lose outbound internet access. This does not affect inbound traffic to the public tier or database connectivity within the VPC. Recovery requires either replacing the NAT Gateway or temporarily re-pointing the route table to nat-az2.

Security Boundaries

Three distinct trust boundaries exist in this architecture. The public boundary accepts traffic from the internet only on ports 80 and 443 at the load balancer tier. The application boundary accepts traffic only from the load balancer security group. The database boundary accepts traffic only from the application security group. An attacker who compromises the load balancer cannot directly reach the database — they must first compromise the application tier.

The NAT Gateway ensures private instances never have a public IP and never accept inbound connections from the internet, even if a misconfigured security group were to allow it — the routing layer provides a second enforcement point.

Reflection

This architecture is the foundational network layer for most serious AWS deployments. Before expanding it, consider: do your private subnets need to reach AWS services like S3 or DynamoDB? If so, evaluate VPC Endpoints to route that traffic privately without going through the NAT Gateway, which reduces cost and eliminates internet exposure for those calls. Do you need private connectivity to on-premises systems? A VPN or Direct Connect attachment extends this VPC into your corporate network. Every addition to this foundation builds on the same routing and security group primitives you used here.

Final Architecture Review

Question 1 of 2

0/2

A developer launches an RDS instance in private-db-az1 and tries to reach it from their laptop over the internet. What prevents this?

The database security group has no inbound rule from 0.0.0.0/0The database subnet has no route to the internet, and sg-db only accepts traffic from sg-appRDS does not support internet routingThe IGW blocks database traffic by default

Back

Submit

Lab Complete — I can confirm:

0 of 6 completed

I built a six-subnet, two-AZ VPC from scratch with correct routing tiersI understand how route tables create the public/private subnet distinctionI implemented security group chaining with source-based rulesI can trace the data flow for both inbound and outbound trafficI identified all billable resources and completed cleanupI understand the AZ-level failure behavior of this architecture