IPAM Adds BGP Route Protection and Delegated RPKI: Route Hijack Defence Without the RIR Portal

Executive summary

On 7 August 2026, AWS announced general availability of BGP route protection monitoring and delegated RPKI management in Amazon VPC IPAM, for Bring Your Own IP (BYOIP) prefixes.

It has three layers. Route discovery shows every BYOIP route across accounts and Regions with its ASN, advertisement status and RPKI validity. Route protection findings evaluates each route against published ROA data and flags missing, conflicting or permissive ROAs and overlapping announcements from other ASNs. Delegated RPKI lets you authorise AWS to create and renew Route Origin Authorizations on your behalf after a one-time setup with your registry.

Available in all commercial Regions, but not GovCloud (US) and not the China Regions.

Two constraints decide whether it applies to you. Only route discovery is available on the IPAM Free Tier — findings and delegated RPKI both require the Advanced Tier, and the findings API returns UnsupportedOperation otherwise. And AFRINIC customers get monitoring only; delegated RPKI is not supported for them.

There is also one way to cause an outage with it, covered at the end.

What changed

Some background, because this feature is meaningless without it. When you announce IP space to the internet, nothing inherently proves you are entitled to. RPKI is the system that fixes that, and a Route Origin Authorization is the signed object that does the proving: it says this ASN may announce this prefix, up to this level of specificity. Three attributes — CIDR, ASN, and max-length.

Networks that validate RPKI reject announcements that contradict a published ROA. If you have no ROA, they have nothing to reject, and anyone can announce your space.

Until now, if you brought your own IP space to AWS you created those ROAs by hand at your registry, and renewed them by hand before they expired.

Layer 1: route discovery

IPAM discovers all BYOIP routes across accounts and Regions and shows prefix, locale, advertisement status, ASN, RPKI validity, ROA strength, route overlaps and ROA expiration in one dashboard. Available via get-ipam-discovered-routes.

Layer 2: route protection findings

IPAM evaluates each discovered route against published ROA data and surfaces findings through get-ipam-route-protection-findings. A finding carries RpkiStatus, RpkiStrength, the matching Roas with their MaxLength and Expiration, and any RouteOverlaps with the offending ASN and a detection timestamp.

Layer 3: delegated RPKI

After a one-time delegation with your registry, AWS creates ROAs when you provision a CIDR, renews them before expiry, and can manage ROAs for on-premises prefixes you have not brought to AWS at all. AWS describes the outcome as going from per-prefix registry portal logins to "zero manual ROA operations".

Strict versus permissive

The distinction that matters most, and the one the dashboard reports on:

Why AWS built this

AWS is unusually blunt about the problem in its own documentation: customers "either use their RIR's hosted portal or run open-source tools like Krill to operate their own RPKI certificate authority", and "many customers skip ROA creation entirely or create them once and forget to renew."

That is the real state of affairs. The reasons are structural rather than careless:

• The work happens outside AWS. ROAs live at ARIN, RIPE, APNIC or LACNIC. Nothing in your AWS tooling knows they exist, so they fall outside every review, dashboard and IaC pipeline you have.
• Expiry is silent and undated in your systems. A ROA expires and the prefix quietly stops being protected. Traffic keeps flowing. There is no alarm because nothing you own is tracking it.
• It scales badly. Dozens or hundreds of ROAs, each with its own expiry, across multiple registries if you hold space in several regions.
• Detection needed a third tool. Knowing someone was announcing your space meant subscribing to an external BGP monitoring service.

Bringing ROA state into IPAM — where your address inventory already lives — puts it inside the boundary your team actually looks at.

Architecture

The three layers build on each other, and each works independently. You can start with monitoring, understand your posture, and add delegation later without disrupting existing routes.

The tier boundary is the first design decision

This is where most evaluations will end, so it belongs before anything else:

On the Free Tier you can list your routes and nothing more. get-ipam-route-protection-findings returns an UnsupportedOperation error. So "can I see whether my prefixes are protected?" is an Advanced Tier question, and the answer costs money before you learn anything.

Delegation changes how provisioning works

Once an Internet Registry Association is active, BYOIP provisioning is materially different. You no longer prove ownership with a signed message, because AWS verifies it against the association:

