Designing private network connectivity between AWS and Microsoft Azure

In this blog post, I will share some available architectures for building private network connectivity between Microsoft Azure and Amazon Web Services (AWS). There are many scenarios where an organization might need secure networking connectivity between AWS and Azure. Some customers running workloads in Azure choose the AWS Cloud as their strategic long-term cloud platform, which usually initiates a series of cloud migration projects. In these situations, customers require secure network connectivity to transfer data from Azure to AWS.

The use cases discussed in this blog post extend to any scenario that require secure private network connectivity between Azure and AWS using private IP addresses.

Solution overview

At a high level, there are three patterns for building this network connectivity. Each pattern has its own benefits and limitations:

1. AWS Site-to-Site VPN over the public internet.
2. AWS Direct Connect and Azure ExpressRoute in customer-managed infrastructure.
3. AWS Direct Connect and Azure ExpressRoute in a facility with a multicloud connectivity provider.

Prerequisites

• Infrastructure running on AWS with one or more Amazon Virtual Private Clouds (VPC).
• Infrastructure running on Azure with one or more vNets.

AWS Site-to-Site VPN over the public internet

This pattern uses the native site-to-site VPN solution in both cloud providers. This pattern is particularly helpful when there is no need for the private connectivity, throughput, and low latency provided by AWS Direct Connect. In this scenario, the network link is built over a VPN tunnel.

Benefits and limitations

Consider the following benefits and limitations when deploying this solution:

Benefits:

• Network traffic between the source and destination is encrypted.
• Achieve network speeds up to 1.25Gbps of aggregated throughput using Virtual Private Gateway, and when using AWS Transit Gateway, bandwidth across tunnels can be aggregated at 1.25Gbps per tunnel.
• Optionally, enable an Accelerated Site-to-Site VPN connection. It uses the AWS Global Accelerator to route traffic from an on-premises network to an AWS edge location closest to the customer gateway device. AWS Global Accelerator optimizes the network path by using the congestion-free AWS global network to route traffic to the endpoint to provide the best application performance.

Limitations:

• This solution is using public internet to build the VPN tunnel, and depending on the internet provider, the bandwidth may not be guaranteed.
• Traffic flowing over the public internet, even though encrypted in a VPN tunnel, could be an issue for customers with compliance and regulatory requirements.
• Refer to Microsoft documentation for limitations of the Azure Site-to-Site VPN solution.

Depending on whether there is a requirement for multi-VPC or single VPC connectivity, there are two different architectures.

Multi-VPC approach

To reduce the routing complexities of multi-VPC and multi-region architectures, AWS offers Transit Gateway, which simplifies AWS networking and puts an end to complex VPC peering relationships by acting as a cloud scale router. Transit Gateway + AWS Site-to-Site VPN uses a transit gateway VPN attachment to create an IPSec VPN connection.

As illustrated in Figure 1, in this approach, multiple VPCs are connected across one or more accounts to a hub network in Azure. The key components of this architecture include:

• In AWS:
  • AWS Transit Gateway.
  • Customer Gateway, which is the public IP of the Azure virtual network gateway.
  • Transit gateway VPN attachment to build the VPN connection to Azure.
• In Azure:
  • Azure VPN Gateway, which is used to send encrypted traffic to/from an Azure vNet over the public internet.
  • Local Network Gateway, which routes to the VPN endpoint in AWS. Two are required for redundancy.

Figure 1 – Connectivity between AWS and Azure using AWS Transit Gateway

Single VPC approach

If connectivity is required for a single VPC, then it is possible to use a virtual private gateway. Refer to Figure 2.

Figure 2 – Connectivity between AWS and Azure using virtual private gateway

The key components of this architecture include:

• In AWS:
  • Virtual private gateway, which is the router on the AWS side of the VPN tunnel.
  • Customer gateway, which is the public IP of the Azure virtual network gateway.
• In Azure:
  • Azure VPN gateway, which is used to send encrypted traffic to/from an Azure vNet over the public internet.
  • Local network gateway, which routes to a VPN endpoint in AWS. Two are required for redundancy.

AWS Direct Connect and Azure ExpressRoute in customer-managed infrastructure

In this pattern, a private network is created utilizing AWS Direct Connect and Azure ExpressRoute without going through the public internet. AWS Direct Connect links an internal network to an AWS Direct Connect location over a standard Ethernet fiber optic cable. One end of the cable is connected to a customer-managed router and the other to an AWS Direct Connect router. Refer to AWS Direct Connect Resiliency Recommendations to choose the right resiliency option for your network.

Benefits and limitations

Consider the following benefits and limitations when deploying this solution:

Benefits:

• Network traffic between the source and destination is not exposed to the public internet as it flows over AWS Direct Connect, the customer’s network, and Azure ExpressRoute.
• Customers can use this pattern when they need a predictable latency across the cloud platforms.
• This pattern allows customers to benefit from up to 100Gbps per link.

Limitations:

• Customers will need to manage and maintain the relevant routing configurations in their data centers.
• Refer to Microsoft documentation for limitations of Azure ExpressRoute solution.

