Connecting Amazon VPCs

Outbound Internet Access from Private Subnets ## NAT Gateway ## NAT Instance (Legacy Approach) ## VPC Peering: Direct VPC-to-VPC Connectivity ## Transit Gateway: Centralized Network Hub ## Hybrid Connectivity: On-Premises to AWS ## Site-to-Site VPN ## AWS Direct Connect ## Private Connectivity with AWS PrivateLink ## Multi-Account and Landing Zone Architectures ## Choosing the Right Connectivity Model ## Operational Considerations ## Conclusion Designing a VPC is only the beginning. In real-world systems, networks rarely exist in isolation. Applications need to communicate with other VPCs, access the internet securely, and integrate with on-premises infrastructure. This final part of the VPC series explores the primary connectivity options available in AWS, how they differ, and when each should be used in production environments. Most production workloads run in private subnets but still require outbound internet access for updates, API calls, or external integrations. A NAT Gateway allows instances in private subnets to initiate outbound internet traffic while remaining unreachable from the internet. NAT Gateways are the standard solution for outbound internet access in private subnets. A NAT instance is an EC2-based alternative to a NAT Gateway. Today, NAT instances are used only in specialized or cost-sensitive scenarios. VPC peering enables private connectivity between two VPCs using AWS’s internal network. Important constraints: VPC peering is simple and effective for small architectures but becomes difficult to manage at scale. AWS Transit Gateway acts as a hub that connects multiple VPCs and on-premises networks. Transit Gateway is commonly used in enterprise-scale AWS environments to replace complex peering meshes. Many organizations operate in hybrid environments where workloads span both on-premises data centers and AWS. Direct Connect is preferred for latency-sensitive or high-throughput workloads. PrivateLink allows services to be exposed privately between VPCs without full network connectivity. PrivateLink is increasingly used in service-oriented and multi-tenant designs. In mature AWS environments: Typical design includes: This approach improves security, governance, and scalability. Architectural simplicity should always be prioritized over premature complexity. Networking issues are often difficult to debug without proper visibility. Amazon VPC provides a powerful and flexible networking foundation, but its true strength lies in how well it connects systems together. Whether enabling secure internet access, linking multiple VPCs, or extending networks to on-premises environments, choosing the right connectivity option is crucial for long-term success. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Fully managed and highly available within an AZ - Scales automatically - Requires a public subnet and Elastic IP - No inbound connections allowed - Manual scaling and patching - Single point of failure unless carefully designed - Lower throughput - CIDR ranges must not overlap - No transitive routing - One-to-one relationships only - Simplified routing - Supports thousands of attachments - Enables transitive connectivity - Ideal for multi-account architectures - Encrypted tunnel over the internet - Quick to set up - Suitable for low to moderate traffic - An initial connectivity solution - A backup for Direct Connect - Dedicated private network connection - Consistent latency and higher bandwidth - More expensive but highly reliable - No need for peering or routing changes - Reduced attack surface - Ideal for SaaS-style architectures - Each workload or team often has its own AWS account - Networking is centralized - Shared services are isolated - A shared networking account - Transit Gateway for connectivity - Centralized inspection and logging - Monitor NAT Gateway costs and traffic - Plan CIDR ranges with future growth in mind - Avoid overlapping networks - Centralize logging and monitoring - Document network architecture clearly