AWS creates strict ROAs matching the pool's locale and ASN. Worth pausing on if you hold a large block: the long-standing manual BYOIP guidance tells you to set max-length to /24 for IPv4 so you can split the block across Regions, which is permissive for anything shorter than a /24. Automatic strict ROAs are the safer default but a different shape from what the manual instructions produce. If you bring a /20 and rely on splitting it, confirm the resulting ROAs match your advertisement plan before you rely on them.

On-premises prefixes get the same treatment

A routing policy registration covers IP space you have not brought to AWS: a prefix plus a list of ASNs, mapping to one ROA per ASN. That makes IPAM a control plane for your whole address estate, not just the part running in AWS — which is a bigger claim than the announcement makes.

Business value

A silent risk becomes a visible one. The honest value is not automation, it is discovery. Most organisations do not know their current RPKI posture. A dashboard showing Valid, Invalid and Unknown across every prefix answers a question most teams cannot answer today.

Expiry stops being a memory test. Auto-renewal removes an entire class of incident whose root cause is "nobody had a calendar reminder from 2023".

One fewer external dependency. Route hijack detection previously meant a third-party monitoring subscription. Overlap detection is now part of the platform holding your address inventory.

Provisioning gets simpler. No X.509 certificate, no RDAP record edit, no signed authorization message, no waiting up to 24 hours for a manually created ROA to propagate before you can advertise.

On-premises space comes along. Routing policy registrations cover prefixes that never touch AWS, which is unusual scope for an AWS feature and worth noting if you are consolidating address management.

Security considerations

This is a hijack-mitigation control, and it is partial by nature. ROAs only help against networks that perform RPKI validation. A validating network rejects an invalid announcement; a non-validating one still accepts it. Adoption is broad but not universal, so a correct ROA reduces the blast radius of a hijack rather than preventing it. Do not present this internally as making hijacking impossible.

Permissive ROAs are the quiet weakness. A permissive ROA is RPKI-valid, so a dashboard that only reported validity would show green. AWS's own framing is precise: with a permissive ROA, an attacker who compromises your ASN credentials can announce more-specific prefixes that are also valid, splitting your traffic. That is why ROA strength is reported separately from validity, and why it is worth looking at.

Delegation is a real trust decision. You are authorising AWS to publish signed objects that assert who may announce your address space. That is appropriate for space you use on AWS. Think harder about it for on-premises prefixes via routing policy registrations, where AWS is not otherwise in the path.

Whoever can call these APIs can change your routing security posture. create-ipam-routing-policy-registration and batch-modify-ipam-routing-policy-registrations alter which ASNs are authorised to announce your prefixes. Scope those permissions to network administration, not to general IPAM read access.

Existing ASN authorisations must survive the change. Long-standing AWS guidance is that when migrating advertisements from on-premises to AWS you create a ROA for your existing ASN before creating ROAs for Amazon's ASNs, or you risk impacting current routing. The same ordering logic applies when handing management to AWS.

AWS reserves the right to stop advertising non-compliant space. Documented plainly in the BYOIP prerequisites: if your ROAs are invalid or non-compliant, Amazon may stop advertising your range. Correct ROAs are an availability dependency, not only a security nicety.

Cost considerations

The cost is the Advanced Tier, and AWS did not publish rates in the announcement. Pricing is on the IPAM tab of the VPC pricing page; verify it for your Region before modelling, because everything except route discovery sits behind that tier.

Model it against what it replaces, not from zero. If you already pay for third-party BGP monitoring, or run your own RPKI certificate authority such as Krill, this consolidates that spend and that operational load. If you do neither today, this is new spend buying visibility you currently do not have — a real benefit, but a different conversation with a budget holder.

The tier is IPAM-wide, not per-prefix. Advanced Tier affects your whole IPAM deployment, so the decision is bigger than route protection and should be taken against everything the tier includes.

Monitoring first is a legitimate way to size the case. AWS explicitly supports starting with discovery and adding delegation later. Route discovery on the Free Tier tells you how many BYOIP prefixes you actually have and where, which is the input to any cost model — even though it will not tell you whether they are protected.

Operational considerations

Setup is a genuine two-party exchange, not a console toggle. You call create-ipam-internet-registry-association, wait for state pending-enable, take the resulting ChildRequestXml to your registry portal, submit the delegation request, then extract RpkiVersion, ServiceUri, ChildHandle, ParentHandle and ParentBpkiTa from the registry's response and pass them to enable-ipam-internet-registry-association. Budget for registry turnaround.

