Build multi-account AWS connectivity with VPC Lattice as the sole network fabric

Rahul Sahotay, Amazon Web Services

Summary

As a multi-account AWS footprint grows from a handful of accounts into the hundreds, one question keeps resurfacing: how much networking should each workload account really own? The instinctive answer is "everything it needs to be self-sufficient." So every account gets its own interface VPC endpoints, its own NAT gateways, its own route tables and DNS. It works. It also means the same networking stack is built, paid for, patched, and audited hundreds of times over, and the cost and operational load climb in lockstep with the account count.

There is another way to draw the line. Instead of every account owning its connectivity, you build it once in a central Network account and let workload accounts consume it. This pattern uses Amazon VPC Lattice as that shared fabric for three connectivity needs that nearly every workload has: private access to AWS services, controlled internet egress, and ingress for consumers that live outside the fabric. A workload account joins by creating a single VPC association, and from that moment it inherits private AWS-service access and filtered egress with no per-account endpoints, gateways, or route tables to stand up.

It is worth being precise about where this fits. VPC Lattice routes by DNS name and service network, not by IP address, so this is a cost-effective alternative for the service-access, egress, and ingress patterns, not a wholesale replacement for IP routing. Transit Gateway remains the right tool for east-west routing between VPCs, hybrid connectivity over Direct Connect or VPN, and centralized traffic inspection. The two are not mutually exclusive: a single VPC can hold a Transit Gateway attachment and a VPC Lattice association at the same time, each carrying the traffic it handles best.

What this pattern gives you

The shared fabric is deployed once in the Network account and exposed through three environment-scoped service networks (dev, test, prod). The companion repository provides reference implementations in both AWS CDK (TypeScript, 14 stacks) and AWS CloudFormation (11 templates), with architecture diagrams and a security review summary.

Prerequisites and limitations

Prerequisites

Limitations

Product versions

Architecture

Target technology stack

Target architecture

Everything in this pattern is built once in the central Network account and offered outward, so a workload account gains its connectivity the moment it creates a single VPC association. Three pillars sit on that one shared fabric:

Figure 1: High-level topology showing the three pillars on a single VPC Lattice fabric.

Figure 2: Shared endpoint data flow. A workload VPC resolves an AWS service domain through the VPC Lattice-managed Private Hosted Zone, and traffic reaches the shared interface endpoint in the Network account through the Resource Gateway.

Figure 3: Centralized egress data flow. A workload sends outbound traffic to the shared Squid proxy through the service network, where an FQDN allowlist filters the request before it leaves through the Network account.

Figure 4: Ingress data flow. External, on-premises, and cross-Region consumers reach shared services through a Service Network Endpoint in the ingress VPC.

Automation and scale

Onboarding a workload account is deliberately dull: one VPC association with PrivateDnsEnabled, plus a security group that permits egress to the VPC Lattice managed prefix list, rolled out at scale through a service-managed AWS CloudFormation StackSet or AWS CDK. VPC Lattice creates Private Hosted Zones automatically so standard AWS service domains (for example, ssm.us-east-2.amazonaws.com) resolve to Lattice addresses in the 129.224.0.0/17 range with no per-workload DNS configuration.

Tools

AWS services

Code

The reference implementation is in the GitHub repository aws-samples/sample-vpc-lattice-multi-account-connectivity, provided in both AWS CDK (TypeScript, 14 stacks) and AWS CloudFormation (11 templates), with 4 architecture diagrams and 15 documentation files.

Best practices

These recommendations apply to the shared-fabric model described in this pattern. They cost nothing to adopt on day one and become expensive to retrofit later. Apply them before onboarding your first wave of workload accounts.

Naming: make names a contract, not decoration

VPC Lattice resource names are functional. The workload association automation looks up the target Service Network by name at deploy time, so a name is a contract the onboarding process depends on.

Prescriptive recommendation: Pick one short, lowercase, org-wide prefix and build every name from the same ordered parts: prefix, scope or service, environment, role. Note that only Service Networks and Service Network Endpoints are per-environment; Resource Gateways and Resource Configurations are shared, one per VPC or per service, and serve all three environments:

Per environment:
  sn-dev-shared              (dev Service Network)
  sn-test-shared             (test Service Network)
  sn-prod-shared             (prod Service Network)
  sne-dev-ingress            (Service Network Endpoint for dev ingress)

Shared across environments:
  net-endpoint-resource-gw   (Resource Gateway, one per Endpoint VPC)
  net-egress-resource-gw     (Resource Gateway, one per Egress VPC)
  ssm-endpoint-rc            (Resource Configuration, one per exposed service)
  squid-proxy-rc             (Resource Configuration for the egress proxy)

Encode the environment, never the account: environment is the unit of isolation in this pattern, so it belongs in the name; account identity belongs in tags.

Why this matters: Consistent naming enables automated lookup, simplifies IAM policy conditions, and makes CloudTrail log analysis practical at scale.

Tagging: make every resource attributable from day one

