The Bill That Stops Moving: What Direct Connect Flat-Rate Pricing Actually Changes

On 5 October 2026, AWS’s Networking & Content Delivery team published a post about a pricing change for Direct Connect, and it opens with an observation any network engineer will recognise: in an on-premises network, a leased line or an MPLS link costs the same “no matter how much data they moved.” The cloud traded that certainty for flexibility, and for most workloads the trade was right. For a few it quietly became the most volatile line on the network bill.

Flat-rate pricing is the correction. It is also a pricing decision that is half a routing decision, because what the fixed rate covers is defined by geography, and geography is exactly what fails over when a Region has a bad day.

The problem: a bill that scales with the thing you are proud of

Under pay-as-you-go, Direct Connect charges a port-hour rate plus data transfer out (DTO) from AWS to your network, per gigabyte. Inbound transfer is free. Per-gigabyte pricing is fine until the workload is the sort that moves data out continuously. AWS’s own list of the cases where DTO becomes hard to predict is generative AI training and inference, medical imaging, video rendering and large-scale data analytics.

The pattern behind that list is the uncomfortable part. The more successful the workload, the more it exports, and the less your forecast survives contact with it. Finance wants a number in January; the traffic has opinions in March.

The challenge: a fixed price needs a fixed boundary

You cannot sell “no per-gigabyte charge” without saying from where to where, and the answer AWS chose is tiers. A tier defines the traffic path between an AWS Region and a Direct Connect location, and traffic that leaves through a geographic scope you did not subscribe to is “charged at standard DTO rates.” The announcement describes two:

• Tier 1 is the local path: a Region and the Direct Connect location that serves it.
• Tier 2 covers source Regions in the same general geographic area, a continent for example, and the Direct Connect locations that serve them.

Everything else in the product follows from that boundary, and so does most of what can bite you.

A single-Region Tier 1 design from AWS’s worked example: us-west-2, two Direct Connect locations in the Seattle metro, Active-Standby.

There are three smaller boundaries to learn at the same time. Flat-rate applies to 10 Gbps and 100 Gbps dedicated connections only; hosted connections are not eligible. It covers DTO, not the rest of the path: data processing in AWS Transit Gateway and AWS Cloud WAN is billed separately, Direct Connect SiteLink traffic is “not covered by any tier,” and colocation, cross-connect and last-mile fees are never part of it. And it arrives with resiliency built in, which is where it gets interesting.

The solution: read the fine print as an architecture

Port-pairs, and the arithmetic of “effective bandwidth”

A flat-rate connection is provisioned as a port-pair: two physical ports on separate devices, within or across Direct Connect locations, tied together by a resiliency group. You then run them Active-Active or Active-Standby. The line to read twice is this one: effective bandwidth equals one port, so a 10 Gbps pair gives you 10 Gbps, not 20.

That is correct engineering, and it is also an easy way to hurt yourself. In AWS’s third worked scenario, two 100 Gbps connections in London run Active-Active under a data-movement task capped at 100 Gbps, with a CloudWatch alarm on the sum of ConnectionBpsEgress across both connections set to fire when aggregate use approaches 50% of total port capacity. The reasoning is the whole point: if you let the pair run at 150 Gbps because both links are healthy, the loss of one location leaves you holding 100 Gbps of capacity against 150 Gbps of demand. Flat-rate pricing gives you a predictable bill. It does not repeal the capacity arithmetic of failure.

If you only want the price and not the topology, the announcement says a port-pair is “recommended but optional.” A flat-rate connection without a resiliency group is still governed by the Single Connection SLA, and when you do add a second connection to form a pair, the second one is included at no added charge.

The failover path is the expensive path

The second worked scenario is the one I would put in front of every architecture review. A linear-channel playout operation streams from us-east-1 and ca-central-1, with a port-pair in Reston and another in Montreal, both on Tier 1. In steady state each Region’s traffic travels its local path, which falls inside the tier, so the bill is flat.

Then a Region is impaired and its market is served from the surviving Region through the same Direct Connect locations. AWS states the consequence plainly: that cross-Region path “exceeds Tier 1 coverage and falls back to standard DTO rates.” The design that was cheapest on a normal day becomes metered, at volume, on the worst day of the year. Moving to Tier 2, which covers both Regions and both locations, makes one tier cover steady state and failover alike, “so you can forecast the cost during normal operation and during a failover.”

Why Tier 1 is not automatically the safe choice for a multi-Region design: the failover path sits outside it.

The same logic applies to growth. Extending the topology to a new Region after provisioning “might require a tier change,” and traffic from a Region outside your tier is billed at standard rates until you raise it. A flat rate is a statement about where traffic is allowed to be, and your resiliency plan is a statement about where traffic will end up when things break. Reconcile the two on paper before the incident does it for you.

Billing mode is per location, per account

Two operational details deserve a ticket in your backlog. First, billing mode is set at the location level within an account: within one account, all connections at a Direct Connect location must use the same mode, and converting one connection to flat-rate “converts every connection at that Direct Connect location in the same account.” If a forgotten test connection shares a location with your production pair, it comes along. Different locations in the same account can use different modes.

Second, if one location must serve both a heavy, sustained workload and a light one, the announcement’s answer is account separation: keep the streaming workload on flat-rate in a dedicated networking account and leave the intranet traffic on pay-as-you-go in another account in the same AWS Organization, both sharing the same physical locations.

Conversion itself needs no new circuits. The console has a Change Billing Mode dialog, and the API action is UpdateConnectionsBillingMode, which takes up to 200 connections per request. Its reference lists the accepted values as PayAsYouGo and FlatRateTier1 through FlatRateTier5. Note the mismatch: the announcement describes two tiers, the API names five. I would read that as room to grow rather than something you can order today, and the announcement itself says that for coverage beyond the published tiers you should talk to your account team.

Deciding whether it pays

The announcement’s break-even method is pleasingly low-tech. Pull the ConnectionBpsEgress CloudWatch metric for each connection, apply the RUNNING_SUM() math expression to see cumulative volume across the billing period, then find your actual DTO spend in Cost Explorer or AWS Data Exports, where it appears under usage types of the form {Region}-{DirectConnectLocation}-DataXfer-Out:dc.{#}. Compare average monthly outbound spend with the flat-rate price for your tier, divide that price by the per-gigabyte DTO rate, and you have the volume above which flat-rate wins.

I cannot give you that number here. The announcement does not quote a rate; it points to the flat-rate pricing page for current figures, and I am not going to invent one. Whatever the price, the shape of the decision is clear: sustained, growing or spiky outbound volume favours flat-rate, and a quiet link that mostly receives does not.

The footprint: what to do on Monday

Three judgement calls, in the order I would make them.

Decide the failure scope before the tier. Write down which Region serves which market when the other is impaired, then pick the smallest tier that covers that path. If the failover path is outside the tier, you have not bought a flat bill, you have bought a flat bill that works until it matters.

Treat the location as the unit of billing. Audit every connection at a location before converting any of them, and decide deliberately whether a second account is cleaner than a mixed mode.

Keep the capacity alarm even when the bill is boring. A fixed price removes the financial signal that used to nag you about heavy transfers. The 50% aggregate-utilisation alarm in AWS’s own example is the replacement signal, and it is the one that tells you a single-location loss will not overrun the surviving port.

Flat-rate pricing is a good change, aimed at the right workloads, with honest fine print. The bill stops moving; the topology still does. It is the second half of that sentence that earns your attention. If you want the other side of the same service, Direct Connect opening its BGP table covers the visibility work, and AWS Interconnect covers what happens when the cross-connect itself is automated away.