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.
Welcome to the final lecture of this course where I will summarize the key points from the previous lectures. I started this lecture talking about how an organization would obtain an AWS Direct Connect connection. The high level steps for that process are: 1, an AWS customer request a DX connection in a DX location. 2, once the connection request has been received, AWS will allocate a DX port for the customer on one of their AWS-owned DX routers in the specified DX location. 3, once the DX port has been allocated, the customer downloads the letter of Authorization Customer Facility Access form, or the LOA-CFA, which authorizes the DX location support staff to connect the customer environment to the specified AWS DX port. 4, the customer completes the LOA-CFA form and sends it to the DX location to authorize the DX location support staff to physically access the customer-owned equipment for the purposes of establishing the cross connect with the AWS DX port. 5, with the LOA-CFA form in hand, the DX location support staff run the cross-connect cable from the customer-owned equipment to the AWS-owned DX port.
6, physical Connectivity is now established and the Direct Connect is now available for use. 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 route 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. 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. We then looked at some advanced Direct Connect connectivity architecture, starting with those available via the AWS Direct Connect Resiliency Toolkit. The AWS Direct Connect Resiliency Toolkit assist cloud administrators with the creation of an advanced DX architecture that is in alignment with an organization's SLA objective. The Resiliency Toolkit provides three resiliency models to choose from.
1, maximum resiliency. This model creates multiple DX Connections in multiple DX locations. 2, high resiliency. This model creates a single DX connection in multiple DX locations. 3, development and test. This model creates multiple DX connections in a single DX location. Within this section, we looked at link aggregation groups or LAGs. LAGs enable multiple physical DX connections to function as a single connection of their aggregated bandwidth. For example, four physical 1GB DX connections configured as a LAG would function as a single 4GB DX connection. Remember that the LAGs provide a measure of resiliency, such as providing protection against the failure of a single DX switch port or cross-connect cable, they do not provide any benefit in regards to the failure of an entire DX location. The primary benefit of a LAG is increased network performance via the consolidated bandwidth of the individual LAG members. Finally, we did a quick recap on VPC peering and how the Transit Gateway has simplified the setup and operation of a global AWS network.
The AWS Transit Gateway is a regional resource that introduces a hub and spoke architecture to support highly scalable and easy-to-manage networks. The Transit Gateway functions as the hub through which traffic is routed to each connected network or spoke. A spoke can be a VPC, an on-prem data center, or a remote office. To support global networks, inter-region peering can be used to connect Transit Gateways in multiple regions. When an organization uses Direct Connect, a Transit VIF, Direct Connect Gateways, and Transit Gateways, they have the opportunity to establish connectivity to any resource in the network regardless of its physical location or AWS region. Transit VIFs allow for some truly remarkable network designs and have become the standard for many of the clients I have personally worked with. I encourage you to remember the following bullet points. 1, each Transit VIF supports up to three Transit Gateways. 2, each Transit Gateway can be attached to 20 Direct Connect Gateways. 3, each Transit Gateway can support up to 5,000 attachments and 50 peering connections.
And 4, a single Direct Connect supports one Transit VIF and a combination of up to 50 Public and Private VIFs. That now brings me to the end of this lecture and to the end of this course. You should now have a greater understanding of the AWS Direct Connect connectivity options available to you. Feedback on our courses here at Cloud Academy is valuable to both us as trainers and students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you could contact firstname.lastname@example.org. Thank you for your time and good luck with your continued learning of cloud computing. Have a great day.
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).