AWS Cloud WAN series · Part 16 of 17

Cloud WAN Cost Engineering: What You Pay For, and When It's Worth It

Sixteenth in the AWS Cloud WAN series. Cloud WAN's value is operational, not financial — for an equivalent topology it usually costs more than Transit Gateway. This piece makes that concrete: the four things you're billed for, a worked monthly bill, who pays what across accounts, and a clean test for when the premium earns its keep. Every number here is from AWS's own pricing page; the one estimate that isn't, I flag as an estimate.

A caveat before any number: the prices below are illustrative figures from AWS's published examples at time of writing and vary by Region. Always confirm current rates on the Cloud WAN pricing page and model your own traffic. The goal here is to teach you the structure of the cost — not to quote you a bill.

What you actually pay for — the four dimensions of a Cloud WAN bill

Cloud WAN billing is on-demand, with no upfront fees, and it comes down to four things (Figure 1). Two are fixed and dominate most bills; two are variable.

Core Network Edges. When Cloud WAN places a CNE in a Region, you pay roughly $0.50/hour — about $365/month per Region, with partial hours rounded up. This is the fixed cost of having connectivity in a Region, independent of traffic, and it's the dominant fixed line. It's why "how many Regions" is a budget decision, not just a connectivity one: every Region you light up adds another ~$365/month floor before anything moves.

Attachments. Each attachment — VPC, VPN, Connect/SD-WAN — carries an hourly fee that starts the moment it connects and varies by Region: around $0.065/hour for a VPC attachment in us-east-1 (~$47.45/month), higher in some Regions (~$0.080/hour in Frankfurt). This is where a large network gets expensive. As the series has said since Article 1, Cloud WAN does not reduce your attachment count — a hundred VPCs is a hundred attachment fees, every hour. That isn't a footnote; it's where most of the premium lives.

Peering. Peering a CNE with a Transit Gateway in the same Region carries an hourly fee per connected component, comparable to an attachment fee and Region-dependent. One detail saves real money: TGW route-table attachments riding on top of a peering carry no extra charge — you pay for the peering, not for each route-table attachment on it.

Data processing. A per-GB charge of around $0.02/GB applies to data sent from a VPC, VPN, or Direct Connect Gateway through a CNE, in all Regions. On top of that, standard inter-Region data transfer applies when traffic crosses Regions — billed separately from Cloud WAN, but a real part of the total. Data processing is the one line that scales with how much your network actually moves.

Where the money goes at low traffic — a worked monthly bill

AWS's published examples make the structure obvious. Take a single Region, two VPCs, 100 GB: one CNE in us-east-1, two VPC attachments, and VPC-1 sending 100 GB to VPC-2.

• CNE: 1 × $0.50 × 730 hrs = $365.00
• Attachments: 2 × $0.065 × 730 = $94.90
• Data processing: 100 GB × $0.02 = $2.00
• No inter-Region transfer (all in-Region)
• Total ≈ $461.90/month plus standard data transfer

The lesson jumps out (Figure 2): at low traffic, fixed costs are essentially the whole bill. The CNE and attachments are ~$460; the data processing is $2. Cloud WAN's cost is the price of existing, not the price of moving — right up until traffic gets large.

Now add a Region. Put a CNE in us-east-1 and Frankfurt and have VPC-1 (us-east-1) send 100 GB to VPC-2 (Frankfurt). The us-east-1 attachment is 1 × $0.065 × 730 = $47.45; the Frankfurt attachment is 1 × $0.080 × 730 = $58.40; data processing applies at $0.02/GB; and now inter-Region data transfer out of us-east-1 to Frankfurt applies on top, at standard rates. Two CNEs at ~$365 each underpin the whole thing. Cross-Region adds the second CNE's fixed cost and transfer charges on top of processing — multi-Region is materially more expensive than single-Region. Design your Region footprint deliberately; Article 7's rule was "wide enough, no wider," and this is the bill behind it.

Who pays for what across accounts — the billing split

In a multi-account org — the normal case, and the subject of Article 14 — the charges are split so each account pays for what it owns (Figure 3):

• The account that created the core network pays for CNEs, for VPN and SD-WAN/Connect attachments, and for data processing on VPN traffic.
• The account that owns a VPC pays for its own VPC attachment and the data processing from that VPC.
• The Direct Connect Gateway owner pays the hourly and data-processing charges for the DX attachment.
• For cross-account TGW peering, the Cloud WAN account pays for the CNE side and the TGW account pays for its side.

This is exactly what you want for chargeback or showback: the network account carries the fixed CNE cost — a shared platform cost to allocate — while workload accounts naturally carry their own attachment and data-processing costs. Build your cost-allocation tags around that split so the central CNE spend can be apportioned rather than sitting as an unexplained lump on the network account's bill.

