AFRINIC and the economics of cloud NAT and platform power

The architecture review begins with a diagram that looks comfortingly modern. A payments company serving African merchants is moving its application estate into private subnets. The customer databases will not sit on public addresses. Worker nodes will talk to managed services over private links where possible. The API tier will sit behind load balancers. Build systems, fraud engines, billing jobs and settlement workers will reach the public internet through managed NAT gateways. The board expects the usual cloud argument: fewer exposed servers, better isolation, faster deployment and a cleaner disaster-recovery story.

Then the finance lead asks a smaller question. Which public identity will the company's outbound traffic use?

The question changes the room. The engineers can design private subnets in an afternoon. They can attach NAT gateways, assign external IPs, add route tables, turn on logs and route traffic through platform-managed egress. But the company has bank partners that allowlist source addresses, payment providers that score origin reputation, public agencies that record supplier endpoints, fraud vendors that treat egress identity as part of trust, and auditors who want to know who can change the routes. The application is becoming less exposed to the internet, yet its outbound identity is becoming more dependent on the cloud platform.

Cloud NAT is often sold as a convenience. It lets resources without public IPv4 addresses initiate outbound connections and receive responses. In an IPv4-scarce world, it is also an industrial pricing machine. It turns translation, external addresses, gateway hours, per-gigabyte processing, logging, telemetry, data transfer, account architecture and routing defaults into billable platform primitives. A company may reduce the number of public endpoints it exposes, but it does not stop buying public internet identity. It buys that identity in a concentrated, metered and provider-controlled form.

AFRINIC matters to this cloud diagram because it is the Regional Internet Registry for Africa and the Indian Ocean region, and because its region entered IPv4 Exhaustion Soft Landing Phase 2 on 13 January 2020. Under that regime, ordinary requests are constrained between /24 and /22. That scarcity does not create cloud NAT. AWS, Azure, Google Cloud and other platforms would operate managed egress products anyway. Scarcity changes the bargaining position. It makes independent, portable public IPv4 harder to obtain, harder to finance and more important when a company wants not to rent all public identity from a platform.

AFRINIC also brings registry-layer uncertainty. Public reporting has described alleged African IPv4 address misappropriation, the Cloud Innovation dispute, bank-account freezes in 2021, Mauritius court proceedings, receivership, 2025 election disputes, later board-recovery reporting, ICANN intervention in a winding-up context and continuing litigation. These are contested public facts and should be treated as risk context, not as final findings on every claim. The economic point is narrower. When the record layer behind African-administered address resources is perceived as uncertain, firms that might otherwise bring, lease or control portable public IPv4 become more dependent on cloud-provider NAT, external IP pools and platform billing systems.

The thesis is therefore not that cloud NAT is bad. Private subnets and managed NAT are often sensible. The thesis is that cloud NAT is not merely a network feature. Under IPv4 scarcity it turns public internet identity into a metered export function controlled by platforms. The registry's correct role is boring ledger certainty: predictable records, authorised-use evidence, transfer and leasing clarity, reverse DNS, routing evidence and continuity services. It is not cloud-industrial policy. If the ledger is weak, platform power grows without needing to announce itself as power at all.

The architecture review starts with an egress address

Cloud architecture diagrams hide the most important public address in the wrong place. They usually place attention on inbound traffic: the load balancer, the API gateway, the web application firewall, the content-delivery front door. Those are visible. They carry certificates, domains, rate limits and public customer promises. Outbound traffic looks less dramatic. It is a route table entry from private subnets to a NAT gateway, a checkbox in a subnet template, an egress rule, a logging destination and an external IP assignment.

Yet for a regulated company, the outbound address can be more politically important than the inbound address. It is the address a bank sees when the company calls a settlement API. It is the address a fraud vendor sees when a scoring job retrieves data. It is the address a tax authority or public-service partner may record in a procurement file. It is the address that appears in security logs when software updates, data synchronisation, sanctions screening, customer messaging, payment callbacks or operational monitoring leave the private network. If that identity changes, the company may need to update allowlists, risk files, contracts and incident-response playbooks.

The move to private subnets does not remove this identity. It concentrates it. A fleet of virtual machines or containers with no public IPv4 can still share a smaller set of public egress addresses. That is one reason the architecture feels elegant. The company exposes fewer public surfaces. It can scale compute nodes without assigning every instance a public address. It can patch and replace workloads without asking each partner to update a firewall. The public identity becomes a managed choke point.

The choke point is useful, but it is also a control point. Whoever controls the NAT gateway, the external IPs, the route tables, the logging policy and the cloud account controls the public identity of the company's outbound traffic. That power is not abstract. A misconfigured route can send production jobs through the wrong egress address. A deleted gateway can break access to external vendors. A change in logging policy can make an incident harder to reconstruct. A cloud account split can change which team owns the egress point. A region move can force new addresses into bank and public-sector allowlists.

The old question was whether a server had a public IPv4 address. The cloud question is who packages public reachability for a private estate. The answer is often the platform. The provider supplies the managed NAT service, the external IP addresses, the routing constructs, the metrics, the logs, the cost categories and the account boundaries. The customer decides, but the decision is made inside a menu whose defaults and prices are written by the provider.

That is why the opening scene belongs in a board-level architecture review rather than in a router manual. A company may think it is buying compute and security. It is also choosing the institution that will meter and mediate its public internet identity. If it owns or controls portable IPv4, it has one kind of bargaining position. If it depends on provider-owned egress addresses, it has another. If AFRINIC-region resources carry extra uncertainty, the provider-controlled option becomes more attractive even before anyone says the word lock-in.

