CloudWatch Metric Guide
RejectedConnectionCountApplication Load Balancer CloudWatch metric
RejectedConnectionCount counts the number of connections that were rejected because the load balancer had already reached its maximum number of connections. Per AWS documentation, it is only reported when its value is nonzero.
What it measures
About RejectedConnectionCount
RejectedConnectionCount counts the number of connections that were rejected because the load balancer had already reached its maximum number of connections. Per AWS documentation, it is only reported when its value is nonzero.
| Namespace | AWS/ApplicationELB |
| Metric name | RejectedConnectionCount |
| Unit | Count |
| AWS docs | Official Application Load Balancer metrics reference |
Why this metric matters
RejectedConnectionCount is a harder failure than a slow response or even a 5xx from the load balancer — the connection never gets far enough to be counted by RequestCount or routed to a target at all. Application Load Balancer scales its own capacity automatically (measured in LCUs — load balancer capacity units), but that scaling isn't instantaneous. A sudden, sharp spike in connection volume can outrun the ALB's auto-scaling before it provisions enough capacity, and every connection attempt in that gap gets rejected outright.
Because this happens at the load balancer layer, it's invisible to target-side monitoring — your backend's CPU, memory, and error rate can all look completely normal while real client connections are being turned away before they ever reach your application. This is why RejectedConnectionCount needs its own alarm rather than being inferred from target health metrics.
Recommended alarm threshold for RejectedConnectionCount
Recommended threshold
> 0 in any 1-minute window
AWS only reports this metric when it's nonzero, so any data point at all represents connections that were actively refused (Nuberio recommendation: alarm on any occurrence, not a threshold). This is distinct from CapacityUtilization approaching 100%, which is a leading indicator — RejectedConnectionCount is the lagging confirmation that capacity was actually exceeded and traffic was dropped.
Is your RejectedConnectionCount alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including RejectedConnectionCount — in 5 minutes.
Common failures that show up in RejectedConnectionCount
When RejectedConnectionCount reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
Traffic spike outrunning ALB auto-scaling — a sudden surge (flash sale, viral link, DDoS-adjacent burst) arrives faster than the ALB's capacity units can scale to absorb it
No LCU reservation set for a known-spiky workload — services with predictable traffic bursts (scheduled jobs, marketing campaigns) benefit from pre-reserving LCU capacity rather than relying on reactive auto-scaling alone
Connection leaks on the client side — a misbehaving client or retry storm holds open far more concurrent connections than a single legitimate session needs, artificially consuming the ALB's connection capacity
Underlying capacity issue upstream — a target group with all-unhealthy targets can cause connection backpressure that compounds into rejected connections at the load balancer itself under sustained load
How the Nuberio Audit checks RejectedConnectionCount
The free Audit scans every Application Load Balancer resource in your account and checks whether a RejectedConnectionCount alarm exists, whether its threshold and evaluation period are configured sensibly, and flags it if it's missing entirely. Every finding comes with the exact CLI command to fix it — read-only access, no credit card, results in about 5 minutes.
Nuberio Audit
Scans your CloudWatch setup for missing or misconfigured RejectedConnectionCount alarms. Free, 5-minute read-only scan.
Related Application Load Balancer metrics
RejectedConnectionCount rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Application Load Balancer coverage.
FAQ
Frequently asked questions about RejectedConnectionCount
Common questions about setting up CloudWatch alarms for RejectedConnectionCount in Application Load Balancer.
What is the recommended CloudWatch alarm threshold for RejectedConnectionCount?+
> 0 in any 1-minute window. AWS only reports this metric when it's nonzero, so any data point at all represents connections that were actively refused (Nuberio recommendation: alarm on any occurrence, not a threshold). This is distinct from CapacityUtilization approaching 100%, which is a leading indicator — RejectedConnectionCount is the lagging confirmation that capacity was actually exceeded and traffic was dropped.
Which CloudWatch namespace does RejectedConnectionCount belong to?+
RejectedConnectionCount is published in the AWS/ApplicationELB namespace with a unit of Count. You can find it in the CloudWatch console under "Metrics" → "AWS/ApplicationELB". See the Application Load Balancer CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for RejectedConnectionCount?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Application Load Balancer resources are missing a RejectedConnectionCount alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a RejectedConnectionCount alarm set up?+
Yes. The free Audit works whether or not you have any RejectedConnectionCount alarm configured — it reads the resource directly from CloudWatch and tells you which resources need one, plus 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, DynamoDB, SQS, API Gateway, S3, CloudFront, ElastiCache, and EKS. To find which Application Load Balancer alarms your account is missing — including RejectedConnectionCount — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.