Tags drive cost allocation, automation filtering, and governance queries. Activate cost allocation tags in the management account billing console before deploying; activation is forward-looking only, so untagged early resources never show up in cost data.

Mandatory tag set:

Assign explicit security groups to every resource that creates an ENI

If your landing zone (AWS Landing Zone Accelerator or similar) strips default security group rules, resources that create elastic network interfaces (Resource Gateways, Service Network Endpoints, Fargate tasks, and interface VPC endpoints) fail with silent connection timeouts rather than an explicit error. Always attach a named, explicitly configured security group to these resources. This is the most time-consuming failure mode to diagnose, because nothing logs an error; plan for it up front.

Finalize naming and custom domains before you create resources

VPC Lattice custom domain names cannot be changed after a resource is created. Changing a domain requires deleting and recreating the resource, which drops all of its associations and Resource Configurations. Lock the naming convention above before the first deploy.

Use split-horizon DNS when ingress (SN-E) and VPC-association paths coexist

A single DNS record cannot serve both paths. The Service Network Endpoint path resolves to the endpoint's per-AZ secondary IPs, while the VPC-association path resolves to VPC Lattice-managed IPs in the 129.224.0.0/17 range. If an Ingress VPC with Service Network Endpoints coexists with workload VPCs that associate directly, use separate Private Hosted Zones associated with the appropriate VPCs.

Enable RAM organization sharing before standing up the fabric

OU-scoped Resource Access Manager shares only work after sharing with AWS Organizations has been enabled in the management account (aws ram enable-sharing-with-aws-organization). Do this first, or the shares fail.

Monitoring: the trade-off for centralization

The shared-fabric model concentrates connectivity into fewer components. This is both its strength (one place to govern, secure, and observe) and its primary operational trade-off (a failure in the shared fabric affects all consumers). Centralized monitoring is not optional; it is the trade you make for reducing per-account overhead.

Day-one observability:

Quota planning

Track usage against the quotas that matter for this pattern. Defaults are Region-specific and adjustable through AWS Support.

The practical takeaway: at a hundreds-of-accounts estate, the binding limit is VPC associations per service network (500). Environment-scoped service networks keep you well inside it; if a single environment approaches 400 associations, request an increase early.

Auth policy design: scope to OU paths, not account IDs

Service Network IAM auth policies should use aws:PrincipalOrgPaths conditions rather than listing individual account IDs. New accounts added to an OU automatically inherit access without policy updates. The reference implementation pairs the OU-path match with an organization ID check as a second boundary:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "vpc-lattice-svcs:Invoke",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-EXAMPLE12345"
    },
    "ForAnyValue:StringLike": {
      "aws:PrincipalOrgPaths": [
        "o-EXAMPLE12345/r-EXAMPLE/ou-EXAMPLE-dev0000/*"
      ]
    }
  }
}

Why this matters: Account-ID-based policies require updates every time you onboard a new account, which defeats the zero-touch onboarding promise. OU-path conditions make the policy scale with the organization structure.

AWS Well-Architected Framework alignment

This pattern maps to all six pillars of the AWS Well-Architected Framework:

*Follow the principle of least privilege and grant the minimum permissions required to perform a task. For more information, see Grant least privilege and Security best practices in the IAM documentation.

Key trade-off: concentration risk

This pattern deliberately concentrates connectivity into a single managed fabric. This is both its strength (one place to govern, secure, and observe) and its primary risk (a failure in the shared fabric affects all consumers). Mitigations:

Epics

Troubleshooting

Related resources

GitHub repository: aws-samples/sample-vpc-lattice-multi-account-connectivity

AWS documentation

Frameworks and tools

Related AWS Prescriptive Guidance

Pricing references

Additional information

This section quantifies what the shared-fabric model changes compared to a per-account connectivity model. The numbers are expressed in resource counts and cost drivers (per-hour, per-GB, per-endpoint-hour), not in dollars. Actual savings depend on Region, traffic volume, and the specific pricing in effect when you deploy. Validate with the AWS Pricing Calculator against your own traffic profile.

What you will achieve:

Outcome 1: Cost-predictable connectivity

The shared-fabric model changes the cost structure from per-account (scales with estate size) to per-environment (fixed at 3 regardless of estate size).

Shared endpoints consolidation:

In the per-account model, each workload VPC provisions its own interface VPC endpoints. The shared-fabric model exposes a single set in the Network account. Per-account figures are illustrative (10 endpoints x 3 AZs); the reference implementation deploys 10 shared endpoints.

Business impact. Connectivity-to-AWS-services cost stops scaling with account count. The 151st or 501st account onboards with zero incremental endpoint spend.

Centralized egress consolidation:

In the per-account model, highly available outbound access means one NAT Gateway per AZ, per VPC, per account. The shared-fabric model consolidates this into a single egress path:

Business impact. Egress cost consolidates into one managed path that the platform team owns and right-sizes centrally.

Transit Gateway attachment reduction (for these patterns only):

For the specific patterns covered here (AWS-service access and filtered egress), VPC Lattice routes traffic without a TGW hop:

Outcome 2: Reduce per-account operational overhead

