Geo-Redundant Architecture with Equinix Redundant Network Edge (1 Network Edge per Metro) and AWS Multi-Region Connectivity

1. Summary

This solution outlines a geo-redundant architecture utilizing redundant Equinix Network Edge instances deployed in separate metros, with connectivity to AWS via Direct Connect in two AWS Regions. The design is intended to enhance service availability and business continuity by providing geographically diverse network and cloud connectivity paths.

1.1 Solution Overview

This solution uses one pair of Redundant Equinix Network Edge devices: one in Equinix’s Metro-A (Primary Compute Plane) and the other in Equinix’s Metro-B (Secondary Compute Plane).

Each Network Edge device connects to its AWS region via AWS Direct Connect (Hosted Connections) over the Equinix Fabric platform:

• Path A: Equinix Fabric (Metro-A) → Virtual Connection A → AWS-Region-A
• Path B: Equinix Fabric (Metro-B) → Virtual Connection B → AWS-Region-B

This solution spans dual AWS regions, with both Network Edge devices and AWS VPCs in a fully Active-Active deployment. Traffic via Network Edge in Metro-A communicates with AWS-Region-A VPC through Virtual Connection A; traffic via Network Edge Metro-B communicates with AWS-Region-B VPC through Virtual Connection B (see Diagram 1).

1.2 High-Level Diagram

1.3 Key Outcomes

The design delivers

• A geo-redundant architecture leveraging geographically diverse Equinix Network Edge instances deployed across multiple metros and AWS Direct Connect connectivity designed as per AWS Multi-Region deployment by having one Direct connection each at multiple locations.
• Resilient traffic failover between metros in the event of a failure impacting the respective Equinix Virtual Connection or AWS Direct Connection.
• Ensures Cross-metro and Cross-platform traffic is primarily routed through the Equinix Fabric backbone, with an alternate path through the AWS global backbone infrastructure during Equinix Virtual Connection failure scenarios.

1.4 Assumptions/Caveats

• AWS Resiliency model: AWS deployment follows the “AWS DX High Resiliency: Multi-Site Non-Redundant model” which is one of the recommended models for High Resiliency by having one direct connection each at multiple locations to support Critical Production Workloads. References: AWS Direct Connect Resiliency Recommendations
• AWS component selection: AWS Networking constructs are customer dependent, for example, Transit Gateway was selected on the assumption that the customer operates multiple VPCs per region requiring full-mesh connectivity. Alternative designs (e.g. VGW-only) are also valid depending on customer topology inside AWS.
• SLA: The Network Edge and Virtual Connections services deployed as part of this design provide service availability in accordance with the applicable Equinix SLA, which offers up to 99.999%.

The AWS connectivity component in this design utilizes AWS Hosted Connections. AWS does not provide an SLA for Hosted Connections; the AWS Direct Connect SLA applies only to Dedicated Connections as per AWS documentation. AWS Direct Connect Service Level Agreement

2. Technology Stack & Scope

2.1 Technology Stack

2.2 Out-of-Scope

3.0 Low Level Design

3.1 Topology

The target design demonstrates a resilient multi-region architecture spanning Singapore and Hong Kong, leveraging Equinix Fabric, Network Edge, AWS Direct Connect, and AWS Transit Gateway.

The Equinix metros selected for this design/lab are Singapore and Hong Kong, while the corresponding AWS Regions are Asia Pacific (Singapore) (ap-southeast-1) and Asia Pacific (Hong Kong) (ap-east-1), respectively (refer to Diagram 2 above).

The Singapore Network Edge establishes a Direct Connect path to AWS Singapore (ap-southeast-1) through Equinix Fabric and eBGP is established with AWS Direct Connect Gateway (AS 64514) and advertises customer prefixes, including loopback networks 1.1.1.0/24 and 11.11.11.0/24, to AWS via the eBGP session. AWS further propagates learned routes to the AWS Transit Gateway (AS 64512), which provides connectivity to resources within the Singapore VPC (10.0.0.0/24).

Likewise, Hong Kong Network Edge establishes a Direct Connect path to AWS Hong Kong (ap-east-1) through Equinix Fabric and eBGP is established with AWS Direct Connect Gateway (AS 64515) and advertises customer prefixes, including loopback networks 2.2.2.0/24 and 22.22.22.0/24, to AWS via the eBGP session. AWS further propagates learned routes to the AWS Transit Gateway (AS 64513), which provides connectivity to resources within the Hong Kong VPC (192.168.10.0/24).

