CloudWatch Metric Guide
NetworkOutAmazon EC2 CloudWatch metric
NetworkOut measures the number of bytes sent by the instance on all network interfaces during the CloudWatch measurement period.
What it measures
About NetworkOut
NetworkOut measures the number of bytes sent by the instance on all network interfaces during the CloudWatch measurement period.
| Namespace | AWS/EC2 |
| Metric name | NetworkOut |
| Unit | Bytes |
| AWS docs | Official Amazon EC2 metrics reference |
Why this metric matters
Unexpected spikes in NetworkOut are a security indicator as much as an infrastructure indicator. Normal application traffic generates a predictable volume of outbound data. A sudden jump in NetworkOut that doesn't correlate with inbound traffic or application requests can indicate data exfiltration by a compromised instance, a misconfigured backup job writing to the wrong destination, or a logging pipeline in a runaway state.
For applications with data transfer costs, NetworkOut is also a direct cost driver. Cross-AZ data transfer, NAT Gateway egress, and internet egress all generate variable AWS charges. Monitoring NetworkOut lets you catch cost anomalies before they appear on the bill — typically 30+ days later.
Recommended alarm threshold for NetworkOut
Recommended threshold
Anomaly detection recommended — alert when NetworkOut exceeds 3 standard deviations above baseline for the same time of day and day of week
Like NetworkIn, the appropriate NetworkOut threshold is workload-specific (ConvOps recommendation for anomaly-based detection). A spike that represents 10x normal egress from a small internal API is categorically different from the same absolute value on a media delivery server. Baseline-relative detection catches both cases without requiring separate alarm configurations per instance type.
Is your NetworkOut alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including NetworkOut — in 5 minutes.
Common failures that show up in NetworkOut
When NetworkOut reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Data exfiltration from a compromised instance — malware or a compromised credential is copying data to an external endpoint
Misconfigured backup or sync job — a backup process is writing to the wrong S3 bucket, cross-account, generating unexpected transfer charges
Runaway logging pipeline — the application begins logging at debug verbosity in production, sending gigabytes of logs to an external logging service
NAT Gateway cost leak — a Lambda or ECS task is making repeated calls through a NAT Gateway that could be replaced with a VPC endpoint
Traffic amplification in reverse — the instance is being used as a reflection point for a DDoS attack
How Nuberio debugs NetworkOut alarms
When NetworkOut triggers an alarm, Nuberio Diagnose reads CloudWatch Logs, CloudTrail (recent API calls, deploys, config changes), and the current resource state in parallel. It correlates these with AWS/EC2 metrics on the same resource — giving you a plain-English root cause with numbered fix options, sent to WhatsApp or Slack, usually within 60 seconds of the alarm firing.
Before any anomaly in NetworkOut reaches you as a proactive alert (via Nuberio Watch), it passes through 9 verification checks: a Recovery check (did the metric self-heal?), an AWS Status check (is AWS itself having an incident?), a Deploy check (was there a recent Lambda update, ECS deploy, or RDS parameter change in the last 120 minutes?), a Quota check, an Infrastructure check, a Security check, a Flap check (has this metric been anomalous more than 5 times in the last 24 hours?), a TLS check, and a Vulnerability check. Only anomalies that pass all relevant checks reach you — with full context attached.
Nuberio Watch
Detects NetworkOut anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
Nuberio Diagnose
When a NetworkOut alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured NetworkOut alarms. Free, 5-minute read-only scan.
Related Amazon EC2 metrics
NetworkOut rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EC2 coverage.
FAQ
Frequently asked questions about NetworkOut
Common questions about setting up CloudWatch alarms for NetworkOut in Amazon EC2.
What is the recommended CloudWatch alarm threshold for NetworkOut?+
Anomaly detection recommended — alert when NetworkOut exceeds 3 standard deviations above baseline for the same time of day and day of week. Like NetworkIn, the appropriate NetworkOut threshold is workload-specific (ConvOps recommendation for anomaly-based detection). A spike that represents 10x normal egress from a small internal API is categorically different from the same absolute value on a media delivery server. Baseline-relative detection catches both cases without requiring separate alarm configurations per instance type.
Which CloudWatch namespace does NetworkOut belong to?+
NetworkOut is published in the AWS/EC2 namespace with a unit of Bytes. You can find it in the CloudWatch console under "Metrics" → "AWS/EC2". See the Amazon EC2 CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for NetworkOut?+
Nuberio does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free Nuberio Audit scans your CloudWatch setup and tells you which Amazon EC2 resources are missing a NetworkOut alarm. Nuberio Watch then monitors NetworkOut using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use Nuberio without already having a NetworkOut alarm set up?+
Yes. Nuberio Watch monitors NetworkOut independently of your CloudWatch alarm configuration — it reads the metric directly from CloudWatch every 5 minutes on the Growth plan. If you run the free Audit first, it will tell you which resources need a NetworkOut alarm and provide the copy-paste AWS CLI command to create it.
This page is part of the CloudWatch metric guide — thresholds and debugging guidance for every metric across RDS, Lambda, ECS, ALB, EC2, and DynamoDB. To find which Amazon EC2 alarms your account is missing — including NetworkOut — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.