Introducing AWS DX

Using a VPN connection when you get started makes a lot of sense. It can be up and running in no time and will likely cause no big change in your network topology.

However, it is not always the best option. For cases where internet connectivity unreliability becomes a business risk, AWS DX offers the right alternative by offering low latency and consistent bandwidth connectivity between your on-premises infrastructure and AWS.

In a nutshell, a DX connection ties one end of the connection to your on-premises router and the other end to a virtual interface (VIF) on AWS. There are three different types of VIFs: public VIFs, private VIFs, and transit VIFs. Public VIFs are used to connect to AWS services’ public endpoints. Private VIFs are used to connect to your own AWS environments within a VPC. Transit VIFs allow you to end the connection on a TGW.

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.

Additional Considerations for Resiliency

As a best practice, it is recommended to have at least two separate connections at two different DX locations. In this case, you end up with two DX connections. This will provide resiliency against connectivity failure due to a device failure, a network cable cut, or an entire location failure.

To achieve maximum resiliency, use at least two separate connections terminating on distinct devices in at least two DX locations attached to two different regions. In this case, you end up with at least four DX connections and are protected not just against a single device failure, a network cable cut, or an entire location failure, but also against an entire geography failure.

Either as an alternative to additional DX connections or as an additional resiliency protection measure, you can also create a VPN connection as a backup connectivity option.

Now that you know how to set up hybrid network infrastructure, you are ready to learn how to create a hybrid storage infrastructure between your on-premises locations and your AWS environment.

Cost Factor

On top of the already mentioned reasons to opt for a DX connection, such as network bandwidth consistency and throughput, the cost is obviously an important aspect not to be ignored or discarded too quickly.

For occasional usage and low data volume transmission between your on-premises environment and AWS, in many cases, a VPN connection is good enough, and this is what organizations typically begin with when they start using AWS. After all, all organizations already have broadband internet access nowadays, so setting up a simple IPsec connection is usually straightforward. However, when additional requirements come in, such as improving network consistency and reliability or benefiting from a higher network throughput, organizations start looking into AWS DX.

And beyond technical requirements, the overall cost of the solution should also be estimated. For AWS Managed VPN, you pay for the number of hours the connection is active (which varies per AWS region) and for data (volume) that you transfer from AWS to your on-premises environments, also known as Data Transfer Out (DTO). For AWS DX, you pay a price per port hours a DX connection is up (which varies per AWS region and connection capacity) and for data (volume) that you transfer from AWS to your on-premises environments. Data sent into AWS bears no costs.

DTO costs for data sent over a VPN connection are the same as for data sent over the internet from your AWS environment and vary per AWS region. DTO costs for data sent over a DX connection vary per combination of AWS region and AWS DX location. The closer those two are to each other, the lower the DTO costs. For instance, DTO costs are lower when transferring data from any AWS region in Europe to any DX location in Europe than from any AWS region in Asia to any DX location in Europe (and vice versa, by the way). That said, DTO costs for traffic sent over DX are always lower than DTO costs for traffic sent over the internet (VPN or not), and sometimes even an order of magnitude lower.

Thus, besides mere technical requirements, in situations when large volumes of data (terabytes (TB) or beyond) need to be transferred from your AWS environments to your on-premises environment(s), it can become significantly more beneficial financially to leverage a DX connection.