The redundant Device Link Group’s, i.e. DLG interconnect provides an iBGP adjacency between the Singapore and Hong Kong Network Edge Instances within AS 100.

AWS Transit Gateway Peering provides native inter-region connectivity between the Singapore and Hong Kong AWS environments. The peering attachment enables route exchange between the respective Transit Gateways, allowing VPCs in both regions to communicate directly across the AWS global backbone.

For Same-Region traffic exchange between Equinix and AWS (e.g., within Singapore), traffic uses the nearest/local Equinix Fabric Virtual Connection to AWS. This ensures the most direct path and reduces latency.

For Cross-Region traffic exchange between Equinix and AWS (e.g., traffic exchange between Singapore Network Edge & Hong Kong /ap-east-1 AWS VPC OR traffic exchange between Hong Kong Network Edge & Singapore/ap-southeast-1 AWS VPC), then Equinix Fabric backbone is the preferred WAN transport path. The AWS global backbone via Transit Gateway Peering serves as a secondary path.

Within AWS, traffic between VPCs across regions stays within the AWS global backbone, enabling secure inter-region communication between workloads and EC2 instances.

Note - Since NSP connections terminating on Equinix Fabric ports cannot be replicated in a lab environment, the prefixes expected to be announced by NSPs from customer branch sites are simulated using loopback interfaces configured on the Network Edge devices and the same is shown in above Low-Level Topology Design.

3.2 Current Paths for Traffic Exchange between Equinix Platform and AWS Cloud- (With Out Traffic Engineering)

Problem Statement - With no Traffic Engineering in place,

if Network Edge in Singapore Metro wants to communicate with AWS VPC in Hong Kong, then it exits locally via Virtual Connection A for all AWS-bound traffic and tries to use AWS backbone (as shown in Diagram 3 below). However, return traffic from AWS Hong Kong region follows AWS hot potato routing and exits at the nearest Direct Connect egress point — which is Virtual Connection B

This causes Asymmetric routing & makes use of AWS backbone as the primary backbone for forward traffic, instead of using Equinix Fabric backbone.

Likewise, if Network Edge in Hong Kong Metro wants to communicate with AWS VPC in Singapore, then it exits locally via Virtual Connection B for all AWS-bound traffic and tries to use AWS backbone (as shown in Diagram 4 below). However, return traffic from AWS Singapore region follows AWS hot potato routing and exits at the nearest Direct Connect egress point — which is Virtual Connection A

This causes Asymmetric routing & makes use of AWS backbone as the primary backbone for forward traffic, instead of using Equinix Fabric backbone.

While the above behavior is totally functional, it is not the desired behavior because, it causes asymmetric traffic flows (which can introduce complications where stateful firewalls or security inspection devices exist along the path), and it also places more reliance on the AWS internal backbone for cross-region delivery.

Solution to Avoid asymmetric Routing - So, to correct this behavior in order to influence the egress exit path on the Network Edge device and to bring symmetry in Forward and Return Path, BGP Local Preference is configured in Singapore and Hong Kong Network Edges to achieve the desired path of having symmetric forward and return path as described in Section 3.3 later.

Note - No Traffic Engineering is required to manipulate the egress exit path from AWS towards the Equinix Network Edge. AWS inherently follows hot potato routing and always exits at the nearest available Direct Connect location relative to the source VPC — meaning AWS Singapore traffic will naturally exit via Virtual Connection A (Path A) and AWS Hong Kong traffic will naturally exit via Virtual Connection B (Path B). This behavior already aligns with the desired egress path without any additional BGP manipulation on the AWS side.

3.3 Desired Path for Traffic exchange between Equinix Platform and AWS Cloud

Scenarios:

Scenario 1

1.a. Forward Traffic from Network Edge in Equinix Singapore Metro (i.e., from prefixes 1.1.1.0/24 & 11.11.11.0/24) should use Virtual Connection A (aka Path A) to reach VPC in AWS ap-southeast-1.

And traffic destined for resources hosted within the Hong Kong AWS VPC should traverse the Equinix Fabric backbone use Virtual Connection B (aka Path B) to reach VPC in AWS ap-east-1. (See Diagram 5 below for the forward paths from Network Edge in Singapore to AWS)

1.b. Return Traffic from VPC in AWS ap-southeast-1 to Network Edge in Singapore Metro should use Virtual Connection A (aka Path A) and return traffic from VPC in AWS ap-east-1 should use Virtual Connection B (aka Path B) and traverse via Equinix Fabric backbone to reach Network Edge in Singapore Metro. In short, return traffic should follow the same path as forward traffic in Scenario 1.a to avoid asymmetric routing. (see Diagram 5 below for return paths from AWS to Network Edge in Singapore)

