Architecture overview - Serverless Transit Network Orchestrator

Architecture overview

Deploying this solution with the default parameters builds the following environment in the AWS Cloud.


        Serverless Transit Network Orchestrator solution architecture (with an AWS Transit Gateway VPC attachment)

Figure 1: Serverless Transit Network Orchestrator solution architecture (with an AWS Transit Gateway VPC attachment)


        Serverless Transit Network Orchestrator solution architecture (with an inter-Region AWS Transit Gateway attachment)

Figure 2: Serverless Transit Network Orchestrator solution architecture (with an inter-Region AWS Transit Gateway attachment)

This solution includes an AWS CloudFormation template (aws-transit-network-orchestrator-hub) that you deploy in the primary account you want to act as the hub in the solution’s hub-and-spoke model. For guidance on choosing a hub account, refer to Choosing a Hub Account. This template launches all the components necessary to automatically connect your VPCs to AWS Transit Gateway.

Note

Before you launch the hub template, note the spoke account IDs or the AWS Organizations ARNs. You will enter them into the applicable template parameters during deployment.

The hub template optionally deploys AWS Transit Gateway Network Manager, but it is not a dependency for the web interface. The hub template launches AWS Lambda functions, AWS Step Functions, Amazon DynamoDB, Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), AWS Resource Access Manager (AWS RAM), and AWS Transit Gateway. The template also deploys a Transit Network Management web interface that includes AWS Transit Gateway Network Manager, Amazon Simple Storage Service (Amazon S3), Amazon CloudFront, AWS AppSync, and Amazon Cognito.

The solution also includes a template (aws-transit-network-orchestrator-spoke) to deploy in spoke accounts. This template deploys a CloudWatch Events rule that monitors VPC and subnet tags. To identify the VPCs (spoke accounts) for the solution to manage, tag the VPCs and the selected subnets within those VPCs. This tag change is sent to the hub account through an EventBridge bus. When the event is received in the hub account, an AWS Lambda function is initiated to start the Serverless Transit Network Orchestrator workflow. For more information about the workflow, refer to Appendix B.

Note

You must wait for the hub stack launch to complete before you launch spoke templates. The spoke template depends on the Amazon CloudWatch Events bus policy that is created during the hub stack launch.

AWS Step Functions (Serverless Transit Network Orchestrator state machine) and Lambda process network requests from the spoke accounts and event details are stored in DynamoDB. You can choose whether to approve requests automatically or manually. If you choose to approve requests automatically, the VPC attaches to AWS Transit Gateway. If you choose to approve request manually, Amazon SNS sends an email to request approval. After the request is approved, the Serverless Transit Network Orchestrator state machine applies the network change. If the request is rejected, DynamoDB and the spoke resources tag are updated with the rejected status.

When a request is approved, the solution updates the route table associated with the subnet in the spoke account with a default route with AWS Transit Gateway as the target, which provides bi-directional connectivity. The solution workflow updates the subnet’s route table with the default route as defined in the hub template.

The solution also adds (or updates) a Serverless Transit Network Orchestrator Status tag with the request status as a mechanism to update the spoke account user. The spoke account user checks on the status using either the Transit Network Management web interface (if they have permission) or by viewing the tag in their spoke account.

Note

Serverless Transit Network Orchestrator will not overwrite existing default routes with different targets.

The Transit Network Management web interface is deployed into an Amazon S3 bucket configured for static web hosting. Amazon CloudFront is used to provide public access to the solution’s bucket contents. Amazon Cognito is used to manage user access to the web interface.

Users can view tagging event details and the history of network requests from different accounts, and monitor their status in the web interface. Administrators can accept or reject requests when manual approval is required.

Version 2.0 introduces the capability to create and delete inter-Region transit gateways. The hub template deploys a new CloudWatch Events rule that monitors transit gateway tags. This tag change is monitored only in the hub account. The transit gateway peering attachment state machine is initiated after the event is received in the hub account. For more information about the workflow, refer to Appendix C.

Version 2.0 adds support for using an existing transit gateway and allowing users to provide a list of custom CIDR blocks and/or managed prefix list IDs to update the VPC route tables as destinations. Managed prefix lists enable users to manage the IP addresses that they frequently use for the resources in a single group, instead of repeatedly referencing the same IP addresses in each resource.