The Route Nobody Signed: What AWS's New RPKI Automation Actually Fixes

On 24 April 2018, at 11:05 UTC, a small Ohio hosting provider announced five prefixes on the public internet that it had no right to originate: 205.251.192.0/24, .193.0/24, .195.0/24, .197.0/24, and .199.0/24, the address block Amazon uses for Route 53’s authoritative DNS servers. Doug Madory, then of Oracle’s Internet Intelligence team, documented the hijack in detail: only around 15% of the internet’s BGP sources accepted the forged announcements from AS10297, but that fifteen percent happened to include Google’s public DNS resolver. For roughly two hours, anyone whose DNS resolution touched a network that believed the fake route got silently redirected off myetherwallet.com to a server in Russia running an impostor certificate. Enough people clicked through the browser’s certificate warning that real Ethereum changed hands. Nobody breached AWS, and nobody broke TLS. A network in Columbus, Ohio simply announced someone else’s address space, and for two hours a meaningful slice of the internet had no way to tell that it was lying.

That is the specific failure mode Resource Public Key Infrastructure exists to close. RFC 6480, which formalised RPKI in February 2012, lets the holder of a prefix publish a cryptographically signed attestation — a Route Origin Authorization, or ROA — naming exactly which autonomous system may originate it. A network that validates ROAs can reject an unauthorised announcement mechanically, the way a validating resolver in 2018 could have rejected AS10297’s announcement of Amazon’s own DNS space if the tooling and the habit had both been in place. The Internet Society’s own read on the incident named the general fix without singling out RPKI specifically — “if all the operators along the path had implemented the MANRS actions… this Ethereum BGP hijack would not have propagated” — but MANRS’s own Global Validation action names RPKI explicitly as one of its tools. Eight years on, the cryptography was never the hard part. Running it, at fleet scale, was.

The problem: an unsigned prefix looks exactly like a stolen one

Every prefix an AWS customer brings to the platform under Bring Your Own IP starts, by default, with no RPKI coverage at all. AWS’s own documentation is direct about what that means in practice: a prefix with no ROA carries RPKI status Unknown, and “any ASN can announce your prefix or a more-specific prefix, and validating networks have no basis to reject it” — precisely the gap AS10297 walked through in 2018. A ROA closes that gap only if it stays current and only if it’s tight enough to matter. An expired ROA degrades silently from Valid back to Unknown — “traffic continues flowing, but the prefix is no longer protected,” with nothing in the data plane to flag the change. And a permissive ROA, one whose max-length attribute is wider than the prefix itself, authorises the origin ASN to announce more-specific subnets too; compromise that ASN’s credentials and an attacker can carve out a sub-prefix that is still, technically, RPKI-valid. None of these failure states look different from a healthy prefix until something is actively watching for them — without route monitoring, AWS notes, “you don’t know until customers report connectivity issues, which can take hours or days.”

The challenge: RPKI’s ergonomics were built for occasional use, not fleets

Publishing a correct ROA has never been the hard problem; maintaining hundreds of them across a real cloud footprint is. Before this launch, an AWS customer with BYOIP prefixes managed RPKI the way most of the industry still does: log into each Regional Internet Registry’s own portal — ARIN, RIPE NCC, APNIC, or LACNIC — per prefix, prove ownership through WHOIS or a DNS TXT record, create the ROA by hand, and track its expiry against a renewal date that lives nowhere but a spreadsheet or a calendar reminder. The alternative is running an open-source RPKI certificate authority such as Krill to self-host the whole lifecycle, which trades manual clicking for a piece of infrastructure that itself needs operating. AWS states the predictable outcome plainly: “many customers skip ROA creation entirely or create them once and forget to renew.” A control that only works when nobody forgets is a control that will eventually fail; it was only ever a matter of which prefix, and which Thursday.

The solution: AWS takes over the RIR relationship, not just the dashboard

AWS’s answer, announced 7 August 2026, builds on VPC IPAM in three layers that can be adopted independently. Route discovery finds every BYOIP route across every account and Region IPAM has visibility into and lists prefix, ASN, advertisement status, and locale — available through the get-ipam-discovered-routes API on IPAM’s Free Tier, no RIR contact required. Route protection findings, gated behind the Advanced Tier, evaluate each discovered route against published ROA data and add RPKI validity, ROA strength, and route overlap detection — Free Tier customers calling the equivalent findings API get an UnsupportedOperation error instead. The third layer, delegated RPKI, is where AWS stops just watching and starts acting: authorise it once, and IPAM creates ROAs automatically whenever you provision a BYOIP prefix, renews them before they expire, and can manage Route Origin Authorizations for address space you haven’t even brought to AWS.