Scenario 2

2.a. Forward Traffic from Network Edge in Equinix Hong Kong Metro (i.e., prefixes 2.2.2.0/24 & 22.22.22.0/24) should use Virtual Connection B (aka Path B) to reach VPC in AWS ap-east-1.

And traffic destined for resources hosted within the Singapore AWS VPC should traverse the Equinix Fabric backbone and use Virtual Connection A (aka Path A) to reach VPC in AWS ap-southeast-1. (See Diagram 6 below for the forward paths from Network Edge in Hong Kong to AWS)

2.b. Return Traffic from VPC in AWS ap-east-1 to Network Edge in Hong Kong Metro should use Virtual Connection B (aka Path B) & the return traffic from VPC in AWS ap-southeast-1 should use Virtual Connection A (aka Path A) and traverse via Equinix Fabric backbone to reach Network Edge in Hong Kong Metro - In short, Return Traffic should follow same path as Forward Traffic as mentioned in Scenario 2.a to avoid any asymmetric routing. (see Diagram 6 below for return paths from AWS to Network Edge in Hong Kong)

Scenario 3

3.a In an event if Virtual Connection A (aka Path A) goes down, the forward and return traffic for prefixes advertised through Network Edge in Equinix Singapore Metro should be re-routed via Network Edge in Equinix Hong Kong Metro and still be able to reach AWS VPC in AWS ap-southeast-1 region via Virtual Connection B (aka Path B) - (as shown in Diagram 7 below)

Note - Diagram 7 illustrates the network failover path for validation purposes. In a typical AWS geo-redundant application deployment, workloads in both AWS Regions would be replicas of each other, and users would access the nearest available workload. As a result, traffic would not normally perform a full hairpin traversal across both regions, reducing latency and improving overall application performance.

For example, as shown in Diagram 7, if Virtual Connection A between the Equinix Singapore Metro and AWS Singapore Region (ap-southeast-1) becomes unavailable, traffic originating from the Equinix Singapore prefixes (1.1.1.0/24 and 11.11.11.0/24) will fail over to Virtual Connection B via the Equinix Hong Kong Metro and application requests can be fulfilled directly by the workload hosted in the AWS Hong Kong Region without requiring traffic to traverse the AWS inter-region backbone to reach the original workload in Singapore.

Scenario 4

4.a In an event if Virtual Connection B (aka Path B) goes down, the forward and return traffic for prefixes advertised through Network Edge in Equinix Hong Kong Metro should be re-routed via Network Edge in Equinix Singapore Metro and still be able to reach AWS VPC in AWS ap-east-1 region via Virtual Connection A (aka Path A) - (as shown in Diagram 8 below)

Note - Diagram 8 illustrates the network failover path for validation purposes. In a typical AWS geo-redundant application deployment, workloads in both AWS Regions would be replicas of each other, and users would access the nearest available workload. As a result, traffic would not normally perform a full hairpin traversal across both regions, reducing latency and improving overall application performance.

For example, as shown in Diagram 8, if Virtual Connection B between the Equinix Hong Kong Metro and AWS Hong Kong Region (ap-east-1) becomes unavailable, traffic originating from the Equinix Hong Kong prefixes (2.2.2.0/24 and 22.22.22.0/24) will fail over to Virtual Connection A via the Equinix Singapore Metro and application requests can be fulfilled directly by the workload in the AWS Singapore Region without requiring traffic to traverse the AWS inter-region backbone to reach the original workload in Hong Kong.

3.4 Desired Path within AWS

VPCs in AWS ap-southeast-1 and AWS ap-east-1 should be able to communicate directly with each other via Transit Gateway Peering over the AWS backbone, without having to use Equinix backbone.

3.5 Need to Inject Static Routes into AWS Transit Gateway Peering

AWS Transit Gateways (TGWs) by default learn prefixes only for the directly connected BGP peers established with the Network Edge routers over AWS Direct Connect. Under normal operating conditions, this enables traffic to use the regionally aligned Direct Connect and Equinix Fabric path for ingress and egress connectivity.

However, in failure scenarios such as those illustrated in Diagrams 7 and 8, the directly aligned Direct Connect path may become unavailable. To enable seamless fallback from the Equinix backbone to the AWS inter-region backbone via Transit Gateway Peering, static routes must be configured and propagated across the Transit Gateway peering attachments.

