Wasabi Technologies IP Ranges
Wasabi Technologies runs S3-compatible hot cloud object storage out of Boston, founded in 2015 by Carbonite co-founders David Friend and Jeff Flowers and opened to the public in 2017 on a pitch of Amazon S3 compatibility at a fraction of the price, with no separate egress or API-request fees. Its network answers from AS395717, registered with ARIN to Wasabi Technologies, Inc. in November 2016 - months before the public launch - under the ASN name BLUEARCHIVE-ZONE-1.
- Provider
- Wasabi Technologies
- Primary ASN
- AS395717
- Category
- Cloud
- Headquarters
- Boston, USA
- Announced IPv4 prefixes
- 20
- Registry
- ARIN
Known IP ranges
These prefixes are currently announced to the global routing table by AS395717 (BLUEARCHIVE-ZONE-1 - Wasabi Technologies, Inc.). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
130.117.252.0/24
154.49.215.0/24
149.13.185.0/24
130.117.185.0/24
154.61.149.0/24
38.73.225.0/24
38.27.106.0/24
27.131.254.0/24
154.56.213.0/24
154.18.200.0/24
What does a Wasabi Technologies IP mean in a privacy test?
A Wasabi address in a lookup means the connection reached Wasabi's storage service, not a machine a customer installed software on: Wasabi rents object storage rather than virtual machines, so nothing on this network runs arbitrary software the way a VPS host's customers can. Wasabi does not publish a fixed list of the addresses that service runs on, so a firewall rule built from this ASN's routed blocks needs checking against a live lookup rather than a file that stays current on its own. What is on the other end of a connection is either Wasabi's own storage service or a customer's publicly readable bucket, never the customer's own server.
Wasabi does not publish a machine-readable IP list
Wasabi's own support documentation is direct about this: its firewall-whitelisting article states that Wasabi does not publish its IP addresses because, as the service scales, it is continually adding new ones, and it recommends allowing the service URL by name instead - s3.wasabisys.com for the US East 1 region - because a domain survives changes that would break an address-based rule. Each of Wasabi's sixteen storage regions has its own hostname, from s3.us-west-2.wasabisys.com to s3.eu-south-1.wasabisys.com and s3.ap-southeast-2.wasabisys.com, with the management console always reachable at console.wasabisys.com regardless of region. Where an address-based rule is unavoidable, Wasabi's own advice is to run nslookup against the relevant service URL and expect to repeat it, since the addresses a name resolves to are not fixed.
What is checkable is public routing data, not a Wasabi-published file, and it is worth being precise about what the registry does and does not say. RIPEstat's announced-prefixes data lists twenty IPv4 prefixes currently routed under AS395717, all of them /24s, and no IPv6 space at all. Most of that space is not registered to Wasabi: eighteen of the twenty sit inside blocks registered to Cogent Communications, LLC - 38.91.42.0/24 falls under Cogent's 38.0.0.0/8 and 154.61.149.0/24 under 154.61.0.0/16 - so a WHOIS lookup on them returns Cogent, not Wasabi. Only two are registered to Wasabi itself: 27.131.254.0/24, inside the ARIN direct allocation 27.131.252.0/22 under netname WT-535, and 103.151.85.0/24, which is an APNIC record under netname WASABI-AP rather than an ARIN one. The ARIN organization handle BLUEA-2 belongs to the AS395717 record itself, not to these prefixes. Public routing data adds a caution worth carrying into any filter built on this list: bgp.he.net records Wasabi reaching the internet through transit from carriers including Cogent, Hurricane Electric, GTT and Zayo rather than a large public-peering footprint, and shows only one of the twenty routed prefixes as RPKI-valid - the single block Wasabi holds directly - so an RPKI-only filter would pass most of this space through unvalidated. The full list is a snapshot of what is routed today, not a published commitment, so it can grow or shift the same way the service URLs' resolved addresses do.
Storage traffic, not a customer's own server
Wasabi is object storage, not a compute cloud, and that changes what an address on this network can mean compared with a VPS or a hyperscaler's general compute space. Nobody rents a virtual machine from Wasabi and points arbitrary software at the internet the way an EC2 or DigitalOcean customer can; every connection to AS395717 terminates in Wasabi's own S3-compatible storage service answering a request against a bucket, or in Wasabi's management console and API, rather than in software a customer installed and configured themselves.
That does not make the traffic Wasabi's own in the sense that matters to a reader. Wasabi lets an account make a bucket or an individual object publicly readable - accounts opened after March 13, 2023 need to ask Wasabi support to turn that on, where older accounts could enable it themselves - and a public object is fetched straight from a URL such as yourbucket.s3.wasabisys.com/file. So a browser or a crawler connecting to a Wasabi address can be retrieving one customer's public files, not anything Wasabi itself put there. An address match confirms the request reached Wasabi's storage layer; it says nothing about which customer's bucket answered, and Wasabi's own support channel, not the registry, is where that gets resolved.
Related tools
Frequently asked questions
What IP ranges does Wasabi Technologies use?
Wasabi announces addresses under AS395717, an ASN registered with ARIN to Wasabi Technologies, Inc. RIPEstat's announced-prefixes data lists twenty IPv4 prefixes currently routed, all /24 blocks, and no IPv6 space. Most of that space is not registered to Wasabi: eighteen of the twenty, including 38.91.42.0/24 and 154.61.149.0/24, sit inside blocks registered to Cogent Communications, LLC. Only 27.131.254.0/24 (an ARIN allocation to Wasabi Technologies, Inc.) and 103.151.85.0/24 (an APNIC record, netname WASABI-AP) are registered to Wasabi itself. Wasabi does not publish this list; it is drawn from routing data.
Why does a Wasabi IP address appear in my privacy test?
Because a connection reached Wasabi's storage service rather than because anything of yours is hosted there. Wasabi is object storage, not a VPN or proxy, so the address is either Wasabi's own console or API traffic, or a browser or crawler fetching a customer's publicly readable bucket - not an exit point anyone routes their own connection through.
Does Wasabi publish an IP allowlist for firewalls?
No. Wasabi's own support documentation states that it does not publish its IP addresses because it keeps adding new ones as the service scales, and recommends whitelisting the service URL, such as s3.wasabisys.com, by name instead. Where an address-based rule cannot be avoided, Wasabi's advice is to run nslookup against the relevant service URL and expect to repeat it later.
How do I check whether an address really belongs to Wasabi?
Check which ASN announces it, not who the block is registered to. A WHOIS lookup alone is misleading here: eighteen of the twenty /24s routed by Wasabi sit in Cogent-registered space, so ARIN's WHOIS returns Cogent Communications, LLC for addresses Wasabi really is serving from. The reliable check is RIPEstat's announced-prefixes or a BGP lookup showing the address falls in a prefix originated by AS395717. Even then it confirms only that Wasabi's network announces the block, not which customer or bucket the traffic involves.
Does a Wasabi IP address prove which customer's data is involved?
No. An address on AS395717 shows that a request reached Wasabi's storage service, not who owns the bucket behind it. Wasabi lets accounts make individual buckets or objects publicly readable, so the same address space can be serving one customer's public files as easily as Wasabi's own console or API traffic, and telling those apart requires Wasabi's own account records rather than anything visible in a registry lookup.