Various Flavors of AWS DX – Designing Networks for Complex Organizations – SAP-C02 Study Guide

Various Flavors of AWS DX

You can use AWS DX provided that one of the following applies:

  • Your network is co-located with an existing AWS DX location; see https://packt.link/Awm60 for a current list of these.
  • You leverage an AWS DX partner, a member of the AWS Partner Network (APN); see https://packt.link/6OyGq for a current list of these.
  • You work with an independent service provider to connect to AWS DX.

There exist three types of DX connections. That said, only the first two types listed in the following section are recommended when you require a consistent connection capacity, which is eventually the main reason to set up a DX connection.

Dedicated Connection

This type of connection, available as 1 gigabit per second (Gb/s), 10 Gb/s, or 100 Gb/s ports, consists of a dedicated link assigned to a single customer. Dedicated connections can be combined to further increase your bandwidth by using link aggregation groups (LAGs). Link-speed availability can vary per DX location, so it is best to consult the list of DX connections from the AWS documentation at the link mentioned previously.

Dedicated connections support up to 50 private or public VIFs and 1 transit VIF.

Hosted Connection

This type of connection, available from 50 megabits per second (Mb/s) to 10 Gb/s, consists of a connection provided by an AWS DX partner and is made available on a link shared with other customers. AWS makes sure that the sum of all hosted connections’ capacities per link does not exceed the network link’s actual capacity.

With up to 500 Mb/s capacity, hosted connections support one private or public VIF. Hosted connections of 1 Gb/s or more support one private, public, or transit VIF.

If you require more than one VIF, either obtain multiple hosted connections or use a dedicated connection.

Hosted VIF

Some AWS DX partners provide hosted VIFs, which consist of a VIF made available to you in your AWS environment while the underlying DX connection is managed in a separate account by the provider. However, it is worth noting that AWS does not limit the traffic capacity on hosted VIFs. Therefore, the underlying DX connection capacity can be oversubscribed, which could result in traffic congestion, and therefore it is not a recommended option when you’re looking for a consistent capacity to connect your on-premises and AWS environments.

AWS DX Connectivity Overview

The following diagram shows an overview of end-to-end (E2E) connectivity when setting up an AWS DX link between your on-premises and AWS environments:

Figure 2.5: Public and private VIFs

In the case of a private VIF, the VIF can be attached either to a VGW in a VPC in the same region as your DX connection or to a DX gateway (DX GW). An AWS DX GW is a globally available resource on AWS that can be accessed from any region. Its role is to help connect multiple VPCs, possibly in multiple AWS regions, through AWS DX.

It is important to note that a single DX dedicated connection can support up to 50 public or private VIFs. When using private VIFs, you have a choice either to connect those VIFs directly to your VPCs or to use a DX GW in between. Because each DX GW can connect on the other end up to 10 VGWs (so, 10 VPCs), using a DX GW allows you not only to connect to 500 VPCs through a single DX connection, but those VPCs can also be in multiple AWS regions.

Additionally—and this will be the focus of a later section in this chapter—you can also leverage an AWS TGW to simplify routing in cases where you have a large number of VPCs (in the 100s or 1,000s). A single TGW can support up to 5,000 (VPC) attachments today.

Large and complex organizations typically have an AWS environment spanning more than one AWS region, whether this is because they operate in multiple geographies or to follow some regulatory recommendations, or for disaster recovery (DR) purposes.

The following diagram summarizes the various options available:

Figure 2.6: DX options summary

Such complex organizations adopt either a private VIF to DX GW (Option 2) or a transit VIF to DX GW (Option 3) or sometimes a combination of the two, essentially because an AWS DX GW and a TGW make their life so much easier. A VPN connection over a public VIF (Option 4) can be used to enforce E2E encryption as an extra security measure over public VIFs when MACsec (IEEE 802.1AE Media Access Control (MAC) security standard) encryption over DX is not available at your preferred DX location.

Now, you may be wondering when to use IPsec encryption and when to use MACsec encryption over DX. The first consideration is connection speed. MACsec encryption is available at speeds (10 Gb/s and 100 Gb/s) that cannot be reached with a single VPN connection (maximum 1.25 Gb/s). So, if you require encryption on links of 10 Gb/s or more, then MACsec, if it is available at your DX location, is a much easier solution for encryption. Alternatively, you could think of aggregating multiple VPN IPsec connections to work around the throughput limit, but that increases the operational complexity. The second consideration is technology. IPsec encryption is an E2E connectivity encryption mechanism that works at layer 3 of the Open Systems Interconnection (OSI) model (that is, IP). MACsec encryption, on the other hand, is a hop-by-hop encryption mechanism at layer 2 of the OSI model (that is, MAC). In this case, every network hop is responsible for encrypting the data frames until the next hop, and so on so forth. Both encryption mechanisms operate at different layers and are not mutually exclusive, but you can use either of the two or both simultaneously. MACsec encryption brings an additional protection layer to your security arsenal.