CloudWatch Network Monitoring · Flow monitors · TCP performance observability
With Network Flow Monitor, lightweight agents installed on EC2 and EKS collect TCP connection statistics and show retransmissions, timeouts, RTT, and data transferred for flows between workloads in near real time. Each monitor computes a network health indicator (NHI) that tells you whether the AWS network was the problem.
An NHI of 100 means there was an AWS network issue during that period. If it is 0 (Healthy) but retransmissions rose, look at the workload side first.
Interval at which agents send aggregated statistics (eBPF-based, no payload access)
Monitor metrics (RTT · retransmissions · timeouts · data transferred · NHI)
Maximum number of accounts in a scope with Organizations integration
Supported Regions (including Seoul, ap-northeast-2)
Why Network Flow Monitor
When application latency appears, the first hurdle is deciding whether to look at the network, the instance, or the code. Network Flow Monitor puts TCP metrics from real workload traffic and an AWS network health verdict on the same screen, speeding up that first call.
Collects retransmissions, retransmission timeouts, RTT, and bytes transferred from production connections, not synthetic probes. Flows are broken down into intra-AZ and inter-AZ, inter-VPC, S3 and DynamoDB, and other Regions.
NHI reports 0 or 100 to indicate whether any flow tracked by the monitor experienced an AWS network issue. It tells you whether to hand troubleshooting to the AWS side or dig into the workload.
For each metric, the flows with the highest values are shown as top contributors, and Historical explorer expands the components along the path as a topology so you can narrow down which segment is at fault.
How it works
Agents receive only kernel TCP events and send them to Network Flow Monitor about every 30 seconds. All flows within the scope are shown by category in Workload insights, and flows you want to keep watching become a monitor by specifying local and remote resources.
# Track flows from the web subnet (local) → DynamoDB and another AZ (remote)
aws networkflowmonitor create-monitor \
--monitor-name web-to-backend \
--scope-arn arn:aws:networkflowmonitor:ap-northeast-2:111122223333:scope/e21c…d8cf \
--local-resources type="AWS::EC2::Subnet",identifier="arn:aws:ec2:…:subnet/subnet-0web…" \
--remote-resources type="AWS::AWSService",identifier="DynamoDB" \
type="AWS::AvailabilityZone",identifier="ap-northeast-2c"
# Once created, metrics are published to the AWS/NetworkFlowMonitor namespace
# DataTransferred · Retransmissions · Timeouts
# RoundTripTime(µs) · HealthIndicator(0 healthy / 100 degraded)agent Collects TCP statistics with eBPFReceives only the bpf_sock_ops struct (addresses, ports, counters, RTT) from the kernel and never sees the payload. On EC2, install it with SSM Distributor, a CloudShell script, or RPM/DEB packages; on EKS, install it as an add-on.
scope Observation range and topologyA range defined by account (or a set of Organizations accounts) and Region. Once the scope is set, the service builds a resource topology, and Workload insights shows top contributors across the entire scope.
monitor Metrics and NHILocal resources can be subnets, VPCs, AZs, EKS clusters, or Regions; remote resources can be subnets, VPCs, AZs, AWS services (S3, DynamoDB), or Regions. When a Region is the remote resource, measurement extends to that Region's edge.
Workload insights categories: INTRA_AZ · INTER_AZ · INTER_VPC · INTER_REGION · AMAZON_S3 · AMAZON_DYNAMODB · UNCLASSIFIED (for example, flows through a NAT gateway or leaving AWS). RTT is not always computed, so its data can be sparse.
Features
Workload insights
Groups the flows reported by agents into categories such as intra-AZ, inter-AZ, inter-VPC, inter-Region, and AWS services, and shows data transferred and the top flows for each metric. This is where you pick the flows to turn into monitors.
Monitors
A monitor continuously publishes metrics for the specified flows. In Historical explorer, choose a time range to see the top flows by retransmissions and RTT and the topology of components along the path.
NHI
HealthIndicator is a binary value of 0 (Healthy) or 100 (Degraded). When you see a performance anomaly, first check whether it was an AWS network issue to set the direction of your investigation.
Inter-Region
Since September 2025, it also measures flows to public IPs in other Regions and private flows over VPC peering and Transit Gateway peering, and NHI reflects the health of the AWS global network between Regions.
Amazon EKS
The AWS Network Flow Monitor Agent add-on runs an agent pod on every node. Flows are enriched with pod metadata, and node-level system metrics are exposed in OpenMetrics format for collection by Prometheus-compatible tools.
CloudWatch
Monitor metrics are published to the AWS/NetworkFlowMonitor namespace and can be used in alarms and dashboards like any CloudWatch metric. Agents can send data privately through a PrivateLink interface endpoint.
Default quotas: 1 scope per account per Region, 20 monitors per account per Region (adjustable), and 25 local and 25 remote resources per monitor. The service as a whole supports about 5 million flows per minute and about 5,000 instances with agents installed; beyond that, monitoring performance may be affected until capacity is increased. The agent is for Linux (Amazon Linux 2023, RPM- and DEB-based distributions, x86_64 and Graviton).
Compare
Network Flow Monitor covers real TCP flows between workloads inside AWS, Internet Monitor covers the segment to internet end users, and Network Synthetic Monitor covers hybrid paths between VPCs and on-premises. VPC Flow Logs records flows rather than measuring performance.
| Item | Network Flow Monitor | Internet Monitor | Network Synthetic Monitor | VPC Flow Logs |
|---|---|---|---|---|
| Segment covered | Between workloads in AWS · S3 · DynamoDB · other Regions | Application ↔ internet end users (city-network) | VPC subnet ↔ on-premises IP (Direct Connect, etc.) | IP flows through ENIs and TGWs |
| Data source | Real traffic, instance agents | AWS global networking data and VPC flow log analysis | Synthetic traffic from AWS-managed probes | Flow metadata records |
| Key metrics | Retransmissions, timeouts, RTT, data transferred | Performance and availability scores, latency, health events | RTT, packet loss | bytes, packets, ACCEPT · REJECT |
| AWS cause attribution | NHI | Health events (show affected city-networks and ASNs) | NHI (DX paths, TGW inter-Region peering) | None |
| Installation | Agent required (EC2 · EKS, Linux) | None | None (probes are managed by AWS) | None |
| Billed by | Monitored resources (agent instances) + CloudWatch metrics | Monitored resources + city-networks + logs | Monitored resources + CloudWatch metrics | Vended logs GB |
Reference architecture
Agents on EC2 instances and EKS nodes observe inter-AZ flows and flows to S3 and DynamoDB and send them to Network Flow Monitor. A delegated administrator account manages the scope, and monitor metrics feed CloudWatch alarms and dashboards. Reachability Analyzer handles validation of the path configuration itself, and VPC Flow Logs handles flow records.
On narrow screens, swipe the diagram sideways.
Getting started
If you will monitor multiple accounts, register a delegated administrator for CloudWatch in Organizations and proceed from that account.
Initialize from Flow monitors under Network Monitoring in the CloudWatch console. This creates the service-linked role, the scope, and the initial topology, and takes up to 30 minutes.
Attach CloudWatchNetworkFlowMonitor
Review the top flows by category, such as inter-AZ, inter-VPC, and S3, and pick the workloads to track continuously.
Create monitors from local and remote resources, and set CloudWatch alarms on HealthIndicator and retransmission metrics.
After adding accounts to or removing them from a scope, wait about 20 minutes while the topology is rebuilt before making the next change. You can also add accounts from the management account, but using a delegated administrator is recommended.
Pricing
Flow monitoring pricing is determined by two things: the number of compute resources with an agent deployed and active (monitored resources), and the CloudWatch metrics that are published. Unit prices vary by Region.
| Billing item | Billed by | Notes |
|---|---|---|
| Monitored resource | Number of compute instances with an active agent | One EC2 instance or one EKS node counts as one monitored resource |
| CloudWatch metrics | CloudWatch metrics pricing | Standard metric pricing applies to the metrics a monitor publishes to AWS/NetworkFlowMonitor |
| Alarms · dashboards | CloudWatch alarm and dashboard pricing | Alarms on NHI or retransmission metrics and custom dashboards are each billed at standard rates |
| Private transport (optional) | Interface VPC endpoint pricing | Sending agent traffic over PrivateLink adds endpoint-hour and data-processed charges |
The number of instances running an agent drives cost, so deploy to the critical tiers (web, app, and DB nodes) first rather than to every instance. For the latest prices and calculation examples, see CloudWatch Network Monitoring with flow monitoring on the Amazon CloudWatch pricing page.
Next step
Bring the tier structure of your critical workloads, their dependencies across AZs, VPCs, and Regions, and your account structure, and we will help you define the agent deployment scope, monitor design, and NHI alarm criteria.