This is necessary because:

• TGW route tables do not automatically propagate on-premises prefixes across peering attachments to a remote TGW in another AWS region. — this is a known AWS architectural behavior. How AWS Transit Gateway works - Amazon VPC
• Without static routes explicitly configured on the peering attachment, the remote TGW has no awareness of on-premises prefixes reachable via its TGW peer region, making inter-region failover impossible.
• Static routes on the TGW peering attachment provide a persistent, pre-provisioned fallback path that becomes active only when the primary regionally aligned Direct Connect path is unavailable.

This ensures that when a regional Direct Connect path or Equinix metro becomes unavailable, traffic can still reach the remote AWS region through the AWS Transit Gateway peering infrastructure, thereby maintaining connectivity continuity across regions.

Key Note’s -

• To support the cross-region failure scenarios illustrated in Diagrams 7 and 8, the customer must manually configure less specific static routes in each Transit Gateway route table, pointing to the peer Transit Gateway for all on-premises prefixes that must remain reachable during a regional Direct Connect or Equinix metro failure - See snapshot 3 and 4 under section 4.3 in this doc to see static routes manually injected onto TGW’s for this design. (These static routes serve as a pre-provisioned backup path and enable traffic to traverse the AWS Transit Gateway peering infrastructure when the primary regionally aligned Direct Connect path becomes unavailable).
• In addition to supporting failover scenarios, static routes must also be configured on the AWS Transit Gateway peering attachments to enable communication between VPCs residing in different AWS Regions through Transit Gateway peering.

4. Deployment & Implementation

Steps are listed in recommended deployment order. All steps below were completed for this lab validation

4.1 Steps for Deployment

4.2 IP Address Plan

The following IP address plan is illustrative, actual addresses should align with your organization's allocation scheme. This plan is referenced directly during the deployment phase, which is why it is included here. Overlapping subnets are not supported in this design.

Equinix Side.

AWS Side

4.3 Basic Sample Cisco Configuration for the NEs to achieve the target design.

Basic BGP Sample configuration for Network Edge in Equinix Singapore Metro

router bgp 100

bgp log-neighbor-changes

network 1.1.1.0 mask 255.255.255.0

network 11.11.11.0 mask 255.255.255.0

network 192.168.5.0 mask 255.255.255.252

network 192.168.6.0 mask 255.255.255.252

network 192.168.11.0 mask 255.255.255.252

neighbor 192.168.5.2 remote-as 100

neighbor 192.168.5.2 next-hop-self

neighbor 192.168.6.2 remote-as 100

neighbor 192.168.6.2 next-hop-self

neighbor 192.168.11.2 remote-as 64514

neighbor 192.168.11.2 password 7 032752180500701E1D

neighbor 192.168.11.2 soft-reconfiguration inbound

neighbor 192.168.11.2 route-map LP in

maximum-paths ibgp 2

Basic BGP Sample configuration for Network Edge in EQUINIX Hong Kong-Metro

router bgp 100

bgp log-neighbor-changes

network 2.2.2.0 mask 255.255.255.0

network 22.22.22.0 mask 255.255.255.0

network 192.168.5.0 mask 255.255.255.252

network 192.168.6.0 mask 255.255.255.252

network 192.168.12.0 mask 255.255.255.252

neighbor 192.168.5.1 remote-as 100

neighbor 192.168.5.1 next-hop-self

neighbor 192.168.6.1 remote-as 100

neighbor 192.168.6.1 next-hop-self

neighbor 192.168.12.2 remote-as 64515

neighbor 192.168.12.2 password 7 02250D4808095E731F

neighbor 192.168.12.2 route-map LP

in maximum-paths ibgp 2

Sample Cisco Path Manipulation configuration to Influence Forward Traffic from Cisco NE to AWS Cloud using Local Preference.

3 basic steps involved for configuring Local Preference in Cisco 8K VNF’s.

Part 1: - Configure Standard ACL to match the interested Prefixes advertised from AWS VPC.

Part 2: - Configure route-map and set Local Preference to 200 for the AWS prefix.

Part 3: - Attach the route-map facing AWS BGP neighbor

To inject static routes manually onto AWS Transit Gateway Route Tables to use AWS backbone in case Local Equinix Virtual Connection failure

For AWS Singapore Transit Gateway

For AWS Hong Kong Transit Gateway

5. Validation and Test Summary

This section focuses on defining the validation methodology, test approach, and documenting the validation results that confirm the deployed solution behaves as designed.