Private subnets make public identity a platform export

The private subnet is one of the great habits of public cloud. It is a sensible habit. Most workloads do not need to be directly reachable from the internet. Databases, workers, caches, internal APIs, message consumers, build runners and analytics jobs should usually live behind private addressing. Private ranges make internal scaling cheap, reduce accidental exposure and let security teams describe boundaries in a language procurement departments understand.

But private addressing creates an export problem. The internal estate still needs the outside world. It must call software repositories, payment processors, public APIs, security feeds, customer systems, email providers, identity services, cloud control planes and other vendors. For IPv4 destinations, that traffic must leave through some public identity. Managed NAT is the platform answer: keep the workloads private, translate them at the edge of the virtual network, and meter the translation.

The economic change is subtle. Public identity becomes less like a property of each machine and more like an export licence from the platform account. The customer may own the application, the data and the internal address plan. The provider supplies the public wrapper through which private resources speak to the legacy internet. That wrapper can be standardised, billed, logged, monitored and tied to platform governance.

This is not the same as access-network CGNAT. Carrier-grade NAT in an ISP shares public addresses among subscribers and creates attribution, support and application-compatibility costs. Cloud NAT sits inside a different market structure. It is chosen during architecture design, governed through account permissions, priced through cloud bills, observed through platform telemetry and embedded in procurement claims about secure private architecture. The pain is not usually a consumer support ticket. It is a cloud invoice, a compliance question, a FinOps dashboard, a migration plan and a partner allowlist.

Private-by-default architecture therefore has a public-identity shadow. The more successful the company is at moving workloads into private subnets, the more valuable the few public egress points become. A bank does not care that the settlement worker sits on a private address. It cares which public address called the endpoint. A fraud system does not see the customer's subnet design. It sees an origin. A regulator does not audit every internal container. It asks who could change the route that reaches an external service.

The platform's power sits in that translation between private abundance and public scarcity. Private addresses are effectively unlimited for internal design. Public IPv4 is scarce, reputation-bearing and partner-visible. NAT is the bridge. Because the bridge is managed, it becomes a product; because the product is metered, it becomes a pricing surface; because the surface touches partner trust, it becomes a governance issue.

An African fintech, health platform or public-service supplier may adopt this architecture because it is standard cloud practice. The institutional question is whether it has a credible alternative to provider-controlled egress when the public identity matters. If it can bring, lease or hold portable IPv4 with clean AFRINIC-region evidence, it can separate platform use from public identity. If not, private subnets become one more path by which a cloud account rents the company's internet face.

Managed NAT turns translation into a billable primitive

The pricing pages of the major cloud providers are useful because they say plainly what architecture diagrams imply. AWS's VPC pricing page treats NAT Gateway as an hourly resource and a per-gigabyte processing path, with ordinary data-transfer charges still applying where the traffic leaves through that path. Azure's NAT Gateway pricing page says billing begins when the resource is created, and its data-processing meter covers outbound and return data while bandwidth charges also apply. Google's Public NAT pricing page breaks the stack into hourly gateway cost, per-GiB processing, hourly external-IP cost and data-transfer-out cost. The particulars differ by provider and region; the economic shape is consistent. Translation is not a free side effect of private subnet design. It is a meter.

That meter is not merely a price list. It is a way of making public identity a recurring platform service. A private estate reaches the IPv4 internet through a managed edge; the edge is measured in time, traffic, address use and, when the customer needs evidence, logs and telemetry. The customer may see a secure private architecture. The invoice sees a public export function.

These pages should not be read as accusations. Providers have real infrastructure costs. Managed NAT needs capacity, redundancy, control-plane engineering, telemetry, support, documentation and integration with the rest of the cloud network. If customers value managed egress, providers will charge for it. The institutional point is that cloud NAT converts a protocol workaround into an accounting category. Scarcity becomes visible, but only after the architecture has placed egress identity under the platform.

The metering also changes design incentives. Engineers may reduce public endpoints and route more outbound traffic through shared gateways. Finance teams may encourage private-only compute because public IPv4 addresses cost money. Security teams may prefer centralised egress because it is easier to monitor. Platform teams may require all workloads in an account to use standard NAT modules. Each decision is defensible. Together they create a centralised export layer whose price and governance belong to the platform.

For high-volume applications, per-gigabyte NAT processing can matter. For low-volume but always-on environments, hourly gateway charges can matter. For multi-zone resilience, duplicate gateways can matter. For regulated environments, logs can matter. For payment and public-sector systems, external IPs can matter. The company rarely buys "NAT" alone. It buys a bundle of translation, availability, external identity, data movement and evidence.

IPv4 scarcity is the background condition that makes this bundle politically significant. If public IPv4 were abundant and portable, a company could more easily design its own egress identity across providers. With scarcity, the managed NAT bundle becomes a substitute for public address independence. It lets the company avoid assigning public addresses to every workload, but it can also make the provider the default owner of the public edge.

External IP charges change the meaning of "no public servers"

Cloud teams often say that an application has no public servers. That may be true and still misleading. The application may have no publicly reachable compute instances, while still consuming public IPv4 through load balancers, VPN endpoints, NAT gateways, bastion paths, managed databases, private connectivity products with public control paths, global accelerators or other service edges. "No public servers" does not mean "no public identity." It means public identity has moved into platform resources.

