Most cloud users do not want to think about BGP. That is fair. You should not need to understand global routing to deploy an app.
But the cloud still sits on the internet, and the internet is held together by networks announcing which IP prefixes they can reach. When those announcements are wrong, traffic can disappear, detour, or land somewhere it should not.
That is why routing hygiene matters.
What MANRS is
MANRS stands for Mutually Agreed Norms for Routing Security. It is a set of operational practices for networks that want to reduce routing incidents and abuse.
For a cloud provider, the relevant ideas are simple:
- Do not announce prefixes you should not announce.
- Filter customers so they cannot accidentally or maliciously leak routes.
- Keep routing contact and policy data accurate.
- Support routing security mechanisms like RPKI.
Route filtering
Route filtering is the boring control that prevents exciting outages.
If a customer brings their own IP space, the provider should not blindly accept any route they send. The provider should validate that the customer is allowed to originate that prefix and that the route matches the agreed policy.
Without filtering, one bad configuration can leak routes to the wider internet.
RPKI
RPKI lets networks publish signed statements about which ASNs are allowed to originate which prefixes.
It is not a complete security system, but it gives other networks a way to reject obviously invalid announcements. For cloud users, that means better odds that traffic reaches the right place and fewer avoidable reachability problems.
PeeringDB
PeeringDB is where networks publish practical interconnection information: ASN, policy, contact details, exchange presence, and peering preferences.
This matters during normal operations and during incidents. If someone needs to reach your network operator quickly because a route looks wrong, stale contact data turns a fixable incident into a longer outage.
BYOIP and customer impact
Bring-your-own-IP makes routing hygiene visible to customers. If you bring a prefix to a cloud, you care that:
- The cloud only announces what you authorized.
- The route is filtered correctly.
- Abuse contacts are current.
- The prefix has the right IRR/RPKI state.
- Incidents have a real operator path.
That is not marketing polish. It is the plumbing that keeps your addresses reachable.
Why this belongs in cloud docs
Cloud providers like to talk about regions, instance types, and storage. The network layer is easier to hide until it breaks.
MANRS is a useful shorthand for a provider taking that layer seriously. It does not mean incidents are impossible. It means the provider has committed to the practices that make routing failures less likely and easier to contain.