Similar to the previous option, which was using Site-to-Site VPN, Depending on whether there is a requirement for multi-VPC or single VPC connectivity, there are two different architectures.

Multi-VPC approach

If connectivity is required from the private network in Azure to be available in multiple VPCs, then use an AWS Direct Connect gateway connected to a transit virtual private interface (VIF) and a transit gateway, as shown in Figure3.

Figure 3 – Connectivity between AWS and Azure using AWS Direct Connect, AWS transit gateway and Azure ExpressRoute through an on-premises router

There are a number of AWS Direct Connect features in this architecture:

• AWS Private VIF is an AWS Direct Connect virtual interface (VIF). A private virtual interface, which enables VPC access and connects to an AWS Direct Connect gateway for connecting a private VIF to multiple VPCs across multiple accounts and Regions or a virtual private gateway for connecting a private VIF to a single VPC.
• AWS Transit VIF is used to access one or more transit gateways associated with a Direct Connect gateway.
• Direct Connect Gateway is used to connect the transit gateway to AWS Direct Connect.

Note, depending on the network architecture, there are various ways of connecting a Direct Connect link to VPCs. See available architectures in the Network-to-Amazon VPC Connectivity Options whitepaper.

Single VPC approach

In a pattern where there is only one particular VPC that requires connectivity to Azure (i.e. one particular workload in need of access to Azure vNets), then use an AWS private VIF directly connected to a virtual private gateway, as illustrated in Figure 4.

Figure 4 – Connecting a single VPC in AWS to a hub network in Azure using an AWS Direct Connect and Azure ExpressRoute through an on-premises router

Azure ExpressRoute and private peering allow access to resources within a vNet on private IPs from on premises. Organizations might consider this option in the following scenarios:

• More than 1.25 Gbps of single-flow throughput up to 100Gbps or more is required.
• Predictable latency and packet loss are important.
• Due to regulatory, compliance, and privacy requirements, they can’t build the connectivity over the public internet.

In this pattern, AWS Direct Connect is either co-located with an AWS Direct Connect location or in an on-premises data center. For a list of AWS networking partners, refer to AWS Network Competency Partners. An Azure ExpressRoute connection is also required. Once connections to both cloud providers are established, configure routes between the two platforms to enable communication.

AWS Direct Connect and Azure ExpressRoute hosted by a multicloud connectivity provider

This option is similar to the second pattern, AWS Direct Connect and Azure ExpressRoute in customer-managed infrastructure. However, in this pattern, the AWS Direct Connect and Azure ExpressRoute terminate at a multicloud connectivity provider. The provider handles routing and management of the connections. This reduces the effort required to set up the cross-cloud routing by the customer.

Benefits and limitations

Consider the following benefits and limitations when deploying this solution:

Benefits:

• The network connectivity provider manages and maintains the relevant routing configurations between the cloud platforms, which simplifies network management for customers.
• Network traffic between the source and destination is not exposed to the public internet as it flows over AWS Direct Connect, the customer’s network, and Azure ExpressRoute.
• Use this pattern when predictable latency is required across the cloud platforms.
• This pattern allows customers to benefit from up to 100Gbps links.

Limitations:

• Refer to Microsoft documentation for limitations of the Azure ExpressRoute solution.

Depending on whether there is a requirement for multi-VPC or single VPC connectivity, there are two architectures available, as illustrated in Figure 5 and 6.

Multi-VPC approach

Figure 5 – Connecting multiple VPCs in AWS to a hub network in Azure using an AWS Direct Connect and Azure ExpressRoute through a multicloud connectivity provider

Single VPC approach

In a scenario where there is only one particular VPC that requires connectivity to Azure (i.e. one particular workload in need of access to Azure vNets), then use an AWS private VIF directly connected to a virtual private gateway, as illustrated in Figure 6. The AWS Direct Connect and Azure ExpressRoute terminate at a multicloud connectivity provider and the provider handles routing and management of the connections.

Figure 6 – Connecting a single VPC in AWS to a hub network in Azure using an AWS Direct Connect and Azure ExpressRoute through a multicloud connectivity Provider

Cleanup

There is no cleanup needed. This blog post serves as a guide to architecture rather than an implementation guide.

Conclusion

In this blog post, I discussed the three main patterns for building private connectivity between Azure and AWS. The optimal architecture for an organization will come down to networking requirements around throughput, latency, and jitter.

I discussed three available patterns for building a multicloud architecture:

1. Using native technologies in Azure and AWS to build site-to-site VPN connectivity. A typical use case would be small offices which don’t require guaranteed throughput and low latency.
2. Using AWS Direct Connect and Azure ExpressRoute. Building the network connectivity by routing the traffic through an on-premises datacenter. This approach delivers a low latency private network that bypasses the public internet.
3. Using AWS Direct Connect and Azure ExpressRoute. Building the network connectivity using a multicloud connectivity provider. The provider manages the complexity of cross-cloud routing, simplifying the second option, AWS Direct Connect and Azure ExpressRoute in customer-managed infrastructure.

The described patterns enable customers to establish a private network connection between AWS and Azure, which can be utilized to facilitate network connectivity between workloads and services across the cloud platforms, catering to organizations that require multicloud network interactions.

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.