Introduction

The standard way to restrict access to a CloudFront distribution by IP is to attach AWS WAF to the distribution and use an IP set rule. That approach is simpler and safer than trying to build the logic into your origin because CloudFront can reject requests before they reach the backend.

Use AWS WAF as the Primary Control

CloudFront itself does not have a first-class "allow only these IPs" setting in the distribution behavior UI. The normal solution is:

1. create an IP set in AWS WAF
2. create a web ACL that uses that IP set
3. associate the web ACL with the CloudFront distribution

You can use this for either:

• an allowlist
• a blocklist

For security-sensitive distributions, an allowlist is usually easier to reason about.

Example WAF Rule in CloudFormation

1Resources:
2  OfficeIps:
3    Type: AWS::WAFv2::IPSet
4    Properties:
5      Name: office-ips
6      Scope: CLOUDFRONT
7      IPAddressVersion: IPV4
8      Addresses:
9        - 203.0.113.10/32
10        - 198.51.100.0/24
11
12  CloudFrontAcl:
13    Type: AWS::WAFv2::WebACL
14    Properties:
15      Name: cloudfront-ip-acl
16      Scope: CLOUDFRONT
17      DefaultAction:
18        Block: {}
19      VisibilityConfig:
20        CloudWatchMetricsEnabled: true
21        MetricName: cloudfront-ip-acl
22        SampledRequestsEnabled: true
23      Rules:
24        - Name: allow-office-ips
25          Priority: 1
26          Action:
27            Allow: {}
28          Statement:
29            IPSetReferenceStatement:
30              Arn: !GetAtt OfficeIps.Arn
31          VisibilityConfig:
32            CloudWatchMetricsEnabled: true
33            MetricName: allow-office-ips
34            SampledRequestsEnabled: true

With DefaultAction set to block, only the IPs in the set are allowed.

Associate the ACL with CloudFront

Once the web ACL exists, attach it to the distribution. In infrastructure-as-code, keep that association in the same stack or a clearly related stack so the security boundary is not managed manually.

The key operational point is that WAF evaluates the viewer IP before the request reaches the origin. That reduces unnecessary load and keeps the access rule close to the edge.

When CloudFront Functions or Lambda at Edge Make Sense

You can implement IP checks in CloudFront Functions or Lambda at Edge, but that should usually be the fallback, not the first option. WAF is better when the rule is simply "allow or block by IP range."

Custom code is more appropriate when:

• the decision depends on headers and IP together
• the rule must transform the response
• you need custom logging or special challenge behavior

For plain IP restriction, WAF is less error-prone.

Be Careful with Proxies and Corporate Networks

An IP allowlist is only as stable as the client network. This works well for office networks, VPN egress ranges, or fixed partner infrastructure. It works poorly for users on consumer mobile networks or dynamic residential IPs.

Before adopting IP restriction, confirm:

• which IP ranges are actually stable
• how often they change
• who owns updates when the ranges change

If that ownership is unclear, the control will drift and break access unexpectedly.

Test with a Block Default

A good rollout pattern is:

1. create the WAF rule in count or monitor mode if needed
2. verify sampled requests and logs
3. switch to allowlist enforcement

For a production cutover, test from:

• an allowed IP
• a blocked IP
• a CDN cache hit path
• a cache miss path

That gives confidence that the restriction is applied consistently.

Common Pitfalls

The biggest mistake is implementing IP filtering only at the origin and forgetting that CloudFront still accepts and forwards unwanted traffic. WAF is a better place for edge access control.

Another issue is allowlisting unstable client IPs. That makes the system look randomly broken from the user's point of view.

A third problem is using custom edge code for simple allowlist logic that WAF already handles more cleanly.

Summary

• Use AWS WAF with an IP set to restrict CloudFront access by IP.
• Attach the WAF web ACL directly to the distribution.
• Prefer an allowlist when access should be limited to known networks.
• Use edge code only when the decision logic is more complex than IP matching.
• Make sure the allowed IP ranges are actually stable and operationally maintained.