Direct Connect is a private Ethernet circuit between a router you control and an AWS router sitting in a colocation facility. That is all. There is no managed service in the middle, no tunnel, no encryption by default. A connection is a port at a Direct Connect location: you plug fiber into it (or a partner does), and AWS lights up the other end.

What makes it a service rather than a cable are virtual interfaces. Each virtual interface (VIF) is a VLAN on that port carrying one BGP session, and the type of VIF decides what the BGP session can reach. Everything else in this article is a consequence of those two facts: it is a physical port you pay for by the hour, and a BGP session you operate.

If you remember one thing: Direct Connect does not make your traffic "faster to AWS". It makes your path deterministic. You trade the internet's variance for a circuit with a fixed price, a fixed route, and a fixed way of failing.

There are two connection types. A dedicated connection is a whole port at 1, 10, 100, or 400 Gbps, owned by your account, which you reach through a Direct Connect Partner or your own network provider. A hosted connection is a slice of a partner's port, sold at 50, 100, 200, 300, 400, or 500 Mbps and 1, 2, 5, 10, or 25 Gbps, and the partner controls the capacity and the price. The AWS docs list single-mode fiber with 1000BASE-LX, 10GBASE-LR, 100GBASE-LR4, or 400GBASE-LR4 optics, 802.1Q VLAN support end to end, and BGP with MD5 authentication. BFD is optional, and asynchronous BFD only takes effect once you configure it on your own router.

Then come the three VIF types. A private VIF reaches a VPC over private IPs, attached either to a virtual private gateway or to a Direct Connect gateway. A public VIF reaches AWS public endpoints such as S3 and the API endpoints, and the prefixes you advertise on it are visible to all AWS customers. A transit VIF reaches one or more Transit Gateways through a Direct Connect gateway. MTU differs by type: private VIFs take 1500 or 9001, transit VIFs take 1500 or 8500.

The Direct Connect gateway (DXGW) is the piece people skip until they need it. It is a global construct, not tied to a Region, that lets one VIF reach virtual private gateways or transit gateways in other Regions and other accounts. Without it, a private VIF talks to exactly one VPC's virtual private gateway.

Who operates what: AWS operates its router and the DXGW. You operate your router, your BGP configuration, the cross-connect in the colo (billed by the colo provider), and the last-mile circuit if your datacenter is not in the colo. The last-mile part is why Direct Connect projects slip. The AWS side takes minutes; the physical side takes weeks.

Use Direct Connect when you move enough data that per-GB internet egress is a line item someone asks about, or when a workload needs predictable latency to a datacenter. Do not use it to "be more secure" by itself: a cable is not encryption. And do not use it as your only path. The AWS pricing guide itself says that a single flat-rate connection leaves you to provide resiliency yourself, for example with Site-to-Site VPN, and the SLA says the same thing in legal language.

Two meters run for a dedicated connection: port-hours and data transfer out (DTO). Data transfer in is $0.00 per GB everywhere, and there is no setup fee or minimum, but port-hours bill even when nothing flows. From the pay-as-you-go pricing page, dedicated ports outside Japan are $0.30/hour at 1 Gbps, $2.25 at 10 Gbps, $22.50 at 100 Gbps, and $85.00 at 400 Gbps. Hosted connections are priced by the partner; the page lists $0.03/hour at 50 Mbps up to $6.20/hour at 25 Gbps. DTO from a US source to the contiguous US, Canada, or Europe is $0.0200 per GB, and from Tokyo or Osaka to the US it is $0.0900.

Then there are the costs that are not on the AWS bill: the cross-connect fee at the colo, the last-mile circuit, and your router. Budget conversations that start from the $2.25/hour number and stop there are the reason finance dislikes network projects.

The thing that changed: on September 15, 2026, AWS announced flat-rate pricing for dedicated connections. One fixed hourly rate replaces port-hours plus DTO. It applies to 10 Gbps and 100 Gbps dedicated connections only, in commercial Regions (China excluded). You pick one of five geographic tiers, from same-metro to any Region globally, and the rate depends on bandwidth and tier. The tier covers DTO from the Regions inside it; traffic from Regions outside your tier is billed at standard rates. Data transfer in is still free, and SiteLink, the colo cross-connect, and last-mile charges are billed separately.

