Peering Policy

Interconnect with the Amazon global network

This document outlines Amazon’s policies and preferences for peering with external third parties on a settlement free basis (“Amazon Peering Policy” or “Amazon Settlement Free Interconnection Policy”) and includes the key factors that Amazon considers when assessing a request from external parties for peering with Amazon’s AS16509 network or any successor AS numbers (“Amazon AS16509”). In order to provide a highly available and high performance experience for our customers, Amazon maintains a global network infrastructure and peers with external networks, utilizing both public peering (Internet Exchanges) and private peering (Private Network Interconnect). 

Click here for Amazon AS16509 interconnection facilities 

Peering Requests

Any external party that intends to peer with Amazon AS16509 must have an up-to-date and fully completed entry in All peering requests should come via email. Amazon will, in its sole discretion, assess peering requests and existing arrangements on a case-by-case basis considering the external party’s adherence to the best practices below and other factors. Amazon endeavors to respond, either inclined or declined, to all peering requests on a timely basis; however, due to the number of requests that Amazon receives, Amazon will not respond to provide reasons as to why any individual peering request is declined.

Peering Best Practices

The following are best practices expected of Amazon’s peering partners:

  1. Maintain an up-to-date and fully completed entry in
  2. Use a unique public autonomous system number (“ASN”)
  3. Operate a dual stack (IPv4 and IPv6) network using a public ASN
  4. Timely resolve issues raised in trouble tickets, with a 24x7 network support contact
  5. Commit to interconnect with Amazon in all common locations where Amazon and the partner both have a point of presence
  6. Maintain entries in Internet Routing Registries (“IRR”) and use IRR entries for filtering across the partner’s network(s)
  7. Comply with the Peering Technical Guidelines in Appendix below.
  8. Enable or have plans for enabling Resource Public Key Infrastructure (“RPKI”) for route origin validation
  9. Avoid malicious or otherwise undesirable traffic or activity on the partner’s network

Peering Technical Guidelines

Amazon expects its peering partners to comply with the following technical guidelines which are based on best common practices for Internet eXchange Points (“IXPs”). Public peering partners must adhere to the technical requirements of the respective IXPs that are used for interconnection and may only use the IPv4/v6 addresses assigned to them by those IXPs.


  • Support Border Gateway Protocol (“BGP”) version 4 routing protocol for propagating routing information across the interconnection
  • Announce only the peering partner’s own routes, its customer routes and any other network that has agreed to allow the partner to announce its routes to third parties
  • On public IXPs, a peering partner should only announce prefixes with its own next-hop IP address and not announce routes on behalf of other peers on the IXP
  • Support both IPv4 unicast and IPv6 unicast traffic as native or dual-stacked
  • Accept any appropriately IRR-registered prefix announcements up to /24 in length for IPv4 and /48 in length for IPv6
  • Employ a routing policy that ensures that traffic generally follows a closest-exit behavior.
  • Support BGP prefix filter updates using these IRRs, with automated router configuration updates occurring no less than every 24 hours: RADB, ALTDB, RIPE, APNIC and ARIN
  • Support BGP prefix filters using Route Origin Authorizations (“ROAs”) for origin ASN validation for directly connected peers, or use RPKI-based validation for all route and traffic exchange.


Forward traffic on interconnection interfaces only to routes being advertised across the interconnection. Any traffic destined for Amazon’s network will be forwarded via dynamic routing and not static routing. If a peering partner continues to send Amazon traffic over an interconnection to IP address after Amazon has withdrawn the prefixes, Amazon will not continue to peer with that external party.


Maintain a 24x7x365 operational contact on For private peers, Amazon prefers to have direct and multiple levels of contacts for policy, capacity, and operational discussion, including face-to-face annual meetings at peering conferences, network operators forums, IXP members meetings or a mutually agreed location.

Non-Routing Devices

Amazon will peer with looking glass and route-collectors only over IXPs. When a BGP speaker is collecting routing information for analysis and not for immediate routing decisions, the BGP speaker may use a private AS number and should not advertise any routes.

Additional Technical Guidelines for Private Peering

Physical Connection

  • Amazon does not support private peering interconnections at speeds that are less than 10Gbps.
  • New or existing peering partners may request a private interconnection for any location where both parties have a point of presence.
  • The cost of in-building cross connects will be shared equitably between Amazon and the partner.
  • The physical port requirements are:
    • All interfaces configured as auto negotiating
    • Optical interconnections with single-mode fiber
    • Use of standards based 10GBase-LR, and 100GBase-LR optics,although extended Range 10GBase-ER and 100GBase-ER4 optics may be considered on a case by case basis.
    • Support of IEEE 802.3ad Link Aggregation (LACP) or multipath to distribute load across multiple interconnect ports

Ethernet MAC Layer

  • One of the following ethertypes for all frames forwarded:
    • 0x0800 – IPv4
    • 0x0806 – ARP
    • 0x86dd – IPv6
  • Same source MAC address for all frames forwarded. All link-aggregated ports for a partner are treated as a single port.
  • No forwarding of broadcast or multicast traffic
  • Link-local traffic limited to the following protocols:
    • ARP
    • IPv6 Neighbor solicitations and advertisements

Examples of other link-local protocols that should be disabled on the interconnection facing interfaces include: IRDP, ICMP redirects, IEEE802 Spanning Tree, Vendor proprietary discovery protocols (e.g. CDP, EDP), Interior routing protocol broadcasts (e.g. OSPF, ISIS, IGRP, EIGRP), BOOTP/DHCP, PIM-SM, PIM-DM, DVMRP

IP Address

Amazon prefers private interconnections to use /31 (preferred) or /30 for IPv4 link-local addresses, and /127 (preferred) or /64 for IPv6 link-local addresses. IPv6 site-local addresses will not be used. Domain Name System (“DNS”) may be configured with mutual agreement between Amazon and the partner.

Additional Factors

In addition to the guidelines above, Amazon may consider other factors in agreeing to peer with external parties, such as these preferred specifications:

  • Peering partners should not prioritize any Internet traffic which passes across its backbone and customer links except for traffic associated with reasonable network management.
  • Peering partners should support a comprehensive and documented BGP community scheme for marking prefixes sent to peers, identifying:  prefix origin (incl. City, State/Province, Country, Continent) and prefix type (customer, internal).
  • Peering partners should support BGP community triggered packet discard (blackholing) of traffic within the network supporting IPv4 prefixes up to /32 and IPv6 prefixes up to /128.