Alarm on ROA expiry even with auto-renewal. IPAM publishes a RoaExpiration metric to the AWS/IPAM namespace, in days remaining, with dimensions Cidr, RoaPrefix, Asn and MaxLength. Alarm when it drops to or below a threshold. Metrics publish to the global IPAM account, so create the alarm in that account and Region.

Batch changes are atomic, single changes are not obviously safe. batch-modify-ipam-routing-policy-registrations succeeds or fails as a unit, with no partial application. A registration change that would invalidate existing routes fails, and --force overrides that check. Treat --force here as the routing equivalent of a force push.

The filter names do not match the returned fields. AWS documents this quirk directly: you filter on account-id but the response returns ResourceOwnerId, and you filter on byoip-cidr-state but the field is State. ROA strength is not filterable at all, so finding permissive ROAs means pulling findings and filtering client-side.

LACNIC works, with a caveat. Delegated RPKI is supported, but automatic CIDR discovery and ROA pre-creation are not available during initial setup, so expect more manual work at the start.

Tradeoffs

Against your registry's hosted portal. The portal is free and you already have it. It gives no cross-account view, no overlap detection, no expiry alarms and no automation. If you hold a handful of prefixes and renew reliably, the portal is sufficient and this is convenience.

Against running your own RPKI CA. Krill and similar give complete control and work regardless of cloud provider. AWS says plainly that if you already run a mature CA with full automation, delegated RPKI duplicates it — though the dashboard may still add central visibility. Do not dismantle a working CA for this.

Against third-party BGP monitoring. Dedicated services generally see more of the global routing table and alert on more than prefix overlap. IPAM's advantage is that it sits next to your address inventory and covers what you own. For a serious hijack-response capability, IPAM is a complement rather than a replacement.

Against doing nothing. Worth stating, because it is the actual status quo for many. Doing nothing is defensible only if your prefixes are not advertised to the internet. If they are, the current arrangement is usually an unmonitored ROA that someone created once.

Implementation guidance

Prerequisites

• An IPAM in the Advanced Tier for anything beyond route discovery.
• One or more BYOIP prefixes provisioned to IPAM pools.
• Access to your registry account: ARIN, RIPE NCC, APNIC or LACNIC. AFRINIC cannot use delegated RPKI.
• A commercial Region. Not available in GovCloud (US) or the China Regions.

Start with what costs nothing

Route discovery works on the Free Tier and answers "what do we actually advertise?" before you spend anything:

aws ec2 get-ipam-discovered-routes \
    --ipam-resource-discovery-id ipam-res-disco-0365d2977fc1672fe \
    --resource-region us-west-2

Then find what is unprotected

On the Advanced Tier, go straight to the prefixes with no ROA or a broken one:

aws ec2 get-ipam-route-protection-findings \
    --ipam-id ipam-0a1b2c3d4e5f6g7h8 \
    --filters "Name=rpki-status,Values=invalid,unknown"

A finding tells you what you need in one object — status, strength, the ROA's max-length and expiry, and any overlapping announcement:

"RpkiStatus": "valid",
"RpkiStrength": "strict",
"Roas": [
    { "Asn": "64512", "Prefix": "203.0.113.0/24",
      "MaxLength": 24, "Match": true,
      "Expiration": "2027-06-15T00:00:00Z" }
],
"RouteOverlaps": [
    { "Prefix": "203.0.113.128/25", "Asn": "64513",
      "DetectedAt": "2026-03-10T15:45:00+00:00" }
]

That RouteOverlaps entry is the shape of a sub-prefix hijack: a longer prefix inside yours, announced by an ASN that is not you.

Alarm on expiry regardless

aws cloudwatch put-metric-alarm --region us-east-1 \
    --alarm-name "IPAM-RoaExpiration-203.0.113.0-24" \
    --namespace "AWS/IPAM" \
    --metric-name RoaExpiration \
    --dimensions Name=Cidr,Value=203.0.113.0/24 Name=RoaPrefix,Value=203.0.113.0/24 \
                 Name=Asn,Value=64512 Name=MaxLength,Value=24 \
    --statistic Minimum --period 86400 --evaluation-periods 1 \
    --threshold 30 --comparison-operator LessThanOrEqualToThreshold \
    --treat-missing-data notBreaching \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:roa-expiry-notifications

All four dimensions are required to target a single ROA.

Best practices