The flat-rate page publishes two example rates: a 10 Gbps port-pair at Tier 1 is $10.96/hour and a 100 Gbps port-pair at Tier 3 is about $219.18/hour. The page's monthly figure for the first one is $8,000.07, but $10.96 times 730 hours is $8,000.80. I use the arithmetic, and so should you when you budget; confirm against the page before signing anything.

The word "port-pair" matters. A flat-rate port-pair is two dedicated ports on different devices with the same speed and tier. One carries traffic and the other stands by, at no extra charge. Usable bandwidth is one port: a 10 Gbps port-pair is 10 Gbps, not 20. So the honest comparison is flat-rate against two pay-as-you-go ports, not one.

On that basis the break-even is in the next section's script. The short version for 10 Gbps: flat-rate wins above roughly 236 TB of outbound data per month, which is about 7 percent utilization of one port. Below that, pay-as-you-go is cheaper. Free tier: none.

Straight from the quotas page. Hard limits: 50 private or public VIFs per dedicated connection (51 combined with transit, of which at most 4 are transit), and exactly 1 VIF per hosted connection. A DXGW takes at most 20 virtual private gateways, 6 transit gateways, and 30 private or transit VIFs. Adjustable: 10 active connections per location per Region per account, 200 DXGWs per account, 10 LAGs per Region.

The one that causes outages is the BGP prefix limit. A private or transit VIF accepts 100 routes per session by default (separately for IPv4 and IPv6), raisable to 1,000 with prefix controls. If you advertise more than your configured limit, the BGP session goes idle and the VIF reports DOWN. A route table that grew during a network merger has taken production off Direct Connect this way. Transit gateway to on-premises is capped at 200 prefixes combined unless raised.

Flat-rate has its own constraints. One billing mode per account per location. Billing mode changes are limited to three per connection in any rolling six months. A LAG cannot mix modes. Bandwidth cannot be changed after creation. Hosted connections are not eligible.

The physical port is not something I can walk you through in a blog post: you request it, wait for the Letter of Authority, and have the colo run a cross-connect. What we can build in an afternoon is everything on the design side: the cost model, a catalog of locations, and the AWS-side routing core (a Direct Connect gateway associated to a virtual private gateway) that costs nothing while idle. I did not have an AWS account attached to this run, so the boto3 below follows the current API reference and is not executed; the cost model is, and its output is shown.

Prerequisites. Python 3.10+, pip install boto3, an AWS account, and credentials for a role with these actions: directconnect:DescribeLocations, directconnect:DescribeConnections, directconnect:CreateDirectConnectGateway, directconnect:DescribeDirectConnectGateways, directconnect:CreateDirectConnectGatewayAssociation, directconnect:DescribeDirectConnectGatewayAssociations, directconnect:DeleteDirectConnectGateway, directconnect:DeleteDirectConnectGatewayAssociation, plus ec2:CreateVpnGateway, ec2:AttachVpnGateway, ec2:DescribeVpnGateways, ec2:DetachVpnGateway, ec2:DeleteVpnGateway. Estimated cost of following along: $0. The DXGW, the virtual private gateway, and the association have no hourly charge by themselves; only ports and data transfer do.

Step 1: the cost model. Save as dx_cost_model.py:

Run it with python3 dx_cost_model.py. Output from my run:

Two caveats the script cannot fix. The $0.02/GB figure applies to the US-to-US, Canada, and Europe rows; swap in your own source row from the pricing page. And Tier 1 covers only the local metro's Region, so a multi-Region design may need a higher tier at a higher rate. The flat-rate guide's own example: a 100 Gbps pair at SFO serving us-east-1 and eu-central-1 sits in Tier 2 for one and Tier 3 for the other.

Step 2: find locations. Pick where your cross-connect would land:

