1. Home
  2. Training Library
  3. Networking, Connectivity, and Content Delivery (SAP-C02)

Advanced Connectivity Options


Course Introduction
VPC Fundamentals
What is a VPC?
PREVIEW16m 20s
VPC Security and Control
VPC Connectivity
VPC Sharing using the AWS Resource Access Manager
Understanding Direct Connect, Implementation and Configuration
Why Direct Connect?
5m 25s
Understanding AWS Direct Connect - Connectivity Options

The course is part of this learning path

Instructor: David Ball

Advanced Connectivity Options

HA/Resiliency - The AWS Direct Connect Resiliency Toolkit

In the first lecture of this course, I stated that the first step in the DX connection process is that a customer requests “A” DX connection in “A” DX location….and you may be asking yourself, “Can a customer request multiple DX connections in a DX location?” or “Can a customer request multiple DX connections in multiple DX locations in order to increase the resiliency of their direct connect?”  I am happy to say the answer to both questions is “Yes”, “most definitely YES”.  In fact, with the introduction of the Direct Connect Resiliency Toolkit, AWS has made it easier to deploy resilient DX architectures from the time a DX connection is initially requested. 

If you open the Direct Connect service dashboard in the AWS Management Console and click Create Connection, you’ll see (2) connection ordering types, Classic and Connection wizard.  The Classic connection enables an organization to configure a single direct connection, often for the purposes of adding an additional direct connect to an existing DX infrastructure.

The Connection Wizard ordering type launches the AWS Direct Connect Resiliency Toolkit to assist with the creation of an advanced DX architecture that is in alignment with an organization's SLA objective.

The Resiliency Toolkit provides the following resiliency models:

  1. Maximum Resiliency - this model (shown on the screenshot) 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


Link Aggregation Groups (LAGs)

If you explore the resiliency levels available to you as part of the Direct Connect Connection Wizard, you will notice that both the Maximum Resiliency and the Development and Test models will deploy multiple DX connections in a given DX location.  Multiple DX connections within a single DX location can be configured as a Link Aggregation Group, or LAG, for short.  

LAGs enable multiple physical DX connections to function as a single connection of their aggregated bandwidth.  For example, four (4) physical 1GB DX connections, configured as a LAG, would function as a single 4GB DX connection.  

When considering LAGs, remember the following:

  • All DX connections in a LAG are active.

  • There is a maximum of (4) connections allowed per LAG.  Note however, that if you are using 100GB DX connections, only (2) connections can be added to a LAG.

  • All DX connections within a LAG must be the same speed.  For example, a 1GB DX connection cannot be in the same LAG as a 10GB DX connection.

  • All LAG members must terminate in the same AWS DX location/endpoint.

  • You can move an existing DX connection into a LAG AND you can create a LAG with 1 DX connection though it is a best practice to add all LAG members at the same time.

  • The ‘minimumLinks’ attribute of a LAG defines the minimum number of active links required for the LAG to be operational.  As you might have guessed, this value can be set from 1 to 4.  If you have a 4GB LAG composed of 4 x 1GB DX connections and you know you must have at least 2GB for your applications to work correctly, you would set the minimumLinks value to 2.  If 3 of the 1GB connections in the LAG are inactive, the LAG itself will be in a down state until at least one of the DX connections is restored to operation.

Though LAGs provide a measure of resiliency, such as 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 datacenter.  The primary benefit of a LAG is increased network performance via the consolidated bandwidth of the individual LAG members.

Transit VIFs and AWS Transit Gateways

Transit Gateway Overview

Since its introduction in November 2018, the Transit Gateway (or TGW) has become an essential component to countless AWS customers.  Especially for those who must scale their networks to support and connect workloads across multiple AWS accounts, VPCs, and regions.

Prior to the Transit Gateway, VPCs could be connected to one another via a VPC peering connection to route traffic between them. A VPC peering connection establishes a non-transitive, one-to-one relationship between two VPCs.  What does that mean?

For a visual example, here we see that VPC-A has a peering connection with VPC-B and VPC-C.  Thus, resources in VPC-A and VPC-B can communicate AND resources in VPC-A and VPC-C can communicate.  But since there is no direct VPC peering connection between VPC-B and VPC-C, resources in those VPCs cannot communicate with one another.


Though AWS customers appreciated the ability to connect VPCs with peering connections, as the number of VPCs and the need for peering connections increased, it became readily apparent that managing point-to-point network connections across multiple VPCs was complex; even unsustainable.    

Consider this diagram that shows the number of peering connections that would be needed to fully mesh seven (7) VPCs.  Imagine trying to scale and manage such a network to support 50, 100, or a 1000 VPCs!

Image from

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 together, thereby establishing network connectivity for VPCs in AWS regions across the globe.  The data that traverses a TGW network is automatically encrypted and does not travel over the public internet.

Image from

Connecting Direct Connects to TGW Networks

Earlier in this lecture I said it was possible to combine Private VIFs with Direct Connect Gateways to access multiple VPCs in multiple AWS regions within the same account…and that’s a great feature.  But what about those multi-account, multi-region, multi-VPC AWS environments?  Is it possible to use a Direct Connect connection to attach on-prem networks to a TGW-based global AWS network?

The answer is a resounding yes by means of creating a Transit VIF and attaching it to a Direct Connect Gateway.  A Transit VIF will enable you to connect and access up to three (3) Transit Gateways per Direct Connect Gateway, over a private dedicated connection as shown in the diagram.

Image adapted from

Before we jump into a final architecture example, here are a few bullet points you should remember:

  • Each Transit VIF supports up to (3) Transit Gateways.

  • Each Transit Gateway can be attached to 20 Direct Connect Gateways.

  • Each Transit Gateway can support up to 5,000 attachments and 50 peering connections.

  • A single Direct Connect supports (1) Transit VIF and up to 50 Public/Private VIFs.

Finally, a Transit Gateway is able to route to and from Direct Connect Gateway attachments, even those located across a TGW peering connection.  Practically any network connected via a Direct Connect Gateway that is attached to a Transit Gateway is reachable over the Transit Gateway network and this allows AWS customers to architect very intricate and robust networks.

For example, consider this diagram.  

On the left we have an AWS Transit Gateway network that spans (3) regions.  The TGWs are peered and thus an AWS resource in any VPC could communicate with resources in any region across the AWS network.  

On the right, we have 3 geographically dispersed data centers, each connected to an AWS Direct Connect which utilizes a Transit VIF attached to a Direct Connect Gateway which is itself attached to a Transit Gateway.  

This type of architecture could allow a resource in any corporate data center to access an AWS resource in any region….AND because the corporate data centers all use Direct Connect with Transit VIFs, this configuration would allow the corporate data centers to communicate with one another using the AWS Transit Gateway network.


3h 20m

This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam. 

Want more? Try a Lab Playground or do a Lab Challenge

Learning Objectives

  • Get a foundational understanding of VPCs, their security, and connectivity
  • Learn about VPC sharing using the AWS Resource Access Manager
  • Discover inter-regional and intra-regional communication patterns in AWS
  • Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
  • Understand routing in AWS, including static and dynamic routing
  • Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
  • Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.