AWS Landscape 6: VPC Design

The Virtual Private Cloud (VPC) design establishes isolated and secure networking for SAP workloads while enabling cross-account and cross-environment connectivity. Each AWS account has a dedicated VPC, ensuring security boundaries, simplified routing, and support for high availability (HA) deployments across Availability Zones (AZs).
Key objectives of the VPC design:

• Ensure network isolation per account.
• Support HA across multiple AZs.
• Enable cross-VPC communication using a centralized Transit Gateway.
• Plan non-overlapping CIDR blocks for future expansion and on-prem connectivity.

Objective

• Design VPCs for each AWS account to:
• Provide isolated, secure networking for SAP workloads.
• Maintain connectivity between accounts via Transit Gateway.
• Support multi-AZ deployment for high availability.
• Coordinate IP addressing with on-premises networks for Direct Connect or VPN.

Overview:

Single VPC per account simplifies management and improves security.
Subnets are distributed across multiple AZs for HA.
Transit Gateway in the Network Service account centralizes connectivity.

Proposed VPC CIDR Allocation per Environment/Account:

Environment	Account Type	VPC CIDR
Production	Workload	10.0.0.0/16
Development	Workload	10.1.0.0/16
Pre-Production	Workload	10.2.0.0/16
Quality	Workload	10.3.0.0/16
Sandbox	Workload	10.4.0.0/16
Network Services	Shared Service	10.10.0.0/16
Shared Services	Shared Service	10.20.0.0/16
Security	Security	10.30.0.0/16
Logging	Security/Shared	10.40.0.0/16

Technical Steps to Implement VPCs

Step 1: Create VPC

Log in to the AWS account (repeat for each environment: Production, Dev, QA, Sandbox, Shared, Network, Security, Logging).

Navigate to VPC → Create VPC.

Provide the following:

Name tag: e.g., Prod-VPC, Dev-VPC

IPv4 CIDR block: Follow your design table (e.g., 10.0.0.0/16 for Production, 10.1.0.0/16 for Dev, etc.)

Tenancy: Default (choose Dedicated only if required)

Click Create VPC.

Step 2: Create Subnets per AZ

Create 2+ subnets per AZ for high availability.

Example for Production VPC (10.0.0.0/16):

Subnet     AZ  CIDR       Purpose

Subnet-1 AZ1 10.0.0.0/24 App EC2 + DB Primary

Subnet-2 AZ2 10.0.1.0/24 App EC2 + DB Secondary

Repeat subnet creation for:

• Dev, QA, Sandbox
• Shared Services
• Network Account

Best practice: Use consistent subnet naming conventions across accounts for clarity.

Step 3: Internet & NAT Gateways

Public Subnets

Attach Internet Gateway (IGW) to the VPC.

Associate public subnets with route tables that include a default route to IGW.

Private Subnets

Deploy NAT Gateway in a public subnet.

Update private subnet route tables to route internet-bound traffic through the NAT Gateway.

Step 4: Configure Route Tables

Public Subnet Route Table:

Route 0.0.0.0/0 → IGW

Private Subnet Route Table:

Route 0.0.0.0/0 → NAT Gateway

Transit Gateway Routing:

Configure route tables to allow cross-account VPC connectivity via Transit Gateway.

Step 5: Apply Security

Security Groups:

Create SGs per application, database, or service tier.

Use least privilege rules (allow only necessary ports and IP ranges).

Network ACLs (NACLs):

Apply subnet-level controls for additional security segmentation.

Segmentation:

Separate workloads into:

• Application subnets
• Database subnets
• Management / bastion hosts
• Shared services (DNS, AD, monitoring)

Step 6: Connect VPCs via Transit Gateway

Deploy Transit Gateway in the Network Service Account.

Attach all VPCs: Production, Dev, QA, Sandbox, Shared Services, Security, Logging.

Update Route Tables:

Add Transit Gateway routes in each VPC to enable cross-VPC communication.

Verify Connectivity:

Test routing between accounts while maintaining segmentation policies.

Diagram – VPC Connectivity Across Accounts:

Network Service VPC

• Contains Transit Gateway for cross-VPC connectivity.
• Acts as the central routing hub for all workload and shared VPCs.

Workload VPCs

• Prod, Dev, and QA VPCs each have AZ1 and AZ2 subnets for high availability.
• Connect to Transit Gateway for cross-account / cross-environment communication.

Central VPCs for Shared Functions

• Shared Services VPC: CI/CD, automation, common tools
• Security VPC: Threat detection, monitoring, security tooling
• Logging VPC: Centralized audit logs

Scalability & Governance

• Transit Gateway allows centralized management of routes and security.
• Adding new workload VPCs only requires attaching to the TGW.

Notes and Best Practices

• Single VPC per account simplifies isolation and security management.
• CIDRs are planned for future expansion and on-prem integration.
• Transit Gateway ensures scalable and centralized connectivity between accounts and environments.
• Subnet distribution across AZs supports HA deployments for SAP workloads.