Monitoring Cloud IP Ranges: AWS and GCP Prefixes Change Without Warning
Cloud providers add and retire IP prefixes regularly. If your firewall rules or allowlists reference specific cloud CIDR blocks, you need a process to keep them current — or you will break production.
Cloud providers are not static. AWS launches new regions, expands existing ones, adds new services, and retires old infrastructure. Each of these events can change the set of IP prefixes the provider uses. If your organisation uses cloud IP ranges to control traffic — allowing inbound from CloudFront, blocking egress to competitor cloud regions, or detecting cloud-sourced traffic in your SIEM — stale prefix lists cause incidents.
How Often Do Ranges Change?
AWS updates its ip-ranges.json file multiple times per month, sometimes daily. The file includes a Unix timestamp sync token that changes with every update. You can check the current state of AWS ranges on our AWS IP ranges page. Google Cloud similarly updates its cloud.json feed regularly. Azure's Service Tag download is refreshed weekly.
What Changes Typically Look Like
Most changes are additions — AWS adds new prefixes for a new region or service expansion. Occasionally, prefixes are removed when infrastructure is retired or renumbered. The delta between two versions of the feed might be a handful of new /24 or /22 prefixes in a new availability zone. Over a year, the cumulative changes are significant.
The AWS SNS Notification Topic
AWS provides an SNS topic that publishes a notification whenever ip-ranges.json changes. Subscribe to the topic at:
arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged
Your Lambda function can receive this notification, download the new feed, compare it against the previous version, and automatically update your security groups, WAF rules, or firewall policies with any new prefixes. This is the cleanest automation approach for AWS-native allowlisting.
A Simple Monitoring Workflow
- Store the current sync token for each provider in your config or database
- On a schedule (hourly or daily), fetch the provider's JSON feed
- Compare the sync token to the stored value
- If changed, compute the diff (added and removed prefixes)
- Apply the diff to your firewall or allowlist configuration
- Alert your team with a summary of what changed
GCP and Azure
Google Cloud does not provide an equivalent SNS topic, so polling is required. Pull the GCP ranges on a schedule and compare the syncToken field. For Azure, subscribe to Microsoft's weekly download update announcement and diff the JSON. Storing the previous version of each provider's feed in a git repository gives you a clean history of all changes and the ability to trace exactly when a specific prefix was added or removed.