CloudWatch Metric Guide
NetworkInAmazon EC2 CloudWatch metric
NetworkIn measures the number of bytes received by the instance on all network interfaces during the CloudWatch measurement period.
What it measures
About NetworkIn
NetworkIn measures the number of bytes received by the instance on all network interfaces during the CloudWatch measurement period.
| Namespace | AWS/EC2 |
| Metric name | NetworkIn |
| Unit | Bytes |
| AWS docs | Official Amazon EC2 metrics reference |
Why this metric matters
A sudden spike in NetworkIn is one of the clearest signals of a DDoS attack, a misconfigured bulk data transfer, or an unexpected data ingest workload. Unlike CPU or memory, which give gradual warnings, NetworkIn can jump from baseline to network saturation in a single measurement period.
For instances that process events from SQS or other queuing systems, NetworkIn growth can indicate queue depth growing faster than the consumer can drain it — a backlog forming that will eventually cause message expiry or memory pressure. NetworkIn is also useful for validating infrastructure cost assumptions: unexpected data transfer volumes are often the cause of surprise AWS bills.
Recommended alarm threshold for NetworkIn
Recommended threshold
Anomaly detection recommended over fixed threshold — alert when NetworkIn exceeds 3 standard deviations above the historical baseline for the same time of day
Appropriate NetworkIn thresholds vary enormously by workload type — a media processing instance legitimately receives gigabytes per hour, while a small API instance receiving the same volume is under attack. Z-score anomaly detection against a time-of-day baseline (used by ConvOps Watch) avoids both false positives for legitimate high-traffic workloads and false negatives for low-baseline instances. AWS documentation does not publish a universal threshold.
Is your NetworkIn alarm already set up correctly?
The free ConvOps Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including NetworkIn — in 5 minutes.
Common failures that show up in NetworkIn
When NetworkIn reaches an alarm threshold, these are the most common root causes — in order of how often ConvOps sees them across customer AWS accounts.
DDoS or traffic amplification attack — a volumetric attack sends more traffic than the instance's network bandwidth can handle
Misconfigured data pipeline — a data transfer job points to the wrong destination and begins sending large volumes of data to a production instance
S3 or DynamoDB stream consumer processing more records than expected — a change in upstream data volume propagates to the consumer
Logging agent misbehavior — an application agent or sidecar begins sending excessive log data due to a configuration change
Forgotten replication — a replication setup is still running to an instance after the primary workload was migrated elsewhere
How ConvOps debugs NetworkIn alarms
When NetworkIn triggers an alarm, ConvOps 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 NetworkIn reaches you as a proactive alert (via ConvOps 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.
ConvOps Watch
Detects NetworkIn anomalies with z-score against 30-day time-bucketed baselines. 9 verification checks before any alert.
ConvOps Diagnose
When a NetworkIn alarm fires, reads logs, CloudTrail, and resource state. Sends root cause + fix options to WhatsApp or Slack.
ConvOps Audit
Scans your CloudWatch setup for missing or misconfigured NetworkIn alarms. Free, 5-minute read-only scan.
Related Amazon EC2 metrics
NetworkIn rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon EC2 coverage.
FAQ
Frequently asked questions about NetworkIn
Common questions about setting up CloudWatch alarms for NetworkIn in Amazon EC2.
What is the recommended CloudWatch alarm threshold for NetworkIn?+
Anomaly detection recommended over fixed threshold — alert when NetworkIn exceeds 3 standard deviations above the historical baseline for the same time of day. Appropriate NetworkIn thresholds vary enormously by workload type — a media processing instance legitimately receives gigabytes per hour, while a small API instance receiving the same volume is under attack. Z-score anomaly detection against a time-of-day baseline (used by ConvOps Watch) avoids both false positives for legitimate high-traffic workloads and false negatives for low-baseline instances. AWS documentation does not publish a universal threshold.
Which CloudWatch namespace does NetworkIn belong to?+
NetworkIn 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 ConvOps automatically create CloudWatch alarms for NetworkIn?+
ConvOps does not create alarms for you by default — it debugs the alarms you already have (or identifies missing ones). The free ConvOps Audit scans your CloudWatch setup and tells you which Amazon EC2 resources are missing a NetworkIn alarm. ConvOps Watch then monitors NetworkIn using z-score anomaly detection against a 30-day baseline, running 9 verification checks before alerting you.
Can I use ConvOps without already having a NetworkIn alarm set up?+
Yes. ConvOps Watch monitors NetworkIn 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 NetworkIn alarm and provide the copy-paste AWS CLI command to create it.