describe_locations returns the location code you pass to create_connection later, the Region it homes to, and the port speeds on offer. Filter by the Region where your workloads live; the location's home Region is what the flat-rate tier is measured against.

Step 3: the AWS-side core. Create a virtual private gateway, attach it to a VPC, create a DXGW, and associate them:

The cidr list is the set of VPC prefixes AWS will advertise to your router over BGP. It is the allow-list you will tune most often, and it is what keeps you under the 100-route default. Your on-premises ASN will live on the VIF, not here; the Amazon-side ASN set on the DXGW must differ from it, per the VIF rules (you cannot use the same ASN for the customer gateway and the virtual gateway or DXGW on one VIF).

When a port exists, the VIF is one call, from the AWS CLI reference shape: aws directconnect create-private-virtual-interface --connection-id dxcon-xxxx --new-private-virtual-interface virtualInterfaceName=prod,vlan=101,asn=65000,mtu=9001,addressFamily=ipv4,directConnectGatewayId=<gw>. VLAN is 1 to 4094, unique on the connection, and cannot be changed after creation. MD5 BGP authentication is on by default and cannot be disabled.

For the AWS-side core, poll the association until it is associated:

Expected: associating a few times, then associated. For a real connection, the verification is different and it is the part most teams skip: ask AWS to bring down the BGP session on one connection through the Resiliency Toolkit's failover test, and confirm your traffic moves to the redundant VIF. If you have never watched traffic fail over, you do not have a redundant design; you have a diagram.

The Direct Connect SLA defines three deployment shapes, and the credit you get depends entirely on which one you built. Multi-Site Redundant requires at least four connections across two locations, two per location on unique AWS devices, plus Enterprise Support and a completed Well-Architected Review; credits start when monthly uptime falls below 99.99 percent. Multi-Site Non-Redundant needs at least two connections across two locations and Enterprise Support, with a 99.9 percent threshold. A Single Connection starts crediting below 95.0 percent, and AWS does not recommend it for production.

Read the credit line: 10, 25, then 100 percent of the port-hour charge for the affected connections, issued only above $1, non-refundable, and the sole remedy. It is a refund of port-hours, not compensation for downtime. Unavailability means a complete inability to send or receive for at least 120 consecutive seconds. Excluded: anything past the demarcation point, your equipment, your configuration, and hosted connections accessed through a partner. The toolkit docs map this to design names: maximum resiliency targets 99.99 percent, high resiliency 99.9 percent, and development and test covers device failure in a single location only. The SLA is a design checklist more than an insurance policy.

VIF stuck in down with BGP idle. Either the BGP MD5 key does not match, the VLAN tag does not match what AWS has, or you advertised more prefixes than your limit and AWS dropped the session. Check prefix count first; it is the silent one.

Traffic flows one way. Your router learned AWS routes but AWS does not know yours, usually because the DXGW association's allowed prefixes do not include the on-premises-reachable range, or an asymmetric route points back through the internet.

Throughput stops at a number that is not your port speed. MTU mismatch. Jumbo frames need to be enabled consistently, and switching a VIF to jumbo can disrupt every VIF on that connection for up to 30 seconds. If two routes for the same prefix come in with different MTUs, or a VPN advertises the same route, the path uses 1500.

The flat-rate bill does not drop. Check that the tier covers the source Region of your traffic. Out-of-tier DTO is billed at standard rates, and multi-Region DXGW or Transit Gateway designs hide this.

Failover works on paper only. Both connections landed on the same AWS device, or the same location. The toolkit prevents same-device terminations; a hand-ordered classic connection does not.

Delete in reverse order, and make sure no VIF still references the gateway:

Deleting a real connection stops port-hours; remember the cross-connect at the colo is billed by the colo and has its own termination process. For this tutorial's resources the bill was $0 and stays $0.

If your steady-state outbound volume is under about 236 TB a month on 10 Gbps, stay pay-as-you-go and spend the savings on a second location. If you are above it, flat-rate buys you a budget that no longer moves with traffic. Either way, the cable is the cheap part; the BGP session and the second path are the product.