1. Run route discovery first. It is free and it tells you the size of the problem before you commit to a tier.
2. Prefer strict ROAs unless you have a specific traffic-engineering reason for permissive. AWS recommends strict as the default.
3. Treat permissive as a finding, not a setting. Validity alone will look green.
4. Alarm on RoaExpiration even with auto-renewal. Automation that silently stops is worse than no automation.
5. Create a ROA for your existing ASN before adding Amazon's when migrating advertisements, per long-standing BYOIP guidance.
6. Check the deltas before batch changes and treat --force as a last resort.
7. Filter findings client-side for ROA strength — the API cannot filter on it.
8. Verify the ROAs delegation creates for large blocks match how you actually advertise, since automatic ROAs are strict.

Who should adopt, who should wait

Adopt

• Anyone with BYOIP prefixes advertised to the internet who cannot currently state their RPKI posture. Start with free route discovery today.
• Organisations with ROAs across multiple registries and no central expiry tracking.
• Teams paying for third-party BGP monitoring whose main use is watching their own prefixes.
• Anyone who has skipped ROA creation because the registry process was too manual to sustain.
• Teams wanting on-premises prefixes managed alongside AWS space.

Wait

• AFRINIC members. Monitoring and findings only; delegated RPKI is not supported.
• GovCloud (US) and China Region workloads. Not available.
• Teams on the Free Tier who cannot justify Advanced Tier — you will see routes and learn nothing about their protection.
• Organisations already running a mature RPKI CA with automation and monitoring. AWS says this would duplicate it.
• Anyone whose BYOIP space is not advertised to the internet. No BGP announcement means no hijack risk, and AWS says so directly.
• Teams using only AWS-owned IP space. AWS already manages those ROAs.

Two constraints and one way to cause an outage

This matters because the announcement reads as a monitoring feature, and monitoring sounds like something you enable and look at. The part that tells you anything is paid, and the tier applies to your whole IPAM deployment.

If your address space is registered in Africa, the automation half of this launch is unavailable, and no amount of configuration changes that. Worth checking before building a plan around it.

This is the one that turns a tidy-up into an incident. Removing the association strips the ROAs, the prefixes fall to RPKI status Unknown, and validating networks lose any basis to distinguish your announcement from someone else's. Traffic does not stop — which is exactly why it will not be noticed. The prefixes simply become unprotected, and stay that way until somebody looks.

Handle disassociation as a change with a rollback plan: create replacement ROAs at the registry first, confirm they have propagated, and only then remove the association. AWS notes elsewhere that a manually created ROA can take up to 24 hours to become visible, so this is not a same-hour operation.

Key takeaways

1. Three independent layers: route discovery, route protection findings, and delegated RPKI. You can adopt them in order.
2. Only route discovery is on the Free Tier. Findings and delegation require the Advanced Tier, which applies IPAM-wide.
3. AFRINIC cannot use delegated RPKI. LACNIC can, without automatic CIDR discovery or ROA pre-creation during setup.
4. Commercial Regions only — not GovCloud (US), not China.
5. Strict ROAs are the recommended default; permissive ROAs stay RPKI-valid while allowing sub-prefix announcements.
6. With delegation, provisioning uses Message="CoveredByInternetRegistryAssociation" with an empty signature and no WHOIS or DNS validation, and ROAs are created strict.
7. Routing policy registrations extend ROA management to on-premises prefixes never brought to AWS.
8. Alarm on the RoaExpiration metric in AWS/IPAM, in the global IPAM account, with all four dimensions specified.
9. Deleting an Internet Registry Association deletes its ROAs. Arrange replacement coverage first.
10. Pricing was not published in the announcement. Check the IPAM tab on the VPC pricing page.

Official AWS references

• Amazon VPC IPAM now supports BGP route protection monitoring
• What is IPAM? — AWS removed its BGP route protection and delegated RPKI pages from this guide after publication; the announcement above is now the only first-party description of the feature
• Tutorial: Bring your IP addresses to IPAM
• Prerequisites for BYOIP in Amazon EC2
• Bring your own IP addresses (BYOIP) to Amazon EC2
• Monitor IPAM with Amazon CloudWatch
• get-ipam-route-protection-findings, AWS CLI Reference
• create-ipam-internet-registry-association, AWS CLI Reference
• Amazon VPC pricing (IPAM tab)
• How AWS is helping to secure internet routing