
Private Anycast Network Provider: Who Holds the ASN, the IP Blocks, and the Exit Terms
A private Anycast network is only yours if the registry records say so. What a provider quote must state about ASN and IP-block registration, route objects, hardware, and leaving.
The short answer
A private Anycast network is private only if the records say so. Before you compare providers on price or number of locations, ask who the registry shows as the holder of the ASN and the address blocks, who can issue or withdraw the authorisations that let those blocks be announced, whose name is on the hardware and hosting contracts, and what leaving looks like in writing. A provider can build an excellent network and still leave you more dependent than the CDN you were trying to get away from, if those four answers point at the provider.
Who this is for
This is for the CTO, Head of Infrastructure, or procurement lead at a casino, crypto exchange, or regulated fintech who has already decided that owning the edge is worth considering and is now comparing a build partner against doing it in-house. It is about the contract and the records. For whether owning an edge makes sense at all, read building a private Anycast edge from scratch; this article does not argue that case again.
Why the quote needs to cover ownership
The reason to run a private edge is usually to stop depending on someone else's account, jurisdiction, or terms of service. A provider-built network can quietly reintroduce exactly that dependency one layer down: the ASN is registered to the provider, the address space is leased, the transit contracts are the provider's, and the configuration lives in the provider's tooling. Day to day, nothing looks different. The difference appears the day the relationship ends or the provider has its own problem.
So the questions below are not about distrust. They are the same diligence you would apply to any critical supplier whose failure takes your platform down.
The five things to pin down
1. The registry record for the ASN
An autonomous system number is issued through a regional internet registry, and the registry database shows a holder. Some providers register ASNs in their own name, or through a sponsoring organisation, and operate them on a customer's behalf. That can be a legitimate arrangement, but it should be a choice you made knowingly.
Ask for:
- The holder organisation that will appear in the registry, and that it is your legal entity or a holding entity you control.
- If a sponsoring organisation is involved, who it is, what your contract with it is, and what happens to the ASN if that sponsor stops.
- Who holds the administrative and technical contacts, since those contacts can change records.
2. The registry record for the IP blocks
Address space can be assigned to you, or only leased from a provider for as long as you are a customer. Leased space leaves with the provider. If your allow-lists, payment-processor whitelists, and regulator filings all contain those addresses, renumbering at exit is a project of its own.
Ask whether the blocks are registered to you, how they were obtained, and whether the provider holds any right to reclaim them. If an address block is obtained from a broker or transferred, ask for the transfer record.
3. Who controls the announcement
Announcing a block from several locations needs authorisations: the LOA that lets a network announce your space, and the route objects and cryptographic route-origin records that tell the rest of the internet your announcement is legitimate. Whoever can create, change, or revoke these controls whether your edge is reachable.
| Question | Why it matters |
|---|---|
| Who can issue and revoke the LOA? | Whoever can revoke it can take the announcement down |
| Whose account holds the route objects and origin records? | Changes should require you, not only the provider |
| Is there a second authorised person on your side? | A single contact is a single point of failure |
| How are changes approved and logged? | An unlogged change is an outage you cannot reconstruct |
The RPKI and route-object work is also your defence against a hijack of your own prefixes, which is covered in private Anycast for Web3 infrastructure. The point here is narrower: ownership of those records is part of ownership of the network.
4. Hardware, hosting, and transit
A private network sits on real contracts: rack space at each location, transit and peering, and the devices that run BGP. Ask whose name each is in. Contracts in your name survive a change of builder; contracts in the provider's name are part of what the provider is selling you, and the quote should price them honestly. If the provider supplies the hardware, say whether you can buy it, and at what price, when you leave.
5. Exit and handover
An exit clause is where an ownership claim is tested. The quote should state:
- That the registry records and authorisations stay with you and the provider's rights end on your written instruction.
- What is handed over: configurations, health-check logic, runbooks, diagrams, monitoring definitions, in a form your team can read and use.
- How a transition to another operator is run, using the same overlapping-announcement approach described in migrating a live casino to private Anycast without downtime.
- What the provider charges for exit assistance, and for how long it is obliged to provide it.
A provider that has thought about this will have a handover document. One that has not will describe goodwill.
Operations: what "managed" is carrying
Many buyers take a build plus an ongoing operating arrangement. That is reasonable, since running the network is where the continuing effort lies. The quote should separate the two so you can see what you are paying for each month: who watches BGP sessions around the clock, who is paged, what the response expectation is for a session loss or a hijack attempt, how capacity reviews are scheduled, and when hardware is replaced. If the operating service ends, the network must keep working on your records and your contracts; an arrangement that only works while the provider is operating it is a service dependency, not ownership.
Questions worth asking on the first call
- Show us the registry record for the ASN and the address blocks you will use for us.
- If we leave in two years, which of these records change and which do not?
- Who can revoke the authorisation letter, and how would we know it had happened?
- Which contracts at each location are in our name?
- What do we receive on exit, and what does the exit assistance cost?
What this does not cover
Ownership paperwork does not make a network resilient. Redundant locations, sensible health checks, and tested failover do, and a badly designed private edge can fail by its own hand, as set out in when your own health checks take you fully offline. Registries also differ in their rules and procedures; take advice from the relevant registry or counsel for the specifics of your holding structure.
Limitations
This is a buyer's checklist for reading a quote. It does not describe the rules of any particular registry, does not give legal advice on holding structures, and ranks no provider. It cites no statistics and no AnySec-original figures; pricing for our own engagement is on the service page.
What to do next
Lay each quote you hold against the five items above and mark what is unstated or points at the provider. To see how an engagement is scoped and what you receive at handover, read the Private Anycast Network page; to have a draft scope reviewed, request a network design review and attach the ownership questions you want answered.
Frequently asked questions
What is a private Anycast network? An edge you announce yourself, with your own ASN, address blocks, and BGP sessions at several locations, so the network identity belongs to you and not to a vendor's account.
How do I check who actually holds my ASN and IP blocks? Read the holder field in the public database of the regional internet registry that issued them. Ask for the record itself, not a description of it.
What is a letter of authorization in a private Anycast build? The document by which an address holder authorises a network to announce a block. Whoever can issue or withdraw it controls whether the network stays up.
What should happen to the network if we stop using the provider? The registry records stay with you, the provider's authorisations are withdrawn on your instruction, and configuration and runbooks are handed over in usable form. The quote should say so.
Is it cheaper to run a private Anycast network than to use a CDN? Sometimes, at scale, but only if the comparison includes operations, hardware refresh, and incident handling over the period you would keep it.
Sources and review
This article describes ownership and contract terms in general terms and cites no external statistics and no AnySec-original numbers, case results, or SLA figures. Author: AnySec Engineering. Published 2026-10-07; last reviewed 2026-10-07.
Related reading
- Building a private Anycast edge from scratch — whether to own an edge at all, which this article assumes.
- Migrating a live casino to private Anycast without downtime — the overlapping-announcement method a clean handover relies on.
- Private Anycast for Web3 infrastructure: the BGP hijack DDoS protection misses — why route-origin records are part of owning the network.
- Private Anycast for a digital bank: when a single CDN becomes a DORA concentration risk — the regulatory substitutability question behind an exit clause.
Keep reading
All insights →Rather not learn this in production.
Talk to the engineers behind these write-ups — no sales script, a straight read on where you stand.
Get a fixed quote
