In this section of the AWS Certified Advanced Networking - Specialty learning path, we introduce you to the various tools, technologies, and services used to connect on-premises environments to the AWS Cloud, including Direct Connect and VPNs.
- Identify and describe how Direct Connect and VPNs are used to connect on-premises environments to the AWS Cloud
- Describe advanced AWS Direct Connect connectivity scenarios, including when to leverage Public, Private, and Transit Virtual Interfaces (VIFs)
- Understand routing fundamentals for static and dynamic routing in AWS along with industry-standard routing protocols such as Border Gateway Protocol (BGP)
- Describe how to use encryption to secure traffic as it travels across VPNs and Direct Connect connections
The AWS Certified Advanced Networking - Specialty certification has been designed for anyone with experience designing, implementing, and operating complex AWS and hybrid networking architectures. Ideally, you’ll also have some exposure to the nuances of AWS networking, particularly regarding the integration of AWS services and AWS security best practices. Many exam questions will require advanced level knowledge of many AWS services, including AWS networking services. The AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
In order to use an AWS Direct Connect, you must create at least one Virtual Interface or VIF. A VIF contains the configuration parameters necessary to support a BGP peering connection between the AWS DX port and the customer router, thereby allowing traffic information to be exchanged between them. AWS currently supports three types of VIFs; Public, Private, and Transit. Public VIFs are used to access AWS public services using public IP addresses via the AWS backbone network. Private VIFs are used to access resources within an Amazon VPC using private IP addressing. And please note that a single DX connection can support a combination of up to 50 Public and Private VIFs. Transit VIFs are used when you wish to access one or more Amazon VPCs via a Transit Gateway that is associated with a Direct Connect Gateway, and the DX connection can only support one Transit VIF. Within the AWS management console, a VIF is created using the Virtual Interface page of the Direct Connect service dashboard.
Though each type of VIF has its own unique purpose, they all share the following configuration options. 1, VIF name. Here, you can specify any arbitrary name, however, it is a best practice to use a naming strategy that allows your resources to be easily identified. 2, VIF owner. Here, you specify the AWS account that owns the DX connection. 3, VLAN. You can select any VLAN ID, but note that for a given AWS DX connection, the same VLAN ID cannot be used for multiple VIFs. 4, address family. Here, you choose the address family IP version 4 or IP version 6 with which to establish a BGP peering connection. To provide support for both families, an additional parent connection can be configured after a VIF has been created. 5, BGP ASN or Autonomous System Number. Here, you specify the ASN for your network. Any number can be used, but if you will be deploying a Private VIF, it is a best practice to use an ASN that you own, or from the private ASN range of 64512-65535.
If you are deploying a Public VIF using a public ASN, you must own the ASN as ownership of it will be verified during the Public VIF creation process. 6, BGP MD5 authentication key. This value represents the password used to authenticate the BGP connection between the AWS and customer-owned equipment. The password must match on both BGP peers for the connection to be established. This may all seem a bit confusing, but let's take some time to examine each VIF type to better understand its intended purpose. Public VIFs are used to enable direct network access to all AWS public zone services using the AWS network as opposed to the public Internet. They are ideal if you require a high-speed, low-latency connection to public AWS services such as Amazon S3, DynamoDB, Amazon SNS, and Amazon SQS.
Though they cannot be used to directly access private IPs, Public VIFs can be used to create VPN connections to provide encrypted access to private networks within VPCs. Border Gateway Protocol (BGP) community tags can be used as a means to control the routes advertised and received over a Public VIF. You can advertise any public IPs that you own over BGP knowing that any IP address prefixes advertised by AWS customers stay within the Amazon network and are not re-advertised to other customers, providers, or networks. Private VIFs enable direct network access to AWS resources such as EC2 instances within a single VPC using their private IP addresses. A Private VIF is connected to an AWS Virtual Private Gateway which is attached to a single VPC in the same region as the DX connection. With Private VIFs, the BGP peer IP addresses do not need to be public and can be statically defined by you or automatically generated by AWS when the Private VIF is created. Once the BGP session is active, your peer router will receive announcements from the cidr block ranges associated with your VPC.
It is true to say that Private VIFs enable direct network access to AWS resources within a single VPC using their private IP addresses. It is also true to say that by combining Private VIFs with Direct Connect Gateways, you can access multiple VPCs in multiple AWS regions within the same account. Your router will establish a BGP session with a Direct Connect Gateway and then receive route announcements from all VPCs associated with the DX Gateway. One very important note to call to attention, however, is that the DX gateway does not allow the VPCs associated with it to communicate with one another. Transit VIFs are increasingly popular when dealing with complex hybrid networks. A Transit VIF is used to associate AWS Transit Gateways with Direct Connect Gateways in order to connect to multi-account, multi-region, and multi-VPC AWS networks.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).