Designing a Production-Ready Multi-Environment AWS VPC Foundation with CDK & TypeScript

Modern cloud platforms—especially observability systems powered by OpenTelemetry—require a secure, scalable, and highly repeatable networking baseline. Without a well-designed VPC architecture, your microservices, tracing pipelines, telemetry collectors, or monitoring agents will eventually hit:

• IP conflicts
• Routing inconsistencies
• Security gaps
• Cross-environment interference
• Rising NAT Gateway costs
• Limited scalability

To avoid these issues, you need a robust networking layer created through Infrastructure-as-Code (IaC).
This article walks you through a production-ready AWS networking foundation, implemented using AWS CDK (TypeScript), designed for dev/staging/prod environments and built as the baseline for an enterprise observability platform.

Why Networking Matters in an Observability Platform

A high-performance observability system depends on:

• Consistent multi-environment VPC structure
• Private access to AWS services (S3, DynamoDB, etc.)
• Isolated subnets for collectors, agents, and telemetry buffers
• Predictable IP-space for future scaling (EKS, ECS, Lambda, OpenTelemetry collectors)
• High availability across Availability Zones
• Minimal data transfer costs

This project solves all of these problems at the foundation layer.

High-Level Architecture: Multi-Environment VPC Foundation

Each environment—dev, staging, and prod—gets a fully isolated VPC with deterministic CIDR allocations.

VPC Architecture Diagram

This diagram illustrates the environment-specific VPC (10.x.0.0/16) created by AWS CDK. It shows multi-AZ public subnets, the Internet Gateway, route table propagation, and VPC Gateway Endpoints for S3 and DynamoDB. The diagram highlights how public subnets route outbound traffic through an IGW while VPC endpoints provide private access to AWS services without traversing the internet.

Environment-Aware Design (Key Feature)

A single CDK stack deploys differently based on your input:

cdk deploy --context environmentSuffix=dev
cdk deploy --context environmentSuffix=staging
cdk deploy --context environmentSuffix=prod

Automatically Assigned CIDR Blocks

Why this matters:
When building multi-account or multi-region observability platforms, overlapping IP blocks cause:

• VPC peering failures
• Transit gateway routing issues
• Cross-environment collisions

This design eliminates that risk.

High-Availability Public Subnet Architecture

Two public subnets are deployed across multiple Availability Zones:

• Enables fault-tolerant load balancers
• Supports zero-downtime deployments
• Prepares for future private subnet tiers
• Ensures resilience for observability agents or collectors deployed publicly

Every subnet has:

• Auto-assign public IPs
• Routes to IGW
• High availability across AZs
• Output exports for future stacks (ECS, Lambda, EC2, EKS, OpenTelemetry collectors)

Internet Gateway & Routing Design

This diagram explains how the public subnets (10.x.1.0/24 and 10.x.2.0/24) are deployed across two Availability Zones, each automatically assigned public IPs. Both subnets forward outbound traffic to a shared route table that directs 0.0.0.0/0 to the Internet Gateway, enabling secure internet access for resources like load balancers or bastion hosts.

This allows public resources (such as bastion hosts, NAT gateways, load balancers, or telemetry UIs) to communicate with the internet securely.

Private, Cost-Free Access to S3 & DynamoDB

The stack provisions gateway endpoints for:

• Amazon S3
• Amazon DynamoDB

Why is this critical?

• Observability pipelines often write huge volumes of data to S3 (traces, logs, metrics).
• ✨ DynamoDB may be used for metadata, ingestion queues, or span indexes.
• 💸 Without endpoints, you pay NAT Gateway data-processing charges.
• 🔐 With endpoints, traffic stays inside AWS’s private network.

Endpoint Architecture

This diagram focuses on the VPC Gateway Endpoints that enable private, cost-free connectivity to Amazon S3 and DynamoDB. It demonstrates how these endpoints eliminate the need for NAT Gateways and public routing by keeping traffic entirely within the AWS network backbone.

What This Stack Deploys

CDK Deployment Workflow

Deploy to Dev

cdk deploy --context environmentSuffix=dev

Deploy to Staging

cdk deploy --context environmentSuffix=staging

Deploy to Production

cdk deploy --context environmentSuffix=prod

Why This Design Works Perfectly for Observability Platforms

A production observability stack (OpenTelemetry + OTEL collector + tracing backends) needs:

• Private networking
• Dedicated subnet isolation
• HA routing
• Fast access to storage (S3)
• Predictable IP layout
• Gateway endpoints for telemetry storage
• Zero NAT costs during ingestion bursts

This VPC acts as the base layer for all of that.

Conclusion

A robust observability platform demands a solid, scalable networking foundation—and AWS CDK makes it effortless to codify and maintain.

This multi-environment VPC architecture provides:

• Consistent, isolated deployments
• High availability across AZs
• Secure routing & private service access
• Cost-optimized S3/DynamoDB patterns
• A future-proof foundation for OpenTelemetry, containers, and microservices

This is the kind of infrastructure that scales with your organization, your telemetry volume, and your platform maturity.

Repository & Source Code

The complete Infrastructure-as-Code implementation for the multi-environment VPC foundation is available on GitHub:

GitHub Repository:
https://github.com/rahulladumor/observability-platform-opentelemetry