{"id":4291,"date":"2022-04-01T13:58:00","date_gmt":"2022-04-01T11:58:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=4291"},"modified":"2022-04-01T14:46:53","modified_gmt":"2022-04-01T12:46:53","slug":"hybrid-cloud-networking-backup-aws-direct-connect-network-connection-with-aws-site-to-site-vpn","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/hybrid-cloud-networking-backup-aws-direct-connect-network-connection-with-aws-site-to-site-vpn\/","title":{"rendered":"AWS Direct Connect with AWS Site-To-Site VPN as a failover"},"content":{"rendered":"\n
Today, many solutions require approaches that implement a joint use of public cloud providers and their own on-prem resources. In this series of articles, we provide an overview of useful AWS services to build a hybrid network that seamlessly extends workloads from local installations to the public cloud according to business needs. <\/p>\n\n\n\n
If you like to know more about Direct Connect, please check our previous blog post<\/a>. It explains what it is and how to choose it regarding some specific needs.<\/p>\n\n\n\n In some cases, this connection alone is not enough. It is always better to guarantee a fallback connection<\/strong> as the backup of DX. There are several options, but implementing it with an AWS Site-To-Site VPN<\/strong> is a real cost-effective solution that can be exploited to reduce costs or, in the meantime, wait for the setup of a second DX.<\/p>\n\n\n\n Please bear in mind that this solution does not ensure an SLA, and it is impossible to obtain it with a connection over the public internet. <\/p>\n\n\n\n This article will progress on what has already been put in place in the previous article (Hybrid Cloud Networking: centralized NAT Gateway through AWS Transit Gateway)<\/a>. We presented how to set up a Transit Gateway and share network appliances between AWS Accounts. So, please, it might be helpful to read it first to fully understand what will be explained here. <\/p>\n\n\n\n Let’s assume that a fictitious company currently wants to connect its own on-premises facilities with the AWS Accounts directly to a DX connection by using a VPN Site-To-Site as a backup.<\/p>\n\n\n\n Before proceeding, it is required that a Direct Connect has been already requested and ordered. Plus, the whole AWS networking has been centralized through Transit Gateway.<\/p>\n\n\n\n As shown below, the connection between the local facility and AWS through the Direct Connect private connection can be configured by directly attaching the DX to the AWS Transit Gateway.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Let’s dive in: <\/strong><\/p>\n\n\n\n Direct Connect offers a location over a standard Ethernet fiber-optic cable. One end is connected to the on-prem router, and the other to the AWS DX router. A user can associate it directly with the Transit Gateway through the Transit Virtual Interface (VIF)<\/strong>. This specific interface is different from the private\/public interface because it is linked directly with the Transit Gateway. This enables connectivity to all VPCs that share an attachment. <\/p>\n\n\n\n Be careful! Please note that it is possible to attach only 1 transit virtual interface for DX dedicated connection. This limit cannot be increased. <\/a><\/p>\n\n\n\n After the setup has been done, the company wants to use the site-to-site VPN <\/strong>as a backup. It consists of an encrypted link, called VPN tunnel, that connects the on-prem site with AWS. Each VPN connection includes two VPN tunnels which can simultaneously be used for high availability<\/em>. <\/p>\n\n\n\n In our case, the two endpoints will be the Customer Gateway (CGW) for the on-prem side and the Transit Gateway for the AWS one.<\/p>\n\n\n\n Please note that VPN has a couple of limits that must be taken into account in this design:<\/p>\n\n\n\n The modified scenario will look like this:<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n With this improved configuration, the traffic will flow through Direct Connect and, when a failure happens<\/strong> on the DX<\/strong>, the traffic will be switched to the failover VPN Channel<\/strong>. The purpose of using DX as the primary active path<\/strong> is that it guarantees:<\/p>\n\n\n\n The entire routing behavior and the failover mechanism is managed by the BGP protocol<\/a>, and it’s a constraint for the customer gateway router to support it. The router will send various keepalive packets to check if the DX path is active, and if a failure is detected, the path is switched to the fallback one (VPN). In fact, BGP dynamic routing is directly controlled by the Customer Gateway. The CGW, whether software or a physical appliance, must be configured appropriately by the network administrator to exchange routing information among the various routers. It works by managing a table of IPs (called prefixes) that provides information on the reachability of the different networks we’re observing. Then, BGP is responsible for exchanging IP blocks advertisement (IP prefixes) to the various systems. <\/p>\n\n\n\n <\/p>\n\n\n\n Hence, to have our infrastructure in place, it is necessary to advertise the same prefix<\/strong> for both the Direct Connect (VIF)<\/strong> and the VPN<\/strong>, because if the CGW is advertising the same routes toward the AWS VPC, the Direct Connect path is always preferred, regardless of AS path prepending.<\/p>\n\n\n\n Please, by considering the table\u2019s point 3, be careful when configuring the VPN Site-To-Site. Inside the VPN wizard form, a user must specify “Dynamic”<\/strong> as Routing Option, <\/strong>otherwise all the reasoning would fall.<\/p>\n\n\n\n Sometimes, a scenario of asymmetric routing might occur with this kind of configuration. Asymmetric routing<\/strong> means that a package traverses from a source to a destination in one path and takes a different path when it returns to the source. i.e., traffic from AWS to on-premise might flow through the Direct Connect link, but for the opposite, the traffic might traverse the VPN tunnel instead.<\/em><\/p>\n\n\n\n
In some scenarios, hybrid cloud networks rely on AWS Direct Connect (DX)<\/strong>. This service provides another option rather than the public internet to connect to AWS by delivering data through a private network connection<\/strong> between<\/strong> the on-premise facility<\/strong> and the AWS cloud<\/strong>. <\/p>\n\n\n\nHigh-Level Architecture<\/h1>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
But if BGP is advertising prefixes, how are the priorities<\/strong> of the routes managed by AWS? Well, to understand it better, let\u2019s shift the focus on the Transit Gateway and resume them in a table:<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\n