Why federation can raise the bill, not lower it — the double-domain charge

Article 11 flagged a cost trap in federated paths, and the mechanics are worth getting exactly right because the intuitive version is wrong. In a TGW → Cloud WAN → TGW path, the traffic transits two routing domains, and data-processing charges are incurred in each domain where the traffic arrives over a billable VPC or VPN attachment — so you pay processing on the TGW side and on the Cloud WAN side.

Here's the part to correct: the CNE-to-TGW peering hop itself is free — there's no per-hop data-processing charge for it. The asymmetry that bites is in data transfer, not the peering hop: Cloud WAN applies inter-Region data-transfer charges in both the receive and the send direction, while TGW applies it outbound only. The net for a two-TGW-via-Cloud-WAN flow is more data-related charges than a naive single-hop intuition predicts — not because the hop costs money, but because the traffic gets processed in two domains and transferred with both-direction billing on the Cloud WAN side.

Two implications follow:

• Federation is an operational win, not necessarily a cost win. Phase 1 buys you dynamic global routing and simpler management; it doesn't automatically lower inter-Region cost, and for two-TGW flows it can raise it.
• The cost case improves at Phase 2. Once VPCs attach directly to Cloud WAN and the intermediary TGWs are gone, traffic stops transiting two domains and the picture gets better (Article 12).

So if cost reduction is a goal, plan to reach Phase 2. Don't stop at federation and expect the bill to fall.

The ~30% premium — an estimate, not an AWS quote

Putting it together: for an equivalent topology, Cloud WAN tends to run around a 30% premium over a Transit Gateway architecture, driven mainly by the higher per-attachment fee and the CNE per-Region base. But be honest about where that number comes from. It is a practitioner estimate — from a named AWS solutions architect's blog, captioned by its own author as "illustrative and Region-dependent" — not an AWS-published figure. Treat it as a directional band, not a line item (Figure 4).

The comparison underneath it is real, though. Transit Gateway also bills per attachment-hour (~$0.05 for a VPC) and per-GB data processing (~$0.02), but it has no $365/month-per-Region CNE equivalent for a managed global spine. That CNE base, plus a per-attachment fee that runs a little higher on Cloud WAN, is where the premium comes from. You trade that cost for the operational automation Cloud WAN provides — full-mesh dynamic routing, one policy, easy rollback.

So the honest framing from Article 1 holds: if you're operationally happy with TGW, there is no financial case to migrate. The premium is real, and you should know its source — mostly attachments and CNEs — before you commit.

When the premium is worth it — and when to stay on TGW

The decision is almost always operator-driven, not financial or capability-driven. Cloud WAN doesn't make the network cheaper or do something TGW can't; it makes the network cheaper to operate. So the question is whether that operational saving outweighs the premium for your footprint.

• Justified when your team is drowning in route-table change tickets, cross-Region peering management, and per-VPC association toil across many accounts and Regions. The reduction in operator time — fewer changes, faster onboarding, one policy, easy rollback — is the value, and for a large enterprise it routinely outweighs the ~30% premium.
• Not justified when you have a handful of VPCs in one or two Regions, a stable topology, and no segmentation pain. Here Cloud WAN is over-engineering, and the CNE fixed cost especially is hard to defend on a small footprint.
• Capability-neutral. Cloud WAN adds no capability that reduces other costs — it doesn't delete firewalls, replace SD-WAN/MPLS, or cut attachments. Don't build a savings case on capabilities it doesn't deliver (Article 1's "what it does not do").

The clean test: would the hours your team spends managing TGW routing, multiplied by their cost, exceed the premium? If yes, migrate for the operational win. If no, stay. Most large multi-Region, multi-account enterprises land on "yes"; most small, stable networks land on "no." That's not a hedge — it's the actual answer, and it depends on a number only you can fill in.

The levers that actually move the bill

If you do run Cloud WAN, these are the knobs that change the number — in rough order of impact.

Notice what's not on the list: service insertion has no separate charge, but it also doesn't reduce firewall instances or licenses — run 70 firewalls today and you run 70 after, each inspection hop just adds standard data processing. The levers that work are about fewer Regions, fewer attachments, and fewer inspection hops — not a discount you can switch on.

That completes the operations cluster: you can build it, run it, see it, and now account for it. The series finishes with a capstone — Article 17 assembles segments and the matrix, centralized egress plus east-west inspection, hybrid Direct Connect, and a RAM-shared core managed as code into one reference architecture for a global, multi-Region, multi-account enterprise network, with the end-to-end decision framework for whether — and how — to adopt Cloud WAN at all.