Appearance
AWS Network Topology
Purpose
This document describes the AWS network architecture for the DR environment. The network follows a hub-spoke topology using AWS Transit Gateway as the central routing hub, with a Palo Alto VM-Series firewall handling north/south traffic inspection. The design mirrors the Azure network architecture to provide a consistent security posture across both environments.
Topology Overview
Internet
│
│ (north/south)
▼
┌────────────────────────┐
│ Firewall VPC │
│ Palo Alto VM-Series │
└────────────────────────┘
│
┌────────────────────────┐
│ Transit Gateway │
│ (hub / routing) │
└────────────────────────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌──────────┐ ┌──────────────┐
│ Identity │ │ Prod │ │ Dev │
│ VPC │ │ VPC │ │ VPC │
└─────────────┘ └──────────┘ └──────────────┘
│ ▲ ▲
└─────────────────┴────────────┘
(routed to identity,
not to each other)
┌──────────────────┐
│ Management VPC │
│ (admin access) │
└──────────────────┘VPC Summary
| VPC | Purpose | Connected To |
|---|---|---|
| Firewall VPC | North/south traffic inspection | Transit Gateway |
| Identity VPC | Directory / identity services | Transit Gateway, Prod, Dev |
| Production VPC | DR production workloads | Transit Gateway, Identity |
| Dev VPC | Development and test workloads | Transit Gateway, Identity |
| Management VPC | Infrastructure administration | Transit Gateway |
Transit Gateway
The AWS Transit Gateway acts as the central routing hub connecting all VPCs. Rather than creating individual VPC peering connections between every VPC, each VPC attaches to the Transit Gateway and routing is controlled centrally via Transit Gateway route tables.
Route Table Design
Routing is configured with specific routes only — no catch-all routes that allow unrestricted VPC-to-VPC communication. Each VPC only has routes to the VPCs it needs to reach, enforcing the same isolation model used in Azure.
| Route Table | Attached VPCs | Permitted Routes |
|---|---|---|
| Firewall route table | Firewall VPC | All VPCs (inspection point) |
| Spoke route table | Prod, Dev, Identity, Management | Firewall VPC, Identity VPC only |
| Management route table | Management VPC | Firewall VPC only |
Key Routing Rules
- All internet-bound traffic from spoke VPCs routes through the Firewall VPC via the Transit Gateway
- Prod and Dev VPCs have no direct route to each other through the Transit Gateway
- Both Prod and Dev have routes to Identity VPC for directory services
- Management VPC routes only to the Firewall VPC for admin access
Traffic Flow
North/South Traffic (Internet ↔ Internal)
All inbound and outbound internet traffic passes through the Palo Alto VM-Series firewall. Spoke VPCs have no direct internet gateway — all external traffic is routed through the Transit Gateway to the Firewall VPC.
- Inbound: Internet → Firewall VPC (untrust zone) → policy check → Transit Gateway → spoke VPC
- Outbound: Spoke VPC → Transit Gateway → Firewall VPC → untrust zone → Internet
East/West Traffic (VPC ↔ VPC)
Prod and Dev VPCs have no direct route to each other via the Transit Gateway. This is intentional — isolating production and development environments limits blast radius and prevents dev activity from impacting production workloads or data.
Both Prod and Dev independently route to the Identity VPC to allow directory and authentication services to function without creating a direct prod-dev path.
Management Traffic
The Management VPC connects via the Transit Gateway to the Firewall VPC only. Administrative access to infrastructure is restricted by Palo Alto firewall policy to authorized sources.
Comparison to Azure Network Architecture
The AWS network topology intentionally mirrors the Azure hub-spoke design to maintain a consistent security model across both environments. The key difference is the connectivity mechanism:
| Aspect | Azure | AWS |
|---|---|---|
| Hub connectivity | VNet peering | Transit Gateway |
| Traffic inspection | Palo Alto VM-Series | Palo Alto VM-Series |
| Spoke isolation | No prod/dev peering | No prod/dev TGW routes |
| Identity connectivity | VNet peering to both | TGW routes to both |
| Internet access | Via firewall hub | Via firewall VPC |
This consistency means that security policies, zone models, and traffic flow patterns are familiar across both environments, reducing operational complexity during a DR failover.
Security Design Rationale
Why Transit Gateway Over VPC Peering
VPC peering requires individual peering connections between every pair of VPCs that need to communicate. With multiple VPCs, this creates a complex mesh of connections that is difficult to manage and audit. Transit Gateway centralizes routing, making it easier to control and audit traffic paths, and allows route tables to enforce isolation without managing individual peering relationships.
Why Prod and Dev Are Isolated
Consistent with the Azure design, Prod and Dev have no direct network path to each other. A compromised dev environment cannot be used to pivot into production DR workloads, and a misconfiguration in dev cannot affect production systems.
Why a Dedicated Identity VPC
Placing identity services in their own VPC allows both Prod and Dev to consume directory services independently without being connected to each other. It also allows identity infrastructure to have its own security controls applied separately from workload environments.
Compliance Relevance
| Requirement | How Network Topology Addresses It |
|---|---|
| HIPAA §164.312(a) — Access Control | Prod/dev isolation limits access to ePHI systems |
| HIPAA §164.312(e) — Transmission Security | All traffic inspected by Palo Alto firewall |
| SOC2 CC6.6 — Logical Access | Network segmentation enforces environment boundaries |
| SOC2 CC6.7 — Data Transmission | Centralized firewall ensures all data flows are inspected |
Document History
| Date | Change | Author |
|---|---|---|
| March 2026 | Fixed Azure Network Topology link | Rory |
| February 2026 | Initial draft | Rory |