Multi-Account Design for Amazon VPC Lattice - Configuration Patterns for RAM Sharing and Service Networks
This article explains RAM sharing design, strategies for splitting service networks, and the hierarchical design of Auth Policy when operating VPC Lattice in a multi-account environment.
Challenges of VPC Lattice in Multi-Account Environments
In an AWS multi-account strategy, you separate accounts by workload to establish security boundaries. However, communication between microservices needs to cross account boundaries, and this was previously achieved with a combination of VPC peering, Transit Gateway, and PrivateLink. VPC Lattice can establish cross-account communication at the application layer, but design in a multi-account environment has its own specific considerations. Deciding in which account to place the ownership of service networks, the sharing scope of services, and the management responsibility for Auth Policy is an important decision point in the design.
Sharing Service Networks with RAM
Cross-account connectivity in VPC Lattice is achieved through AWS Resource Access Manager (RAM). The account that owns the service network creates a RAM resource share and grants participating accounts permission to associate with the service network. As the share destination, you can specify individual account IDs, organizational units (OUs) in Organizations, or the entire organization. The recommended pattern is a configuration in which service networks are consolidated in a dedicated network management account (Networking Account) and shared per OU. This centralizes lifecycle management of service networks, and when a new workload account is added to an OU, access to the service network is granted automatically at that point. By using the trust relationship in Organizations to make acceptance of RAM shares automatic, you can reduce the operational load.
Strategies for Splitting Service Networks
How to split service networks depends on the size of the organization and its security requirements. In small organizations (fewer than 10 accounts), a simple configuration that registers all services in a single service network is easy to manage. In medium-sized or larger organizations, we recommend splitting service networks by environment (production / staging / development) or by domain (payments / authentication / notifications, etc.). Splitting by environment eliminates the risk of production services being called from the development environment. Splitting by domain clarifies responsibility boundaries between teams and lets you distribute the management of Auth Policy. However, if you split service networks too finely, communication paths between services become complex and the operational load increases. It is practical to use about 50 to 100 services per service network as a guideline and to consider splitting when that number is exceeded.
Hierarchical Design of Auth Policy
Auth Policy in VPC Lattice is applied at two levels: the service network level and the service level. In a multi-account environment, you make use of this hierarchical structure to design the division of responsibilities. The network management account manages the service network level policy and broadly controls "which account's principals can access services in the service network". Each workload account manages the service level policy and finely controls "from which principals access to its own service is allowed". With this separation, network administrators can govern the overall security framework while each team can manage access control for its own services autonomously. Because policy evaluation is done with an AND condition, access denied at the service network level does not get through even if it is allowed at the service level.
Operations and Auditing in the Organization
When you share a service network across multiple accounts, it becomes important to understand and govern who is using which services. While rolling out the service network to each account with the sharing mechanism, you use auth policies to ensure that only allowed accounts and services can communicate. If you aggregate communication logs, you can monitor interactions between services across accounts in a cross-cutting way and detect unexpected access. A division of roles in which a central team manages the sharing framework and policies, and the teams in each account publish / use services within it, supports orderly operations in large organizations.
Summary
In multi-account design for VPC Lattice, the main design patterns are centralized management of service networks through RAM sharing, splitting service networks by environment or domain, and the division of responsibilities through the two levels of Auth Policy. Use a configuration that consolidates service networks in the network management account and shares them via RAM per OU as the baseline, and consider splitting service networks as your organization grows.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon VPC Lattice official page
- AWS Resource Access Manager official page
- AWS Organizations official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.