CAL-001

AWS Networking Foundations

Infrastructure as Code.
Architecture as Code.

DomainCloud Architecture
ComplexityLevel 1
StatusCompleted

Overview

CAL-001 establishes the networking foundation for the Cloud Architect Lab portfolio.

This case study demonstrates the design, implementation, validation, and documentation of a production-inspired Amazon Virtual Private Cloud using Terraform. The current implementation focuses on foundational networking rather than application workloads.

Architecture Overview

The deployed environment uses a dedicated VPC inus-east-1, with separate public and private subnets inus-east-1a.

The public subnet has a default route to an Internet Gateway. The private subnet has only the local VPC route and therefore has no direct internet path.

CAL-001 AWS networking architecture showing an AWS account, Region, VPC, public and private subnets, route tables, Internet Gateway, and security groups

Current Deployment

  • Amazon VPC: 10.10.0.0/16
  • Availability Zone: us-east-1a
  • Public subnet: 10.10.1.0/24
  • Private subnet: 10.10.11.0/24
  • Internet Gateway
  • Public route table
  • Private route table
  • Explicit route-table associations
  • Public Web Security Group
  • Private Application Security Group

No load balancer, NAT Gateway, EC2 instance, or other compute workload is currently deployed.

Routing Design

Public Subnet

  • 10.10.0.0/16 routes locally within the VPC.
  • 0.0.0.0/0 routes through the Internet Gateway.

Private Subnet

  • 10.10.0.0/16 routes locally within the VPC.
  • No default route to the Internet Gateway is configured.

The subnet names describe their intended role, but their route-table associations determine their actual network reachability.

Security Design

Public Web Security Group

  • HTTP on TCP port 80 from the internet
  • HTTPS on TCP port 443 from the internet
  • SSH on TCP port 22 from a trusted administrator CIDR
  • All outbound traffic allowed

Private Application Security Group

  • TCP port 8080 allowed only from the Public Web Security Group
  • All outbound traffic allowed

Referencing the public security group instead of an IP range establishes a reusable trust relationship between future public and private application tiers.

Business Scenario

A growing organization needs a repeatable AWS networking foundation that can support internet-facing and internal application workloads while preserving clear routing and security boundaries.

The environment must be reproducible through Infrastructure as Code, suitable for incremental expansion, and documented clearly enough for engineering review and portfolio presentation.

Technical Highlights

  • Terraform-managed AWS networking infrastructure
  • Custom Amazon VPC
  • Public and private subnet segmentation
  • Internet Gateway and public default route
  • Dedicated public and private route tables
  • Explicit subnet-to-route-table associations
  • Security-group references between network tiers
  • Terraform structure designed for future multi-Availability Zone expansion using for_each
  • Version-controlled Mermaid architecture diagrams
  • Documented deployment, validation, and engineering decisions

Validation

The deployed environment was validated through:

  • terraform fmt
  • terraform validate
  • Terraform execution-plan review
  • Successful Terraform deployment
  • Terraform state verification
  • AWS Management Console verification
  • Comparison of the deployed resources with the architecture diagram

Implementation Evidence

AWS VPC overview showing the deployed CAL-001 networking resources
Deployed VPC, subnets, and networking resources.
AWS public route table showing a default route to the Internet Gateway
Public route table with a 0.0.0.0/0 route to the Internet Gateway.
AWS private route table showing local VPC routing without an internet default route
Private route table with no direct route to the Internet Gateway.

Key Engineering Decisions

  • Build a dedicated VPC instead of using the AWS default VPC.
  • Deploy networking infrastructure before application workloads.
  • Separate public and private network tiers from the beginning.
  • Use dedicated route tables for public and private subnets.
  • Use security-group references instead of IP-based trust between tiers.
  • Maintain infrastructure and architecture artifacts in version control.
  • Build and validate the environment through incremental milestones.

Technology Stack

  • Amazon Web Services
  • Amazon VPC
  • Internet Gateway
  • Route Tables
  • Security Groups
  • Terraform
  • Mermaid
  • Git and GitHub
  • Astro

Future Enhancements

  • Multi-Availability Zone expansion
  • NAT Gateway for private-subnet outbound access
  • Application Load Balancer
  • Public and private EC2 workloads
  • Auto Scaling
  • VPC Flow Logs
  • VPC peering and more advanced connectivity patterns

Source Code

The complete Terraform implementation, documentation, architecture diagrams, and validation evidence for this case study are available on GitHub.

View Source on GitHub