CloudFront IP Address Ranges (October 2026): The List, Origin-Facing vs Edge IPs, the Managed Prefix List and Its Weight of 55, Static IPs, and the Real Viewer IP

CloudFront's IP address ranges are published by AWS in ip-ranges.json under the service name CLOUDFRONT. On October 24, 2026 that meant 214 IPv4 prefixes (about 4.2 million addresses) and 34 IPv6 prefixes. But if you want to allow CloudFront through your origin's firewall, that is the wrong list. The servers that actually fetch from your origin use a much smaller set, CLOUDFRONT_ORIGIN_FACING: 49 IPv4 prefixes (344,384 addresses) and 38 IPv6, also available as the AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing, which you can drop straight into a security group. Two things surprise almost everyone. First, the IP address your browser resolves for a CloudFront site is not an origin-facing address, so allowlisting "the CloudFront IP" you see in DNS blocks CloudFront itself. In our check, all four addresses DNS returned were viewer-facing only. Second, allowing CloudFront's IPs lets every CloudFront distribution reach your origin, including someone else's; you also need a secret header or a private VPC origin. This guide covers the lists, the prefix list and its weight of 55 rules, static IPs, the real viewer IP, and blocking by IP.

Jake's booking site runs behind CloudFront, and one Monday the server behind it was being hammered by bots that went straight to its public address. Ethan looked up the site's IP with dig, allowed only that address on the server's firewall, and five minutes later every visitor got a 504. "So we blocked the bots," Jake said. "We blocked CloudFront," Ethan said. "The address you see is the front door. The one that knocks on our server is a different one."

New to CloudFront? It is AWS's content delivery network: a worldwide set of servers that cache your site close to visitors and fetch from your own server (the origin) when they need to. Our plain-English CloudFront guide covers how a distribution works. For IP addresses, what matters is that there are two directions: the addresses visitors connect to, and the addresses CloudFront connects from when it calls your origin. They are different lists.

Where the CloudFront IP address list lives

AWS publishes every public IP range it uses in one file, updated whenever the ranges change:

curl -O https://ip-ranges.amazonaws.com/ip-ranges.json

Each entry has a prefix, a Region and a service. Two service names belong to CloudFront:

Those counts come from the copy published at 05:37 UTC on October 24, 2026. Every origin-facing IPv4 prefix sits inside the CLOUDFRONT ranges, so the origin-facing list is a strict subset: about 8% of CloudFront's IPv4 addresses. Most CLOUDFRONT entries have the Region GLOBAL (118 of the 214 IPv4 prefixes); the rest are tied to Regions such as us-east-1 (12) and us-west-2 (11), where CloudFront's regional edge caches sit.

To pull out each list with jq:

# every CloudFront IPv4 prefix
jq -r '.prefixes[] | select(.service=="CLOUDFRONT") | .ip_prefix' ip-ranges.json

# only the origin-facing ones, IPv4 and IPv6
jq -r '.prefixes[] | select(.service=="CLOUDFRONT_ORIGIN_FACING") | .ip_prefix' ip-ranges.json
jq -r '.ipv6_prefixes[] | select(.service=="CLOUDFRONT_ORIGIN_FACING") | .ipv6_prefix' ip-ranges.json

There is also an older CloudFront-only list at https://d7uri8nf7uskq.cloudfront.net/tools/list-cloudfront-ips, with two keys: CLOUDFRONT_GLOBAL_IP_LIST (118 prefixes) and CLOUDFRONT_REGIONAL_EDGE_IP_LIST (96). Together they are the same 214 IPv4 prefixes as the CLOUDFRONT service in ip-ranges.json. It has no IPv6 and no origin-facing list, so the "regional edge" list is not the list of addresses that reach your origin: 91 of its 96 prefixes are not origin-facing. For firewalls, use ip-ranges.json or the managed prefix list.

The trap: the IP you see in DNS is not the IP that reaches your server

When you look up a CloudFront domain, DNS returns edge addresses close to you. We resolved a CloudFront domain and got four A records with a 60-second time to live:

d7uri8nf7uskq.cloudfront.net. 60 IN A 99.86.174.126
d7uri8nf7uskq.cloudfront.net. 60 IN A 99.86.174.212
d7uri8nf7uskq.cloudfront.net. 60 IN A 99.86.174.62
d7uri8nf7uskq.cloudfront.net. 60 IN A 99.86.174.151

Then we checked each address against the two lists with the checker script below:

