In our previous post on demystifying AWS Data Transfer services, we briefly explained how AWS is designed from its foundation to be the most secure way for our users to run their workloads in the cloud. In this post, we build on that and focus on how AWS has the largest implementation¹ of Resource Public Key Infrastructure (RPKI). RPKI is a specialized public key infrastructure framework to support improved security for internet BGP routing infrastructure. AWS has advocated for the adoption of RPKI as standard practice with our peer and upstream networks with the goal of advancing overall internet security. Historically, there have been operational events involving RPKI that impacted the internet connectivity of large networks. At AWS, we have a unique implementation of RPKI, which includes safety checks to ensure accuracy, with the ultimate goal of protecting our user’s workloads from such broadly impactful events. In this post, we explain how events like these happen and what AWS does to ensure users aren’t affected. However, to get there, we start with some basics.

An overview of internet routing and BGP

The Internet is a decentralized mesh of independently operated networks. There are tens of thousands of these networks, all connected to each other using BGP protocol. BGP is a standardized protocol that allows autonomous networks (referred to as “autonomous systems” or “AS” for short) to determine the best path for data to travel across the internet. BGP is essential for the internet to function, enabling networks to communicate and send and receive information. Without BGP, it would be impossible for users to perform even the most basic of functions, like browsing the web or sending an email. You can learn more about BGP and how AWS implements BGP in the AWS Cloud Computing Concepts Hub.

We’ll use an example to illustrate how BGP works. Let’s assume that Alice, a network manager, has been assigned a block of IP addresses from her Regional Internet Registry (RIR); she uses her routers to inform neighboring networks that she is the registered user for this block of IPs. Bob, a network manager of a neighboring network, then “gossips” about the block of IP addresses that Alice shared to his neighboring networks. Then Dan, a network manager of a neighboring network to Bob, gossips about Alice’s block of IP addresses to his neighboring networks and so on. This is how BGP enables information to travel around the world hopping from neighboring network to neighboring network.

Figure 1: Alice’s routers tell Bob’s routers about her addresses.

Figure 2: Bob’s router’s “gossip” about Alice’s addresses.

Figure 3: The information continues to travel around the world.

The problem

BGP has been revolutionary not only for the development of the internet, but also for a number of influential applications in internal networking. However, the original BGP specification left operators of the individual networks responsible to establish their own policies to determine the legitimate users of IP blocks. For example, extending the preceding example regarding Alice’s block of IP addresses: what happens when someone (let’s call him Dan) claims the same block of IP addresses as Alice, even though he isn’t the registered user? Dan may have advertised the block of IPs accidentally or intentionally. However, until recently, much of the neighboring networks comprising the internet didn’t have a great way of determining the legitimate user of IP blocks, resulting in many neighbor networks accepting the advertisement and routing traffic back to Dan. The impact of Dan advertising the wrong block of IPs is that Alice could stop receiving some or all of the traffic intended for her block of IPs. In the 2010s, these types of illegitimate advertisements were becoming a significant enough problem that the Internet Engineering Task Force (IETF) decided to develop strategies to address this issue. Ultimately, they developed RPKI.

Figure 4: Dan makes a typo, before RPKI.

What is RPKI?

RPKI is a way for AS to legitimately announce only their network to receive traffic for their IP addresses. For a deep dive into how RPKI works in practice, see our previous post on how AWS is helping to secure internet routing. In short, extending the example of Alice’s network, Alice can “sign” a document called a Resource Origin Authorization (ROA) and publish the document where all other networks can see it linked from one of a few Certificate Authorities (CA) operated by the same organizations that allocated the IP blocks, the RIRs. Other networks across the world can reference that document to decide whether to believe Dan, or another network, when he advertises the same block of IPs. This has already made a big improvement in the integrity of routing of traffic over the internet. Accidents, such as Dan advertising the same block of IPs as Alice, are rapidly becoming less and less impactful as more and more networks adopt RPKI.

Figure 5: Dan makes a typo, after RPKI. Alice creates a document and places it into the Public RPKI Document Repository.

RPKI greatly reduces the harm that any single network can impart to the collective internet, but there are still cases in which accidental or intentional misuse of RPKI can result in misrouting of traffic. If an unauthorized actor (let’s call them Molly) obtains Alice’s RIR credentials, then Molly can make a document authorizing their network, but sign it with Alice’s signature. Now, Alice’s own, legitimate claim on her address block is rejected, and those addresses no longer receive traffic!

