This article continues our exploration of hybrid multi-account access patterns for Amazon OpenSearch Serverless. In the previous installment, we discussed a centralized architecture with a single account managing multiple collections and a shared VPC endpoint. This model is effective for organizations where a single team oversees collections.
However, many organizations consist of multiple business units that require independent control over their OpenSearch Serverless infrastructure. In such cases, the centralized model becomes impractical as each unit desires autonomy over their collections, security policies, and VPC endpoints.
To address this, we propose a pattern where a central networking account manages a custom private hosted zone (PHZ) containing CNAME records for each business unit's VPC endpoint. This setup allows centralized DNS management while granting each unit full control over their infrastructure.
When multiple business units manage their OpenSearch Serverless collections in separate AWS accounts, they each have unique VPC endpoints and private hosted zones. This can lead to DNS fragmentation, making it difficult for clients in spoke accounts or on-premises environments to resolve endpoints across accounts without additional configuration.
To streamline operations, the networking account maintains a custom PHZ that maps collection endpoints to their respective VPC endpoints. This PHZ is associated with a Route 53 Profile and shared with spoke accounts via AWS Resource Access Manager (AWS RAM). On-premises DNS resolution is facilitated through the Route 53 Resolver inbound endpoint in the central networking VPC.
Access Patterns
We introduce two complementary access patterns:
- Pattern 1: On-premises access to collections across multiple business units.
- Pattern 2: Spoke account access to those same collections.
Both patterns utilize the centralized custom PHZ managed by the networking team.
With this architecture, on-premises clients can securely access OpenSearch Serverless collections across various business units. The accompanying diagram illustrates how DNS queries from on-premises systems are resolved through the custom PHZ and routed to the appropriate VPC endpoint via AWS PrivateLink.
Implementation Steps
The following steps outline the implementation:
- The central networking account creates Route 53 Profiles shared with the central OpenSearch Serverless account.
- A custom PHZ is established with the domain
us-east-1.aoss.amazonaws.com, linked to the VPC and Route 53 Profiles. - CNAME records in the PHZ point to each business unit's VPC endpoints.
- Each business unit enables Private DNS on its VPC endpoint, creating local PHZs for DNS resolution.
For access to a collection in BU2, clients follow the same flow using bu-2-collection-id-1.us-east-1.aoss.amazonaws.com. The custom PHZ resolves to BU2’s VPC endpoint, directing traffic correctly.
Pattern 2 allows compute resources in spoke accounts to access OpenSearch Serverless collections across multiple business units. This is illustrated through an example using an Amazon EC2 instance, but it applies to any compute resource within the spoke VPC.
In this setup, spoke VPCs resolve DNS through the shared Route 53 Profile and custom PHZ, routing traffic to the correct collections via AWS PrivateLink.
Cost Considerations
Implementing these architecture patterns involves various AWS services that may incur costs, including Amazon Route 53 for hosted zones, DNS queries, and Resolver endpoints. For precise cost estimates tailored to your workload, consider using the AWS Pricing Calculator.
This article demonstrated how to provide private access to OpenSearch Serverless collections across multiple business units while centralizing DNS management through a custom PHZ. This approach alleviates the need for each business unit to coordinate DNS associations, allowing them to maintain ownership of their collections and VPC endpoints.
For further information, refer to the Amazon OpenSearch Serverless VPC endpoint documentation and Route 53 Profiles documentation.