The objective of this validation is to confirm end-to-end reachability between all on-premises test devices (NE devices) and cloud test endpoints (AWS EC2) under normal conditions and also failure scenarios.

Validation 1

Expected Outcome - Under Normal Operations, Network Edge in Singapore Metro should egress via Virtual Connection A (aka Path A) to reach VPC in AWS ap-southeast-1 & should traverse via Equinix backbone and exit via Virtual Connection B (aka Path B) to reach VPC in AWS ap-east-1 - (please refer Forward Path in diagram 3 in the previous section of the document to refer the flow).

Validation Method

1. Traceroute from Network Edge in Singapore (i.e., 1.1.1.1) to AWS EC2 in ap-southeast-1 (i.e., 10.0.0.4) should use Virtual Connection A (aka Path A) and hit local Direct Connect Gateway in Singapore (i.e., 192.168.11.2) and reach its Destination EC2 which is hosted inside AWS Singapore VPC
2. Traceroute from Network Edge in Singapore (i.e., 1.1.1.1) to AWS EC2 in ap-east-1 (i.e., 192.168.10.4) should traverse via Equinix DLG (i.e., 192.168.5.2 OR 192.168.6.2) and use Virtual Connection B (aka Path B) then hit the Direct Connect Gateway in Hong Kong (i.e., 192.168.12.2) and reach its Destination EC2 which is hosted inside AWS Hong Kong VPC.

Outcome -

As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 2

Expected Outcome - Under Normal Operations , Network Edge in Hong Kong Metro should egress via Virtual Connection B (aka Path B) to reach VPC in AWS ap-east-1 & should traverse via Equinix backbone and exit via Virtual Connection A (aka Path A) to reach VPC in AWS ap-southeast-1 - (please refer Forward Path in diagram 4 in the previous section of the document to refer the flow).

Validation Method

Traceroute from Network Edge in Hong Kong (i.e., 2.2.2.2) to AWS EC2 in ap-southeast-1 (i.e., 10.0.0.4) should traverse via Equinix DLG (i.e., 192.168.5.1 OR 192.168.6.1) and use Virtual Connection A (aka Path A) and hit Direct Connect Gateway in Singapore (i.e., 192.168.11.2) and reach its Destination EC2 which is hosted inside AWS Singapore VPC

Traceroute from Network Edge in Hong Kong (i.e., 2.2.2.2) to AWS EC2 in ap-east-1 (i.e., 192.168.10.4) should use Virtual Connection B (aka Path B) then hit the Direct Connect Gateway in Hong Kong (i.e., 192.168.12.2) and reach its Destination EC2 which is hosted inside AWS Hong Kong VPC.

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 3

Expected Outcome - Under normal Circumstances, AWS VPC in Singapore/ap-southeast-1 should exit via Equinix Virtual Connection A, in Singapore Metro (aka Path A) to reach Network Edge in Singapore Metro and should traverse via Equinix backbone to further reach Network Edge in Hong Kong

Validation Method

1. Do a traceroute from EC2 (10.0.0.4) in AWS Singapore/ap-southeast-1 to Network Edge in Singapore (1.1.1.1) and it should hit AWS Direct Connect Gateway (192.168.11.2) in Singapore/ap-southeast-1 and use Equinix Virtual Connection A , in Singapore Metro (aka Path A) to reach Network Edge in Singapore Metro and should traverse Equinix backbone using DLG (192.168.5.2) to further reach Network Edge in Hong Kong (2.2.2.2).

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 4

Expected Outcome - Under normal Circumstances, AWS VPC in Hong Kong/ap-east-1 should exit via Equinix Virtual Connection B, in Hong Kong Metro (aka Path B) in order to reach Network Edge in Hong Kong Metro and then should traverse via Equinix backbone to further reach Network Edge in Singapore Metro.

Validation Method

1. Do a traceroute from EC2 (192.168.10.4) in AWS Hong Kong/ap-east-1 to Network Edge in Hong Kong (2.2.2.2) should use AWS Direct connect Gateway (192.168.12.2) in Hong Kong/ap-east-1 and use Virtual Connection B in Hong Kong Metro (aka Path B) to reach Network Edge in Hong Kong Metro (2.2.2.2) and should traverse Equinix backbone to reach Network Edge in Singapore Metro (1.1.1.1).

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 5

Expected Outcome - AWS VPC in Singapore/ap-southeast-1 should talk to AWS VPC in Hong Kong/ap-east-1 using AWS cross-region backbone.

