Book a call
,

Direct Connect Flat-Rate Pricing: The Break-Even Model

Jorge Vazquez
Crossing cost lines showing the break-even point for Direct Connect flat-rate pricing

“Should we switch?” is the only question anyone asks about Direct Connect flat-rate pricing, and the only useful answer is a spreadsheet. The launch gives you a fixed hourly rate per port-pair with no data transfer out (DTO) charge for Regions in your pricing tier. Whether that beats per-GB billing depends on how many bytes you move, where they come from, and who ends up paying for them. This post builds the model from your own billing data, then deals with the part most teams forget: allocating a shared fixed fee across accounts. It closes with the cases where flat-rate loses outright.

The Direct Connect flat-rate pricing break-even formula

Strip it down and you are comparing two monthly totals:

  • Pay-as-you-go: port-hours for every port, plus DTO GB from each Region times that Region’s Direct Connect DTO rate, plus SiteLink.
  • Flat-rate: the port-pair’s hourly rate times hours in the month, plus DTO from Regions outside the selected tier at standard rates, plus SiteLink at standard rates.

SiteLink shows up on both sides unchanged, so it cancels out of the decision, but it still belongs in the forecast. Out-of-tier DTO is the variable most people drop, and it is the one that makes flat-rate look better on a whiteboard than on an invoice. The rates you need live on the standard pricing page and the flat-rate pricing page; tier coverage varies by Direct Connect location, so model per location, not per company.

Pulling DTO by Region and account from CUR

Cost Explorer is fine for a quick look, but a model needs rows. The Cost and Usage Report in Athena gives you DTO per usage type, per account, per resource. Direct Connect DTO is attributed to the account responsible for the traffic, which is exactly the split you need later for allocation. Against a CUR 2.0 table:

SELECT
  date_trunc('month', line_item_usage_start_date)      AS month,
  line_item_usage_account_id                            AS account_id,
  line_item_usage_type                                  AS usage_type,
  line_item_resource_id                                 AS resource_id,
  SUM(line_item_usage_amount)                           AS gb,
  SUM(line_item_unblended_cost)                         AS cost_usd
FROM cur2
WHERE line_item_product_code = 'AWSDirectConnect'
  AND line_item_usage_type LIKE '%DataXfer-Out%'
  AND line_item_usage_start_date >= date '2026-03-01'
GROUP BY 1, 2, 3, 4
ORDER BY month, cost_usd DESC;

The usage type prefix identifies the source Region. Map each prefix to “in tier” or “out of tier” for the location you are evaluating, and you have both halves of the flat-rate formula. If you just want a per-account sanity check without Athena, the get-cost-and-usage API can group by linked account:

aws ce get-cost-and-usage \
  --time-period Start=2026-03-01,End=2026-09-01 \
  --granularity MONTHLY --metrics UsageQuantity UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Direct Connect"]}}' \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT Type=DIMENSION,Key=USAGE_TYPE \
  --output json \
| jq -r '.ResultsByTime[] | .TimePeriod.Start as $m | .Groups[]
    | select(.Keys[1] | test("DataXfer-Out"))
    | [$m, .Keys[0], .Keys[1], .Metrics.UsageQuantity.Amount] | @tsv'

The model itself

Feed six months of that data into something you can reason about. A small Python model beats a spreadsheet because you can run it on every location in one pass and re-run it monthly:

HOURS = 730

def monthly_costs(in_tier_gb, out_tier_gb, dto_rate, payg_port_hr,
                  ports, flat_pair_hr):
    payg = ports * payg_port_hr * HOURS + (in_tier_gb + out_tier_gb) * dto_rate
    flat = flat_pair_hr * HOURS + out_tier_gb * dto_rate
    return round(payg, 2), round(flat, 2)

def break_even_gb(dto_rate, payg_port_hr, ports, flat_pair_hr):
    return (flat_pair_hr - ports * payg_port_hr) * HOURS / dto_rate

history = [
    {"month": "2026-06", "in_tier_gb": 210_000, "out_tier_gb": 9_000},
    {"month": "2026-07", "in_tier_gb": 265_000, "out_tier_gb": 12_500},
    {"month": "2026-08", "in_tier_gb": 190_000, "out_tier_gb": 8_200},
]
args = dict(dto_rate=0.02, payg_port_hr=2.25, ports=2, flat_pair_hr=10.96)