The per-account model duplicates not just resources but operational work. Every endpoint, gateway, and route table must be created, secured, monitored, and kept consistent.

Onboarding contrast, per account:

Business impact. Platform teams shift from "deploying connectivity per account" to "maintaining one shared fabric." Workload teams get self-service: associate your VPC, start building.

Outcome 3: Centralized security governance

Consolidating connectivity into the shared fabric also consolidates its governance. Environment isolation comes from OU-scoped IAM auth policies on each Service Network, discovery is limited by OU-scoped RAM shares with external principals disabled, and outbound traffic is constrained by the centralized FQDN allowlist. The result is a single audit surface instead of hundreds of independent per-account configurations, so controls drift less and audits move faster. The Best practices section covers the auth-policy and RAM design in detail.

Outcome 4: Extend the same fabric to external and cross-Region consumers

The first three outcomes serve workloads that associate their VPC directly with a Service Network. The same fabric also reaches consumers that sit outside that association: external clients, on-premises systems (over Direct Connect or VPN), and workloads in other Regions.

A Service Network Endpoint (SN-E) is the entry point for those consumers. Rather than associating an entire VPC, a consumer connects to the shared services through an SN-E placed in an ingress VPC. The SN-E resolves to per-Availability-Zone secondary IP addresses in the ingress VPC, so on-premises and cross-Region callers reach the fabric through a stable, private address they can route to, without joining the Service Network directly.

Business impact. One connectivity investment serves both internal workloads and external/cross-Region consumers, so you do not build and operate a parallel ingress architecture alongside the shared fabric.

How to validate the numbers for your environment

Resource-count changes are deterministic; dollar impacts depend on your traffic patterns, AZ count, Region, and account volume. Use the AWS Pricing Calculator with your own numbers to convert the consolidation ratios above into a defensible business case. Factor in your existing centralization (if you already use TGW for shared services, your baseline is already partially consolidated).

Is this compatible with an existing Transit Gateway deployment?

Yes. This pattern handles three specific patterns: AWS-service access, controlled internet egress, and ingress via Service Network Endpoints. Transit Gateway is retained for east-west IP-routed traffic and hybrid routing. A single VPC can have both a TGW attachment and a VPC Lattice association simultaneously, because Lattice routes by DNS name and service network rather than by IP address.

Does this replace Transit Gateway?

No. This pattern is not positioned as a Transit Gateway replacement. It targets specific connectivity patterns (AWS-service access, controlled egress, and ingress) where VPC Lattice offers a simpler, more cost-predictable delivery mechanism. Transit Gateway remains the right tool for general-purpose IP routing, hybrid connectivity, and centralized traffic inspection. Many organizations will use both: TGW for east-west and hybrid traffic, VPC Lattice for service access and egress.

Our organization already uses TGW with centralized egress. What does this add?

If you already centralize egress through a TGW + NAT Gateway or firewall architecture, you have already achieved consolidation for that pattern. Adopting VPC Lattice for egress offers three incremental benefits:

Evaluate whether these incremental benefits justify the migration effort for your specific environment.

What is the migration path from a per-account architecture?

Incremental and side-by-side. You never have to migrate the entire estate at once:

The association is additive and reversible. If anything looks wrong, disassociate the VPC and the account reverts to its previous connectivity.

How does this work across multiple Regions?

A VPC Lattice Service Network is a regional construct. A multi-Region deployment replicates the pattern per Region:

The IaC is parameterized by Region and instantiated once per Region.

Can I add more AWS service endpoints to the shared set?

Yes. The reference exposes 10 endpoints (SSM, STS, ECR, ECS, CloudWatch Logs, and more). To add another:

What about overlapping CIDRs across workload accounts?

VPC Lattice supports overlapping CIDRs natively. Workload VPCs can use the same CIDR blocks because Lattice routes by DNS name and service network (DNS/HTTP), not by IP address. This is particularly valuable for large organizations where CIDR coordination across hundreds of accounts is impractical or where acquired business units bring their own address space.

What happens if the shared egress proxy goes down?

All workload accounts using the centralized egress path lose outbound internet access for traffic routed through the proxy. Mitigations:

For production workloads that require egress even during a fabric outage, maintain a break-glass NAT Gateway path that can be activated by changing a route table entry. This is the standard resilience pattern for any centralized egress design (TGW-based or Lattice-based).

What IP ranges does VPC Lattice resolve to?

For VPC Resources (what this pattern uses for endpoints and the egress proxy), DNS resolves to addresses in the 129.224.0.0/17 IPv4 range. This is the AWS-managed range for VPC Lattice resource traffic.

How do I update the egress allowlist without a full redeploy?

By default, the allowlist is the ALLOWED_DOMAINS environment variable on the ECS task definition, so updating it requires a stack redeploy (ECS rolls out a new task revision). For frequent changes, source the list from SSM Parameter Store and have the container read it at startup; this lets you change the allowlist without a stack deploy.

Attachments

To access additional content that is associated with this document, download and unzip the following file: attachment.zip