Settlement Free Peering Policy
This policy outlines the requirements for parties that wish to peer with Amazon’s AS16509 network and any downstream networks on a settlement free basis. Amazon peers utilizing public internet exchange points (“IXP”) and private network interconnection (“PNI”). A list of Amazon’s public peering exchange points and private peering facilities can be found on the Amazon.com AS16509 profile at peeringdb.com. Amazon advertises routes selectively at each location depending on factors like the location’s proximity to AWS Regions and service endpoints, and may advertise, withdraw, or cease advertising routes in its discretion in order to maintain availability, redistribute traffic, or mitigate abuse.
Peering with Amazon under this policy is not a service offering, does not establish a contractual relationship, and is not subject to any service level agreements or network availability or other guarantees. Amazon may modify or make exceptions to this policy at any time. Parties who are interested in receiving supported and managed connectivity with routes to the entire Amazon network should consider AWS Direct Connect.
Peering requests must be submitted via email to the address published at https://aws.amazon.com/peering/. Amazon will, in its discretion, assess requests on a case-by-case basis. Amazon attempts to respond to all requests but may not provide the reasons why a request was approved or rejected.
Peers must comply with the following requirements:
- Peer must interconnect in at least two edge locations identified by Amazon within a particular AWS Region to receive routes to that AWS Region.
- Peer must maintain a backbone network that interconnects all of the locations in which peer provides services and must interconnect with Amazon anywhere peer and Amazon are both present in order to enable a bi-directional shortest-exit routing topology.
- For peering at an IXP, peer must maintain connectivity headroom that is two times greater than any peak traffic volume exchanged with Amazon through that IXP.
- PNI peering is only supported using 100 Gbps port speed or greater over single-mode fiber and requires at least two logical interfaces with a minimum capacity utilization of 5% and maximum capacity utilization of 50% per interface. If peer’s utilization exceeds or is projected to exceed 50% at any location, then peer must increase its capacity at that location to ensure any peak traffic does not exceed 50% utilization.
- Peer must maintain a complete and current peeringdb.com profile.
- Peer must maintain a 24x7x365 operational contact and provide an escalation matrix for policy, capacity, and operational discussions, including addressing outages or abuse.
- Peer must operate a dual stack (IPv4 and IPv6) network using a public autonomous system number (“ASN”).
- Peer must register and maintain entries in a public internet routing registry (“IRR”) database and use IRR entries for filtering routing entries across the peer’s network(s) including those from peer’s customers to Amazon.
- Peer must maintain systems and a process to detect and mitigate malicious or illegal traffic originating from peer’s network.
- Peer must not use settlement free peering for its own, or its affiliates’, use of AWS services in excess of 10% of the total traffic exchanged between peer and Amazon on any peering link.
- Peer must announce its own routes and its customers’ routes consistently and uniformly at all locations.
- Peer must not establish a static route, route of last resort, or otherwise send traffic to Amazon through any route not announced via border gateway protocol (“BGP”).
- On IXPs, peer must only announce prefixes with its own next-hop IP address and not any other device connected to the IXP.
- Peer must accept any appropriately IRR-registered prefix announcements up to /24 in length for IPv4 and /48 in length for IPv6.
- Peer must not withdraw or prepend route advertisements in a given peering location such that traffic exit behavior is manipulated.
- PNIs must use IP addresses provided by Amazon.
- Peer must disable or prevent any link-local protocols, vendor discovery protocols, or interior routing protocol broadcasts.
- Peer must support:
- BGP version 4 routing protocol for propagating routing information across the interconnection and equal cost multi-path on all links to evenly distribute traffic.
- BGP community triggered packet discard (blackholing) of traffic within the network supporting IPv4 prefixes up to /32 and IPv6 prefixes up to /128.
- BGP prefix filter updates using the following IRRs, with automated router configuration updates occurring no less than every 24 hours: RADB, ALTDB, RIPE, APNIC and ARIN.
- BGP prefix filters using route origin authorizations for origin ASN validation for directly connected peers, or use resource public key indicated based validation for all route and traffic exchange.
- Both IPv4 unicast and IPv6 unicast traffic as native or dual-stacked.
- Peer must maintain a comprehensive and documented BGP community scheme for marking prefixes sent to its peers, including, but not limited to, identifying prefix origin (incl. City, State/Province, Country, Continent) and prefix type (customer, internal).