print("break-even in-tier GB/month:", round(break_even_gb(**args)))
for m in history:
    payg, flat = monthly_costs(m["in_tier_gb"], m["out_tier_gb"], **args)
    print(m["month"], "payg", payg, "flat", flat, "delta", round(payg - flat, 2))

The rates in args are placeholders; swap in your location’s numbers. With those example inputs, break-even lands around 236 TB of in-tier egress a month against the 10 Gbps Tier 1 pair at $10.96/hour. A 10G link at full line rate moves roughly 3.3 PB a month, so break-even is single-digit average utilization. That is why heavy users will find this an easy call, and why the interesting work is at the margins.

Two refinements make the model trustworthy. First, use the minimum month, not the average: flat-rate charges you every hour, so a quiet month is where it hurts. Second, remember that you get only three billing-mode changes per connection per rolling six months, so a model that flips the recommendation month to month is telling you to stay put.

Stress-test before you commit

Run three scenarios, not one. The floor scenario takes your lowest month and trims another 20 percent for a migration that finishes early or a workload that moves back into AWS. The growth scenario applies whatever egress growth your roadmap implies over the next two quarters. The drift scenario shifts 10 to 20 percent of in-tier bytes to an out-of-tier Region, because someone always spins up analytics in a Region you did not plan for. If flat-rate wins all three, convert. If it only wins the growth case, set a calendar reminder and wait for the growth to show up in CUR rather than in a slide deck. Store the scenario inputs next to the output so the next review argues about assumptions, not arithmetic.

Transit hub splitting one shared network cost across multiple accounts by traffic volume

Allocating a shared flat-rate connection

Here is the chargeback trap. Under pay-as-you-go, DTO lands in the account that sent the traffic, so showback happens for free. Under flat-rate, one fixed fee lands on the account that owns the connection, typically a network account. Every workload account’s egress cost drops to zero and the network team’s bill jumps. Without an allocation rule, you just moved spend from the people creating it to the people who can’t control it.

The common topology helps. A Direct Connect gateway associated with a Transit Gateway, shared to workload accounts through AWS RAM, gives you a per-attachment traffic signal. Transit Gateway publishes per-attachment byte metrics to CloudWatch; pull a month of them and use the ratios as allocation weights:

for att in $(aws ec2 describe-transit-gateway-attachments \
    --filters Name=resource-type,Values=vpc \
    --query 'TransitGatewayAttachments[].TransitGatewayAttachmentId' --output text); do
  bytes=$(aws cloudwatch get-metric-statistics \
    --namespace AWS/TransitGateway --metric-name BytesIn \
    --dimensions Name=TransitGateway,Value=tgw-0abc1234 Name=TransitGatewayAttachment,Value="$att" \
    --start-time 2026-08-01T00:00:00Z --end-time 2026-09-01T00:00:00Z \
    --period 2678400 --statistics Sum \
    --query 'Datapoints[0].Sum' --output text)
  echo -e "$att\t$bytes"
done

This counts all bytes a VPC sends into the Transit Gateway, including VPC-to-VPC traffic, so treat it as an approximation. For precision, filter Transit Gateway Flow Logs to destinations in your on-premises CIDRs. Then turn the weights into a split charge rule in AWS Cost Categories, allocating the flat-rate usage type from the network account to workload accounts by percentage. Refresh the percentages monthly and nobody gets to claim their egress is free.

When flat-rate loses

  • Low egress. If your minimum month sits well below the break-even GB, the fixed fee is pure overhead.
  • Hosted connections. Not eligible. Converting means ordering new dedicated ports, which is a project, not a toggle.
  • Cross-tier Regions. If a large share of your bytes come from Regions outside the tiers offered at your location, you pay the flat fee plus most of the old DTO.
  • SiteLink-heavy estates. SiteLink stays at standard rates, so it contributes zero savings.
  • Oversized ports. Bandwidth is fixed at creation. A 100G pair at the Tier 3 example of $219.18/hour needs petabyte-scale egress to earn its keep.
  • Mixed estates at one location. Every connection at that location in the account must share a billing mode, so one heavy port can drag a light one onto flat-rate with it. Model the location as a unit.

Run the model, allocate the fee, and write the answer down with the data behind it. The flat-rate pricing guide covers the fine print; your CUR covers the rest.

At Enkompass (enkompass.net), this is our home turf. We’ve clawed back six-figure annual savings for clients whose bills were supposedly “already optimized,” usually by building exactly this kind of model. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.

Ready when you are

Let’s map your route to AWS

A free 60-minute architecture review with a senior engineer. No slides, no SDR, just a plan.

Book a cloud review
See the work