Multi-Account Design for Amazon VPC Lattice - RAM Sharing and Service Network Configuration Patterns
Learn how to design VPC Lattice for multi-account environments, including RAM sharing strategies, service network partitioning, and hierarchical Auth Policy design.
VPC Lattice Challenges in Multi-Account Environments
In AWS multi-account strategies, accounts are separated per workload to establish security boundaries. However, microservice communication needs to cross account boundaries, which was traditionally achieved through combinations of VPC peering, Transit Gateway, and PrivateLink. VPC Lattice can establish cross-account communication at the application layer, but designing for multi-account environments involves unique considerations. Key design decisions include which account owns the service network, the scope of service sharing, and where Auth Policy management responsibility resides.
Sharing Service Networks via RAM
Cross-account connectivity in VPC Lattice is achieved through AWS Resource Access Manager (RAM). The service network owner account creates a RAM resource share and grants participating accounts permission to associate with the service network. Share targets can be specified as individual account IDs, Organizations organizational units (OUs), or the entire organization. The recommended pattern is to centralize service networks in a dedicated networking account and share them at the OU level. This centralizes service network lifecycle management, and new workload accounts automatically receive access to the service network when added to the OU. RAM share acceptance can be set to auto-approve using Organizations trust relationships, reducing operational overhead.
Service Network Partitioning Strategy
How to partition service networks depends on the organization's size and security requirements. For smaller organizations (fewer than 10 accounts), a single service network with all services registered is the simplest to manage. For mid-size and larger organizations, partitioning by environment (production, staging, development) or by domain (payments, authentication, notifications, etc.) is recommended. Environment-based partitioning eliminates the risk of production services being called from development environments. Domain-based partitioning clarifies team responsibility boundaries and distributes Auth Policy management. However, over-partitioning service networks increases communication path complexity and operational overhead. A practical guideline is to target 50-100 services per service network and consider splitting when that threshold is exceeded. For more on multi-account design, specialized books (Amazon) can be a helpful reference.
Hierarchical Auth Policy Design
VPC Lattice Auth Policies are applied at two levels: the service network level and the service level. In multi-account environments, this hierarchical structure is leveraged to design responsibility boundaries. Service network-level policies are managed by the networking account and broadly control which account principals can access services within the service network. Service-level policies are managed by each workload account and provide fine-grained control over which principals can access their specific services. This separation allows network administrators to govern the overall security framework while individual teams autonomously manage access control for their own services. Policy evaluation uses AND logic, so access denied at the service network level cannot be overridden by a service-level allow.
Summary
The key design patterns for VPC Lattice in multi-account environments are centralized service network management via RAM sharing, service network partitioning by environment or domain, and a two-tier Auth Policy responsibility model. Start with the baseline of centralizing service networks in a networking account and sharing via RAM at the OU level, then consider service network partitioning as the organization grows.