What is Direct Connect and how does it work? How much does it cost to direct connect versus connect over the Internet? When does it make sense?
-- Enrico Pollini
Amazon started the direct connect offering in 2011 as a way to bypass the Internet and connect to a network port directly on the Amazon Web Services. This way, you get unencumbered access your instances, your databases, your big data sets, etc. It doesn’t matter what type of DDoS attacks are occurring across the Internet - direct connect traffic is isolated and therefore immune to the side effects of what is happening on the Internet.
How does it work? The AWS Direct Connect is essentially peering but with a couple of interesting twists.
First, note that when you access AWS over the Internet, you of course pay for your Internet Transit, but you also pay Amazon a “Data Transfer Fee” of about 8 cents per GB. The actual cost for data transfer is tiered, but I think of it as about 8 cents per GB.
But when you access AWS over a direct connect service, instead of paying transit fees, you pay for the transport to get to Amazon’s leased direct connect port. The data transfer fee in the direct connect model is charged at a much lower rate; depending on the AWS region you are connecting to you are paying maybe 2-3 cents per GB.
The punchline of “The Business Case for Direct Connect”
The break-even point for AWS Direct Connect from a purely financial analysis is about 20 Mbps (under my stated assumptions.) That is, if you have more than 20Mbps of traffic coming out of AWS destined to you I can prove financially it makes sense to direct connect. And beyond this point, the amount of money that you save by going direct can get into the tens of thousands of dollars per month when you have 10’s of Gbps. Big data guys should definitely direct connect.
But saving on data transfer fees is not the primary reason to employ direct connect. The top 4 reasons are:
1) Better Security. Direct Connect, like peering, provides better security because there are fewer network elements that can be compromised. Further, the transport networks are generally not addressable from the Internet, while the Internet is composed of many accessible routers and links which can be attacked. This is the number one motivation for most of the people I spoke with.
2) Better Reliability. Direct Connect, like peering, provides greater reliability for the directly connected traffic. We saw data to support this at the Croatia EPF when Priceline shared a graph that showed their A/B test with a nicely flat latency graph over a peered link, while the Internet path had many hiccups and spikes.
3) Better Performance. Direct Connect, like Peering, generally provides greater performance. The shortest path between two points is a straight line, and direct connect is a straight path to your AWS resources.
4) Better Control and Visibility. Direct Connect, like peering, provides better control and visibility into the traffic exchanged between you and your AWS resources. The dedicated bandwidth means that only two parties are involved in the traffic exchange - you and AWS. What you send they receive and visa versa. Therefore your router counters are instrumentation enough to diagnose and repair most interconnection issues.
It turns out that even when it is a more expensive interconnect solution, many prefer to direct connect because the value of the traffic exchange to the company is far greater than the $2 per Mbps cost of shipping the bits across the Internet.
While my white paper “The Business Case for Direct Connect” isn’t ready for public release yet, I would love the opportunity to talk through these arguments and the math comparing the two models.
I’ll be at the Console Connect Live event Sept 9th in San Francisco and will bring a handful of copies of the white paper for some walkthroughs. The white paper has already been reviewed by about 40 individuals including people from cloud companies and Amazon, but I want some more walkthroughs with those that use lots of Amazon data. I would feel more comfortable sharing this paper more broadly once I get a little more feedback that I am not missing anything major in the analysis.
Send me a note if you are available for a walkthrough (wbn at drpeering dot net) and I hope to see you at Console Connect Live at the Masonic Center next week!
PS - I received several requests for a list of networking books, referring to The Internet Peering Playbook preface where I say “there are plenty of good books on routing algorithms, protocols, and network management.” I’ll do some research and share a couple new favorites next month.