[SEO Subhead]
This Guidance demonstrates an automated approach for creating the DNS resolution required when creating Amazon VPC Lattice services with custom domain names in multi-account environments. It simplifies the configuration process by automating the Amazon Route 53 DNS setup based on Amazon VPC Lattice service creation and removal actions, eliminating the operational effort of creating resources at scale. You can benefit from a simplified way to connect services across multiple AWS accounts, allowing applications to transparently access the required DNS resolution.
Note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
When a new spoke account creates a new Amazon VPC Lattice service, an Amazon EventBridge rule checks that a VPC Lattice service has been created with the proper tag. The EventBridge rule (default event bus) also verifies whether a VPC Lattice service has been deleted upon the removal of such tag.
Step 2
The event is forwarded to the 'Get VPC Lattice service information' AWS Step Functions state machine. Depending on the action (creation or deletion), the state machine publishes an event to the custom event bus. Additionally, for created resources with custom domain names, the state machine retrieves the domain name configuration details, including the domain name generated by VPC Lattice, the hosted zone managed by VPC Lattice, and the custom domain name.
Step 3
The ‘vpclattice_information’ custom event bus in the spoke account is configured with a target pointing to the ‘cross_account’ event bus in the networking account.
Step 4
Unsuccessfully processed events from delivery are stored in the Amazon Simple Queue Service (Amazon SQS) dead-letter-queue (DLQ) within the spoke account for monitoring.
Step 5
The ‘cross_account‘ custom event bus in the networking account invokes the `DNS configuration` Step Functions state machine. This processes the notification sent from the spoke account.
Step 6
Unsuccessfully processed events are stored in the DLQ in the networking account for monitoring.
Step 7
The `DNS configuration` state machine creates or deletes the corresponding alias record in the private hosted zone.
Step 8
AWS Systems Manager and AWS Resource Access Manager (AWS RAM) are used for secure parameter storage and cross-account data sharing.
Step 1
When a new spoke account creates a new Amazon VPC Lattice service, an Amazon EventBridge rule checks that a VPC Lattice service has been created with the proper tag. The EventBridge rule (default event bus) also verifies whether a VPC Lattice service has been deleted upon the removal of such tag.
Step 2
The event is forwarded to the 'Get VPC Lattice service information' AWS Step Functions state machine. Depending on the action (creation or deletion), the state machine publishes an event to the custom event bus. Additionally, for created resources with custom domain names, the state machine retrieves the domain name configuration details, including the domain name generated by VPC Lattice, the hosted zone managed by VPC Lattice, and the custom domain name.
Step 3
The ‘vpclattice_information’ custom event bus in the spoke account is configured with a target pointing to the ‘cross_account’ event bus in the networking account.
Step 4
Unsuccessfully processed events from delivery are stored in the Amazon Simple Queue Service (Amazon SQS) dead-letter-queue (DLQ) within the spoke account for monitoring.
Step 5
The ‘cross_account‘ custom event bus in the networking account invokes the `DNS configuration` Step Functions state machine. This processes the notification sent from the spoke account.
Step 6
Unsuccessfully processed events are stored in the DLQ in the networking account for monitoring.
Step 7
The `DNS configuration` state machine creates or deletes the corresponding alias record in the private hosted zone.
Step 8
AWS Systems Manager and AWS Resource Access Manager (AWS RAM) are used for secure parameter storage and cross-account data sharing.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
EventBridge triggers an automated process when a new VPC Lattice service is created. This process invokes a Step Functions state machine to obtain DNS information for the VPC Lattice service and publishes an event to a custom EventBridge event bus. In the DNS-managing AWS account, another Step Functions state machine receives this event through a cross-account event bus and creates the corresponding DNS configuration by adding alias records. This automation eliminates manual DNS configuration for new or deleted VPC Lattice services, reducing operational overhead in multi-account, large-scale environments and enabling transparent DNS resolution for application services.
-
SecurityRead the Security whitepaper
Amazon SQS policies restrict access to specified accounts, organizations, or resources. AWS Identity & Access Management (IAM) roles for Step Functions limit access to relevant resources like EventBridge, Route 53, or VPC Lattice. AWS RAM securely shares resources such as EventBridge event buses only within the same AWS Organization. These measures enforce the principle of least privilege, limiting access to VPC Lattice DNS resolution automation to only the necessary configuration resources and AWS accounts.
-
ReliabilityRead the Reliability whitepaper
The use of managed services like EventBridge, Step Functions, and Amazon SQS minimizes failure risks for continuous event processing without downtime. Specifically, Amazon SQS DLQs in EventBridge targets enable monitoring and retrying of failed message processing. Whereas Step Functions state machines, running serverless, process these events and collect logs for comprehensive visibility.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
This Guidance uses minimal latency for processing automation across accounts, enabling swift connectivity between a consumer and a newly created VPC Lattice service. In addition, EventBridge provides real-time event processing as a managed service. Moreover, Step Functions and Amazon SQS, both Regional managed serverless services, deliver optimal performance with low operational overhead. This combination of services provides rapid response times and efficient resource utilization in the VPC Lattice DNS resolution automation system, meeting the need for near immediate service availability.
-
Cost OptimizationRead the Cost Optimization whitepaper
AWS manages the computing resources used in this architecture, following a serverless paradigm. EventBridge, Step Functions, and Amazon SQS operate on-demand, activating only when a new VPC Lattice service is created. This serverless approach ensures compute capacity is used briefly for specific actions, avoiding costs associated with long-running processes. By using these managed services, the VPC Lattice DNS resolution automation system optimizes resource utilization while maintaining high performance and reliability.
-
SustainabilityRead the Sustainability whitepaper
On-demand computational services and real-time event processing minimize resource usage and environmental impact. For example, EventBridge, Step Functions, and Amazon SQS are fully managed AWS services that operate on an event-driven basis, providing high efficiency and low cost for short-duration tasks. This event-driven architecture in the VPC Lattice DNS resolution automation system contributes to a smaller environmental footprint compared to continuously running processes.
Related Content
[Title]
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.