How AWS Direct Connect Is Achieved
As one of the first customers on VMware Cloud on AWS, Faction has had the opportunity to start from the beginning when it comes to setting up this much talked about service. It’s currently the end of July here in Colorado, temperatures are hot, Yacht Rock is bumpin, and I continue to work on the in’s and out’s of networking within the Amazon Web Services framework. One piece of AWS networking I often work with is their Direct Connect connectivity.
Direct Connect is basically a physical connection to Amazon and in this post I will go over the basics of how AWS Direct Connect is achieved and once in place, how it is configured with respect to the overall AWS networking configuration.
How AWS Direct Connect is Achieved:
- AWS Direct Connect is one of the services as listed under the Network and Content Delivery section once you log in to the AWS portal. The other options are VPC (Logical Network Isolation), CloudFront (Content Delivery), and Route53 (DNS).
- A Direct Connect from AWS can be ordered from the Direct Connect service section of the AWS portal. Based on the AWS region you are accessing in the portal, a list of physical datacenters can be chosen from a drop-down list as well as a 1gig or 10gig port speed.
- Once the connection is created you can download the LOA/CFA from the portal which you will supply to the facility so the cross-connect between you and Amazon can be put in place.
- Once the physical connection is in place you should see link on your switch and are now ready for the logical continuation of this process.
AWS Networking Configuration:
Creating the virtual interface amounts to turning up a BGP peering session with AWS. There are several pre-requisites here, the easiest of them being having an AWS VPC in the same region as the Direct Connect and a VGW or Virtual Private Gateway attached to this VPC. On the other end of the pre-requisite scale would be having the ability to do BGP peering. This means a physical or virtual router capable of running the Border Gateway Protocol (BGP).
With the VPC, VGW, and BGP in place you can can complete the creation of the virtual interface which will sit on top of the Direct Connect. A nice feature is that AWS allows you to choose the IP addresses with which you will peer with them. The VLAN ID can be chosen as well. Once the BGP session is established, you should see any routes you advertise in the Route Tables section of your VPC that contains the VGW to which you associated the Direct Connect.
And that’s it, networks configured in your VPC can talk with remote networks advertised across the BGP session.
There is the final question of redundancy.
There is another section under the Direct Connect part of the AWS portal called LAGs. A LAG or link-aggregation-group logically bonds together two or more physical connections. Amazon limits a single LAG to four connections but states that this can be increased upon request. Assuming the AWS environment is fully redundant, and with a LAG in place there is redundancy with the connections going in to AWS.
Lastly, we would need to make sure there is redundancy with the router doing BGP peering with AWS. The solution here was to add a second router, and a second virtual interface in the Direct Connect configuration. This will allow for a second BGP connection. The component here that achieves redundancy is that when you create the second virtual interface with the second BGP configuration for the additional router, you can choose the same VGW that you chose when you configured the first virtual interface.
