AWS CloudFront 403 Forbidden: Complete Troubleshooting Guide (Rate Limits, Timeouts & Fixes)

Understanding the AWS CloudFront 403 Forbidden Error

CloudFront can generate a 403 response at three distinct layers: the CloudFront edge itself (geo-restriction, signed URL validation, viewer protocol policy), AWS WAF (rate-based or managed rule block), and the origin (S3 access denied, ALB/API Gateway auth failure). Each layer stamps different headers and log fields, so the first rule of debugging is always: identify which layer rejected the request.

The canonical error the developer sees in a browser or curl response is:

HTTP/1.1 403 Forbidden
X-Cache: Error from cloudfront
X-Amz-Cf-Id: abc123XYZrandomRequestId==

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
</Error>

When the block comes from WAF rather than S3, the body is often empty or contains a custom WAF response body you configured.

Step 1: Identify the Rejection Layer

Check the X-Cache response header first.

• X-Cache: Hit from cloudfront — CloudFront served from cache; 403 was cached from a previous origin response.
• X-Cache: Miss from cloudfront — CloudFront forwarded to origin and origin returned 403.
• X-Cache: Error from cloudfront — CloudFront itself or WAF rejected the request before reaching origin.

Run a verbose curl to expose all headers:

curl -sI "https://d1234abcd.cloudfront.net/path/to/object" \
  -H "Accept: */*" \
  --write-out "\n%{http_code}\n"

Capture the X-Amz-Cf-Id value — you will need it when searching CloudFront access logs.

Enable and query CloudFront standard logs (if not already enabled):

1. Go to CloudFront console → Distribution → Logging → Enable standard logging to an S3 bucket.
2. Wait 5–10 minutes for log delivery, then query with Athena or download directly.

The key log fields for 403 triage are: sc-status, x-edge-result-type, x-edge-response-result-type, cs-uri-stem, x-forwarded-for, and cs(User-Agent).

Step 2: Fix S3 Origin Access Control (OAC) Issues

OAC is the modern replacement for OAI and the most common source of 403 errors when serving static sites or assets from S3.

Symptom: X-Cache: Miss from cloudfront with AccessDenied XML body.

Root cause: The S3 bucket policy does not include a statement granting the CloudFront service principal (OAC) s3:GetObject permission.

Fix: In the CloudFront console, navigate to your distribution → Origins → select the S3 origin → click Edit. Under Origin access, confirm Origin access control settings is selected and an OAC is assigned. Then click Copy policy and paste it into your S3 bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT-ID:distribution/DISTRIBUTION-ID"
        }
      }
    }
  ]
}

Replace YOUR-BUCKET-NAME, ACCOUNT-ID, and DISTRIBUTION-ID with real values. Block Public Access settings on the bucket can remain enabled — OAC bypasses them via the service principal.

Step 3: Diagnose and Fix WAF Rate-Based Rule Blocks

AWS WAF rate-based rules return 403 (or a custom response code you set) when a single IP exceeds the configured request count within a 5-minute window. The default threshold for many managed rule groups is 2,000 requests per 5 minutes.

Symptom: 403 bursts correlating with traffic spikes; X-Cache: Error from cloudfront; no S3 or origin errors in CloudTrail.

Diagnose:

1. Open AWS WAF Console → Web ACLs → select the ACL attached to your CloudFront distribution.
2. Click Sampled requests for each rate-based rule — confirm the blocked IPs and request paths.
3. Check CloudWatch metric BlockedRequests for the specific rule name.

Fix options:

• Raise the rate limit on the rule: WAF → Rule → Edit → increase Rate limit to a value appropriate for your legitimate traffic.
• Add an IP set allow rule with higher priority than the rate rule for known good IPs (your CDN, monitoring services, etc.).
• Scope down the rate rule using scope-down statements so it only counts requests to sensitive endpoints (e.g., /api/auth) rather than all paths.

Step 4: Fix Geo-Restriction 403s

Symptom: 403 only for users in specific countries; CloudFront logs show ForbiddenByGeorestriction in x-edge-result-type.

Navigate to CloudFront console → Distribution → Geographic restrictions. Switch between whitelist (allow specific countries) and blacklist (block specific countries) modes, then add or remove the relevant country codes (ISO 3166-1 alpha-2 format, e.g., CN, RU, IR).

Step 5: Regenerate Expired Signed URLs

CloudFront signed URLs embed an Expires Unix timestamp. Once that timestamp passes, CloudFront returns 403 with the body <Message>Request has expired</Message>.

Verify with:

# Extract Expires from a signed URL query string
URL="https://d1234.cloudfront.net/file.mp4?Expires=1700000000&..."
EXPIRES=$(echo "$URL" | grep -oP 'Expires=\K[0-9]+')
echo "Expires at: $(date -d @$EXPIRES)"
echo "Now:        $(date)"

If expired, regenerate the signed URL server-side using your CloudFront key pair. Ensure the DateLessThan condition is set far enough in the future for your use case.

Step 6: Resolve Origin Timeout Issues

When the origin (EC2, ALB, Lambda) does not respond within the configured timeout, CloudFront returns a 504. However, some origin frameworks return 403 under load when request queues overflow. CloudFront's default origin response timeout is 30 seconds and the origin connection timeout is 10 seconds.

Increase timeout via AWS CLI:

aws cloudfront get-distribution-config \
  --id EDFDVBD6EXAMPLE \
  --query 'DistributionConfig' > dist-config.json

# Edit dist-config.json: find your origin and update:
# "ResponseTimeout": 60,
# "ConnectionTimeout": 15

ETAG=$(aws cloudfront get-distribution-config \
  --id EDFDVBD6EXAMPLE \
  --query 'ETag' --output text)

aws cloudfront update-distribution \
  --id EDFDVBD6EXAMPLE \
  --if-match "$ETAG" \
  --distribution-config file://dist-config.json

Origin response timeout maximum is 60 seconds. If your origin regularly needs more than 60 seconds, use Lambda@Edge or CloudFront Functions to return a 202/placeholder while async processing completes.

Step 7: Invalidate Cached 403 Responses

CloudFront caches 403 responses according to the cache policy's min-ttl. A misconfigured short-lived fix may still serve stale 403s from edge nodes.

Invalidate affected paths:

aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths '/images/*' '/index.html'

For persistent issues, set ErrorCachingMinTTL for 403 to 0 in Distribution → Error Pages while you debug, then restore a sensible TTL (e.g., 30 seconds) once resolved.