Enterprise VPC Peering

Overview

CAL-002 extends the networking foundation established in CAL-001 into a two-VPC enterprise architecture.

The case study models a fictional healthcare organization that separates shared operational services from a patient-facing application environment processing protected health information.

The implementation demonstrates reusable Terraform modules, private VPC peering, explicit cross-VPC routes, controlled outbound internet access, layered network security, and validation of the deployed environment against the documented design.

Business Scenario

The organization requires separate cloud environments for shared management services and patient-platform workloads.

Management, monitoring, logging, and DNS responsibilities belong in a Shared Services VPC. Patient-facing application components and private PHI-processing workloads belong in a separate Patient Platform VPC.

The environments must communicate over approved private paths without creating broad trust between the VPCs or exposing private workloads directly to the internet.

Conceptual Architecture

The conceptual architecture separates business and operational responsibilities before introducing detailed AWS networking components.

Architecture Overview

Network Design

Shared Services VPC

• VPC CIDR: 10.10.0.0/16
• Public subnet: 10.10.1.0/24
• Private subnet: 10.10.11.0/24
• Independent Internet Gateway and NAT Gateway
• Private management and operational service responsibilities

Patient Platform VPC

• VPC CIDR: 10.20.0.0/16
• Public subnet: 10.20.1.0/24
• Private PHI subnet: 10.20.11.0/24
• Independent Internet Gateway and NAT Gateway
• Controlled public ingress and private application workloads

VPC Peering and Routing

A VPC Peering Connection provides a private network path between the two VPCs. Peering does not create implicit trust, so routing and security policy remain explicit.

• Shared Services private route:10.20.11.0/24 through the peering connection
• Patient Platform private route:10.10.11.0/24 through the peering connection
• No broad VPC-to-VPC route using the full VPC CIDR ranges
• No transitive routing through the peering connection

Reusable Terraform Design

The CAL-001 networking pattern was refactored into a reusable local Terraform module and instantiated twice.

• VPC
• Public and private subnets
• Internet Gateway
• Elastic IP and NAT Gateway
• Public and private route tables
• Subnet-to-route-table associations
• Common naming and tagging

Purpose-specific resources—including VPC peering, peering routes, Security Groups, and the Private PHI Network ACL—remain in the root configuration so the foundational module stays reusable.

Security Design

Security is applied through multiple independent layers rather than treating any single control as the complete boundary.

Security Groups

• Public Web Security Group for HTTP and HTTPS ingress
• Private Application Security Group permitting TCP 8080 from the public application tier
• Approved management access on TCP 22 from the Shared Services environment
• Management Security Group for Shared Services workloads

Private PHI Network ACL

• TCP 8080 from the Patient Platform public subnet
• TCP 22 from the Shared Services private subnet
• Required ephemeral response traffic
• Outbound HTTPS for approved updates and services
• Implicit denial of all other traffic

Controlled Internet Egress

Each VPC has an independent NAT Gateway. Private workloads can reach approved internet services for patches, software updates, and package repositories without receiving public IP addresses or routing directly to an Internet Gateway.

Validation

The final deployment created 38 AWS resources and was validated through:

• terraform fmt -recursive
• terraform validate
• Terraform execution-plan review
• Successful Terraform deployment
• Post-deployment idempotency verification
• AWS CLI inspection
• AWS Management Console inspection
• VPC, subnet, gateway, routing, and peering verification
• Security Group and Network ACL verification
• Successful resource teardown after evidence collection

A post-deployment Terraform plan reported no changes, confirming that the deployed environment matched the desired configuration immediately after deployment.

Implementation Evidence

Key Engineering Decisions

• Reuse the CAL-001 networking foundation through a local module.
• Keep purpose-specific security outside the generic VPC module.
• Limit peering routes to approved private subnet CIDRs.
• Provide independent outbound egress for each VPC.
• Use defense in depth through routing, Security Groups, and NACLs.
• Keep private management and PHI workloads without public IPs.
• Defer multi-AZ and production availability features.
• Destroy disposable resources after validation.

Lessons Learned

• VPC peering creates connectivity, not authorization.
• Stateless NACL rules require explicit return-path design.
• Generic infrastructure construction and architecture-specific policy should remain separated.
• Documentation is most useful when each artifact has a clearly defined engineering responsibility.
• Strong scope boundaries are necessary to finish, validate, and publish architecture work.

Technology Stack

• Amazon Web Services
• Amazon VPC
• VPC Peering
• Internet Gateways
• NAT Gateways
• Route Tables
• Security Groups
• Network ACLs
• Terraform
• Mermaid
• Git and GitHub

Repository

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