CloudWatch Metric Guide
RequestsAmazon CloudFront CloudWatch metric
Requests counts the total number of viewer requests received by CloudFront for a distribution, across all HTTP methods and both HTTP and HTTPS. Per AWS documentation, CloudWatch reports this metric with Unit set to "None" rather than "Count."
What it measures
About Requests
Requests counts the total number of viewer requests received by CloudFront for a distribution, across all HTTP methods and both HTTP and HTTPS. Per AWS documentation, CloudWatch reports this metric with Unit set to "None" rather than "Count."
| Namespace | AWS/CloudFront |
| Metric name | Requests |
| Unit | None |
| AWS docs | Official Amazon CloudFront metrics reference |
Why this metric matters
Requests is your CloudFront distribution's baseline traffic signal, and its most useful failure mode is a drop, not a spike. Because CloudFront counts a "request" the moment a viewer hits the edge — before it decides whether to serve from cache or forward to the origin — a falling Requests count almost always points to something upstream of CloudFront: a DNS or Route 53 failover misconfiguration, a CNAME pointing traffic elsewhere, a mobile app release that shipped with the wrong endpoint, or an ISP/regional routing issue. Origin failures do not lower Requests, since CloudFront still received the viewer's request; they show up in 5xxErrorRate instead.
Spikes matter too, but need more context than the raw count alone — a spike from a marketing campaign is healthy, a spike from bot/scraper traffic or a DDoS attempt is not. Remember that all CloudFront metrics, including Requests, are published only to the CloudWatch us-east-1 endpoint with a Region=Global dimension, regardless of where your viewers or origin actually are — querying any other AWS region for this metric returns no data, which is a frequent source of "my alarm never fires" bug reports.
Recommended alarm threshold for Requests
Recommended threshold
Anomaly detection recommended over a fixed threshold — alarm when Requests falls more than 50% below the expected baseline for the same time of day, sustained for 3 consecutive 5-minute periods
AWS does not publish a universal Requests threshold because traffic volume is entirely workload-dependent. The 50%-below-baseline-for-3-periods rule (Nuberio recommendation) is tuned to catch a genuine traffic-loss incident — DNS failover, broken deploy, upstream outage — while riding out normal day-to-day and hour-to-hour variance without false-paging on-call.
Is your Requests alarm already set up correctly?
The free Nuberio Audit scans your CloudWatch setup and flags missing or misconfigured alarms — including Requests — in 5 minutes.
Common failures that show up in Requests
When Requests reaches an alarm threshold, these are the most common root causes — in order of how often Nuberio sees them across customer AWS accounts.
DNS or Route 53 failover misconfiguration — traffic gets routed away from the CloudFront distribution's domain entirely
CNAME/alternate domain name change or expiry that silently redirects viewers to a different endpoint
Mobile app or client release pointing at the wrong API/CDN endpoint after a deploy
Upstream marketing or referral traffic source cut off (ad campaign ended, partner integration broken)
Bot, scraper, or low-level DDoS traffic inflating Requests without a corresponding increase in legitimate origin load
How the Nuberio Audit checks Requests
The free Audit scans every Amazon CloudFront resource in your account and checks whether a Requests 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 Requests alarms. Free, 5-minute read-only scan.
Related Amazon CloudFront metrics
Requests rarely fails in isolation. These metrics tend to correlate — monitor them together for complete Amazon CloudFront coverage.
FAQ
Frequently asked questions about Requests
Common questions about setting up CloudWatch alarms for Requests in Amazon CloudFront.
What is the recommended CloudWatch alarm threshold for Requests?+
Anomaly detection recommended over a fixed threshold — alarm when Requests falls more than 50% below the expected baseline for the same time of day, sustained for 3 consecutive 5-minute periods. AWS does not publish a universal Requests threshold because traffic volume is entirely workload-dependent. The 50%-below-baseline-for-3-periods rule (Nuberio recommendation) is tuned to catch a genuine traffic-loss incident — DNS failover, broken deploy, upstream outage — while riding out normal day-to-day and hour-to-hour variance without false-paging on-call.
Which CloudWatch namespace does Requests belong to?+
Requests is published in the AWS/CloudFront namespace with a unit of None. You can find it in the CloudWatch console under "Metrics" → "AWS/CloudFront". See the Amazon CloudFront CloudWatch metrics reference in the AWS documentation.
Does Nuberio automatically create CloudWatch alarms for Requests?+
No — the free Nuberio Audit does not create alarms for you. It scans your CloudWatch setup and tells you which Amazon CloudFront resources are missing a Requests alarm, then gives you the exact CLI command to create it yourself.
Can I use Nuberio without already having a Requests alarm set up?+
Yes. The free Audit works whether or not you have any Requests 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, and DynamoDB. To find which Amazon CloudFront alarms your account is missing — including Requests — run the free CloudWatch alarm audit. The scan takes under 5 minutes and requires no account.