Provisioning Redundant Connectivity between Your AWS and On-Premises Environments – SAP-C02 Study Guide

Provisioning Redundant Connectivity between Your AWS and On-Premises Environments

When connecting your on-premises environment to your AWS environment, it is highly recommended to make those connections redundant to sustain the failure of any single one of them.

Large organizations are likely to use some form of private connectivity for security purposes; you will then end up choosing between VPN connections over the internet and private connections. You’ve already looked at these two types of connectivity in Chapter 2, Designing Networks for Complex Organizations; please check that chapter out if you’re not sure what the various connectivity options are.

The two major private connectivity options are AWS Managed VPN and AWS DX.

When using AWS Managed VPN, it is highly recommended to connect your Virtual Gateway (VGW) or AWS TGW to two separate Customer Gateways (CGWs) on your end. By doing so, you establish two separate VPN connections, and if one of your on-premises devices fails, all traffic will be automatically redirected to the second VPN. A single VPN connection allows for 1.25 Gbps of bandwidth; however, when using TGW, you can leverage Equal Cost Multi-Path (ECMP) to route traffic across multiple tunnels in parallel, up to 50 Gbps, which is useful when you need to scale beyond the 1.25 Gbps of a single VPN connection.

When using AWS DX, it is recommended to have at least two separate connections at two different DX locations. It will provide resiliency against connectivity failure due to a device failure, a network cable cut, or an entire location failure. You can increase the level of reliability of your DX setup further by adding more connections to additional DX locations. For more details on DX connectivity reliability, you can use the DX resiliency toolkit to help you find the best setup: https://packt.link/x88RO.

It is also possible to combine both technologies in scenarios where your SLAs allow it. If you would like to benefit from the consistency offered by DX most of the time but also, in case of DX failure at your DX location, it is acceptable to use a VPN connection over the internet, then setting up a failover from DX to VPN is a cost-efficient option compared to multiple DX connections to multiple DX locations. In such a scenario, if you have a TGW in your network topology, you could set up ECMP to boost the fallback VPN connection, maintaining a decent bandwidth in case of failover, at least for those who are used to working with 10G or 100G DX connections.

Now, the main reason to have this actual connectivity in the first place between your on-premises and AWS environments is to be able to leverage AWS services or your AWS resources from your on-premises environment, or vice versa. One essential mechanism here, which was already covered in Chapter 2, Designing Networks for Complex Organizations, is VPC endpoints. VPC endpoints, more specifically interface endpoints, powered by AWS PrivateLink, can be used to provide redundant entry points for any traffic targeting a supported AWS service or a VPC endpoint service. Materialized by Elastic Network Interfaces (ENIs) deployed in your subnets within your VPCs, the VPC endpoints are resilient in nature and the connectivity they provide can be made more highly available by deploying them in subnets in multiple Azs.

For more details on the most common hybrid network resiliency approaches, please consult the Hybrid Connectivity whitepaper (you can find the reference in the Further Reading section at the end of the chapter).