99.86.174.126   CloudFront=True   origin-facing=False  -> viewer-facing edge
99.86.174.212   CloudFront=True   origin-facing=False  -> viewer-facing edge
99.86.174.62    CloudFront=True   origin-facing=False  -> viewer-facing edge
99.86.174.151   CloudFront=True   origin-facing=False  -> viewer-facing edge
130.176.88.1    CloudFront=True   origin-facing=True   -> origin-facing (fetches from origins)
8.8.8.8         CloudFront=False  origin-facing=False  -> not CloudFront

All four are CloudFront, and none is origin-facing. So a firewall that allows "the CloudFront IP" from dig lets in nothing CloudFront actually uses to call your server, and visitors see 502 or 504 errors. Those addresses also change: a 60-second TTL means a different set can come back a minute later, and someone in another country gets a different edge entirely. Never allowlist an address you resolved; allow the published origin-facing ranges. Our CloudFront 502 and 504 guide covers the other reasons an origin stops answering.

"So the address on the outside of the building and the one on the delivery van are different," Jake said. "And I only let the building in," Ethan said.

How to allow only CloudFront to reach your origin (security group)

If your origin is on AWS (an EC2 instance, a load balancer, an ECS service), the simplest way is the AWS-managed prefix list. AWS keeps it current, so you never edit IP ranges yourself:

• com.amazonaws.global.cloudfront.origin-facing for IPv4
• com.amazonaws.global.ipv6.cloudfront.origin-facing for IPv6

1. Find the prefix list ID in your Region (each Region has its own pl- ID for the same list):

   aws ec2 describe-managed-prefix-lists \
       --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing \
       --query "PrefixLists[0].[PrefixListId,MaxEntries]" --output text

2. Allow HTTPS from it on the origin's security group:

   aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 \
       --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-xxxxxxxx,Description="CloudFront origin-facing"}]'

3. Remove the old open rule (for example 0.0.0.0/0 on 443) once CloudFront traffic is flowing.
4. Test through CloudFront (should work) and directly to the origin's public address (should time out).

In the console: EC2, Security Groups, edit inbound rules, add a rule with type HTTPS and, as the source, start typing com.amazonaws.global.cloudfront.origin-facing and pick the prefix list. Our security groups guide explains inbound rules.

The weight of 55: why the prefix list fills your security group

A managed prefix list does not count as one rule. Each one has a weight, the number of rule slots it takes, and the CloudFront list's weight is 55, even though it held 49 IPv4 prefixes on October 24 (the extra room lets it grow without breaking your groups). Here is what that does to the default quotas:

For comparison, the S3 and DynamoDB prefix lists weigh 1 each and the Route 53 health checker lists 25. Practical consequences:

• Put the CloudFront rule in its own security group and attach that group to the origin alongside your others. A resource can have several security groups, and the quota applies per group.
• If you need more, request a higher "inbound or outbound rules per security group" quota in Service Quotas.

Why IP allowlisting is not enough, and how to lock the origin properly

Allowing the origin-facing ranges stops random scanners. It does not stop another CloudFront distribution, because every distribution, including one an attacker creates in their own account, fetches from the same origin-facing addresses. Someone who knows your origin's address can point their own distribution at it and walk past your IP rule, and past any CloudFront-side protections such as AWS WAF rules on your distribution. Add one of these:

• A secret origin header. In the distribution's origin settings, add a custom header such as X-Origin-Verify with a long random value, and make the origin (or the load balancer listener rule) reject requests without it. Treat the value like a password, rotate it, and never put it in client code. On an Application Load Balancer, a listener rule that forwards only when the header matches, with a default action that returns 403, does the job.
• A VPC origin. Put the load balancer or EC2 instance in a private subnet with no public address, and connect it to CloudFront as a VPC origin. CloudFront then reaches it over a private connection, and there is nothing public to bypass. VPC origins support Application Load Balancers, Network Load Balancers (with a security group, and without TLS listeners) and EC2 instances; the VPC needs an internet gateway attached even though the origin traffic does not use it.
• Origin access control for S3 buckets and Lambda function URLs, which signs CloudFront's requests so the bucket or function accepts only your distribution. Our OAC guide covers S3.

The strongest setup combines them: a VPC origin where you can, otherwise the prefix list plus a secret header, over HTTPS. Ethan ended up with the prefix list in a dedicated security group and a header check on the load balancer. The bots that knew the server's old address got a timeout; Jake's visitors got their bookings.

Seeing the real visitor IP behind CloudFront

Once CloudFront sits in front, your server's logs show CloudFront's origin-facing addresses as the client, not your visitors. There are three ways to get the real address:

