Managed AWS prefix lists for the third-party services your workloads
depend on: Stripe, Datadog, GitHub, and dozens more, kept current in your
account. Reference pl-… in a security group rule and you're done.
No agent, no proxy, nothing of ours in your data path.
Locking down VPC egress is a solved problem right up until the first
third-party dependency. Vendor IP ranges live in a dozen inconsistent formats and
churn without notice. So most teams punch 0.0.0.0/0:443
into the egress rules and quietly give up the entire posture. An attacker with a
foothold can exfiltrate to anywhere on port 443. PCI DSS 4.0 (req. 1.3.2) and your
SOC 2 auditor both have opinions about that.
Every range comes from the vendor's official publication, with a provenance chain. Never widened, never summarized across gaps. The covered address set is preserved exactly.
Vendor rotations propagate to every consumer's security groups within minutes, with grace windows keeping old + new ranges live through the transition, so rotations are non-events.
Security groups are free, add zero latency, and your auditor already understands them. No gateway to operate, no vendor in your traffic path, nothing new to fail.
We publish each service's ranges as AWS-managed-style prefix lists and share them to your accounts via AWS RAM. One CloudFormation stack accepts the share and files the security-group quota increase your subscriptions need.
Use pl-… in security group rules exactly like an AWS-managed
prefix list: egress.stripe.api.v4, egress.datadog.agents.v4,
one list per service, purpose, and address family.
When the vendor's ranges change, the list updates and every referencing rule follows; typically inside the hour of the vendor publishing, and within a minute of the change landing in our feed. Staged rollouts hit our own canary account first; suspicious changes are quarantined before they ever publish; updates are signed end-to-end with an ed25519 signature over the feed index, every service document hash-chained to it, verified before anything is applied.
Note: IP pinning only works for services with dedicated, published ranges. The catalog classifies every service and tells you plainly when a CDN-fronted service can't be pinned safely. Those services aren't out of reach; a later phase adds hostname-aware egress enforcement that runs entirely in your VPC, built on this same catalog.
The data layer is open and free: a signed, versioned feed of official vendor IP ranges. 45+ services, rebuilt continuously, with per-purpose scoping and change history, plus a Terraform provider for plan-time use.
source = "slash0-io/egress".
Data sources for every service and purpose in the catalog.
registry ↗
Signed JSON at feed.slash0.io/v1, with sync tokens, provenance, and a changelog. browse the catalog ↗
The feed pipeline is open source, with every parser tested against archived vendor fixtures. github.com/slash0-io/feed ↗
The hosted tier delivers these ranges as managed prefix lists, kept current in your account. It is live and onboarding design partners now. Tell us which services you allowlist (or wish you could) and we'll reach out as slots open.