AWS's VPC pricing page makes this distinction visible by charging hourly for public IPv4 addresses associated with resources in relevant VPC contexts, whether in use or idle, while treating customer-provided address arrangements separately. The detail matters because it pushes customers to audit where public IPv4 exists and whether each address is worth keeping. It also encourages designs in which public exposure is concentrated into fewer managed resources.

Google Cloud's Public NAT page folds external IP cost directly into the NAT calculation. The NAT gateway does not merely process traffic; it uses external addresses that have their own hourly cost. The company's egress identity is therefore priced as part of the translation design. It is not hidden in a vague connectivity bundle. It appears as a resource attached to a gateway.

Azure's NAT Gateway design similarly depends on public IP addresses or prefixes attached to the gateway, even where the pricing page separates the NAT gateway charge from other bandwidth and public IP price categories. The architecture is the same at a higher level. A private subnet sends outbound traffic through a provider-managed resource that owns or uses public-facing addresses.

This changes the politics of public reachability. In the older hosting model, a public IP address could feel like a small operational allocation. In cloud, public IPv4 becomes a governance signal. Idle addresses trigger cost controls. In-use addresses become tags in billing reports. External IPs are attached to projects, subscriptions, accounts or resource groups. A platform team can ask why a workload has a public address. A finance team can ask who owns the charge. A security team can ask whether the address is approved.

Those questions improve hygiene. They also normalise a world in which the provider mediates every public IPv4 decision. The company is not simply counting addresses; it is counting provider-controlled address resources inside provider-defined scopes. If it lacks an independent public IPv4 plan, it may come to see provider egress addresses as the natural unit of internet identity.

For African companies, the distinction is important because public IPv4 independence may already be difficult. Phase 2 allocations cannot satisfy large growth demand. Market purchases require capital, diligence and transfer confidence. Leasing requires continuity evidence and contract clarity. AFRINIC's recent history adds a perceived risk premium. Against that background, paying for provider external IPs and NAT gateways can feel simpler. The simplicity is real. So is the dependency.

The sentence "we have no public servers" can therefore become a comfort blanket. The better question is: whose public addresses carry the company's economic relationships? If the answer is the cloud provider's address pool, then the company has not escaped IPv4 scarcity. It has outsourced the public face of scarcity to a platform.

Egress identity becomes a banking and procurement dependency

The first users to notice a public egress change are often not users at all. They are counterparties. A bank has a list of source addresses allowed to call a payment API. A card processor has fraud rules built around expected origins. A public agency has a supplier record that names endpoints and security controls. A sanctions-screening provider watches for unusual access. A managed-security vendor correlates source addresses with tenants. An enterprise customer has written the supplier's public egress ranges into a firewall change request that took six weeks to approve.

In those environments, egress identity is part of the commercial contract even when the contract does not say so elegantly. The address is a trust shortcut. It is not sufficient for security, but it is common in security practice. It reduces noise for counterparties. It helps incident response. It gives procurement teams something concrete to record. It gives auditors a trail.

Cloud NAT concentrates this trust shortcut. A company may route many private workloads through a small number of public egress addresses because that is easier for partners to allowlist. The design is efficient until the company wants to change provider, region, account or architecture. Then the same concentration becomes a migration queue. Each counterparty must be notified, tested and sometimes persuaded. If the egress addresses are provider-owned, the company cannot simply take them away. It must ask partners to trust new provider addresses or move through a customer-controlled prefix if it has one.

The cost is not only engineering labour. It is institutional time. Bank allowlist changes can require risk committees. Public-sector procurement changes can require contract amendments. Health or education systems may need security sign-off. Cross-border payment partners may require compliance review. A small African SaaS provider may have fewer staff to run that process than a global platform, yet it faces the same counterparty conservatism.

This is where cloud NAT becomes platform power. The provider does not need to impose a punitive exit fee. The egress identity has become embedded in the customer's partner network. Moving away from the platform means asking external institutions to repeat trust work. The provider's address pool has become part of the customer's reputation.

Portable IPv4 reduces that dependency if it is trusted. A company that can bring a recognised prefix to one cloud, route it from another, move it to a regional data centre and retain reverse DNS and routing evidence can preserve partner trust across infrastructure choices. The company still needs migration discipline, but it is not rebuilding public identity from scratch. It owns the continuity layer.

AFRINIC's contribution should be to make that continuity credible for African-administered resources. It should not decide whether a fintech uses AWS, Azure, Google Cloud, a local provider or a hybrid design. It should maintain records and services so that a customer-controlled address plan can be financed, contracted and accepted. When the ledger is uncertain, bank and procurement friction reinforces platform egress. The cloud bill then becomes a substitute for institutional trust.

Logs and telemetry make the NAT bill bigger than the gateway

The visible NAT charge is only the beginning of the evidence cost. A regulated workload cannot simply send traffic through a gateway and hope. It needs logs, flow records, metrics, alerts, retention policies, access controls, query paths and sometimes export into analytics systems. It needs to prove which workload used which egress address at which time. It needs to distinguish a vendor call from a suspicious outbound connection. It needs to answer incident questions without giving too many people access to sensitive traffic metadata.

Google's Cloud NAT pricing page points directly to this wider cost by separating Cloud NAT logging pricing into Network Telemetry, Cloud Logging, BigQuery or Pub/Sub charges. Azure's page lists a NAT Gateway Flow Logs category for the newer flow-log path. AWS places NAT gateway metrics and flow visibility inside its broader VPC, CloudWatch, flow-log and telemetry ecosystem rather than making the NAT gateway charge the whole story. The product details differ, but the pattern is the same: egress evidence is a platform service stack.