Figure 6: Molly obtains Alice’s RIR credentials.

Routine operator errors can lead to similar results. For example, if Alice makes a typo when creating a document, she might authorize the wrong network to receive traffic to her IP block. Alice could also create authorizations for blocks of IPs that she owns and that don’t precisely match her advertisements. All of the preceding errors lead to legitimate claims being rejected, despite the networks participating in the RPKI consuming the documents and acting on them as intended.

AWS, running one of the most well-connected networks spanning the globe, saw the great benefit of RPKI, but also felt the need to take a “trust but verify” approach. When these types of events have happened in the past, AWS users could still exchange traffic with the affected network, because AWS kept following the affected network’s true intentions. So how did we do it?

The measured approach of AWS when implementing RPKI

AWS takes a measured approach to implementing RPKI. Just as in any other RPKI implementation, we first download all documents from all networks from the public RPKI document repositories. Then, we check all the signatures to determine who is authorized to receive traffic destined for all of the documented IP blocks. When this is complete, we send those authorizations to the devices in our network that decide to accept or reject other networks’ advertisements. But this isn’t the whole story. As we have described earlier, RPKI is a powerful tool that can cause significant impact to internet connectivity. We anticipated the preceding unintended consequences as we were building our RPKI deployment pipeline and added safety checks to our implementation.

Figure 7: The AWS network goes through a four-step process. First, it gets all the documents from the Public RPKI Document Repository. Second, it checks the documents’ signatures. Third, it performs safety checks. Fourth, it sends the documents to the AWS routers.

The following is a list of some of the most impactful safety checks that we incorporate into our RPKI implementation:

1. We predict when a likely unintended impact will happen as a result of rolling out new documents, such as the loss of reachability toward a significant portion of IP blocks behind a network.
2. We send changes to our routers in waves. We pause between waves while observing a variety of health metrics, and roll back if we see any trouble.
3. We safeguard the creation and publication of our own authorizations to make sure that users coming to us from the wider internet are able to stay connected. We have a wide array of guardrails around this pipeline. We always double-check before issuing a document that it doesn’t conflict with any active claim we’re making on the internet. We periodically check that RPKI consumer software exactly reflects our intended authorizations. We verify that our workflows to refresh our authorizations are working by checking the expiry times of our authorizations. These are just a few examples. We’ve invested deeply in this area and will continue to do so.
4. We also built redundancies into our system to address how our documents might be consumed by other networks. Announcing large overlapping blocks of IP addresses and generating documents for each one creates multiple layers of redundancies that would need to fail before any impact occurred.

Protecting users’ internet-facing workloads

RPKI has been a cornerstone of the AWS efforts to protect our users’ internet-facing workloads since we first adopted it in 2019. Furthermore, we only see it becoming more important as its use grows. In 2024, for the first time, more than 50% of the internet is covered by a RPKI ROA (Document), which is an exciting milestone for all participants of the internet. As of May 2025, according to National Institute of Standards and Technology (NIST) this metric now exceeded 55.8%, up from 50.1% in May 2024. We look forward to seeing this trend continue through 2025 and beyond as more and more internet traffic is protected by RPKI.

Looking to the future

Looking to the future, we are also excited about ways in which we can bolster our RPKI implementation, such as through the standardization and implementation of Autonomous System Provider Authorization (ASPA). ASPA will provide a level of path protection by constraining not only which networks are allowed to make a claim on an IP block, but also which networks are allowed to gossip about it. This will help prevent traffic from going through networks that may be unreliable or untrusted.

Although ASPA is still being standardized, we are committed to using it and all tools at our disposal to continue to make the internet a safe and reliable place for everyone. The AWS implementation of RPKI is just one example amongst many other features and services, both internal and external, which demonstrate how we prioritize security on behalf of our users.

Conclusion

In this post we explained the basics of BGP protocol and RPKI. We demonstrated our unique approach to RPKI implementation and the benefits of doing this on behalf of our users. If you have questions about this post, then start a new thread on AWS re:Post, or contact AWS Support.

References:

1. Measured by the number of Border Gateway Protocol (BGP) prefix validations (NIST)

About the authors