Networking & Content Delivery
Using VPC Reachability Analyzer to discover network paths across multiple AWS Regions
Amazon Web Services (AWS) customers can use the AWS global infrastructure to deploy workloads to multiple AWS Regions. They can create global networks that span multiple AWS Regions to connect these workloads to each other and to on-premises networks. A common design pattern is to use a central networking AWS account to own shared network resources, such as AWS Transit Gateway, which is used to provide network connectivity to other AWS accounts with workload resources.
As a network administrator you may want to detect and diagnose network connectivity between resources owned by different accounts and located in different AWS Regions. You can use VPC Reachability Analyzer, a configuration analysis tool that allows you to check whether there is a networking path between a source and a destination resource. At the time of writing this post, the source and destination resources in a path analyzed by VPC Reachability Analyzer must be in the same AWS Region.
In this blog post, we show how you can chain multiple paths in VPC Reachability Analyzer to analyze connectivity between resources located in multiple AWS Regions.
Prerequisites
We assume you are familiar with Amazon Virtual Private Cloud (Amazon VPC) constructs like subnets, route tables, and VPC Reachability Analyzer.
We also assume that you have created a delegated administrator account to analyze resources across multiple accounts using VPC Reachability Analyzer, as described in the documentation and in this walkthrough.
This solution assumes that VPCs in each AWS Region are connected to each other using a Transit Gateway in that AWS Region, and transit gateways in multiple AWS Regions are connected using Transit Gateway peering.
This solution is implemented as a Python script. You must have Python 3 and the AWS SDK for Python (Boto3) installed on the machine where you intend to run the script. The script is designed to be executed with API credentials of an AWS Identity and Access Management (IAM) principal (such as IAM Role) in the VPC Reachability Analyzer delegated administrator account.
The AWS managed policy known as “AmazonVPCReachabilityAnalyzerFullAccessPolicy” must be attached to the IAM Role to grant permissions to analyze paths using VPC Reachability Analyzer.
Setup review
The following figure shows the network architecture that we use to demonstrate the solution.
Figure 1 Network architecture to demonstrate the solution.
Our setup uses three AWS Accounts:
- Account 1: This account has resources located in US East (Ohio)
- Account 2: This account has resources in US West (Oregon)
- Central Networking Account: This account owns the networking constructs: four transit gateways, two in each AWS Region, and the Transit Gateway peerings shown in the preceding figure. Additionally, this account is a delegated administrator account for VPC Reachability Analyzer.
Walkthrough
Command-line options
This script has the following command-line options:
- source-ip: IP address of the source resource
- source-resource: full ARN of the source resource
- destination-ip: IP address of the destination resource
- destination-resource: full ARN of the destination resource
- destination-port: destination port used to evaluate connectivity
- protocol: TCP or UDP (defaults to TCP)
- max-paths: in case there are many different paths between the source and destination AWS Regions, this script can take a long time to finish execution. Use this parameter to limit the number of paths that should be considered between the two AWS Regions. As shown in the preceding figure, there are two separate paths between the two AWS Regions.
Solution overview
This solution requires Transit Gateways as the underlying mechanism for providing network connectivity. First, this solution derives the source and destination AWS Region names from the source and destination resource ARNs provided as command-line options. Then, the script identifies Transit Gateway peerings between the two AWS Regions. For the example shown in the preceding figure, there are two Transit Gateway peerings between the Regions.
For each Transit Gateway peering, this solution creates a pair of regional VPC Reachability Analyzer analyses, one for each ‘leg’ of the multi-Region path. For our setup, the script creates two pairs of analyses shown in the following figure.
Figure 2 Network architecture showing the VPC Reachability Analyzer paths and analyses.
The following table shows the source and destination resources for each VPC Reachability Analyzer analysis.
Path | Region | Analysis | Source Resource | Destination Resource |
Path-1 | Ohio | 1a | Source Instance | TGW-Peering-1 |
Path-1 | Oregon | 1b | TGW-Peering-1 | Destination Instance |
Path-2 | Ohio | 2a | Source Instance | TGW-Peering-2 |
Path-2 | Oregon | 2b | TGW-Peering-2 | Destination Instance |
Table 1 VPC Reachability Analyzer paths and analyses.
Then, the script correlates the outcomes of each pair of analyses. If both of the pairs are successful, then you have a networking path from the source to the destination resources that are deployed in different AWS Regions.
If one or both of the analyses in the pair fails, then you do not have network connectivity between the resources. In this case, we expect paths 1a and 1b to be successful. Since VPCs don’t have attachments into Transit Gateways named TGW-Ohio-NotConnected and TGW-Oregon-NotConnected, VPC Reachability Analyzer analyses for 2a and 2b should both be unsuccessful.
To troubleshoot the paths even further, you can view the details of the analyses either from VPC Reachability Analyzer Console or through an API call.
Now let’s look at how you would use this solution.
Step-1: Executing the script
Clone the code from our GitHub repository, and navigate to the correct directory:
git clone https://github.com/aws-samples/vpc-reachability-analyzer-multi-region
cd vpc-reachability-analyzer-multi-region
Provide the command-line options and execute the script. In the following command, we provide the options to trace network connectivity between the source and the destination instances shown in Figure 1:
python3 vpc_ra_multi_region.py --destination-port 22 --source-ip '10.100.7.248' --destination-ip '10.200.11.8' --source-resource arn:aws:ec2:us-east-2:111111111111:instance/i-123456789abcdefgh --destination-resource arn:aws:ec2:us-west-2:222222222222:instance/i-123456789abcdefgh --protocol 'tcp' --max-paths 2
Since this Python script creates the VPC Reachability Analyzer configuration in the background, it can take a few minutes to complete.
Step-2: Understanding the output
The output of this program is a JSON object that includes details about each pair of regional VPC Reachability Analyzer analyses that it creates. For our setup, the output JSON object looks like the following:
{
"SuccessfulPair": {
"SourceNetworkInsightsAnalysisArn": "arn:aws:ec2:us-east-2:333333333333:network-insights-analysis/nia-123456789abcdefgh",
"SourceNetworkInsightsAnalysisURL": "https://us-east-2.console.thinkwithwp.com/networkinsights/home?region=us-east-2#NetworkPathAnalysis:analysisId=nia-123456789abcdefgh",
"SourceNetworkInsightsPathId": "nip-123456789abcdefgh",
"DestinationNetworkInsightsAnalysisArn": "arn:aws:ec2:us-west-2:333333333333:network-insights-analysis/nia-123456789abcdefgh",
"DestinationNetworkInsightsAnalysisURL": "https://us-west-2.console.thinkwithwp.com/networkinsights/home?region=us-west-2#NetworkPathAnalysis:analysisId=nia-123456789abcdefgh",
"DestinationNetworkInsightsPathId": "nip-123456789abcdefgh"
},
"UnsuccessfulPairs": [{
"SourceNetworkInsightsAnalysisArn": "arn:aws:ec2:us-east-2:333333333333:network-insights-analysis/nia-123456789abcdefgh",
"SourceNetworkInsightsAnalysisURL": "https://us-east-2.console.thinkwithwp.com/networkinsights/home?region=us-east-2#NetworkPathAnalysis:analysisId=nia-123456789abcdefgh",
"SourceNetworkInsightsPathId": "nip-123456789abcdefgh",
"DestinationNetworkInsightsAnalysisArn": "arn:aws:ec2:us-west-2:333333333333:network-insights-analysis/nia-123456789abcdefgh",
"DestinationNetworkInsightsAnalysisURL": "https://us-west-2.console.thinkwithwp.com/networkinsights/home?region=us-west-2#NetworkPathAnalysis:analysisId=nia-123456789abcdefgh",
"DestinationNetworkInsightsPathId": "nip-123456789abcdefgh"
}]
}
In this case, the script detected one SuccessfulPair and one UnsuccessfulPair. The SuccessfulPair corresponds to paths 1a and 1b depicted in Figure 2, and the UnsuccessfulPair object is for paths 2a and 2b shown in Figure 2. The corresponding URLs take you to the VPC Reachability Analyzer console page for each path. The following table maps the paths that we discussed in the preceding table with the outputs generated by the script.
Table 2 Mapping the analysis numbers from Table 1 to fields in the script output.
Analysis | Script output field |
1a | SuccessfulPair.SourceNetworkInsightsAnalysisURL |
1b | SuccessfulPair.DestinationNetworkInsightsAnalysisURL |
2a | UnsuccessfulPair.SourceNetworkInsightsAnalysisURL |
2b | UnsuccessfulPair.DestinationNetworkInsightsAnalysisURL |
Let’s focus on the SuccessfulPair first and view the details of the VPC Reachability Analyzer paths from the AWS Management Console.
The following figure shows the console screenshot for Analysis 1a.
Figure 3 Result of analysis 1a
You can also check the details of the path as shown in the following figure. Note that the source and destination IP addresses are from the command-line options provided to the script. The source resource is the source-instance, and the destination is the Transit Gateway peering attachment
Figure 4 Path details for analysis 1a.
Similarly, we have another VPC Reachability Analyzer path in Region-2, and the URL is provided in the script’s JSON output. The following figure shows the screenshot of path 1b. Note that this path is reachable.
Figure 5 Result of analysis 1b.
The path details show that the source resource is the Transit Gateway attachment, and the destination resource is the destination Amazon Elastic Compute Cloud (Amazon EC2) instance, as shown in the following figure.
Figure 6 Path details for analysis 1b.
Since both the paths are successful, the script included these paths under the SuccessfulPair object.
The following two figures show the console outputs for paths 2a and 2b. Note that both of these paths are unsuccessful.
Figure 7 Result of analysis 2a.
Figure 8 Result of analysis 2b.
The following table shows the final result of executing this script. Since paths 1a and 1b are successful, the script detected a valid networking path between the source and destination resources that were deployed in different AWS Regions.
Table 3 Results of paths analyzed.
Path | Analysis | Successful Networking Path? |
Path-1 | 1a and 1b | Yes |
Path-2 | 2a and 2b | No |
Cleaning up
We recommend deleting any resources that you may have deployed specifically to test out this solution.
Conclusion
In this post, we discussed a sample multi-Region topology and used AWS Transit Gateway to provide inter-Region connectivity. We also described how you can use a Python script to extend VPC Reachability Analyzer’s functionality and use it to check whether there is a network path across multiple AWS Regions. With this information, you can troubleshoot network connectivity issues for multi Region deployments, verify that your network configuration matches your intended connectivity, and create automation in case the configuration drifts from your desired intent.
If you have questions about this post, then start a new thread on AWS re:Post, or contact AWS Support.