This matters because NAT without evidence is a weak compliance story. A board may approve private subnets because they reduce exposure. An auditor will then ask how outbound movement is monitored. A bank may accept a source address, then ask how the company detects unauthorised use of that address. A public agency may ask how logs are retained and who can view them. A security team may require VPC flow logs, NAT logs, DNS logs, proxy logs, identity logs and cloud-account audit logs to be correlated.

Each layer creates cost and lock-in. Logs are priced by volume, storage duration, query frequency and export path. Analytics pipelines are built around provider-native formats. Alerts are written in platform-specific rule languages. Dashboards rely on provider metrics. Incident responders learn where to click. Data may be copied into BigQuery, Cloud Logging, CloudWatch, Azure Monitor, a SIEM or a data lake through provider-specific connectors. A NAT design therefore becomes an observability design.

For an African company paying in hard currency or through regional cloud resellers, these charges can be difficult to predict. NAT data processing may sit in one line. External IPs in another. Data transfer out in another. Logging in another. Analytics queries elsewhere. A local finance team may not see the true egress-identity cost until several months of traffic patterns have accumulated. By then, partner allowlists and architecture defaults may already be built around the provider.

The telemetry question also affects control. If the logs proving egress identity live primarily inside one provider, exit requires rebuilding evidence elsewhere. The company must show partners that new logs are equivalent, that retention is adequate, that access controls are strong and that incident processes still work. That is not impossible. It is another switching cost.

The registry layer does not replace cloud telemetry. AFRINIC records cannot tell a company which container called a vendor at noon. But registry certainty can reduce the need to make platform logs carry the entire trust story. If a company has stable, portable public identity with clear holder and authorised-use evidence, cloud telemetry is operational evidence, not the only evidence of continuity. If the address record is weak, platform telemetry becomes part of the provider's trust moat.

Cloud account architecture turns addresses into organisational power

Cloud NAT is not only a network service; it is an account-governance decision. In a serious cloud estate, accounts, subscriptions, projects and landing zones are designed around teams, environments, billing centres, security boundaries and regulatory obligations. The NAT gateway sits somewhere in that structure. It may be centralised in a shared network account, duplicated per application account, attached to a hub-and-spoke design, deployed per region, or managed by a platform team that serves many product teams.

Each choice changes organisational power. A central egress account gives a platform team leverage over which workloads can reach the internet, which external IPs are used, which logs are retained and which exceptions are allowed. Distributed egress gives product teams more autonomy but makes cost, logging and partner allowlists harder to manage. Multi-account architectures can improve security while complicating address continuity. A merger, spin-out, vendor handover or public-sector outsourcing contract can become difficult if the public egress identity is trapped in the wrong account boundary.

This is not a theoretical problem. A fintech may separate production from development, regulated workloads from marketing tools, regional subsidiaries from the parent company, or customer environments from internal systems. If all outbound traffic exits through a central platform account, that account becomes a miniature network operator. It holds the public egress identity of the company. It also holds the permissions to change routes and logs. The internal politics of cloud governance become the politics of public identity.

Provider-managed routing deepens the dependency. Route tables, NAT associations, internet gateways, firewalls, private links, service endpoints and transit constructs are expressed through platform APIs. Infrastructure-as-code templates encode them. Policy engines enforce them. Cost allocation tags classify them. A company that wants to move from one cloud to another cannot simply copy a router configuration. It must translate an organisational model.

External IPs are especially sticky because they connect internal account design to external trust. A bank may not care which project owns a NAT gateway. It cares that traffic arrives from an approved address. If the company reorganises cloud accounts and the address changes, external friction appears. If the address belongs to the provider, account architecture and provider identity are intertwined. If the address belongs to the customer, the company has more room to reorganise without changing every partner relationship.

AFRINIC-region address certainty matters because it can give African firms a counterweight to platform account power. A recognised, portable prefix can be assigned across internal cloud structures and moved across providers if the technical and contractual conditions are met. The company still depends on cloud implementation rules, but the public identity is not born inside a provider account. Without that independence, the platform account becomes the container for both the application and its public economic face.

The narrow registry function again becomes commercially large. Accurate holder records, authorised contacts, reverse DNS, routing evidence and transfer or leasing clarity help a company prove that public identity belongs in its own governance model. If those records are contested, stale or discretionary, the cloud account's provider addresses look safer. Organisational power then shifts from the company to the platform through a thousand ordinary route-table decisions.

AFRINIC uncertainty makes independent egress harder to underwrite

The AFRINIC context should be handled without pretending courts and public disputes have already answered every question. The reliable point for economic analysis is that the registry layer has been unusually visible as a source of risk. Reporting has described allegations that African IPv4 records were manipulated or misappropriated, with KrebsOnSecurity covering a reported $50 million address-heist investigation in 2019. Internet Governance Project analysis in 2021 described the Cloud Innovation conflict, AFRINIC's attempted resource action, court proceedings and bank-account freezes. Later reporting covered receivership, election disputes, annulment and renewed board efforts. The Register reported in 2026 that AFRINIC was presenting signs of recovery, while also covering continuing litigation and ICANN intervention in a winding-up context.

