Module Objective: Design an Amazon VPC networking environment — including subnet layout and traffic security — that supports the compute and database layers already added.
Builds on Modules 4–5: This module formalizes the network the compute and database layers actually run inside.
Networking in AWS: An Architectural View
Up to this point, compute and database resources have been discussed somewhat abstractly. This module makes explicit where they actually live: inside an Amazon VPC, whose design determines what can reach them and how.
Amazon VPC Design
Designing a VPC starts with choosing a CIDR block sized for expected growth, then dividing it into subnets that map to the architecture's actual tiers — a pattern that recurs across nearly every AWS reference architecture.
| Design Decision | Guidance |
|---|---|
| CIDR block size | Size generously — resizing a VPC's primary CIDR after resources are deployed is disruptive |
| Subnet-per-AZ | Create matching subnets in each AZ used, to support multi-AZ high availability |
| Tiered subnets | Separate subnets by tier — web, application, database — not just by AZ |
Public and Private Subnets in the Café Architecture
Applying the public/private subnet distinction from AWS Academy Cloud Foundations to the café case study: the load balancer sits in public subnets, the EC2 application tier sits in private subnets, and the RDS database sits in even more isolated private subnets.
Security Within a VPC
Security groups and network ACLs, reviewed in AWS Academy Cloud Foundations, are applied here layer by layer: each tier gets a security group permitting traffic only from the tier that should be allowed to reach it.
| Tier | Should Accept Traffic From |
|---|---|
| Load balancer security group | The internet (ports 80/443) |
| Application security group | Only the load balancer's security group |
| Database security group | Only the application security group |
VPC Peering and VPC Endpoints
As an architecture grows to span multiple VPCs — for different environments, teams, or accounts — VPC peering and AWS PrivateLink/VPC endpoints provide ways to connect them, or to reach AWS services, without traversing the public internet.
| Mechanism | Purpose |
|---|---|
| VPC peering | Direct, private network connection between two VPCs |
| Gateway endpoint | Private connectivity to Amazon S3 or DynamoDB without an internet gateway |
| Interface endpoint (AWS PrivateLink) | Private connectivity to most other AWS services via an elastic network interface |
Content Delivery in the Networking Layer
Amazon CloudFront, reviewed in AWS Academy Cloud Foundations, sits in front of this VPC's public-facing resources, caching content at edge locations and reducing the load and exposure of the origin.
Key Terms for Module 6
- three-tier subnet layout
- A VPC design pattern separating load balancer, application, and database resources into distinct subnets
- VPC peering
- A direct, private network connection between two VPCs
- VPC endpoint
- Private connectivity from a VPC to an AWS service without traversing the public internet
- defense in depth
- Layering independent security controls so a single breach doesn't grant full access
Review Questions
- Why is CIDR block sizing an important decision to get right at VPC creation time?
- In the café architecture's three-tier design, which tier sits in public subnets, and why?
- How does chaining security group rules across tiers implement defense in depth?
- What problem do VPC endpoints solve that a plain internet gateway route doesn't?