Validation Method

1. Traceroute from EC2 in AWS Hong Kong/ap-east-1 (192.168.10.4) to EC2 in AWS Singapore (10.0.0.4) and it should be routed directly using AWS Transit Gateway Peering.

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 6

Expected Outcome - if Equinix Virtual Connection A, Singapore Metro (aka Path A) faces outage, then traffic from Equinix Network Edge in Singapore Metro should be re-routed via Equinix cross-metro Fabric backbone and use Virtual Connection B, in Hong Kong Metro (aka Path B) and be reachable to AWS VPC in Singapore.

Validation Method

1. Shut down the Interface on Equinix Network Edge in Singapore Metro facing AWS Singapore/ap-southeast-1 and then do a traceroute from Equinix Network Edge in Singapore Metro (1.1.1.1) to AWS EC2 in Singapore/ap-southeast-1 (10.0.0.4) and it should be re-routed via Equinix cross-metro Fabric backbone DLG (192.168.5.2) and then use Virtual Connection B (aka Path B) and hit the AWS Direct Connect Gateway in Hong Kong (i.e., 192.168.12.2) and then be routed until EC2 (10.0.0.4).

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 7

Expected Outcome - if Equinix Virtual Connection A , in Singapore Metro (aka Path A) faces Outage, then traffic from AWS VPC in Singapore/ap-southeast-1 should be re-routed using AWS cross-region backbone and then use Equinix Virtual Connection B , in Hong Kong Metro (aka Path B) to enter the Equinix Fabric and be reachable to Network Edge in Hong Kong & Singapore.

Validation Method

1. Shut down the Interface on Equinix Network Edge in Singapore Metro facing AWS Singapore/ap-southeast-1 and then do a traceroute from EC2 in AWS VPC in Singapore/ap-southeast-1 (10.0.0.4) to Equinix Network Edge in Singapore (1.1.1.1) and Equinix Network Edge in Hong Kong (2.2.2.2). AWS EC2 in Singapore (10.0.0.4) should be re-routed via AWS cross-region backbone and hit the AWS Direct Connect Gateway in Hong Kong/ap-east-1 (i.e., 192.168.12.2) and use Equinix Virtual Connection B, in Hong Kong Metro (aka Path B) to re-enter Equinix Network to reach Network Edges in Singapore and Hong Kong.

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 8

Expected Outcome - if Equinix Virtual Connection B, in Hong Kong Metro (aka Path B) faces outage, then Equinix Network Edge in Hong Kong Metro should use Equinix cross-metro backbone and use Virtual Connection A in Singapore Metro (aka Path A) and then use AWS backbone and still be able to reach AWS VPC in Hong Kong/ap-east-1.

Validation Method

1. Shut down the Interface on Equinix Network Edge in Hong Kong Metro facing AWS Hong Kong/ap-east-1 and then do a traceroute from Network Edge in Hong Kong (2.2.2.2) to EC2 in AWS VPC in Hong Kong/ap-east-1 (192.168.10.4) and traffic should be routed via Equinix cross-metro backbone via DLG and use Virtual Connection A , in Singapore Metro (aka Path A) and hit the AWS Direct Connect Gateway (192.168.11.2) in Singapore/ap-southeast-1 and then use AWS backbone to reach the EC2 (192.168.10.4) in AWS Hong Kong region.

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.

Validation 9

Expected Outcome - if Equinix Virtual Connection B, in Hong Kong Metro (aka Path B) faces outage, then AWS VPC in Hong Kong/ap-east-1 should use AWS cross-region backbone and then use Equinix Virtual Connection A , in Singapore Metro (aka Path A) and still be able to reach Equinix Fabric and still be able to access Network Edge in Singapore and Hong Kong.

Validation Method

1. Shut down the Interface on Equinix Network Edge in Hong Kong facing AWS Hong Kong and then do a traceroute from EC2 in AWS VPC in Hong Kong/ap-east-1 (192.168.10.4) to Equinix Network Edge in Singapore Metro (1.1.1.1) and Hong Kong Metro (2.2.2.2) and traffic from EC2 in AWS Hong Kong/ap-east-1 should use AWS cross-region backbone using the Transit Gateway Peering and hit AWS Direct Connect in Singapore/ap-southeast-1 (192.168.11.2) and use Equinix Virtual Connection A in Singapore Metro and still be able to reach Equinix Fabric and access Network Edge in Singapore and Hong Kong.

Outcome - As per above Traceroute, it matches with the Validation Method and hence Verified.