A cloud architect does not need to adjudicate those fights. A bank risk officer does not need to decide which party in every case has the better legal argument. A public-sector procurement board does not need to master the history of regional internet registries. They only need to ask whether an address plan has a dependable evidence chain. If the answer requires explaining years of litigation, receivership and contested authority, the independent address path carries a premium.

That premium affects cloud NAT because independent egress is the alternative to provider-owned egress. A company could lease a block, acquire addresses, bring a prefix into cloud, use it for egress, maintain reverse DNS, keep partner allowlists stable and preserve exit options. That plan needs underwriting. Legal teams must review the lease or transfer. Cloud teams must validate routing and platform support. Finance teams must compare address cost against NAT and external IP charges. Counterparties must accept the address. Auditors must see continuity evidence.

If AFRINIC-administered space is perceived as fragile, each underwriting step becomes harder. A lessee may ask what happens if a registry dispute affects the lessor. A cloud provider may require clearer authority evidence. A bank may ask why the address record has unusual history. A public agency may prefer provider-supplied cloud addresses because the supplier can point to the platform's operating model. A CFO may accept recurring NAT charges because they are easier to approve than a legally complex address arrangement.

The result is not a formal ban on portable IPv4. It is a discount applied to independence. The company may still be able to use its own addresses, but the effort and uncertainty increase. Platform NAT becomes the path of least resistance. Scarce IPv4 then pushes African workloads toward platform-controlled public identity, not because platforms conspired to take it, but because the neutral evidence path became too costly.

This is why the registry's role should be modest and rigorous. AFRINIC should maintain dependable records, clear authorised-use evidence, precise dispute notations, predictable service updates, reverse-DNS continuity and routing-evidence support. It should not turn every commercial use into a moral test of regional loyalty. The more discretionary the registry appears, the more underwriters will prefer provider-owned egress. The ledger that tries to become a gatekeeper accidentally strengthens the gatekeepers with the largest address pools.

The platform wins when portable IPv4 becomes paperwork risk

Platform power often grows through paperwork rather than coercion. A cloud provider does not have to forbid customer-controlled addresses. It can simply offer a default architecture that works immediately, bill it monthly and make the customer-controlled path require more documents, more approvals, more engineering and more uncertainty. If the customer's independent address evidence is clean, the paperwork is manageable. If the evidence is fragile, the default wins.

The issue here is not primarily that large platforms hold address inventory, validate customer-provided prefixes or price public IPv4. Those facts matter, but they are not the centre of this mechanism. The centre is NAT as an everyday export function. A company that designs around private subnets and managed egress may never make a formal address-acquisition decision. It may simply accept that the platform supplies the external identity for outbound traffic and that NAT, external IPs, logs and data movement are part of the cloud bill.

Paperwork risk then becomes an anti-portability force. To use independent IPv4 for cloud egress, the company must explain why it controls the addresses, who is authorised to route them, how reverse DNS works, how abuse and security contacts are handled, how the cloud account maps to the holder or authorised user, what happens if the lease ends, and how partner allowlists will be preserved. None of these questions is unreasonable. Together they create a transaction cost.

In a region with calm registry records, that transaction cost can be lower than the long-term cost of platform dependency. In a stressed registry environment, the cost rises. The company may decide that monthly NAT and external IP charges are predictable enough, while independent address arrangements are too hard to explain to auditors. The provider wins the egress identity because it can package uncertainty into a single invoice.

The danger is cumulative. The first project uses provider NAT because it is faster. The second project copies the pattern. The platform team builds a standard module. Security approves the module. Finance learns the cost category. Partners allowlist the provider egress addresses. Logs and dashboards are built around them. After two years, the company has a cloud NAT estate, not just a NAT gateway. Exit now means changing architecture, evidence, finance practice and counterparty trust at once.

This is how scarcity becomes platform power. The cloud provider does not need ownership rhetoric. It sells working infrastructure. The customer's outside alternative is a portable address plan. If AFRINIC-region address certainty is weak, that outside alternative becomes slower and harder. The provider's NAT product becomes the rational default and then the institutional habit.

The policy answer is not to punish the default. Many defaults are good. The answer is to reduce the paperwork premium for legitimate portable address use. Clear transfer and leasing rules, recognised authorised-use documentation, reliable reverse DNS, precise dispute states and stable routing-evidence services make the independent path easier to underwrite. They make NAT a choice rather than a trap.

Multi-cloud strategy collides with NAT-specific state

Executives often say they want multi-cloud strategy. Cloud NAT is one reason that strategy is harder than the phrase suggests. Compute can be redeployed, databases replicated, containers rebuilt and applications refactored. Public egress identity is harder because it is attached to external trust and provider-specific state. Each cloud has its own NAT product, external-IP model, logging pipeline, routing constructs, account hierarchy, quotas, pricing and operational vocabulary.

An application that leaves through AWS NAT Gateway, Azure NAT Gateway or Google Cloud NAT can be architecturally similar while being institutionally different in every practical detail. The gateway is created differently. Logs flow differently. External IPs are reserved differently. Billing categories differ. Route tables and subnet associations differ. High-availability designs differ. Quotas and support paths differ. The names of the resources in a finance report differ. The incident-response runbook differs.

If the company uses provider-owned egress addresses, a second cloud also means new public identities. Bank allowlists, public-sector records, fraud-provider rules and vendor security policies must be updated. Some partners may accept multiple egress ranges. Others may not. Some may take days. Others may require formal review. A multi-cloud strategy that looks credible in a slide deck can stall at the first bank firewall.

