A Lagos payments company preparing to move more of its merchant-risk system into public cloud does not begin with a seminar on internet governance. It begins with a migration spreadsheet. The core API already serves banks, wallets, card processors and thousands of small merchants. Partner banks keep allowlists. Fraud vendors recognise existing endpoints. A few public-sector and enterprise customers still have firewall rules approved in an earlier procurement cycle. The board wants better resilience and cleaner disaster recovery. The network decision looks routine: take public IPv4 addresses from the cloud provider, bring the company's own addresses into the platform, or push more services behind private networks and NAT while leaving only a few public endpoints.
Those choices are not merely technical. Provider-supplied public IPv4 is quick, well integrated and billed like the rest of the platform. It can attach to virtual machines, load balancers, gateways and managed services without forcing the company to find a broker or update a registry file first. It also ties public identity to the provider's inventory, account controls and future terms. Bring-your-own-IP, usually called BYOIP, preserves more continuity for the customer, but it demands proof: control of the prefix, coherent registration data, authorised routing, usable reverse DNS, acceptable reputation and no dangerous overlap with another announcement. NAT reduces the visible public-address count, but shifts cost into gateways, logging, traceability, port management and customer assurance. Scarce portable IPv4, whether held, leased or acquired, is the most independent option only when banks, auditors, cloud platforms and network operators trust the record behind it.
The spreadsheet becomes a bargaining map. If the fintech uses cloud-provider addresses, it buys speed and accepts some future exit cost. If it brings its own space, it protects customer continuity but must pass a cloud admission process where registry evidence matters. If it relies heavily on NAT, it conserves public addresses while making the remaining public endpoints more important. If it tries to use AFRINIC-administered space, it has to explain not only routing and price, but whether the African registry layer is stable enough for third parties to treat the address plan as bankable.
That is the economics of cloud-provider address power. Public cloud has turned IPv4 scarcity from a background constraint into an industrial input that is priced, monitored, rationed, validated and packaged into accounts. Large platforms hold or control large public IPv4 inventories. They operate IP address management systems, impose quotas, run reputation controls, validate customer-owned prefixes, advertise approved space from global backbones and offer provider-owned addresses as the simplest path. The result is not crude monopoly. It is optionality. A provider can give a customer a choice between platform-owned convenience and customer-owned diligence. If independent address records are trusted, the customer has leverage. If they are not, the platform's own inventory becomes more valuable.
AFRINIC sits inside this problem because it is the Regional Internet Registry for Africa and parts of the Indian Ocean. Its public materials describe a registry for IPv4, IPv6 and autonomous system numbers, with WHOIS, RDAP, reverse DNS, Internet Routing Registry and RPKI services. In a cloud migration file, those services become evidence. A BYOIP request, a route-origin authorisation, a reverse-DNS plan, an abuse-contact record and a letter of authorisation all rely on the same institutional premise: the registry record can be read as a neutral, current and predictable statement of recognition.
AFRINIC also brings difficult context. The region entered IPv4 Soft Landing Phase 2 in January 2020, with the official exhaustion framework limiting ordinary allocation scale. Public reporting since 2019 has described alleged address-record manipulation, the high-value Cloud Innovation dispute, legal conflict over registry authority and resource review, receivership under the Supreme Court of Mauritius, years of impaired board legitimacy, an annulled 2025 election process, subsequent board-recovery efforts and continuing legal and ICANN attention in 2026. Those facts do not prove that every AFRINIC-administered prefix is risky. They explain why cautious counterparties ask extra questions.
The central question is narrow. AFRINIC does not regulate AWS, Azure, Google Cloud or any other platform. Its economic role is simpler and more important: keep African-administered address records reliable enough that African operators and cloud customers are not pushed into platform-owned addresses merely because independent or leased AFRINIC space carries an avoidable registry-risk premium. Neutral record continuity lowers lock-in. Discretionary gatekeeping raises it.
Cloud made IPv4 scarcity visible as an invoice line
Public IPv4 used to hide inside connectivity. A business bought internet access, hosting or a server, and an address appeared as part of the service. Its scarcity was real, but the price was often bundled. Cloud has unbundled enough of the stack to make the address visible. A public IPv4 address is now a line item, a quota object, an idle-resource warning, an architecture review topic and a migration risk.
The large cloud providers are explicit about this. AWS's VPC pricing page treats public IPv4 addresses associated with AWS resources, and idle public IPv4 addresses in an account, as billable at $0.005 per hour. It also says BYOIP and customer-owned IP addresses in the relevant feature path are not charged as AWS public IPv4 addresses. The same page describes IP Address Manager, or IPAM, with a free tier that includes BYOIP v4 and v6 management and Public IP Insights, and an advanced tier that charges active IP addresses. Google Cloud's network pricing charges for external IPv4 addresses and lists in-use static and ephemeral public IPs on standard VM instances at $0.005 per hour, with unused reserved static addresses at $0.01 per hour. Google separately says BYOIP addresses brought by a customer are available only to that customer and have no idle or in-use IP address charge. Azure's custom IP prefix documentation says there is no charge to provision or use custom IP prefixes or the public IPs derived from them, although normal traffic charges still apply.
Those pages should be read as market exhibits, not as moral declarations. They show that cloud providers treat public IPv4 as scarce inventory that must be priced, monitored and governed. An idle address is no longer merely untidy; it is billable or visible to an IP-management tool. A customer's own prefix is not accepted on trust; it is placed behind validation, provisioning and advertising rules. A network architect now asks whether each public endpoint is worth the cost, whether private connectivity can replace exposure, whether a NAT design merely shifts the problem, and whether a customer-owned prefix should be brought into the platform.
This is a change in institutional economics. Pricing makes scarcity legible to finance teams. IPAM makes address use legible to operations teams. BYOIP makes ownership and registry evidence legible to cloud onboarding teams. Public-IP charges make engineers treat address allocation as architecture rather than habit. Once those controls exist, the provider's address inventory becomes a strategic asset. It lets the platform say: reachable IPv4 is available now, but the address identity belongs to our account system unless you pass the tests required to bring your own.
The price per address may look small next to compute, storage or data-transfer bills. That is not the whole signal. The real cost emerges when addresses become attached to customers, partners and reputation. A public endpoint that appears cheap at launch can become expensive to move. A static address that sits in a bank allowlist, a fraud engine, a payment callback, a public-sector firewall or an email-reputation system acquires switching cost.
Cloud has therefore made two kinds of scarcity visible. The first is numerical: there are not enough IPv4 addresses to treat them as free decoration. The second is institutional: there are not enough trusted, portable, reputation-clean, registry-backed address identities to make every customer independent of platform inventory. The cloud provider can manage the first with pricing and architecture. The customer needs the registry layer to solve the second.
AFRINIC's relevance begins there. In a post-exhaustion region, a clean AFRINIC-recognised prefix is not only a routing resource. It is a possible alternative to platform-owned public identity. If the record behind it is trusted, the cloud customer can weigh provider addresses against BYOIP on ordinary commercial terms. If the record is uncertain, the provider's inventory becomes the safer default, even when the customer would prefer portability.
The platform address is a convenience with an exit price
The attraction of provider-supplied addresses is real. A customer can create a virtual machine, load balancer, VPN tunnel or managed endpoint and receive a public IPv4 address without finding a broker, negotiating a lease, buying a prefix, updating a registry object or writing a route-origin plan. The platform absorbs routing complexity. It holds large inventories, advertises from its backbone, handles cloud-side address assignment, integrates addresses into monitoring and billing, and can often replace a failed resource faster than a customer can update its own network.
For a startup or a public agency under deadline, that convenience is valuable. The Lagos payments company can launch a new API in a South African cloud region, place it behind managed load balancing, use provider security services, and meet a deployment milestone. The bank's procurement team sees a major platform. The engineering team sees fewer moving parts. The finance team sees a monthly bill rather than an address-market transaction. The regulator sees a named cloud supplier. The board sees operational speed.
The exit price is less visible. The public IP address becomes part of the customer's operating surface. Partners hard-code it into allowlists. Security vendors treat it as a signal. Merchant callbacks use it. Incident responders search logs by it. Fraud systems learn its behaviour. Reverse DNS may be configured around it. Geolocation corrections may be filed for it. Customers may document it in their own change-control records. Over time, the provider address becomes a piece of business continuity.
Leaving the platform, or even moving a service between accounts, regions or architectures, then requires more than redeploying code. It requires partner communication, firewall changes, allowlist updates, testing windows, new reverse-DNS arrangements, reputation warm-up, certificate and endpoint review, customer notices and sometimes regulatory explanation. The address was easy to start using because the platform controlled it. It becomes hard to leave for the same reason.
Bundled identity is part of the product. A provider that can supply clean public IPv4 from its own pool is reducing customer friction. The economic issue is that this friction reduction becomes bargaining power when customer-owned alternatives are uncertain. The platform does not need to block BYOIP to gain leverage. It only needs the customer's independent path to look slower, riskier or less bankable.
NAT and private addressing change the shape of the power rather than eliminating it. They reduce the number of public endpoints, but they concentrate public identity into fewer choke points. A few egress addresses become critical for partner allowlists, logging and incident review. If those addresses are platform-owned, the dependency is concentrated. If they are customer-owned, the customer needs registry-backed authority to carry them into the platform and back out again.
This is why a cloud-address decision is made early but priced late. At the beginning, provider-owned public addresses look like convenience. After two years, they may be embedded in partner contracts, compliance files and disaster-recovery plans. The customer may still be free to leave in theory, but the cost of changing public identity becomes a private toll. Large customers can manage that toll through dedicated teams and staged migrations. Smaller African fintechs, SaaS platforms, health systems, universities and public-service platforms often cannot.
Portable IPv4 is the counterweight. If a customer can use its own recognised prefix across a cloud platform, another cloud platform, an on-premises site, regional hosting and a disaster-recovery environment, public identity becomes less dependent on one provider. The customer still buys compute, storage, security and network services from cloud platforms. It does not rent its entire public address identity from them. That difference is the economic value of portability.
But portability is not self-executing. It depends on the evidence chain behind the address. The prefix must be recognised. The holder or authorised user must be legible. Route-origin authorisation must align. Reverse DNS and abuse contacts must be manageable. The cloud provider must be willing to accept the prefix into its system. If AFRINIC's record layer is seen as uncertain or discretionary, the customer-owned option loses some of its advantage. The convenience of the platform address becomes stronger not because the platform improved, but because the alternative became institutionally weaker.
BYOIP turns registry records into cloud admission evidence
BYOIP is the clearest proof that registry records have become cloud admission evidence. It is also the most useful discipline for thinking about AFRINIC's role. A cloud provider does not let a customer announce any prefix through a global backbone merely because the customer asks. The provider must protect its network, other customers, routing reputation and relationships with peers. It therefore asks for evidence that the prefix is controlled by the customer, that the route advertisement is authorised, that the block is large enough and clean enough for internet routing, and that the provider's announcement will not overlap dangerously with another origin.
AWS's EC2 BYOIP documentation defines RDAP records as registration data queried at a Regional Internet Registry and describes route-origin authorisation as an object created by RIRs for customers to authenticate IP advertisement in particular autonomous systems. Its current EC2 page says a range must be registered with a RIR, must be registered to a business or institutional entity rather than an individual person, and that the most specific IPv4 range a customer can bring is /24. The same page's RDAP certificate path currently lists ARIN, RIPE NCC and APNIC; a separate Amazon VPC IPAM path can verify domain control with a DNS TXT record regardless of whether the registry supports RDAP. That is product-documentation scope, not a universal AWS rule. The economic point is narrower: AWS asks for verifiable registry-linked control before it advertises customer space.
Azure's custom IP prefix documentation makes the same relationship visible in another form. It describes validation, provisioning and commissioning. It says customers can retain their IP ranges to preserve established reputation and continue passing externally controlled allowlists. It requires ownership and registration verification, and authorisation for Microsoft to advertise the range. Its default IPv4 limits for unified custom prefixes include /21 to /24. Reverse DNS for custom prefixes requires customer-owned reverse zones rather than Azure-owned zones. Custom prefixes themselves are not charged, although traffic is, and prefix movement is constrained by product rules. These details are not side notes. They show that BYOIP is a controlled admission process shaped by address reputation, routing proof, prefix size, reverse-DNS responsibility and cloud-side boundaries.
Google Cloud's BYOIP documentation states that a customer can provision and use its own public IP addresses for Google Cloud resources, that imported addresses are available only to the customer who brought them, and that there are no idle or in-use IP address charges for those brought addresses. It also warns against overlapping BYOIP route announcements because overlapping advertisements can cause unexpected routing and packet loss. Its external-access prefix validation uses ROA and reverse-DNS checks before the imported prefix is assigned into Google Cloud's project and scope structures.
Across the providers, the pattern is consistent even where product details differ. The cloud platform translates external address authority into platform policy. Registry record, route-origin evidence, prefix size, reputation, reverse DNS, account association, regional or global scope and advertisement timing are all converted into cloud objects. The customer may own or control the address outside the cloud, but inside the cloud the address becomes a managed resource subject to platform rules.
That conversion is not sinister. It is necessary. A provider advertising a customer's prefix creates risk for the provider and the internet. It must avoid hijack, overlap, abuse, reputation leakage and customer confusion. The danger appears when the external evidence layer is unreliable. If the registry record is ambiguous, if account authority is disputed, if reverse-DNS control is hard to prove, if route-origin evidence cannot be changed predictably, or if a prefix is entangled in litigation or discretionary review, the cloud provider will either reject the request, slow it down, ask for more proof, or treat the customer's use as higher risk.
In that moment, AFRINIC's administrative quality becomes part of a cloud admission file. A prefix administered by AFRINIC can be technically routable and still carry extra questions. Who is the current recognised holder? Is the holder in good standing? Is there a dispute? Who can authorise a ROA? Who controls reverse DNS? Does the registry accept the intended authorised use? Are records current? Can the customer show a credible chain from holder to cloud account? Will an account hold or governance dispute affect public evidence after the prefix is onboarded?
Cloud providers will not solve those questions for the African market. They will protect themselves. If the independent address path looks difficult, they will offer provider addresses. That is rational platform behaviour. The registry's job is to make the independent path predictable enough that customers are not steered into dependence by avoidable evidence risk.
BYOIP therefore reveals a simple policy test for AFRINIC. Can an African holder or authorised user present a clean, standard, non-discriminatory evidence package to a cloud platform without requiring the cloud provider to understand AFRINIC politics? If yes, the registry is supporting market optionality. If no, the platform's address inventory gains power.
AFRINIC uncertainty adds a premium to African-administered space
AFRINIC uncertainty does not have to break routing to change price. It only has to make counterparties ask for more proof. A cloud provider's onboarding team, a bank's technology-risk committee, a regulator's adviser or a lender financing a cloud migration does not need to decide the merits of every AFRINIC lawsuit. It asks a narrower question: will this address arrangement remain recognised and operable throughout the contract?
The factual background is enough to make the question rational. AFRINIC's own materials identify it as the registry for Africa and the Indian Ocean region and describe services that matter to cloud use: WHOIS, RDAP, reverse DNS, IRR and RPKI. Its IPv4 exhaustion page says the region entered Soft Landing Phase 2 on 13 January 2020, with a minimum allocation or assignment size of /24 and a maximum of /22 under that phase. Scarcity means customers are more likely to depend on existing holdings, transfers, leases, mergers, provider addresses or BYOIP rather than generous new allocations.
Public reporting adds the institutional premium. In 2019, KrebsOnSecurity described allegations that large blocks of African IPv4 addresses associated with dormant or defunct organisations had been manipulated or sold through companies linked to a former AFRINIC staff figure, with a market value estimated at more than $50m. AFRINIC said at the time that it was investigating. Later reporting and analysis described the Cloud Innovation dispute, including high-value IPv4 holdings, out-of-region use claims, leasing economics, resource review, bank-account freezes, litigation and institutional stress. In September 2023, the Supreme Court of Mauritius appointed the Official Receiver, and the NRO's public statement described the receiver's role in maintaining the status quo, preserving the value of the business, overseeing elections and restoring functional governance. The 2025 election process was suspended and then annulled after concerns around voter documentation and proxy authority were publicly reported. A later board recovery effort and 2026 budget and strategy work were also reported, alongside continuing litigation and ICANN intervention in a winding-up context.
These facts should be used carefully. They do not mean every AFRINIC service is failing. They do not mean every AFRINIC prefix is tainted. They do not mean a cloud provider should refuse African space. They do mean that AFRINIC-administered addresses can carry a registry-risk spread unless the institution makes routine evidence boring again.
The spread appears in practical forms. A cloud provider may ask for more documents before accepting BYOIP. A customer may prefer provider addresses because its own AFRINIC space requires explanation. A bank may ask whether an address block involved in a migration is subject to dispute. A procurement lawyer may ask whether the holder, operator and cloud account match. A risk committee may worry that a reverse-DNS change, ROA update or registry status could be delayed by institutional conflict. A broker or lessor may charge for managing continuity risk. A smaller operator may abandon BYOIP and use provider addresses because the diligence file is too expensive.
Cloud makes the discount more visible because cloud admission is formalised. BYOIP is not a handshake between two local engineers. It is a platform process that asks for standard evidence. If the evidence is harder to produce for AFRINIC space than for space under a more stable registry record, the customer pays in time, risk and fallback dependence.
The correct institutional response is not defensiveness. A registry lowers the premium by publishing predictable procedures, preserving service continuity, distinguishing disputed from undisputed facts, processing authorised updates, maintaining accurate public records, and treating similarly situated holders alike. It raises the premium when it converts record maintenance into discretionary judgments about business model, geography or institutional loyalty. In cloud markets, uncertainty does not remain inside the registry. It is transmitted into onboarding, procurement, migration and exit decisions.
Large platforms can carry address risk that smaller African operators cannot
Cloud-provider address power is partly a scale advantage. Large platforms hold large address inventories, operate global backbones, maintain relationships with other networks, run reputation teams, employ legal and policy staff, and track public IPv4 use across regions and accounts. They can treat address risk as an operational variable. Smaller African operators and customers often experience the same risk as a business-continuity threat.
If a cloud provider has a problematic address block, it can rotate inventory, quarantine reputation, assign a different range, adjust filters, use its own routing influence, escalate through industry relationships and absorb legal review. If a small SaaS platform has one /24, that block may be its whole public identity. If a regional bank uses a small set of public addresses for partner connectivity, changing them may require months of third-party approvals. If a public-service platform relies on a handful of endpoints, renumbering can become a citizen-service incident. If a regional hosting customer brings AFRINIC space into a cloud or hybrid environment and that space becomes institutionally questioned, the customer cannot easily substitute a global address portfolio.
This asymmetry gives platforms market optionality. They can offer provider-owned addresses as a service, BYOIP as a controlled exception, private networking as an architecture pattern, NAT as an address-conservation tool, and managed edge services as a way to hide the customer's origin. Each option may be rational. The provider benefits because it can price, gate and package them. The customer benefits if the options are genuinely comparable. It loses leverage if only the provider-owned path is simple enough to pass commercial review.
Consider a Ghanaian SaaS company that sells payroll and tax-filing software to medium-sized enterprises. It has grown on a local hosting provider and uses a small pool of public IPv4 addresses that customers have allowlisted. It wants to deploy parts of the application in a major cloud region for resilience and developer productivity. It can use cloud addresses, but then a future move to another provider means changing customers again. It can bring its own address block, but the cloud onboarding process asks for proof, route-origin evidence and clean registry data. If its AFRINIC records are old, if the holder name differs from the operating company after a restructuring, or if a leased arrangement is documented poorly, the platform-owned option becomes the path of least resistance.
The platform has not forced the company to accept lock-in. The institutional environment has made independence costly. That is the subtle form of address power. It is not the power to deny service. It is the power to be the simpler alternative when the neutral record is not sufficiently neutral, current or trusted.
The same pattern applies to African ISPs, hosting firms and systems integrators that serve cloud customers. A local operator with clean portable space can offer hybrid services: customer-owned public endpoints, local breakout, cloud failover, disaster recovery, secure connectivity and multi-cloud exit. If the operator's address evidence is discounted, the cloud provider's own addresses become more credible than the local operator's. The local operator then sells connectivity while the platform owns the public identity layer. Value moves upward.
IPv4 scarcity intensifies the asymmetry. When addresses were abundant, a small operator could request more or renumber with less pain. In a post-exhaustion market, every clean public address carries opportunity cost. Large platforms can spread that cost across millions of customers and product lines. Smaller operators face indivisible risk. One rejected /24, one contested LOA, one reverse-DNS failure, one reputational blacklist, or one registry hold can affect a material share of revenue.
This is why AFRINIC's continuity discipline has distributional consequences. A predictable registry helps smaller actors use scarce address holdings as bargaining assets. An unpredictable registry leaves them with assets that are technically useful but commercially discounted. The discount is then captured by the parties that can sell certainty: cloud platforms, large carriers, brokers with legal capacity, and incumbents with provider-assigned address pools.
The market does not need AFRINIC to favour small operators. It needs AFRINIC not to impose avoidable uncertainty on the evidence those operators use to bargain with large platforms.
The customer buys continuity before it buys compute
Cloud procurement documents often emphasise compute, storage, security, compliance certifications and region footprint. Public IPv4 addresses appear as a networking detail. For many African customers, the order of importance is different. They buy continuity before they buy compute. The workload can move only if customers, banks, regulators, partners and security systems can still recognise it.
The Lagos payments company is typical. Its partner banks may maintain IP allowlists for callbacks, settlement files or risk feeds. Mobile-money partners may allow only known public endpoints. Merchants may have firewalls that permit traffic from published service addresses. Fraud vendors may associate behaviour with source ranges. Email providers may track sender reputation. Customer support logs may depend on stable source addresses. A regulator may ask whether the migration changes where traffic is processed or who controls access. Each dependency turns an address into a continuity anchor.
Provider-owned cloud addresses solve the first deployment problem. They do not necessarily solve the continuity problem. The company must distribute new addresses, update partner records, test paths, wait for change windows and handle exceptions. If it stays in the same platform for many years, the provider address may become accepted. That acceptance is useful but sticky. The next move becomes harder because the public identity is now embedded in a provider account.
BYOIP solves a different problem. It lets the customer keep the same public identity while changing where the service runs. The customer can move a prefix from an on-premises or local-hosting environment into cloud, or design a hybrid posture where the same recognised address space supports multiple operating sites. The value is not only lower IP charges. It is avoiding customer-wide renumbering and preserving reputation. Azure's documentation says this plainly when it describes retaining IP ranges to maintain established reputation and continue through externally controlled allowlists. That sentence captures a large share of the economics.
NAT and private networking help where public identity is not needed. Internal services should not consume public IPv4 merely because engineers failed to design private connectivity. But NAT cannot replace every public identity. Payment callbacks, public APIs, VPN peers, security appliances, email systems, fraud integrations and legacy enterprise partners often still require stable public IPv4. A private architecture may reduce surface area while making the remaining public addresses more important.
The customer's decision is therefore not "cloud or no cloud." It is "whose address continuity will the business trust?" If it trusts the cloud provider's address inventory, it accepts provider control as part of the service. If it trusts its own AFRINIC-recognised or authorised space, it can use cloud while preserving some exit. If it trusts neither, it delays migration, overuses NAT, keeps fragile legacy hosting, or pays for bespoke assurance.
This is where AFRINIC's institutional quality enters ordinary African digital transformation. A public-service platform moving to cloud, a university building research services, a bank modernising APIs, a logistics SaaS company expanding regionally, or a health platform designing disaster recovery may all face the same question. They are not trying to litigate internet governance. They need public address identity that survives cloud choice.
When AFRINIC is boring, the answer can be commercial. Use provider addresses when speed and low friction matter. Use BYOIP when continuity and exit matter. Use NAT and private services where public reachability is unnecessary. Acquire or lease space when the business case justifies it. When AFRINIC is uncertain, the answer becomes institutional. Avoid the independent address path unless you can afford the evidence burden. That pushes the market toward platforms.
The cost is not visible in one invoice. It appears in procurement caution, delayed migrations, conservative architectures, duplicated environments, partner reluctance and weaker exit rights. A customer may save money on a cloud project and still give up address optionality that would have mattered in the next negotiation.
Reputation makes address power durable
Public IPv4 addresses carry memory. They appear in spam lists, fraud signals, geolocation databases, abuse histories, VPN and proxy classifications, enterprise allowlists, DNS records, certificate logs, application telemetry, incident reports, payment-provider files and customer documentation. A new address may be technically reachable but commercially untrusted. An old address may be valuable because it is already known to the right parties and unknown to the wrong ones.
Cloud providers understand this. Their BYOIP documentation frequently frames customer-owned addresses in terms of reputation and continuity. Azure explicitly mentions established reputation and externally controlled allowlists. Google separates customer-brought addresses from ordinary provider inventory and makes them available only to the customer who brought them. AWS's public IPv4 pricing and IPAM materials treat public IP use as something to track, manage and monitor. These are not abstract network features. They are reputation-management tools.
For African customers, reputation has several layers. A fintech's API addresses may be allowlisted by banks. A bank's own public endpoints may be listed in central-bank and correspondent-bank documentation. A SaaS provider's outbound addresses may be trusted by enterprise customers. A university's research services may have long-standing access rules. A public agency may publish addresses in disaster-recovery plans. A mail-sending system may need months to build reputation after a change. An address block used by spammers or hijackers may need remediation before cautious partners will accept it.
AFRINIC's history makes reputation evidence especially important. The 2019 address-heist reporting was not merely a scandal about old records. It showed that stale or manipulated registry records can have downstream reputation effects. Dormant address blocks can be commandeered, sold, used for abusive traffic, listed by anti-abuse systems and then become difficult for rightful or later users to rehabilitate. A registry that cannot maintain reliable holder and contact data does not only create administrative confusion. It damages the reputation capital attached to addresses.
Cloud can either mitigate or compound that risk. A provider-owned address may arrive with the platform's operational backing but also with the provider's own shared reputation environment. A customer-owned address can preserve reputation but requires the customer to prove control and maintain abuse handling. A leased address can be efficient but may require clear documentation of who handles abuse, who controls reverse DNS, who may request ROAs and what happens when the lease ends. A NAT-heavy architecture can reduce public IP consumption but can also concentrate abuse signals behind a few egress addresses.
Reputation makes address power durable because it accumulates over time. Once a customer has spent years training partners and systems to trust provider-owned addresses, leaving the provider means rebuilding that reputation elsewhere. Once a cloud provider has integrated address monitoring and reputation controls into its platform, it can sell certainty as part of the bundle. Once independent AFRINIC space is seen as harder to validate, the customer's own reputation asset may be discounted before it reaches the cloud.
Reverse DNS is a useful example. Mail systems, security tools and operations teams often read PTR records as part of identity and trust. Azure's custom prefix documentation says custom prefixes do not support reverse DNS lookup using Azure-owned zones and that customers must onboard their own reverse zones. That is logical: a customer bringing its own prefix should bring the reverse-DNS authority needed to make the addresses credible. But reverse DNS depends on the registry and delegation path. If the customer cannot update or prove that path predictably, BYOIP becomes harder even if routing is possible.
Abuse contacts behave similarly. A cloud provider accepting a customer prefix needs to know who will answer complaints. A bank using the customer's API needs to know incidents can be escalated. A public agency needs auditability. If AFRINIC records are stale, disputed or hard to correct, the reputation file weakens. The platform can then say, explicitly or implicitly, that its own addresses come with a cleaner operational story.
The answer is not to let any address use proceed without evidence. Reputation requires discipline. The answer is to keep the evidence tied to the relevant fact. Who controls the prefix? Who is authorised to use it? Who handles abuse? Who controls reverse DNS? Which AS may originate it? What is the dispute status? A registry that answers those questions predictably strengthens African address reputation. A registry that expands into judgments about whether a business model is virtuous weakens it, because counterparties cannot tell where evidence ends and permission begins.
Data-residency procurement does not remove address dependence
Cloud region footprint matters for African customers. Major providers operate African regions and adjacent edge, cache and partner arrangements extend their reach. A bank, fintech, public agency or enterprise buyer may prefer a workload to run in an African region for latency, resilience, procurement, regulatory comfort or political acceptability. But data residency is not the same as address independence.
A workload can run in an African cloud region while using provider-owned addresses. It can satisfy a procurement requirement about region location and still leave its public identity under platform control. It can store data closer to users and still make customer exit expensive. It can appear local in infrastructure terms while the ability to preserve public endpoints depends on a global provider's address inventory, terms, quotas and routing policy.
This distinction is easy to miss because cloud procurement collapses many dependencies into one supplier. The provider offers compute, storage, security, monitoring, managed databases, load balancing, DDoS protection, IAM, logging, support and network identity. A public buyer may treat that bundle as operational maturity. The address question is then hidden inside the supplier's architecture. If the buyer later wants to move to another hosting environment, a second cloud, a sovereign procurement framework or an emergency standby environment, it discovers that public addresses were part of the original bargain.
For regulated African customers, the issue is not only exit. It is bargaining position. A bank that can bring its own address space into a cloud region can negotiate cloud service without surrendering all public endpoint continuity. A ministry that owns or controls stable address resources can design a disaster-recovery plan across providers. A fintech with portable addresses can move a critical API if pricing, support, policy or risk changes. A SaaS platform with independent address identity can use cloud as infrastructure rather than as a permanent identity provider.
If AFRINIC-administered address space carries a premium, this bargaining position weakens. The buyer may still insist on local region use but accept provider-owned addresses because the BYOIP file is too slow. A local cloud-adjacent provider may still build a data-centre or managed-service offering but depend on the hyperscaler's address layer for customer reachability. A public-sector customer may speak the language of digital sovereignty while renting public identity from a platform because the neutral regional ledger is not trusted enough.
This is not the same as broad geopolitical fragmentation. The mechanism is narrower. Address dependence converts cloud region choice into provider bargaining power. It makes data-residency procurement less independent than it appears. It also gives platforms a stronger position in future negotiations because the customer's public endpoints, partner allowlists and reputation are embedded in the platform's network.
The effect is likely to be strongest in sectors where address continuity matters most: payments, public portals, health systems, education networks, B2B SaaS, security services, email, identity providers, enterprise APIs and regulated outsourcing. Consumer web applications can sometimes hide behind domains, content-delivery networks and managed front doors. Even there, origin addresses, firewall rules, abuse handling and API partners still matter. In business and public-sector systems, the address file is harder to abstract away.
AFRINIC's role is not to decide whether African customers should use global cloud providers, regional hosting, hybrid architectures or on-premises infrastructure. Those decisions belong to customers, regulators and markets. AFRINIC's role is to keep address recognition neutral enough that those decisions are real choices. If the customer chooses provider-owned addresses because they are efficient, that is a commercial decision. If the customer chooses them because AFRINIC-backed independence is too uncertain, that is an institutional failure.
Data-residency debates often ask where data sits. The cloud-provider address-power question asks who controls the public identifiers that let customers, regulators, partners and users reach the service. Those questions are related but not identical. A credible African registry reduces the risk that local infrastructure ambitions become another path into platform-owned public identity.
Neutral registry continuity is the antidote to platform lock-in
The most important anti-lock-in tool in this market is not hostility to cloud. It is neutral registry continuity. A customer can use public cloud aggressively and still preserve bargaining power if its public address identity is portable, evidenced and recognised. A customer can avoid cloud and still be locked in if its addresses are provider-assigned by a local incumbent. The institutional question is not whether cloud is good or bad. It is whether address recognition lets customers choose.
Neutral continuity starts with the last verified record. A recognised holder should not fear that routine registry services will become bargaining chips during disputes unrelated to those services. RDAP, WHOIS, reverse DNS, IRR and RPKI functions should be treated as continuity infrastructure. If a specific legal order, fraud finding or technical risk affects a particular service, the limitation should be narrow, evidenced and reviewable. Otherwise, the record should keep supporting the networks and customers that depend on it.
This matters for cloud because BYOIP and hybrid architecture depend on continuous evidence. A cloud provider may accept a prefix today but ask whether the route-origin evidence, reverse-DNS delegation or public registration will remain stable tomorrow. A customer may complete a migration but worry that an account dispute will affect updates later. A lender may finance a platform whose revenue depends on stable endpoints. A procurement authority may require proof that the supplier can maintain public identity during a disaster. Continuity is not a philosophical virtue; it is a commercial input.
Neutrality also requires mandate discipline. A registry should verify facts relevant to uniqueness, holder recognition, authorised use, contactability, route origin, reverse DNS, abuse handling, transfers and disputes. It should not use those facts as a route into approving or disapproving cloud strategy. If a holder brings a prefix to a global platform, the registry's question should not be whether the platform is desirable. It should be whether the holder or authorised user is properly evidenced and whether the record remains accurate. If a customer leases address space for a cloud migration, the question should not be whether leasing is morally attractive. It should be whether the authorised-use record, abuse handling, route origin and term are legible enough for counterparties.
A neutral registry lowers platform lock-in by making customer-owned alternatives cheaper. The cloud provider can still sell convenience, performance, security and managed services. It cannot rely on registry uncertainty to make its own address inventory the only practical option. The local operator can still compete by offering hybrid services. The bank can still choose cloud for legitimate reasons. The public agency can still decide that provider-owned addresses are acceptable. But those choices are made against a credible independent path.
AFRINIC's governance crisis shows why this discipline is difficult. When an institution faces litigation, corruption history, contested elections, questions over board legitimacy and resource disputes, it may be tempted to defend itself by expanding discretion. It may frame more decisions as necessary to protect the community, preserve regional interest or prevent abuse. Some protection is necessary. Fraud and forged authority must be rejected. Dormant records must be cleaned carefully. Disputes must be recorded. But if protection becomes open-ended control over commercial use, it raises the very premium that drives customers toward platforms.
Continuity is therefore not weakness. It is institutional strength. It says the registry is confident enough in its narrow function not to judge every cloud, leasing, data-residency or customer strategy. It preserves the record, not the registry's leverage over the record. It reduces the market value of gatekeeping.
For AFRINIC, the anti-lock-in test is practical. Can a small African operator update contact data, reverse DNS and route-origin evidence without becoming trapped in unrelated institutional conflict? Can an authorised user show a cloud provider a standard evidence package? Can a customer distinguish a real dispute from vague registry unease? Can services remain available while board or court processes continue? Can similarly situated holders expect similar treatment? If yes, AFRINIC supports address optionality. If no, cloud platforms and incumbents inherit the bargaining power.
The wrong answer is to fight platforms by expanding registry discretion
One tempting response to cloud-provider address power is for registries to become more interventionist. If large platforms have too much address inventory, restrict transfers. If customers bring addresses into global clouds, question whether the use serves the region. If leasing creates platform dependence, treat leasing as suspect. If out-of-region traffic appears, convert geography into a permission test. If cloud providers benefit from scarcity, use registry policy to ration who may monetise it.
That response gets the economics backwards. Expanding registry discretion often strengthens the platform position it claims to resist. The reason is simple: customers do not stop needing public IPv4 because a registry dislikes a business model. They look for the path that passes procurement and delivery. If customer-owned or leased AFRINIC space becomes harder to explain, provider-owned cloud addresses become easier to accept. The registry may believe it is defending regional interest while pushing customers into global platform inventory.
Discretion has a hidden market effect. It makes independent addresses less bankable. A cloud provider considering BYOIP asks whether the customer can maintain recognised authority. A bank asks whether a prefix could become disputed because of a commercial-use theory. A customer asks whether an address lease might be challenged. A public buyer asks whether a supplier's address plan depends on a registry's shifting view of regional benefit. Each question adds risk to the independent path. The platform-owned path looks cleaner because the platform has already internalised the registry risk through its own allocations and architecture.
This does not mean every address transaction should be approved. A registry must reject forged documents, unauthorised transfers, hijacked dormant space and false claims. It must maintain uniqueness. It may need to record court orders, sanctions facts, corporate-authority disputes and proven abuse-related contact failures. It should require current records and responsible contacts. It should support routing security. But those are evidence rules. They differ from industrial-policy discretion.
The distinction is crucial in the AFRINIC context. Public disputes around Cloud Innovation, Larus, leasing, out-of-region use and resource review have made commercial use of African-administered IPv4 politically salient. Some observers see leasing and monetisation as abuse of community resources. Others see them as ordinary market responses to scarcity and as a way for holders to realise value from scarce capital-like resources. AFRINIC does not need to resolve that policy fight to perform its registry function. It needs to define the evidence required for recognised holder authority, authorised use, route origin, contactability, transfer status and dispute notation.
If a court makes a specific order, the registry must respect it within its scope. If a contract authorises or limits a use, the parties may litigate or arbitrate it. If fraud is proved, records must be corrected. But the registry should not smuggle a broad cloud or leasing policy into record recognition. That is mandate laundering: using the narrow authority to maintain a unique address ledger as the vehicle for broader economic control.
The wrong answer is especially harmful to small operators. A large cloud provider can comply with complex rules, hold multiple address pools, route around uncertainty and employ counsel. A small operator cannot. If registry discretion makes independent space harder to use in cloud, the small operator loses the very scarcity leverage that IPv4 might otherwise give it. It becomes a customer of the platform's address system rather than a holder of portable network identity.
The better answer is procedural modesty. Make the record accurate. Make authorised use legible. Make disputes precise. Make updates predictable. Make appeals available. Make service continuity robust. Let cloud customers, platforms, carriers and regulators negotiate their own commercial arrangements on top of a stable ledger. A registry that tries to defeat cloud power by expanding its own discretion risks becoming the platform's accidental ally.
Cloud admission should be answered with predictable evidence
A cloud-aware AFRINIC regime would not require AFRINIC to build cloud products or bless cloud migrations. It would require the registry to understand how its records are used in cloud admission and to make the relevant evidence predictable. The unit of analysis should be the evidence package, not the registry's opinion of the customer's business strategy.
The package begins with holder recognition. Who is the current recognised holder or legacy holder? Is the name current after mergers, restructurings or corporate changes? Is the account in a status that permits routine updates? Is there a specific dispute or court order? If so, what facts are disputed and which services are affected? A cloud provider should not have to infer this from rumours, press releases or factional statements.
The second element is authorised use. Many cloud cases involve a difference between the holder, the operating company, the cloud account and the origin AS. That difference is not automatically suspicious. A corporate group may centralise address holdings. A bank may use a managed-service provider. A SaaS company may lease a prefix. A public agency may outsource operations. The registry does not need to approve every contract, but the public and private evidence should make the authority chain legible: holder, authorised user, term where relevant, revocation mechanics, abuse contact, route-origin authority and reverse-DNS responsibility.
The third element is route-origin evidence. BYOIP processes rely on ROAs, route-origin checks, route advertisements or equivalent validation. AFRINIC should make it predictable who can request, change or withdraw ROAs and related routing evidence, how disputes affect those actions, and what continuity protections apply during account or governance stress. A customer's cloud migration should not fail because the registry cannot distinguish between a contested transfer and an uncontested route-origin update for the last verified holder.
The fourth element is reverse DNS and reputation. Customers bringing addresses to cloud often do so because they need established reputation and allowlist continuity. Reverse DNS, abuse contacts and public registration data support that continuity. AFRINIC should preserve and update them through clear rules. If a reverse-DNS delegation is rejected, the reason should be tied to a specific technical or authority defect, not to a vague view of the customer's commercial model.
The fifth element is dispute precision. "In dispute" is not a sufficient market signal unless counterparties know what the dispute affects. A court order preserving corporate status is different from an allegation of forged authority. A payment issue is different from a transfer contest. A board-election dispute is different from a prefix-specific injunction. A registry that records precise dispute states helps cloud providers and customers manage risk. A registry that leaves dispute language broad forces them to overreact.
The sixth element is non-discriminatory service levels. Similar requests should receive similar treatment, whether the holder is a large carrier, a cloud-adjacent platform, a small ISP, a university, a public agency, a broker-supported customer or a litigant unpopular with part of the community. Timelines, evidence requirements, escalation paths and appeal rights should be published. The more valuable IPv4 becomes, the more important it is that service discretion not look like economic preference.
Finally, the registry should maintain an audit trail. Cloud admission and financial diligence both reward traceability. Who requested a change? What evidence was provided? What was approved? What was rejected? What service was affected? What dispute was recorded? What path exists to correct an error? This is not bureaucracy for its own sake. It is how a scarce address resource becomes bankable enough to use across platforms.
The cloud providers' own documentation points in this direction. AWS queries RDAP records and route-origin evidence in its EC2 BYOIP process and uses IPAM as another control path. Azure separates validation, provisioning and commissioning and highlights ownership verification, reputation and allowlists. Google uses ROA and reverse-DNS validation, public advertised prefixes, delegated prefixes, project scope and warnings about overlapping announcements. All of these systems assume that the external address record can produce reliable facts. AFRINIC's job is to make that assumption safe for African-administered space.
Predictable evidence does not guarantee acceptance. A provider may still impose product limits, region restrictions, minimum prefix sizes, reputation thresholds, account requirements or security policies. But a predictable registry gives the African customer a fair chance to meet those rules. An unpredictable registry lets the platform's own addresses win before the customer's architecture is evaluated.
The address plan is where cloud strategy meets IPv4 capital
IPv4 scarcity has made address planning a capital-allocation problem. A company deciding whether to use provider addresses, bring its own prefix, lease space, acquire a block, conserve through NAT or wait for IPv6 adoption is allocating scarce optionality. The address plan affects migration cost, customer retention, financing, disaster recovery, partner access and negotiating leverage.
The capital-like character of IPv4 does not require pretending that addresses are land or that registry doctrine has no force. Number resources remain part of a uniqueness system. They depend on coordination. They are not ordinary physical property. But economic reliance is undeniable. A recognised IPv4 block can support revenue, customer relationships, contracts, platform migration, loan diligence and operational continuity. Its value depends on scarcity and on the confidence that recognition will persist.
Cloud has sharpened this capital logic. Public IPv4 has an observable cost inside cloud bills. BYOIP can avoid some address charges while preserving reputation and allowlists. Provider addresses reduce upfront friction but can raise future switching cost. NAT conserves scarce public endpoints but concentrates public identity. A clean portable block can be used as a strategic option across providers. A disputed or weakly evidenced block cannot.
For African operators, this creates a difficult financial question. Should a company spend scarce capital acquiring or leasing IPv4 if registry uncertainty may reduce its usability in cloud? Should it rely on platform addresses if that creates future exit cost? Should it keep workloads in local hosting because BYOIP is uncertain? Should it design IPv6-first services even though many partners still require IPv4? These are capital-allocation decisions under institutional uncertainty, not merely engineering preferences.
Large platforms benefit because they can turn address certainty into product optionality: use our addresses and avoid the independent address file; bring your own if you can satisfy validation; use private connectivity if public exposure is not needed; buy managed services that abstract public endpoints. This menu is valuable. It is also a way of monetising the gap between platform certainty and external uncertainty.
AFRINIC's crisis adds to that gap. When a registry is recovering from receivership, litigation and legitimacy questions, cautious customers assign less value to independent address capital. They may still hold a scarce block, but the block's cloud usability is discounted. The discount is not inevitable. It is a function of evidence quality. If AFRINIC can make authorised use, route origin, reverse DNS and holder recognition predictable, the capital value of African-administered space rises. If it cannot, the same scarce addresses remain operationally useful but strategically weaker.
The capital lens also clarifies why "just use IPv6" is insufficient for this article's problem. IPv6 may reduce long-run numerical scarcity, and many cloud and network designs should support it. But African fintechs, banks, public agencies and SaaS platforms still operate in an IPv4-dependent commercial environment. Partners, firewalls, legacy systems, consumer networks, fraud systems and procurement files continue to make IPv4 reachability valuable. During the dual-stack period, IPv4 remains a scarce bridge between old and new systems. Whoever controls reliable IPv4 identity controls bargaining leverage.
That leverage can be held by customers, local operators, regional address holders, brokers, carriers or cloud platforms. AFRINIC's institutional design affects the distribution. A neutral record lets the holder of scarce address capital deploy it across clouds and networks. A discretionary record suppresses that capital and makes platform-owned substitutes stronger. The address plan is therefore where registry legitimacy becomes cloud economics.
The practical lesson for customers is to treat address decisions as strategic assets, not deployment leftovers. The practical lesson for AFRINIC is to make those assets legible without pretending to own their commercial destiny.
The future bargain is portability without permission politics
Return to the payments company in Lagos. Its board does not need AFRINIC to choose a cloud provider, approve a fintech strategy, subsidise local hosting or punish global platforms. It needs a public address environment in which choices have clear prices. If the company uses cloud-provider addresses, it should know that it is buying convenience and accepting some exit cost. If it brings its own prefix, it should know what evidence is required and how continuity will be protected. If it uses NAT, it should know which public endpoints become concentrated risk. If it leases or acquires scarce portable IPv4, it should know how holder recognition, authorised use, route origin, reverse DNS and abuse contacts will be documented.
That is portability without permission politics. The registry keeps the neutral record. The customer makes the commercial choice. The cloud provider sets product requirements and prices. The bank asks for operational assurance. The regulator applies law. The courts resolve specific disputes. None of these actors needs the registry to become a broad economic gatekeeper over cloud use.
The stakes are large because public cloud is becoming one of the main ways African digital services scale. Fintechs, banks, logistics firms, health platforms, universities, broadcasters, security companies and public agencies will keep using hyperscale platforms where they are useful. They will also need local hosting, hybrid systems, disaster recovery and multi-provider leverage. Address portability is one of the quiet instruments that lets those options coexist.
If AFRINIC's record layer is reliable, African-administered IPv4 can act as bargaining capital. A customer can enter cloud without surrendering all public identity. A local operator can sell managed services without being reduced to access plumbing. A public agency can demand continuity across providers. A bank can design cloud exit without renumbering every partner. A SaaS company can preserve reputation while changing infrastructure. In that world, cloud providers still win business by offering better platforms, not by being the only safe source of public addresses.
If AFRINIC's record layer is unreliable, the opposite happens. Provider addresses become the conservative choice. BYOIP becomes a specialist path for large firms. Leased African space carries extra diligence. Smaller operators lose scarcity leverage. Public-sector procurement speaks about local control while accepting platform address dependence. IPv4 scarcity, instead of empowering African holders, is monetised by the actors with the largest inventories and the strongest trust files.
The design answer is concrete: predictable records, authorised-use evidence, non-discriminatory updates, service continuity, precise dispute notation, audit trails, route-origin reliability, reverse-DNS continuity, abuse-contact accuracy and a clear separation between cloud industrial policy and address recognition. These are modest rules, but they shape a large market.
AFRINIC's crisis makes the lesson sharper because it shows how quickly a registry can become economically visible when scarcity, litigation and platform dependence meet. A neutral registry is not powerless. It can reduce bargaining asymmetry by making public facts dependable. A discretionary registry is not stronger; it transfers power to whoever can survive its uncertainty.
Cloud providers have already made public IPv4 a priced, monitored and policy-governed input. The test for AFRINIC is whether an African customer can bring a legitimate prefix to a platform, maintain route-origin and reverse-DNS evidence, answer abuse and reputation questions, and leave later without asking a registry to bless the business model. If that file is ordinary, cloud becomes infrastructure. If it is exceptional, the platform becomes the default landlord of public identity.