[ad_1]
About STNO: STNO stands for Serverless Transit Network Orchestrator. The STNO solution provides automation to the AWS Transit Gateway service by providing the tools necessary to automate the process of setting up and managing transit networks in AWS environments using multiple VPCs. STNO supports both AWS Organizations and standalone AWS account types. A web interface is created to help control, audit, and approve (transit) network changes.
Operation and Management of Complex Networking. AWS Transit Gateway is a powerful concept for providing connectivity between networks of different types in AWS, be it a VPC, a Direct Connect Gateway, a VPN Gateway or any other. Earlier VPC peering we had but that was not transitive in nature. AWS have done a great job of hiding all the enormous amounts of complexity, which comes with that, under the bonnet, so you don’t have to deal with all the intricacies of the associated networking, but the things that Administrator has to manage are many. STNO makes life easier by automating majority of the part to keep less things in the mind.
Solution Overview: We can use Control tower administrator execution role from Management account to deploy two Cloud formation templates. We can have shared network account and deploy the hub cloud formation template where in spoke template in each member accounts or spoke accounts of the Organization. These Cloud Formation templates will create all required resources to automate the TGW setup and management
Architecture
As described above hub-spoke deployment model use below workflow
An Amazon CloudWatch Events rule monitors 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.
This tag change is sent to the hub account through an Amazon EventBridge bus.
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.
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.
After the request is approved, the STNO state machine applies the network changes. If the request is rejected, the DynamoDB table and the spoke resources tag are updated with the rejected status.
When a request is approved, for bidirectional connectivity, the solution also updates the subnet’s route table in the spoke account with a route to the transit gateway as the target. The solution workflow updates the subnet’s route table with the default route setting defined in the hub template.
Our Use case for STNO:
In our use case we have a hybrid connectivity using three AWS Accounts with VPC’s and one on premises network.
The scenario is one where an AWS customer wants to extend their Active Directory forest into AWS by launching an AWS managed Active Directory in their Shared Services account. They only allow traffic to the on-premises network from the Shared Services account. Also, instances in the AWS Applications account are allowed to communicate with each other as well as to the AWS Managed Microsoft AD in the Shared Services account.
The transit gateway is placed in the Network account, which acts as the “hub” of the network architecture. All other network connections to the transit gateway should be considered “spokes,” and the transit gateway route tables determine allowed traffic between the spokes.
We connect the on-premises network to the transit gateway with a Site-to-Site VPN and associate the VPN with the transit gateway On-premises route table. Once that is done, we configure the network by first deploying the STNO solution in all the accounts, and then use tags on VPCs and subnets in the spoke accounts to automate the rest of the transit gateway configuration.
Download the Hub and Spoke Cloudformation templates from the Github repo
Deploy the STNO hub CloudFormation template in the Network account where you have tgw also deployed
In the hub template, you will find the tgw route tables. You can edit them as per your requirements.
Deploy the STNO spoke CloudFormation template in the Application and Shared Services accounts.
Set manual approval required for “On-premises” transit gateway route table. A use-case is when you don’t want everyone to be able to attach themselves to Direct Connect
Set up the VPN connection from on-premises network to AWS and associate the VPN with the transit gateway in the network account.
Tag the VPC and subnets in the Shared Services account to allow network traffic to flow between Shared Services and on-premises, as well as between Shared Services and workload account.
Tag the VPC and subnets in the Workloads account to allow network traffic to flow between the workloads account and Shared Services account.
Log into the STNO Management web interface and approve all routing configuration requests.
Test traffic connectivity is performing as expected.
In AWS Transit Gateway terminology, we do this by creating VPC attachments to a transit gateway. We define transit gateway route tables, associating the attachments to the transit gateway route tables, and allowing route propagations through the gateway so that return traffic is properly routed back to its source.
STNO solution default deployment, the transit gateway is set up with the following route tables: Flat, Isolated, On-premises, and Infrastructure. I have used inspection route table and egress route table as well because we are inspecting the network traffic as well. Isolated route table, I have removed as its not being used.
In our use case we have:
Member AWS Accounts for workloads: Every Organization has Member Accounts. AWS Applications/workloads hosted in the account are allowed to communicate with each other as well as to the AWS Managed Microsoft AD in the Shared Services account. We associate the Inspect VPC (as both ingress/egress traffic is being inspected) with the transit gateway Flat route table. Finally, we direct transit gateway route propagation from the Flat route table to itself and to the infrastructure route table
Shared services AWS Account (Hosts AWS Managed AD): only allow traffic to the on-premises network from the Shared Services account. This is attached to the infrastructure route table.
On promises network (Corporate DC): This Account has on premises AD forest which has to be extended with AWS managed AD. On-premises network is connected to the transit gateway with a Site-to-Site VPN and associated with TGW On-premises route table. On-Premises route table propagates to Infrastructure route table.
Network Account: We have 3 VPCs (Ingress, egress and inspection vpc) in this account. Also The transit gateway is placed in the Network account, which acts as the “hub” and other Network connections like VPC’s, VPNs considered to be “spokes,” and the transit gateway route tables are responsible for allowing traffic between different spokes.
Every traffic which comes from the internet will go through ingress vpc.
Traffic which workloads initiate will go through egress vpc
Inspection VPC has AWS Network firewall deployed using suri kata firewall rules. Each packet will be inspected here.
Tag the VPC and Subnet(s) in Shared Services account:
This enables connectivity between the Shared Services VPC that hosts an AWS Managed Microsoft AD and on-premises network where the main Microsoft Active Directory server resides.
a) Log in to the Shared Services account.
b) Navigate to the VPC console > Your VPCs. Select the VPC that’s hosting your managed Active Directory server and add these two Tags:
“Associate-with”: “Infrastructure”
“Propagate-to” : “Flat, On-premises”
c) In the VPC console > Subnets, select the subnet you want to be attached to the transit gateway and add the following tag;
“Attach-to-tgw” : <leave blank>
d) Log in to the Network account. In the VPC console > Transit Gateway Attachments, review that there is no new Attachment nor any changes in Associations or propagated Routes. This is because we are trying to make changes to the “On-premises” Route Table. This is intended and as we have set the ApprovalRequired to Yes earlier, manual approval is required for any changes to “On-premises” route table. We approve these changes via Transit Network Management web interface later in the process.
Tag the VPC and Subnets in Member account:
This enables connectivity between the Member account VPC hosting application servers and the Shared Services VPC so that application servers can communicate with the AWS Managed Microsoft AD server. At the same time, application servers won’t have connectivity to on-premises network as this is the desired behavior.
a) Log in to the Application account.
b) Navigate to the VPC console > Your VPCs. Select the VPC that’s hosting your application server and add these two tags:
“Associate-with”: “Flat”
“Propagate-to” : “Flat, Infrastructure”
Note: Tagging the VPC won’t create a transit gateway attachment, nor change anything in the transit gateway route tables. It only updates the DynamoDB table with info that will be used later when a subnet is tagged and actual attachment and route propagations are created.
c) Navigate to the VPC console > Subnets. Select the subnet you want to be attached to the transit gateway and add the following tag:
“Attach-to-tgw” : <leave blank>
Note: Remember that only one subnet from each Availability Zone can be attached to the transit gateway. Otherwise you receive the “DuplicateSubnetsInSameZoneError” error.
EventBridge Rules in Member Account notify subnets and vpc data to Shared Network Account STNO components automatically
VPC CIDR data is displayed in STNO Console -> Action Items page
Shared Network Operator has to APPROVE OR REJECT the request on STNO Console
Shared Network Operator verifies the Member Account VPC details in Transit Gateway Attachments, Transit Gateway Route Tables
This invokes the Lambda function that creates the transit gateway attachment, association, and propagations based on the Tags we added to the VPC in the previous step. This might take a few minutes to complete.
d) Log in to the Network account. In the VPC console > Transit Gateway Attachments, confirm that there is a new attachment. Also review the Associations and propagated Routes for Flat and Infrastructure route tables.
You can also review tagging requests on the Transit Network Management web interface, explained in next step.
Approve routing configurations in the STNO Management Web Interface:
As mentioned earlier in this post, STNO solution deploys a web interface to help control, audit, and approve changes made to the transit gateway.
a) Log in to your Transit Network Management Console web interface. You should have received the URL and login credentials for this when you deployed the STNO solution hub template.
Review the logs for the changes made by the solution. You can see that changes to the Flat Route Table are auto-approved, and hence no action required on the web interface.
b) We now must approve the changes made to the On-premises route table. To approve these changes, on the Transit Network Management Console web interface, under Actions Items page you should see two items waiting for manual approval. Select each at a time and Approve. This makes the actual changes including transit gateway attachments, associations, and propagations. This takes a few minutes to complete.
You can review the logs on the Dashboard page. Also, you can review the new attachment, association, and propagated routes for the transit gateway in the Amazon VPC console.
We can confirm the North-South Traffic connectivity.
AWS Transit Gateway is a complicated device, and the way it’s implemented in AWS, naturally requires a lot of competency from the engineers who deploy it. What’s worse, performing day-to-day tasks becomes a burden on the operator, and over time the complexity of the solution tends to go out of control. STNO offers a neat way to ease that burden by hiding all this complexity under the bonnet. It’s a well thought-through solution, even though not without a few wrinkles
here and there. I’m pretty convinced that it adds a lot of value and is one of the most overlooked solutions from AWS.
If you have any questions or need a hand, please don’t hesitate to contact me on
Website: cloudyblogs.ctocoe.net
by
pradeepsingh
[ad_2]
Source_link
