Backblaze Peering Policy

Backblaze operates data centers in the U.S. and EU. Backblaze (AS40401) has a selective peering policy and will individually analyze each request based on business needs. We take the following factors into account when peering:

  • Traffic levels between our networks
  • Number of sites where we can mutually peer
  • Mutual benefit to proceed with peering
  • Compliance with our legal and technical peering requirements

Peering Policy

Backblaze uses PeeringDB to maintain an updated list of IX points and private peering facilities. We require both parties to utilize industry common best practices for BGP configurations, including but not limited to BCP-38 and route filtering. As we generate filters and BGP sessions from information in PeeringDB, we ask that peers keep an up-to-date entry.

We recommend that peers implement Mutually Agreed Norms for Routing Security (MANRS).

More details on PeeringDB at

Peering Requirements

Configuration requirements include:

  • Publicly routable BGP ASN and IPv4/IPv6 address space
  • ASN/Prefix information in PeeringDB
  • Route and/or Route6 objects in IRR and BGP AS-SET
  • Password authentication recommended

Public Peering (IX)

Peering locations are determined by mutual connectivity in one or more of our locations listed in PeeringDB.

Private Network Interconnection (PNI)

In addition to the requirements above, Backblaze can provide single or multiples of 100G connections depending on the business needs.

Configuration requirements include:

  • 100G-LR4 w/ Single-mode fiber
  • LACP link aggregation
  • P2P /30 or /31 network or Link-Local Addresses

Unsupported Features

At this time, we do not support the following features:

  • Non-public IP address space
  • eBGP multihop
  • Bidirectional Forwarding Detection (BFD)

Important Notices

Backblaze reserves the following rights under our Peering Policy:

  • To accept or decline a peering request at any time for any reason.
  • To alter our peering policy and peering requirements at any time.
  • To suspend, without notice, peering connectivity in the event of a severe quality of service issue, such as high latency, packet loss, or jitter pattern, is detected, and to take appropriate traffic engineering steps to maintain service quality.
  • To selectively withdraw prefixes from public and private peering sessions as needed to protect service quality.
  • To suspend peering in cases of abusive traffic, such as DDoS or malicious intent, at any time.
  • To terminate any peering connection at any time without notice and without reason.

Maintenance Notifications

Any type of planned or unplanned maintenance notifications on a Backblaze public or private peering session should be sent to