How AWS Direct Connect works?

Question

How does AWS Direct Connect work?

From AWS docs:

AWS Direct Connect establishes a dedicated.network connection between your on-premises.network and AWS... bypassing your inte.net service provider.

Please explain what it actually means in practical sense? And why would it be any better?

Answer 1

NOTE: I know there are AWS docs (worst docs I've ever seen) and some other articles and answers on SO, but none of those explain what it actually means in practice or miss some important notes for understanding for somebody who's only used to public inte.net and can't imagine how it's possible to "bybass public inte.net". So I decided to create this post from my collective knowledge and also provided a real example from our company case. Hope it will be useful for somebody.

---

So, from AWS docs:

AWS Direct Connect establishes a dedicated.network connection between your on-premises.network and AWS... bypassing your inte.net service provider.

But to understand what it actually means, lets refresh some knowledge.

Public Inte.net

Inte.net cable goes from your PC to your ISP (Inte.net Service Provider) switch located somewhere in your apartments building, usually.

And then... it gets connected to another switch, and it goes on and on like that, travelling through other cables and switches until it reaches the target PC you wanted to reach. Each switch knows where to send the signal next (how: it's a different topic).

So the signal first travels to some main switch of your ISP (where it does all the pricing/monitoring etc). ISP itself is then connected to another bigger ISP (they have some sort of partnership where your ISP pays that another ISP for using its cables, just like you do with your own ISP). In total, lots of physical cables literally lay down around the world going undersea/underground/over-the-air allowing the whole world to be connected to each other.

Problem

1. There are millions of inte.net users . You can imagine how many switches and cables is needed to support all that big.network, and how much traffic (hello TikTok) is traveling. Because of that:

   1. Your signal doesn't travel via the most optimal route through switches, when it needs to go from your PC to another target machine (some AWS machine in our case). Especially when you're on different continents.

   2. Big traffic also makes your ping fluctuate, depending on the load on each individual switch.

2. There are all sorts of switches , we can't really trust them . Moreover, ISPs aren't required to be compliant with PCI security standard, or any other. If you want a secure connection, you have to use VPN (IPSec, OSI layer 3), but it costs in terms of performance and ping speed.

AWS Direct Connect

AWS own inte.net

AWS came here and said - "let me create my own inte.net around the world. I literally lay down my own physical cables and I'll connect them to only selected (partner) data centers. So you can use those instead of public inte.net" AWS may still probably lease someone's cables (especially underseas one's), but most of the cables/switches are their own ones. Benefits:

1. It's a much smaller.net. Less switches and they're more reliable. Cables go almost straight to AWS. Therefore it's faster.

2. AWS implements MACsec OSI layer 2 security at hardware level. So no VPN required (though you could still use it). It's faster.

How to connect

Obviously, AWS can't connect to each PC in the world just like public ISPs, otherwise it would be the same public inte.net.network, sort of speaking, and wouldn't make sense.

AWS has a partnership with selected data centers around the world to which AWS did the physical connection and put their own switch there (" AWS Direct Connect Cage "). So if you put your server in such data center (or at least your server connects to such data center from other nearest location via public inte.net) you can quickly enter AWS.network where your signal will travel much faster. So you don't even need a public ISP in such case.

You do this to :

1. Reduce latency and improve stability into your AWS environment.

2. Even reduce latency between non-AWS endpoints. When both endpoints use public inte.net to only connect to the nearest AWS cage, while then cage-to-cage traffics goes through AWS internal.network. And voila!

Results

In our company case, we managed to decrease the latency around 5 times (ie 0.5 seconds vs 2.5 seconds) for non-AWS connectivity.