All Tools View Categories About Contact Privacy

IP-Restricted Policy Generator

Build an IAM statement scoped by source IP (aws:SourceIp) — allow-list or deny-list.

Runs entirely in your browser — CIDR ranges never leave this page.
-
operator
0
ranges
-
structurally valid

  

About IP-Restricted Policy Generator

Restricting AWS API access by source IP address is one of the most common condition patterns in IAM, and nearly all of it comes down to one condition key: aws:SourceIp. IP-Restricted Policy Generator builds an Allow statement scoped by that key, handling the two real-world details that trip people up by hand — choosing the right operator for an allow-list versus a deny-list, and getting the single-value-vs-array shape of the condition value right.

The core choice is a toggle between two IAM condition operators. Allow-list mode uses IpAddress: the statement's permissions apply only when the request's source IP falls inside one of the CIDR ranges you list. Deny-list mode uses NotIpAddress instead: the statement applies when the source IP is outside every listed range — useful when paired with a Deny effect elsewhere (this tool's companion, the Deny Policy Generator, can build that Deny statement) to actively block a specific set of known ranges while leaving everything else untouched. Both operators take the same underlying data — a list of CIDR ranges or bare IPs, entered one per line — and the tool assembles the condition value the way AWS itself renders it: a single CIDR becomes a plain string, and two or more become a JSON array, exactly mirroring how AWS's own console and CLI output display these condition blocks rather than always wrapping the value in an unnecessary single-element array.

Each line you enter is checked against a basic CIDR shape — four dot-separated number groups, with an optional /prefix — and any line that does not match is surfaced in a clearly labeled warning rather than silently dropped from the list. This is deliberately a warning, not a block: the regex used is a shape check, not a full IP-semantics validator (it will not catch an out-of-range octet like 999, and it does not recognize IPv6 notation at all), so a line flagged as "unrecognized format" might still be entered into the final condition on purpose — you decide whether to fix it or leave it, rather than the tool silently discarding something you typed intentionally.

Beyond the IP condition, this is a standard Allow-statement builder: multi-line actions and resources fields, an optional Sid, and the same structural validator used throughout this tool category checking that the assembled document has a recognized Effect, a non-empty Action, and a Resource before the JSON is shown. What it does not do is validate against AWS's actual routing or VPC configuration, resolve or expand named CIDR ranges, or check whether the IP ranges you enter correspond to anything real — it is a condition-block builder, not a network validator, and the "unrecognized format" warning is the full extent of its input checking.

The output is a validated Allow statement with the correct IpAddress or NotIpAddress condition, ready to copy, download, or merge into a larger policy — assembled entirely in your browser, with the CIDR ranges you enter never leaving the page.

Features

  • Allow-list vs deny-list toggle — real switch between IpAddress and NotIpAddress operators.
  • Correct single-value vs array shape for the CIDR condition value, matching AWS's own rendering.
  • Multi-line CIDR list with a basic shape check that warns, but never silently drops, unrecognized lines.
  • Multi-line actions and resources fields.
  • Structural validation of the assembled statement and document.
  • Pretty-printed JSON output with Copy and Download .json.
  • Sample office-IP-allow scenario pre-filled.
  • One-click clear.
  • 100% client-side — CIDR ranges never leave the page.

How to Use

  1. Choose allow-list or deny-list mode.
  2. Enter CIDR ranges or bare IPs, one per line.
  3. Review any "unrecognized format" warning and fix lines if needed.
  4. List the actions the condition should govern.
  5. List the resources it applies to.
  6. Optionally set a Sid.
  7. Click Build IP-restricted statement and check the structural validation result.
  8. Copy or download the JSON.

Examples

Example 1 — office-only access. Allow-list mode, CIDRs 203.0.113.0/24 and 198.51.100.0/24, actions s3:GetObject, resources * — produces an IpAddress condition with an array of both ranges.

Example 2 — single VPN exit IP. Allow-list mode, one CIDR 203.0.113.42/32 — produces an IpAddress condition with a bare string value, not an array.

Example 3 — block a known-bad range. Deny-list mode, CIDR 198.51.100.0/24 — produces a NotIpAddress condition; pair this statement's condition with a Deny effect (built separately) to actually block that range.

Example 4 — malformed line warning. CIDR list including 203.0.113.0/24 and my-office-ip — the second line is flagged in the warning as unrecognized format, while the first is still used.

Example 5 — bare IP, no prefix. CIDR list with just 198.51.100.5 — passes the shape check and is included as-is; AWS treats a bare IPv4 address as a /32.

Benefits

  • Gets the IpAddress/NotIpAddress operator choice right for allow-list vs deny-list intent.
  • Matches AWS's own single-value-vs-array rendering, avoiding unnecessary one-element arrays.
  • Warns on malformed CIDR lines without silently discarding them.
  • Structural validation before you attach the statement.
  • Copy or download straight into the IAM console, CLI, or IaC.
  • Private — CIDR ranges never leave your browser.

Frequently Asked Questions

What is the difference between allow-list and deny-list mode?
Allow-list mode uses the <code>IpAddress</code> condition operator, meaning the statement's Allow only applies when the request comes from one of the listed CIDR ranges — everything outside those ranges is not covered by this statement. Deny-list mode uses <code>NotIpAddress</code> instead, meaning the statement applies when the request does <em>not</em> come from one of the listed ranges — a common way to build a Deny statement blocking specific known-bad ranges while leaving everything else alone. This tool always builds an <code>Allow</code> effect statement; pair a <code>NotIpAddress</code> condition with a separate <code>Deny</code> statement (built in the Deny Policy Generator) if you want to actively block specific ranges rather than scope an allow.
Why does a single CIDR render as a plain string but multiple render as an array?
This mirrors exactly how AWS itself renders IAM condition values: a condition key with one value is commonly written as a bare string, and with more than one value becomes a JSON array. Both forms are functionally identical to AWS — this tool just avoids wrapping a single value in an unnecessary one-element array, matching the cleaner style AWS's own console and documentation use.
What counts as a valid line in the CIDR list?
Each line is checked against a basic pattern — four dot-separated numeric groups, with an optional <code>/prefix</code> like <code>/24</code>. Lines that do not match this shape are flagged in an "unrecognized format" warning but are <strong>not silently dropped</strong> — you can still include them if you know they are correct in a way the basic pattern does not anticipate (like an IPv6 address, which this simple regex does not attempt to validate).
Does the CIDR check validate real IP semantics, like octets being 0-255?
No — it is a basic shape check (four dot-separated number groups, optional prefix), not a full IP validator. It will not catch something like <code>999.999.999.999/24</code> as numerically invalid; it only flags lines that do not even match the dotted-number-with-optional-prefix pattern, such as a bare word or a malformed value.
Can I mix bare IPs and CIDR ranges in the same list?
Yes — a bare IP like <code>198.51.100.5</code> (no <code>/prefix</code>) is valid and is passed to AWS as-is; IAM treats a bare IP as a /32 (IPv4) match.
What resources and actions does this apply to?
Whatever you enter — a multi-line actions list and a multi-line resources list, the same as the other statement-builder tools in this category. The IP condition is layered on top of whatever Action/Resource scope you configure.
Does this tool support IPv6?
You can type an IPv6 CIDR into the list, and it will be included in the output condition, but the built-in shape check only recognizes the IPv4 dotted-decimal pattern, so an IPv6 line will always show up in the "unrecognized format" warning even if it is correct — treat that warning as informational for IPv6 lines, not as a rejection.
Is anything I enter sent anywhere?
No — CIDR validation and statement assembly both run entirely in your browser.