• X-Forwarded-For: CloudFront adds the viewer's IP to this header on every origin request. If the viewer came through a proxy, the header can hold several addresses; the right-most one added by CloudFront is the address CloudFront saw.
• CloudFront-Viewer-Address: contains the viewer's IP and source port, for example 198.51.100.10:46532. Add it in an origin request policy; it cannot go in a cache policy. Our headers guide shows how to attach one.
• Logs: CloudFront's own access logs record the viewer address in the c-ip field.

On nginx, the realip module rewrites $remote_addr to the viewer's address, but only if you tell it which proxies to trust. Trusting X-Forwarded-For from everyone lets any client forge its address, so trust only CloudFront's origin-facing ranges. This script writes the config from ip-ranges.json:

#!/usr/bin/env python3
"""cf_nginx_realip.py > /etc/nginx/conf.d/cloudfront-realip.conf
Trust X-Forwarded-For only from CloudFront's origin-facing addresses, so $remote_addr becomes the viewer's IP."""
import json, sys, urllib.request
src = sys.argv[1] if len(sys.argv) > 1 else None
data = json.load(open(src)) if src else json.load(urllib.request.urlopen('https://ip-ranges.amazonaws.com/ip-ranges.json', timeout=30))
nets = sorted({p['ip_prefix'] for p in data['prefixes'] if p['service'] == 'CLOUDFRONT_ORIGIN_FACING'} |
              {p['ipv6_prefix'] for p in data['ipv6_prefixes'] if p['service'] == 'CLOUDFRONT_ORIGIN_FACING'})
print(f"# CloudFront origin-facing ranges from ip-ranges.json {data['createDate']} ({len(nets)} prefixes)")
for n in nets: print(f'set_real_ip_from {n};')
print('real_ip_header X-Forwarded-For;')
print('real_ip_recursive on;')

We generated the file from the October 24 ranges (87 set_real_ip_from lines, IPv4 and IPv6) and checked it with nginx -t in an OpenResty container: "syntax is ok" and "test is successful". To prove the file was really loaded, we also fed it a broken line, and nginx -t failed on it, as it should. Run the script from cron once a day and reload nginx, so new CloudFront ranges are trusted when they appear.

Blocking or allowing visitors by IP

Restricting who can view your site is a different job, and firewall rules on your origin cannot do it, because every request reaches the origin from CloudFront. Do it at CloudFront:

• AWS WAF IP sets: attach a web ACL to the distribution with a rule that blocks (or allows only) an IP set. This is the standard way to block an attacker's addresses or limit an admin page to your office.
• Geographic restrictions: allow or block whole countries in the distribution settings, or with WAF geo-match rules for finer control.
• Signed URLs and cookies with an IP condition: a custom policy can include an IpAddress condition (AWS:SourceIp) so a link works only from one address or range. Our signed URL guide covers key groups and policies.

To block a list of addresses with AWS WAF:

1. In the AWS WAF console, switch to the Global (CloudFront) scope; web ACLs for CloudFront live in US East (N. Virginia).
2. Create an IP set with the addresses or ranges to block (IPv4 and IPv6 need separate sets).
3. Create a web ACL (or edit yours) and add a rule: IP set, your set, action Block.
4. Associate the web ACL with the distribution, then test from an address in the set: it should get a 403.

If you block by IP, remember the viewer address is the one CloudFront sees. People behind a company proxy or a mobile carrier share addresses, so a block can catch more people than you intend.

Does CloudFront have a static IP? Anycast static IPs

By default, no: CloudFront's addresses are shared and change, which is why you point DNS at the distribution's domain name (with a CNAME, or an alias record at the zone apex; see our alias vs CNAME guide). If you truly need fixed addresses, CloudFront offers Anycast static IPs, dedicated to your account and announced from locations around the world:

• 21 static IPs for allowlisting: for example with mobile network operators who waive data charges for your app ("zero rating"), or in customers' outbound firewalls.
• 3 static IPs for apex domains, so example.com can have A records pointing at CloudFront when your DNS provider has no alias records.
• Lists are IPv4-only or dual-stack. An IPv4-only list cannot be attached to a distribution with IPv6 turned on.
• The distribution must use the "Use all edge locations" price class.
• You request them through the console's Static IPs page, which routes the request to CloudFront's support engineers with your traffic figures; the review can take up to two days.

They are not cheap. The CloudFront price list published on October 19, 2026 shows $15,000 a month per IPv4 static IP list and $5,000 a month per IPv6 static IP list, plus a separate line of $0.005 per hour for Anycast static IPv4 addresses. Check the pricing page for which charge applies to your use case before you request a list. For most sites, a CNAME or alias record does the same job for free, and an origin that needs to recognize CloudFront should use the prefix list, not static IPs. CloudFront also supports bringing your own IP range through Amazon VPC IP Address Manager, for organizations that already own address space.

