Overview
The Network Orchestration for AWS Transit Gateway solution automates the process of setting up and managing transit networks in distributed AWS environments. This solution allows customers to visualize and monitor their global network from a single dashboard rather than toggling between Regions from the AWS Console. It creates a web interface to help control, audit, and approve transit network changes.
Benefits
Automate the process of setting up and managing transit networks in distributed AWS environments.
Use the web user interface to either accept or reject tag requests when manual approval is required.
Deploy a web user interface to control, audit, and approve transit network changes.
Automate both AWS Organizations and standalone AWS account types.
Technical details
The following diagram presents the architecture you can automatically deploy using the solution's implementation guide and accompanying AWS CloudFormation templates.
This solution includes two CloudFormation templates:
- network-orchestration-hub - Deploy this template in the account you want to act as the hub in the solution’s hub-and-spoke model.
- network-orchestration-spoke - Deploy this template in spoke accounts.
Step 1
An Amazon CloudWatch Events rule monitors Amazon Virtual Private Cloud (Amazon 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.
Step 2
This tag change is sent to the hub account through an Amazon EventBridge bus.
Step 3
When the event is received in the hub account, an AWS Lambda function is initiated to start the Network Orchestration for AWS Transit Gateway workflow.
Step 4
AWS Step Functions (Network Orchestration for AWS Transit Gateway state machine) and Lambda process network requests from the spoke accounts and event details are stored in Amazon DynamoDB. You can approve requests automatically or manually.
Step 5
If you choose to approve requests automatically, the VPC attaches to AWS Transit Gateway. If you choose to approve requests manually, Amazon Simple Notification Service (Amazon SNS) sends an email to request approval. After the request is approved, the Network Orchestration for AWS Transit Gateway state machine applies the network change.
Step 6
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.
Step 7
The transit gateway provisioned by the solution also gets registered with global network manager. Refer to AWS Transit Gateway Network Manager for more information.
Step 1
An Amazon CloudWatch Events rule monitors Amazon Virtual Private Cloud (Amazon 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.
Step 2
This tag change is sent to the hub account through an Amazon EventBridge bus.
Step 3
When the event is received in the hub account, an AWS Lambda function is initiated to start the Network Orchestration for AWS Transit Gateway workflow.
Step 4
AWS Step Functions (Network Orchestration for AWS Transit Gateway state machine) and Lambda process network requests from the spoke accounts and event details are stored in Amazon DynamoDB. You can approve requests automatically or manually.
Step 5
If you choose to approve requests automatically, the VPC attaches to AWS Transit Gateway. If you choose to approve requests manually, Amazon Simple Notification Service (Amazon SNS) sends an email to request approval. After the request is approved, the Network Orchestration for AWS Transit Gateway state machine applies the network change.
Step 6
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.
Step 7
The transit gateway provisioned by the solution also gets registered with global network manager. Refer to AWS Transit Gateway Network Manager for more information.
"Australia Post is a self-funded postal service business with both commercial and community service obligations, serving 12.3 million delivery points across Australia. Our organization is made up of 35,000 employees so when we needed to expand our cloud technologies to scale our network across our growing cloud infrastructure with siloed VPCs and on-premises data centers, we experienced significant latency issues. The Serverless Transit Network Orchestrator (STNO) solution allowed us to automate our configuration and customize our network setup based on our needs with AWS Transit Gateway, reducing our network setup time from weeks to minutes, resulting on the final solution reaching 13X improved network traffic speeds between accounts."
Related content
Getting into the Serverless Mindset
Learn how to move forward without provisioning, scaling, or managing servers.
Subnets, Gateways, and Route Tables Explained
In this course, we will use sample three-tiered architecture to better understand how certain network components can help you effectively network your application. We review the differences between public and private subnets and discuss how gateways and route tables can be used for network routing.