Customer-controlled IPv4 can reduce this friction if it can be moved or advertised across platforms under clear conditions. It does not make multi-cloud easy. Providers still have technical rules. Routing must be planned. Traffic engineering must be careful. Logs must be rebuilt. But the public identity can remain more stable. The company can say to partners: the address remains ours; the underlying compute location changes. That is a stronger story than asking partners to trust a new provider-owned address set every time procurement changes.

Multi-cloud exit friction has a special African dimension because local and regional infrastructure choices are still evolving. A company may start in a global cloud region, add a local data-centre partner, use a second cloud for resilience, keep a disaster-recovery site in another jurisdiction or repatriate a public-service workload after a political decision. If public egress identity is provider-bound, every infrastructure move becomes a counterparty exercise. If address identity is portable and trusted, infrastructure markets become more contestable.

AFRINIC cannot make cloud providers harmonise NAT products. It can make the address layer less fragile. A recognised prefix with accurate records, clear authorised use and continuity services lets a company design multi-cloud and hybrid architecture around a public identity it can carry. That reduces the market power created by NAT-specific state.

The alternative is a world in which multi-cloud exists mainly above the waterline. Applications may be portable in code, but the egress addresses, logs, partner records and procurement files anchor them to one provider. The company discovers that the hardest part of leaving is not the container image. It is the public identity that private subnets exported through a platform gateway.

Local hosting inherits the same dependency

Cloud NAT power is not limited to hyperscale regions. Local hosting providers, managed-service firms, banks, universities, public agencies and data-centre operators inherit the same dependency when their customers accept provider-controlled egress as the normal public identity model. A local provider may host the compute, but if customers rely on a hyperscale cloud or upstream platform for external IP continuity, local infrastructure remains subordinate to the platform's address layer.

This can happen quietly. A local data centre offers managed Kubernetes or virtual private servers. It peers locally and provides good latency. Customers still place critical outbound integrations in a global cloud because the cloud provides stable egress, mature NAT services, logs and recognised external IPs. Or a local managed-service provider builds on top of a hyperscale network account because customers trust the provider's compliance tooling more than a direct local address plan. The local supplier wins some operational work but loses the public identity layer.

That matters for industrial development. Local hosting is not only racks and power. It is the ability to support customer trust, payment connectivity, public-sector procurement, security evidence, abuse handling, reverse DNS, geolocation and address continuity. If the scarce public IPv4 story is weak, local providers may be forced to rely on upstream platform identity or buy expensive workarounds. Their technical proximity to African users does not automatically give them control over public reachability.

Bank and payment partners amplify this. They are conservative for good reasons. If a local provider cannot present a clean address-evidence package, a bank may prefer the egress ranges of a major cloud even when the workload could run locally. Public agencies may write tenders that reward recognised cloud controls without asking whether public identity is portable. International vendors may accept provider egress faster than regional address evidence. The result is not always better security. It is often lower paperwork cost.

The currency and payment channel also matter. Cloud NAT, external IP and logging charges are often paid in hard currency or through reseller arrangements. IPv4 leases or transfers may also be dollar-priced, but they can create portable value if the evidence is strong. A local provider facing currency volatility must compare recurring cloud egress charges against the cost and risk of obtaining or leasing independent space. Registry uncertainty pushes the comparison toward the platform because the platform bill is easier to understand, even when it compounds over time.

The development question is therefore not whether African firms should avoid global cloud. They should use whatever infrastructure serves customers best. The question is whether local and regional providers can compete for workloads without being structurally disadvantaged at the public identity layer. AFRINIC's ledger certainty is one of the conditions for that competition.

If AFRINIC records are boring, local providers can build credible address plans, customers can use portable prefixes, and cloud platforms compete on service quality. If the records are risky, global platforms sell not only compute but the relief of avoiding the registry file. Local hosting then competes with one hand tied.

FinOps sees the bill after architecture has made the choice

Cloud cost management often arrives after the first architecture has become normal. The NAT gateway exists. The private subnets route through it. The external IPs are allowlisted. The logs feed dashboards. The platform team has a module. Developers know how to request exceptions. Then the FinOps team asks why network egress and NAT processing are rising.

The answer is rarely one mistake. It is usually the sum of many reasonable decisions. Workloads in private subnets need outbound access. High availability duplicates gateways. Traffic to external APIs grows with customer success. Data transfer out is charged. Logs are retained for compliance. External IPs are kept stable for partners. Test environments copy production patterns. Idle resources are not cleaned up because nobody wants to break an allowlist. The bill reflects architecture as culture.

Managed NAT is particularly opaque because its cost is distributed across categories. Gateway hours, per-GiB processing, external IP charges, data transfer out, logging ingestion, storage, analytics queries and SIEM export may appear in different places. A finance lead may see a network bill but not the partner-trust reason behind it. An engineer may see a routing pattern but not the hard-currency cost. A security lead may require logs but not see the cost of retaining low-value traffic. Each department holds part of the truth.

This opacity is a platform advantage. The provider sells integrated convenience. The customer pays through multiple meters. By the time optimisation begins, the public egress identity may already be embedded in external relationships. Reducing cost is no longer a simple matter of deleting a gateway. It may require redesigning subnets, adding private endpoints, changing vendor integrations, adjusting logs, splitting traffic, moving to IPv6 where possible, renegotiating allowlists and perhaps introducing customer-controlled public IPv4. That is a programme, not a ticket.