"Fifteen thousand a month for three numbers," Jake said. "For twenty-one," Ethan said. "And still not something a repair shop needs. Our DNS does aliases."

How often CloudFront IP addresses change

The ranges change whenever AWS adds or moves capacity, with no fixed schedule. Every copy of ip-ranges.json carries a createDate (ours was 2026-10-24-05-37-05) and a syncToken, so you can compare copies. To be told about changes, subscribe to the Amazon SNS topic AWS publishes for exactly this:

aws sns subscribe --region us-east-1 \
    --topic-arn arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged \
    --protocol email --notification-endpoint you@example.com

The notification includes the new create-time, synctoken and an MD5 of the file. A Lambda function subscribed to the topic can regenerate firewall or nginx files automatically. If your origin is on AWS, the managed prefix list makes this unnecessary, because AWS updates the list for you; that is the main reason to prefer it over copying ranges.

Lab: check whether an IP address belongs to CloudFront

This script answers two questions about any address: is it CloudFront, and is it one of the origin-facing addresses that can appear in your origin's logs? It reads ip-ranges.json (downloaded, or a saved copy with --file):

#!/usr/bin/env python3
"""cf_ip_check.py IP [IP ...]: is this address CloudFront, and is it an origin-facing (origin-fetch) address?"""
import ipaddress as ip, json, sys, urllib.request
args = sys.argv[1:]
if '--file' in args:
    i = args.index('--file'); data = json.load(open(args[i + 1])); args = args[:i] + args[i + 2:]
else:
    data = json.load(urllib.request.urlopen('https://ip-ranges.amazonaws.com/ip-ranges.json', timeout=30))
ranges = {}
for p in data['prefixes'] + data['ipv6_prefixes']:
    if p['service'] in ('CLOUDFRONT', 'CLOUDFRONT_ORIGIN_FACING'):
        ranges.setdefault(p['service'], []).append(ip.ip_network(p.get('ip_prefix') or p['ipv6_prefix']))
print(f"ip-ranges.json {data['createDate']}: CLOUDFRONT {len(ranges['CLOUDFRONT'])} prefixes, ORIGIN_FACING {len(ranges['CLOUDFRONT_ORIGIN_FACING'])}")
for a in args:
    addr = ip.ip_address(a)
    cf = any(addr in n for n in ranges['CLOUDFRONT']); of = any(addr in n for n in ranges['CLOUDFRONT_ORIGIN_FACING'])
    kind = 'origin-facing (fetches from origins)' if of else ('viewer-facing edge' if cf else 'not CloudFront')
    print(f'{a:40} CloudFront={cf!s:5}  origin-facing={of!s:5}  -> {kind}')

Run python3 cf_ip_check.py 99.86.174.126 130.176.88.1. The counts it prints (248 CloudFront prefixes and 87 origin-facing on October 24) include IPv6. Use it on the client addresses in your origin's access log: if a request did not come from an origin-facing address, it did not come through CloudFront.

Troubleshooting CloudFront IP problems

504 or 502 errors right after adding a firewall rule

The rule allows addresses from dig or the full CLOUDFRONT list but not the origin-facing ranges, or it allows only IPv4 while CloudFront reaches the origin over IPv6. Use the origin-facing prefix lists for both IPv4 and IPv6.

"The maximum number of rules per security group has been reached"

The CloudFront prefix list takes 55 of the default 60 slots. Move it to its own security group, or request a higher quota.

Bots still reach the origin after the IP rule

They come through their own CloudFront distribution, from the same origin-facing addresses. Add a secret origin header check, or move the origin into a private subnet as a VPC origin.

Every log line shows the same few client addresses

Those are CloudFront's origin-facing servers. Read X-Forwarded-For or CloudFront-Viewer-Address, or configure your web server's real-IP module to trust only the origin-facing ranges.

The prefix list will not fit in a route table

Its weight of 55 is larger than the default of 50 routes. Request a route table quota increase first.

CloudFront IP addresses: frequently asked questions

By lunchtime the bots were gone, the visitors were back, and Ethan's server logs finally showed customers' addresses instead of CloudFront's. "So the trick was to stop trusting the address I could see," Jake said. "And start trusting the one AWS publishes," Ethan said. If your results differ from what this page describes, please tell us. Guides like this stay right because readers write in.

Revision note. Written October 24, 2026, from that morning's ip-ranges.json, a live DNS lookup and an nginx config test. "Appearances can be deceiving," the old saying goes, and with CloudFront the address that appears is the one to ignore.