Your third AWS account usually forces the network question: the new workload needs a database in another account, the internet, maybe the office VPN. Someone proposes VPC peering, someone says "just share the VPC", and someone wants a Transit Gateway.
Each option settles three things that are hard to undo: who can break whose traffic, which account pays per GB, and who edits the route tables. This guide to AWS multi-account networking picks a model per traffic path, scores each on failure domain, cost and ownership, and prices a monthly bill from AWS list prices.
Which AWS multi-account networking model fits each traffic path?
Choose per traffic path, not per account count. Transit Gateway carries east-west traffic past a handful of VPCs, PrivateLink or VPC Lattice expose single services, centralized egress suits light internet traffic, and inspection sits where traffic already converges.
The AWS Security Reference Architecture (SRA) Network account sets the threshold: peering MAY be used when both VPCs are controlled and secured and fewer than 10 are connected. Otherwise you SHOULD use Transit Gateway.
| Model | Fits path | Failure domain | Cost inputs (us-east-1) | Who owns routes | Main limit |
|---|---|---|---|---|---|
| VPC sharing | East-west in one VPC | The whole shared VPC | Owner pays NAT and attachments | VPC owner | Same organization; 100 participants per VPC |
| Transit Gateway | East-west, egress, inspection | Every VPC on a route table | $0.05/attachment-hour + $0.02/GB sent in | Gateway owner; spokes own subnet routes | Overlapping CIDRs need 1:1 NAT |
| VPC peering | East-west | One pair | $0.01/GB each way across AZs | Each VPC owner | Not transitive; 50 per VPC |
| PrivateLink | One service, one way | One endpoint per AZ | $0.01/AZ-hour + $0.01/GB | Consumer endpoint, provider service | Provider can't initiate connections |
| VPC Lattice | Service to service | One service network | $0.025/service-hour + $0.025/GB | Service network owner | 10 Gbps per service per AZ |
Name the traffic path before you pick a service
Most designs carry three kinds of traffic:
- East-west: VPC to VPC, including shared services and on-premises routes arriving through a hub.
- Egress: private subnets reaching the internet through NAT gateways, per VPC or in one egress VPC.
- Inspection: a stateful firewall on east-west traffic, egress, or both.
A model can be right for one path and wrong for another. Peering carries no egress through a peer's gateways, and AWS Network Firewall "cannot be deployed to inspect traffic between VPCs that are peered together" (Deployment models for AWS Network Firewall). Peered VPCs that later need inspection face a migration.
Excalidraw diagram loading.
Five ways to connect VPCs across accounts
Three of these models use AWS Resource Access Manager (RAM) to share one account's resources across the organization. Prices are us-east-1 list prices as of October 2026.
VPC sharing: one VPC, many accounts
AWS VPC sharing lets a network account own a VPC and share its subnets through RAM within the organization. Participants create their own resources but can't change route tables, network ACLs, internet gateways, NAT gateways or Transit Gateway attachments (owner and participant permissions). AWS positions it for applications "within the same trust boundaries".
Transit Gateway: a Regional router you own
"A transit gateway acts as a Regional virtual router" (How AWS Transit Gateway works). The network account shares it through RAM, and each workload account attaches its own VPC. Only the owner edits gateway route tables, which is how you segment: spokes reach the egress VPC, and a blackhole route stops spokes reaching each other.
Attachments cost $0.05 an hour plus $0.02 per GB sent in (Transit Gateway pricing), with room for 5,000 attachments and 100 Gbps per attachment per AZ (quotas). Overlapping CIDRs aren't supported by default, so plan CIDRs with IPAM before the first attachment. Since October 2026, managed 1:1 NAT on an attachment works around that at Regional NAT gateway rates.
VPC peering: direct, one pair at a time
Peering connects two VPCs across accounts and Regions with no hourly fee, and cross-AZ traffic costs $0.01/GB each direction (Amazon VPC pricing). It isn't transitive, and overlapping CIDRs can't peer (How VPC peering works). A full mesh needs n(n-1)/2 connections, so 10 VPCs need 45. The SRA cites that mesh growth when it draws its line at 10.
PrivateLink: one service, one direction
PrivateLink publishes one provider service as an interface endpoint in consumer VPCs. Consumers initiate the connection, and the provider only accepts or rejects it (PrivateLink concepts). Overlapping CIDRs don't matter. An endpoint in three AZs costs $21.90 a month before the $0.01/GB (PrivateLink pricing).
VPC Lattice: service-to-service without routing
VPC Lattice puts services in a service network, shared through RAM and associated with consumer VPCs; IAM auth policies decide who calls what. It uses link-local addresses, so overlapping ranges need no Transit Gateway or peering. A service costs $18.25 a month plus $0.025/GB and request charges (VPC Lattice pricing). Six AZ IDs, including use1-az3 and euw1-az4, don't support it (quotas).
What one bad route table takes down
A failure domain is everything one bad component or change stops. Centralizing cuts what you manage and widens what each piece can break.
- Shared VPC: participants share the owner's route tables and gateways, so one wrong route reaches all of them (my reading of the permission model). If the owner leaves the organization, Auto Scaling can't replace instances and load balancers can't create network interfaces (AWS networking blog).
- Transit Gateway: a wrong route reaches every VPC associated with that table. Only resources in AZs with an attachment subnet reach the gateway, so a skipped AZ is stranded.
- Centralized NAT: per the AWS whitepaper, if an AZ fails, "all traffic will flow via the Transit Gateway and NAT gateway endpoints in the other Availability Zone." A single failed NAT gateway is worse: "traffic might be dropped in that Availability Zone."
- Peering, PrivateLink and Lattice: one pair, endpoint or service.
Past a handful of VPCs, I'd still take the wider Transit Gateway failure domain. One account's route tables are easier to review than 45 peerings, as long as route changes get code review.
Does centralized egress save money? Run the numbers for your traffic
Centralized egress sends each spoke's internet traffic through Transit Gateway to one egress VPC with NAT gateways. AWS's whitepaper on centralized IPv4 egress argues both sides. Centralizing NAT gateways "can be a viable option to reduce costs", then:
"In some edge cases when you send huge amounts of data through NAT gateway from a VPC, keeping the NAT local in the VPC to avoid the Transit Gateway data processing charge might be a more cost-effective option."
Your traffic decides which applies:
| Input | us-east-1 rate | Billed to | Dominates when |
|---|---|---|---|
| NAT gateway hours | $0.045/hour per AZ | VPC with the NAT | Many VPCs in three AZs |
| NAT processing | $0.045/GB | VPC with the NAT | Always; same in both designs |
| Transit Gateway attachment | $0.05/hour | VPC owner | Spokes attached only for egress |
| Transit Gateway processing | $0.02/GB sent in | Sending VPC's owner | Heavy spokes |
| Cross-AZ transfer | $0.01/GB each way | Both sides | NAT in another AZ |
| Network Firewall | $0.395/endpoint-AZ-hour + $0.065/GB | Firewall owner | Inspection on egress |
What Transit Gateway costs per spoke
An attachment is $36.50 a month (730 × $0.05) before traffic, and "Data Processing is charged to the VPC owner who sends the traffic to Transit Gateway." For internet traffic, that bills request bytes to the spoke and response bytes to the network account. AWS gives no egress example, so this is my reading of the pricing page. Flexible cost allocation (November 2025) can reassign either leg.
Worked example: five spokes and one heavy pipeline
Assumptions: us-east-1, 730 hours, three AZs, five spokes already attached for east-west traffic. Traffic is total NAT-processed GB in both directions; each GB enters the gateway once. NAT processing and internet transfer out are equal in both designs and excluded. This arithmetic is derived from AWS list prices (us-east-1, accessed October 2026), not an AWS figure.
Four spokes send 2,000 GB a month combined. The fifth runs a pipeline that grows to 40,000 GB.
| Design | Light (2,000 GB) | Pipeline running (42,000 GB) |
|---|---|---|
| Local NAT in every spoke (5 × 3 × $0.045 × 730) | $492.75 | $492.75 |
| Centralized ($98.55 NAT + $36.50 attachment + $0.02/GB) | $175.05 | $975.05 |
| Hybrid: pipeline keeps local NAT ($135.05 + $40 + $98.55) | n/a | $273.60 |
Centralizing saves $317.70 a month at light traffic and costs $482.30 more once the pipeline runs. The hybrid beats both, matching AWS's NAT gateway guidance for multiple VPCs: distributed NAT for large VPCs, centralized for small ones.
Per spoke, a local three-AZ NAT ($98.55) beats central routing above about 4,900 GB a month ($98.55 ÷ $0.02), before its share of the egress VPC, when the attachment is needed anyway. When it exists only for egress, the line is about 3,100 GB ($62.05 ÷ $0.02).
At 42,000 GB, NAT processing alone is $1,890 a month in either design.
Savings that apply in either design
S3 and DynamoDB gateway endpoints have no hourly or processing charge. Associate one with each spoke's route tables to move that traffic off NAT; the Amazon VPC Endpoint policy generator writes its access policy. Route each spoke AZ to the same-AZ NAT gateway, or cross-AZ transfer joins the bill. A Regional NAT gateway bills the same $0.045 per AZ-hour with less route-table work.
Where should inspection sit, and why does return traffic get dropped?
Egress-only inspection is simple: a Network Firewall endpoint in the egress VPC, ahead of the NAT gateway. It "doesn't require Transit Gateway appliance mode, because you aren't sending traffic between attachments" (NAT gateway with AWS Network Firewall).
East-west inspection is where flows break. Without appliance mode, Transit Gateway keeps traffic in its source AZ, so a response from AZ 2 hits the AZ 2 firewall. It "is therefore dropped, because the appliance in Availability Zone 2 is not aware of the original request." Enable appliance mode on the inspection VPC attachment:
aws ec2 modify-transit-gateway-vpc-attachment \
--transit-gateway-attachment-id tgw-attach-0123456789abcdef0 \
--options ApplianceModeSupport=enable \
--query 'TransitGatewayVpcAttachment.Options.ApplianceModeSupport'
The response describes the modified attachment, so with JSON output the query should print "enable". Each flow then stays in one AZ for its lifetime.
Since July 2025, Network Firewall can also attach to Transit Gateway natively, with appliance mode automatic. Routing is static only, and third-party firewalls and Cloud WAN aren't supported. The managed VPC can't hold a NAT gateway, so egress crosses the gateway twice and pays processing on each hop (Choosing the right inspection architecture).
Three AZs of firewall endpoints cost $865.05 a month (3 × $0.395 × 730) plus $0.065/GB (Network Firewall pricing). A NAT gateway chained behind the firewall has its hourly and processing charges waived, one-for-one against firewall hours and GB. For north-south inspection of four or fewer VPCs, AWS finds a firewall endpoint per VPC the cheapest pattern, though it supports neither TLS inspection nor east-west traffic.
The SRA adds that the inspection VPC "MUST NOT host any other workload." You can also delegate Firewall Manager to the network account.
Who owns the route tables when networks span accounts?
In an AWS multi-account network architecture, the first decision is who owns the shared pieces. The SRA's Network account "isolates the networking services, configuration, and operation from the individual application workloads," with RAM shares scoped to the fewest OUs possible. See where the network account fits in your account structure.
Transit Gateway splits ownership cleanly between gateway route tables and spoke subnet routes; a shared VPC concentrates routing, and peering scatters it. Billing draws a different line: by default, spokes pay for the bytes they send, the network account for egress NAT and response bytes, and the firewall owner for Network Firewall.
An AWS SCP pattern denies ec2:CreateInternetGateway, ec2:AttachInternetGateway, ec2:CreateEgressOnlyInternetGateway, ec2:CreateVpcPeeringConnection and ec2:AcceptVpcPeeringConnection in workload OUs. VPC Block Public Access enforces the internet-gateway side through a declarative policy. Attach it to workload OUs, because bidirectional mode blocks the internet gateway your egress VPC needs. A spoke that keeps its own NAT needs an internet gateway too, so put that account in an OU the SCP doesn't cover and allow a Block Public Access exclusion for its VPC.
An AWS multi-account networking decision flow for your next account
Start with the service, not the network. Overlapping CIDRs or one-way access to one service call for PrivateLink or VPC Lattice. Workloads that share one trust boundary, with one team owning the network, can share a VPC. Below 10 controlled VPCs, with no transit or inspection, peering is enough.
Everything else gets a Transit Gateway in a network account, inspection placed as above, and egress sized per spoke against the 4,900 GB line. If egress must be inspected, a local spoke also pays for its own firewall endpoints ($865.05 a month in three AZs, NAT charges waived), so the line moves to about 43,000 GB ($865.05 ÷ $0.02). Teams still splitting their first account should finish that first.
What the landing zone sets up, and what your network stacks add
The AWS CDK Landing Zone is the account foundation underneath. Its AccountSecurityStackSet deletes the default VPC in every configured Region of every member account and strips every rule from the default security group of each new VPC (constructs reference). Workloads only run in VPCs someone designed, and a PrivateLink endpoint or Lattice resource gateway left on the default security group gets no traffic until you add rules.
A network account is a pull request. Add the account to src/config/organization-structure.ts, for example under InfrastructureOU, and the pull request workflow posts the organization diff as a comment. The OU-targeted StackSets apply the baseline when it joins. CdkBootstrapStackSet targets only the Development and Production OUs, so extend it before deploying network stacks there with CDK.
Trusted access for AWS RAM is already enabled for the organization, and VPC Block Public Access stays off until you add it as a declarative policy. The landing zone ships no shared networking, so the Transit Gateway, egress and inspection VPCs, and RAM network shares here are your own stacks.
Frequently Asked Questions
Do I need a separate network account with only two or three accounts?
Can Transit Gateway connect VPCs with overlapping CIDRs?
Should I use Cloud WAN instead of Transit Gateway?
How do I charge inspection costs back to workload accounts?
Next step
Build Your Network Account on a Baseline You Review in Code
Key Takeaways
- Decide east-west, egress and inspection separately.
- Centralizing widens what one route table breaks, so review Transit Gateway routes like code.
- Above about 4,900 GB a month through NAT, an attached spoke is cheaper with its own NAT; about 43,000 GB if its egress is inspected.
- Enable appliance mode on the inspection VPC attachment.
- Create the network account before the first share.
Next, draw the three AWS multi-account networking paths for your accounts and price the heaviest spoke. Then read the AWS multi-account strategy guide.