For African firms, the financial effect can be sharper because cloud bills may be paid in currencies stronger than local revenue. A NAT cost that looks modest in a US pricing example can be meaningful for a company earning in naira, shillings, cedis, rand, rupees or other regional currencies, especially when bandwidth, logs and support are included. Public-sector buyers may impose fixed budgets while requiring cloud security patterns that increase egress and evidence costs. Startups may delay optimisation because growth pressure dominates.

FinOps should therefore treat NAT as a public-identity cost, not merely a network line. The question is not only "how many gigabytes passed through the gateway?" It is "which business relationships require this egress identity, which traffic can use private service paths, which logs are evidence rather than noise, which external IPs are strategic, and which provider dependencies would be expensive to unwind?"

AFRINIC's role is indirect but real. If portable address paths are credible, FinOps can compare platform NAT against independent egress options. If those paths are uncertain, FinOps can only optimise inside the provider's menu. That is not full cost management. It is bargaining within a dependency.

IPv6 helps, but outbound IPv4 does not vanish on schedule

IPv6 is essential to any honest long-term answer. It reduces the need to ration public identity through IPv4 translation and allows cleaner end-to-end designs where counterparties support it. Cloud providers offer extensive IPv6 features, and African networks should deploy IPv6 seriously. But IPv6 does not make the medium-term cloud NAT problem disappear.

The reason is not technical ignorance. It is counterparties. A workload may support IPv6, while a bank API, government endpoint, fraud vendor, old enterprise firewall, SaaS integration, monitoring service, payment processor, customer device or data partner still requires IPv4. A company does not retire IPv4 when its own architects are ready. It retires IPv4 when enough of its external relationships stop pricing IPv4 compatibility.

Cloud NAT exists in that coexistence period. It is the practical bridge from private cloud resources to IPv4 destinations. Even if inbound services become dual-stack or IPv6-first, outbound dependencies can keep IPv4 egress alive for years. Logs, allowlists and procurement files will reflect that hybrid reality. The NAT gateway may shrink over time, but the trust attached to its public addresses can remain important.

The point is narrower than the familiar IPv6-transition argument. Platform-managed IPv4 egress can become more powerful precisely because IPv6 progress is partial. Managers hear that IPv6 is the future and therefore hesitate to invest in portable IPv4. Engineers still need IPv4 egress for real counterparties and therefore buy NAT services. The company gets neither full independence nor full transition. It rents a bridge for longer than expected.

Providers are well positioned in this bridge period. They can offer IPv6 features, IPv4 NAT, external IPs, private service access, logging, firewalls and dual-stack patterns as one integrated architecture. Customers benefit from that integration. They also become dependent on the provider's interpretation of coexistence. If independent IPv4 is costly or uncertain, the bridge belongs to the platform.

AFRINIC should not use IPv6 optimism to avoid IPv4 ledger discipline. Its exhaustion page itself frames IPv4 scarcity and IPv6 transition together, but transition does not erase the need for current records. During coexistence, African firms need accurate IPv4 recognition, transfer and leasing clarity, reverse DNS, routing evidence and predictable services. Those are not anti-IPv6 demands. They are the conditions that keep IPv4 compatibility from becoming a platform monopoly while IPv6 adoption proceeds.

The practical policy is dual. Accelerate IPv6 where it genuinely reduces dependence on IPv4 egress. At the same time, keep IPv4 records clean enough that the remaining IPv4 dependency is contestable. Pretending IPv4 cloud egress has disappeared is not transition policy. It is a gift to the providers that sell it as a managed service.

The registry's job is ledger certainty, not cloud policy

The strongest response to platform power is not for AFRINIC to become a cloud policy-maker. That would repeat the mistake at the heart of many registry disputes: coordination bodies become dangerous when they confuse record-keeping with authority. A registry is necessary because uniqueness, records, contacts, delegations and routing evidence need a trusted public reference. That necessity does not make the registry a sovereign over business models.

For cloud NAT, the distinction is decisive. AFRINIC should not decide whether an African company uses managed NAT, provider-owned public IPv4, customer-owned prefixes, leasing, local hosting, global cloud, hybrid architecture or IPv6-first design. Those are commercial, technical and regulatory decisions made by the companies and customers that bear the consequences. The registry should make sure that the address evidence behind those decisions is accurate, updateable and not subject to arbitrary surprise.

Ledger certainty has several parts. Holder records must be dependable. Authorised-use evidence must be legible when the holder, operating company, cloud account and route origin differ. Transfers and leases must have clear treatment so counterparties can distinguish legitimate use from fraud. Reverse-DNS delegation must be maintained as a continuity service. Routing-evidence services should remain predictable and narrow. Dispute states should be precise enough that banks, clouds and customers understand what is actually contested. Routine services should not be held hostage to unrelated institutional politics.

This is not a call for weak controls. Fraudulent documents, account takeovers, forged authority, corrupt record changes and hijacked dormant resources require strong correction. The 2019 address-heist reporting shows why the ledger must be protected from manipulation. But correction should be evidence-based, bounded and reviewable. It should not become an open licence for the registry to re-judge every commercial use after the fact.

Cloud NAT makes this discipline more urgent because the outside alternative is so easy. If AFRINIC makes independent address use uncertain, cloud platforms are ready with managed egress. If AFRINIC keeps the ledger boring, platforms must compete against portable identity. The registry does not need to fight cloud. It needs not to make cloud the only practical way to obtain public identity.

