Executive summary
On 10 September AWS extended the network health indicator to paths that cross a Transit Gateway inter-Region peering connection. It exists to settle the argument that starts every cross-Region latency incident: is this AWS, or is this us?
The mechanism is one CloudWatch metric with two possible values. A value of 100 indicates that Network Synthetic Monitor observed a network degradation within the AWS controlled network path. A value of 0 indicates that Network Synthetic Monitor did not observe any network degradation for the AWS network along the path. It is published into your own CloudWatch account, so you can alarm on it and put it on a dashboard.
Two things make this more interesting than a new metric usually is. The bit is derived — AWS calls it a statistical measure, produced by anomaly detection over probe data — so it is an inference presented as a boolean. And it is not available for hours after you create the monitor, because the anomaly detection needs a baseline. That makes it a control with the same property as the flow log format from Architecture #47: you cannot stand it up during the incident it would have explained.
What changed
The indicator already existed for paths reaching a destination over Direct Connect. It now also covers paths that reach a destination in a peered Region.
| Aspect | Detail |
|---|---|
| New coverage | Paths crossing a Transit Gateway inter-Region peering connection |
| What it reports | Health of the AWS network path up to the Transit Gateway peering connection |
| Values | 100 — degradation observed in the AWS-controlled path. 0 — no degradation observed. |
| How it is derived | Statistical correlation across AWS sample datasets plus your probes' packet loss and round-trip latency, using anomaly detection |
| Availability | All Regions except AWS GovCloud (US) and the China Regions |
| Cost | Synthetic monitoring is $0.10 per monitored resource per hour — three subnets is about $216 a month |
Architecture
Network Synthetic Monitor is agentless. You give it a VPC subnet and destination addresses, and AWS builds the probe infrastructure behind the scenes, attaching managed elastic network interfaces into your subnets. Probes are ICMP or TCP, aggregated to CloudWatch every 30 or 60 seconds, and publish round-trip time in microseconds and packet loss as a percentage.
The NHI sits on top of those measurements rather than beside them. AWS applies statistical correlation across its own sample datasets together with your probes' loss and latency, and collapses the result to one of two numbers. That is a genuinely useful thing to have during an incident — the question it answers is otherwise unanswerable from inside your own account — but it is an inference, and the documentation is honest enough to describe it as a statistical measure rather than a measurement.
Where the coverage stops
For a peered-Region path, AWS states that the NHI reflects the health of the AWS network path up to the Transit Gateway peering connection. The segment beyond it is not what this metric is reporting on.
That matters for how you read a 0. A degradation in the remote Region past the peering connection produces the same value as a perfectly healthy path, because in both cases no degradation was observed in the segment being watched. The indicator is not lying; it is answering a narrower question than "is the network fine", and a dashboard tile labelled AWS network: healthy would be overstating it.
Business value
The value is triage time on a specific and expensive argument. A cross-Region latency incident typically burns its first hour deciding whether to escalate to AWS or keep debugging internally, and neither side can prove anything. A binary published into your own CloudWatch account turns that into an alarm condition.
It is worth being clear about what it is worth: it narrows the search, it does not diagnose. A 100 tells you to open a support case with evidence. A 0 tells you to keep looking at your own stack — or at the part of the path this metric does not cover.
Security considerations
Little here is security-sensitive, with one operational exception worth flagging to whoever owns firewall rules. TCP probes periodically switch source ports, using ports in the range 1024–65535, to increase network coverage, and AWS says to make sure firewall rules allow TCP traffic from that entire source port range to the configured destination port.
That is a broad allowance to ask a network team for, and it is worth raising as a deliberate change rather than discovering it as a silent probe failure. ICMP probes avoid the question if your destinations answer echo requests.
Also note the managed ENIs: probe interfaces are created in your subnets, and their IP addresses persist unless you delete and recreate the probe. Anything doing IP-based allowlisting downstream will see stable addresses, which is convenient and also worth documenting so nobody removes them as unexplained.
Cost considerations
Synthetic monitoring is charged per monitored resource per hour at $0.10, so three monitored subnets is roughly $216 a month before the CloudWatch metrics themselves. That is small against an incident and not nothing across a large estate, and it scales with subnets rather than with traffic.
The second cost is traffic, and it is specific to this launch. AWS states that probes reaching destinations across a Transit Gateway inter-Region peering connection send more traffic to cover the additional network paths, and that you can expect up to 240 packets per second to each of these destinations. Inter-Region traffic over a peering connection is billable, so the instrument watching the expensive path also uses it.
Operational considerations
The delay is the thing to internalise. AWS: each time that you create a new monitor, add a probe, or re-activate a probe, the NHI for the monitor is delayed by a few hours while AWS collects data to perform anomaly detection.
So this cannot be deployed reactively. An incident starts, someone suggests standing up a monitor to find out whether it is AWS, and the answer arrives after the incident is over. Anomaly detection needs a baseline and a baseline needs history — the same reason a flow log cannot be given fields retroactively.
The other caveat to record somewhere durable: NHI is not accurate for Direct Connect attachments that use intermediary routing with Cloud WAN, and AWS says not to treat the value as an indication of a performance issue on hybrid networks that include Cloud WAN. If your topology is heading toward Cloud WAN, that is worth knowing before you build alarms on this.
Tradeoffs
| Approach | Works well when | Breaks down when |
|---|---|---|
| NHI alarm on peered-Region paths | You have standing cross-Region paths and recurring "is it AWS" arguments. Cheap, and answers a question nothing else can. | The problem is past the peering connection, or the topology uses Cloud WAN. Both give a 0 that means nothing. |
| Round-trip time and packet loss alarms | Detecting that something is wrong at all. These are measurements, not inferences. | Attribution. They tell you the path degraded, not whose path it was. |
| Stand it up during the incident | Never. | Always — the NHI is delayed by hours while the baseline is collected. |
Implementation guidance
Create monitors on the cross-Region paths that carry production traffic today, not on everything. The charge is per monitored resource per hour and the probe traffic is real, so the list should be the paths whose degradation would actually trigger an escalation.
Choose the protocol deliberately. ICMP is simpler if destinations reply to echo requests; TCP is more representative of real traffic and requires the 1024–65535 source port allowance through any firewall in the path.
Then alarm on NHI = 100 as an escalation signal, and alarm on round-trip time and packet loss separately as detection signals. Keeping those two purposes on separate alarms is what stops a 0 being read as reassurance.
Best practices
- Deploy before you need it. The indicator is delayed by hours after any monitor or probe change.
- Label dashboards precisely. "No AWS-side degradation observed on this segment" — not "AWS healthy".
- Alarm on NHI for attribution and on loss and latency for detection. They answer different questions.
- Record the Cloud WAN exclusion next to the alarm, so whoever inherits it knows when to distrust it.
- Budget the probe traffic on peered paths — up to 240 packets per second per destination, over a billable inter-Region link.
Who should adopt this
Anyone running production traffic across Transit Gateway inter-Region peering who has ever spent an incident bridge arguing about whose network it is. That is the specific pain, and this is a direct and inexpensive answer to it.
Anyone running hybrid connectivity through Cloud WAN should read the caveat first, and anyone whose cross-Region paths are incidental rather than production-critical can safely skip it — the value is entirely in having it already running when something breaks.
Key takeaways
- NHI now covers paths crossing a Transit Gateway inter-Region peering connection, reporting the AWS path up to that connection.
- It is binary: 100 means degradation observed in the AWS-controlled path, 0 means none observed — which is not the same as healthy.
- It is derived by anomaly detection, so it is an inference, and it is delayed by hours after any monitor or probe change.
- Not accurate on hybrid networks using Cloud WAN for intermediary routing — AWS says so explicitly.
- $0.10 per monitored resource per hour, plus up to 240 packets per second per destination across the peering connection.
Comments