Skip to main content
Latest Documentation
This is the latest documentation for the Cloud Posse Reference Architecture. To determine which version you're currently using, please see Version Identification.
Version: v1
Sponsor @cloudposse

Decide on VPC NAT Strategy

DRAFT

Context and Problem Statement​

Considered Options​

Option 1 - One VPC per Region, Per Platform Account with Dedicated NAT Gateways per AZ (Recommended)​

Our Recommendation is to use Option 1 because it keeps the separation by stage and ensures all egress per stage

originates from a specific set of IPs


Pros​

  • Easily managed with terraform

  • Easier for third parties to restrict IPs for ingress traffic

  • Keep accounts symmetrical

Cons​

  • More expensive to operate as more NAT gateways are deployed (mitigated by reducing the number of gateways in lower stages)

Option 2 - One VPC per Region, Per Platform Account with Centralized NAT Gateways per AZ in Network Account​


The Compliant Framework for Federal and DoD Workloads in AWS GovCloud (US) advocates for a strategy like this, whereby in the Network (transit) account, there will be a DMZ with a Firewall.


Pros​

  • Ideally suited for meeting specific compliance frameworks

Cons​

  • All traffic from all accounts egress through the same NAT IPs, making it hard for third-parties to restrict access (e.g. staging accounts can access third-party production endpoints)

  • Shared NAT gateways are “singletons” used by the entire organization; changes to these gateways are not be rolled out by stage. Risky to make changes - in the critical path of everything.

Option 3 - Shared VPCs with Dedicated NAT Gateways​

Pros​

  • Less expensive

Cons​

  • All traffic from all accounts egress through the same NAT IPs, making it hard for third-parties to restrict access (e.g. staging accounts can access third-party production endpoints)

  • Shared VPCs are “singletons” used by multiple workloads; changes to these VPCs are not be rolled out by stage. Risky to make changes.

References​