This is the paradox. A registry that expands discretion in the name of protecting regional resources may push regional workloads into global platform egress. A registry that restrains itself to accurate records may do more for African infrastructure sovereignty than a thousand speeches about stewardship. The boring ledger is not a retreat from policy. It is the institutional condition for real choice.

Policy should make cloud NAT costs visible

Cloud NAT costs should not be hidden inside a general cloud-adoption narrative. They should be measured as part of public identity economics. A company or public buyer should be able to ask how much it pays for NAT gateway hours, per-GiB processing, external IPs, data transfer out, logging, telemetry, SIEM export, high availability, support and partner allowlist maintenance. It should also ask which of those costs would change if the company controlled portable public IPv4, used private service paths, moved to IPv6 for specific counterparties or changed providers.

The first policy implication is transparent cost accounting. FinOps teams should classify NAT and external IP spend separately from generic networking. They should attach business reasons to stable egress addresses: bank allowlist, public agency integration, fraud vendor, software repository, monitoring vendor, customer API, disaster recovery. They should identify logs that support evidence and logs that exist only because nobody reviewed retention. They should show the currency exposure of recurring egress charges.

The second implication is procurement discipline. Public-sector and regulated buyers should ask suppliers not only where data resides, but who controls public egress identity and how it can move. A tender that requires cloud hosting but ignores egress portability may accidentally buy platform lock-in. A bank allowlist process that accepts provider addresses quickly but treats customer-controlled African prefixes as suspicious may entrench the platform. A better process would evaluate evidence quality, not brand familiarity.

The third implication is cloud-account governance. Companies should know which team can create, delete or change NAT gateways, external IPs and route tables. They should require change records for production egress. They should test whether logs can prove the use of an egress address without exposing excessive metadata. They should rehearse region or provider exit for at least one critical partner, because the exercise will reveal whether public identity is portable or merely hoped to be.

The fourth implication is registry evidence. AFRINIC should publish and maintain predictable paths for authorised-use recognition, reverse DNS, routing evidence, transfer and leasing clarity, and dispute notation. The goal is not to create a cloud-specific approval office. The goal is to let a cloud, bank, auditor or public buyer understand the address file without treating every African-administered prefix as a legal research project.

The fifth implication is IPv6 realism. Every NAT-cost report should identify which outbound dependencies can move to IPv6 and which cannot. That reduces NAT traffic where transition is real, while preventing managers from using IPv6 rhetoric to ignore continuing IPv4 costs. IPv6 progress and IPv4 ledger certainty are complements during the bridge period.

These policies are not glamorous. They do not promise to defeat platforms. They make the price of platform egress visible and the alternative credible. That is enough. Markets change when hidden dependencies become measurable and when outside options can be financed.

The boring ledger is the anti-platform policy

The final lesson is institutional. Cloud NAT is powerful because it is ordinary. No one needs to announce a new regime of platform control. A developer creates private subnets. A platform team attaches NAT. A finance system records hourly and per-gigabyte charges. External IPs become allowlisted. Logs become compliance evidence. A public agency accepts the supplier's cloud architecture. A bank records the egress address. A second workload copies the same pattern. After enough repetitions, the platform controls the company's public IPv4 export function.

IPv4 scarcity is the pressure behind the pattern. Public addresses are too valuable to scatter casually across every workload, so private architecture and managed egress are rational. AFRINIC's Phase 2 reality confirms that large fresh allocations are not the African growth answer. But scarcity alone does not decide who controls the public identity. Institutions do. If the registry layer is trusted, independent and leased address paths remain viable. If it is uncertain, provider NAT becomes the lowest-friction answer.

This is why AFRINIC's recovery should be judged by market boringness, not by institutional drama. Can a company show a clean record? Can an authorised user prove use without exposing private customer data? Can reverse DNS and routing evidence be maintained through ordinary processes? Can disputes be marked precisely rather than allowed to contaminate unrelated services? Can transfers and leases be understood by banks and cloud providers without ideological theatre? Can routine continuity survive board, court and election stress?

If the answer is yes, African firms gain bargaining power. They can use AWS, Azure, Google Cloud, local data centres, carriers and hybrid systems on commercial terms. They can pay for NAT where it is efficient, use provider addresses where convenient, and still preserve a path to portable public identity where business continuity requires it. Platforms remain important suppliers, but they do not become the unavoidable owners of public egress.

If the answer is no, the result will not be a noble protection of African resources. It will be a quieter dependence. Workloads will sit in private subnets. NAT gateways will meter the export of traffic. External IPs will sit in platform accounts. Logs will live in provider telemetry systems. Bank and public-sector allowlists will recognise provider ranges. Local hosting will borrow public identity from upstream platforms. FinOps teams will optimise within the menu they inherited. The registry will still exist, but its uncertainty will have made the platform more powerful.

The correct role for AFRINIC is therefore small and severe: protect the ledger, not the gatekeeper. Keep records accurate. Keep services predictable. Keep disputes bounded. Keep authorised use legible. Keep reverse DNS and routing evidence available as continuity infrastructure. Do not launder business-model judgments through registry discretion. Do not pretend IPv6 has already removed the need for IPv4 egress. Do not make a cloud provider's NAT gateway the safest way for an African company to have a public face.

Cloud NAT will remain useful. Private subnets will remain good architecture. Managed egress will remain a legitimate service. The question is whether those tools are chosen because they are efficient or because registry uncertainty has made independence too costly. AFRINIC cannot control the clouds. It can control whether its own record layer is boring enough that African firms have a real choice.