The one-time authorisation is a real handshake with the registry, not a checkbox. AWS’s own tutorial walks through it at the API level: create-ipam-internet-registry-association generates a ChildRequestXml payload that you take to your RIR’s own portal; the RIR’s parent response hands back a RpkiVersion, ServiceUri, ChildHandle, ParentHandle, and ParentBpkiTa, which feed into enable-ipam-internet-registry-association to complete the trust relationship. From that point on, provisioning changes shape: the --cidr-authorization-context flag that BYOIP has always required stays in the command, but its signed-message content collapses to Message="CoveredByInternetRegistryAssociation",Signature="" — AWS verifies ownership against the association instead of a signature you generated yourself, and creates a strict ROA matching the pool’s ASN and locale with no separate ROA step at all.

The strict/permissive distinction is worth sitting with, because it’s where most of the actual protection lives. A ROA carries three fields — CIDR, ASN, and max-length — and max-length decides how much protection you actually bought. AWS’s own tutorial example makes this concrete with the standard RFC 5737 documentation prefix 203.0.113.0/24 and private-use ASN 64512 — reserved, along with the rest of 64512–65534, by RFC 6996: a strict ROA sets max-length to /24, matching the prefix exactly, so only that exact announcement from AS 64512 is RPKI-valid — anything more specific, from any ASN, is invalid on sight. In the same worked example, a second ASN, 64513, announces 203.0.113.128/25 — a sub-prefix nobody authorised. Because the ROA is strict, IPAM’s route protection findings surface it immediately as a route overlap, in the same API response that confirms 203.0.113.0/24 itself is Valid and strict. That is, mechanically, a live hijack detection: the exact shape of what happened to Amazon’s own DNS prefix in 2018, caught by evaluation rather than by a customer noticing their site was serving the wrong content two hours later.

Delegated RPKI doesn’t cover every registry equally, and the gaps are worth knowing before you plan around it. AFRINIC supports route discovery and findings only — no delegated RPKI. LACNIC supports delegation, but automatic CIDR discovery and ROA pre-creation aren’t available during initial setup. And for address space you’re not routing through AWS at all — on-premises prefixes under the same organisational umbrella — a routing policy registration (RPR) lets IPAM manage ROAs for them anyway, as a CIDR-to-ASN-list mapping applied through the same delegated association, with atomic batch updates so a multi-prefix change can’t land half-finished. AWS also publishes a RoaExpiration CloudWatch metric per BYOIP route, in days-remaining terms, specifically so “forgot to renew” — the exact failure mode AWS’s own documentation calls out — can trip a CloudWatch alarm instead of a hijack.

The footprint

None of this changes what BGP fundamentally is: still a trust-based protocol between autonomous systems, still capable of accepting a bad announcement from anyone willing to make one. What changes is who has to notice first. Before this launch, a BYOIP customer’s RPKI posture was whatever they remembered to do at four different registries, checked whenever someone thought to check. After it, a strict ROA and continuous overlap monitoring are a documented, API-callable default — you can see your entire fleet’s RPKI status without touching an RIR portal at all, and delegate the RIR relationship itself the moment the manual version stops being worth keeping. Start with monitoring; it costs nothing, needs no registry contact, and is the only way to know whether “we have ROAs” is actually true for every prefix or a belief about the ones someone remembers setting up. Delegate only when you’re ready to depend on it — disassociating an Internet Registry Association removes every AWS-managed ROA under it in one action, the same discipline you’d apply before deleting any other single point of cryptographic trust.

And remember what this doesn’t fix. Amazon’s own prefixes were the ones hijacked in 2018, and it made no difference that Amazon runs credible infrastructure, because the networks in the hijack’s path weren’t validating ROAs against anyone’s announcements, authorised or not. RPKI-signing your own prefix protects it only on networks that bother to check — a floor this launch raises considerably for AWS BYOIP customers, without being able to raise it for the rest of the internet along with them. Sign the prefix anyway. Fifteen percent of the internet was still enough to redirect a wallet in 2018; a validating network with nothing to check against would have waved the hijack straight through regardless.