Summary

  • Cloud NAT is not merely a technical device for hiding private subnets. In cloud markets it becomes the place where public IPv4 scarcity, egress identity, pricing, account custody, allowlists, and provider-controlled routing meet.
  • Large platforms convert scarce address capacity into address power when their public IPv4 pools, NAT gateways, BYOIP admission rules, account controls, and deprovisioning procedures determine whether an Asia-Pacific operator can keep a stable public identity outside the platform.
  • APNIC matters in this chain because reliable registry records, RDAP, Whois, transfer evidence, RPKI/ROAs, and address-history records give resource holders an outside option. But the registry's strongest role is narrow evidence infrastructure, not cloud-architecture supervision.
  • The policy risk is subtle: if registry evidence is slow, unclear, non-portable, or entangled in discretionary approval, cloud provider addresses become the default identity layer. That shifts bargaining power from networks that hold address capital to platforms that rent, meter, and administer address use.

The moment of truth in a cloud migration often arrives in a spreadsheet no customer ever sees. A Singapore fintech has moved its ledger, fraud engine, and customer-notification service from two colocation rooms into a public cloud region. The compute plan is approved. The Kubernetes clusters are private. The security team likes the idea that application servers no longer carry public addresses. The finance team likes the smaller rack footprint. Then the bank-integration team asks a pedestrian question: what source IP addresses should be sent to the banks, payment networks, fraud vendors, tax portals, and SMS providers that allowlist the company's outbound traffic?

The first answer is architectural. The workloads will sit in private subnets. Outbound traffic will pass through managed NAT gateways. The NAT gateways will use a small set of public IPv4 addresses. Those addresses will be recorded in partner allowlists. Logs will map internal workload identity to external source address and port. The provider's monitoring will show bytes, packets, connection counts, failures, and charges. On the diagram, this is clean. Private inside, public outside, controlled choke point in the middle.

The second answer is economic. Those public IPv4 addresses are not just numbers. They are credentials embedded in counterparties' operational memories. They determine whether a bank accepts an API call, whether an anti-fraud engine treats a request as familiar, whether an e-mail vendor sees continuity, whether a regulator's filing endpoint avoids a manual exception, and whether an incident responder can separate the company's traffic from the platform's other tenants. Changing them is not like changing a subnet label. It is closer to changing a business passport.

The third answer is institutional. Who controls the addresses? If the fintech uses cloud-provider addresses, the provider supplies the public egress identity, prices it, attaches it to the account, and can change the rules around reservation, movement, deletion, abuse handling, region use, and billing. If the fintech brings its own APNIC-registered IPv4 range, it may preserve its external identity, retain reputation, and reduce dependence on the provider's pool. But it must pass the provider's BYOIP admission process, create the right routing authorization, bind the range to the right account and region, accept platform-specific limits, and deprovision carefully before moving the same range elsewhere.

That is the real subject. Cloud NAT is often described as a convenience for private networks. It is also a mechanism through which cloud platforms turn address scarcity into platform power. The power is not crude. It is not a visible monopoly over packets. It is distributed across product defaults, public IPv4 charges, NAT processing charges, BYOIP eligibility, account controls, routing authorization, abuse reputation, partner allowlists, and the operational pain of leaving. In Asia Pacific, where fast-moving cloud adoption sits beside mature telecom incumbents, national cloud projects, fintech integration, gaming platforms, and fragmented regulatory jurisdictions, the result is a quiet shift in who owns the public face of a service.

This is not a cloud product explainer. NAT gateways, elastic IP addresses, custom prefixes, external addresses, public advertised prefixes, and elastic IP services all differ across providers. The names change. The underlying economics are stable. A platform with large public IPv4 inventory can sell convenience. A customer with portable address capital can negotiate. A customer without portable address capital rents identity from the platform. APNIC's records do not decide which architecture the customer should choose. They decide whether the customer can prove enough control over its own address resources to make choice meaningful.

The public address became the egress credential

Most application teams learn address economics in reverse. They first discover private addressing because it is cheap, abundant, and easy to automate. Cloud templates create private subnets. Container nodes receive private addresses. Serverless and managed services hide source hosts. Security groups, routing tables, and identity policies appear more important than public numbering. Public IPv4 feels like the old Internet: necessary at the perimeter, but no longer the center of design.

That impression is partly true inside the platform. It is false at the boundary. The outside world still sees source addresses. Banks still ask for static egress ranges. Government gateways still ask suppliers to declare public endpoints. Legacy fraud vendors still score IP reputation. SaaS vendors still apply rate limits, country rules, and tenant histories to source networks. Mail systems still remember prior behavior. Games and ad platforms still fight abuse by combining account signals with IP signals. Security operations centers still write exceptions around known egress IPs because exceptions around abstract cloud identities rarely cross organizational boundaries.

The result is a split identity. Inside the cloud, identity is account, role, workload, service principal, policy, and tag. Outside the cloud, identity is still a public IP address, a prefix, an ASN, a reverse-DNS pattern, a geolocation record, a reputation history, and a set of partner allowlists. NAT is the translator between the two worlds. It compresses many private workloads into a smaller number of public identities, and then asks the rest of the Internet to trust those identities as if they represented a coherent operator.

Compression is useful. It reduces public IPv4 consumption. It makes private-subnet design manageable. It limits the number of addresses that have to be placed into partner allowlists. It gives security teams a small set of egress choke points for logging and policy. But compression also creates custody. If the external address belongs to the platform, the platform is not only selling compute and network transit. It is renting the customer's public face.

The rent is not only the published hourly price. It includes the dependency built into every contract and allowlist. A fintech that has sent ten thousand partner requests to whitelist four cloud addresses has created a switching cost. A game operator that runs anti-cheat, payment, and customer support through provider-owned egress addresses has created a reputation dependency. A public-sector vendor that certifies a small set of cloud NAT addresses for document submission has embedded those addresses into procurement, audit, and incident playbooks. The customer may own its code and data. The platform may still own the address memory through which the outside world recognizes the service.

This is why cloud NAT belongs in the economics of IPv4 scarcity. NAT makes scarce addresses stretch farther, but the stretching happens through an institutional intermediary. When that intermediary is a carrier, the debate becomes CGNAT, logging, lawful requests, abuse attribution, and support cost. When the intermediary is a cloud platform, the debate becomes public IP pricing, account authority, provider pools, BYOIP admission, and cloud exit friction. Both are scarcity responses. They allocate different forms of power.

Pricing made the address visible again

For a decade cloud users were trained to treat public IPv4 as an accessory. It was bundled into a machine, load balancer, gateway, or managed service. Some charges existed for idle reservations, but the address itself did not always appear as a universal line item. That made the economics easy to ignore. Engineers optimized compute, storage, database licensing, data transfer, and observability. Address count was a hygiene issue.

The recent pricing shift changed the psychology. AWS introduced a charge for all public IPv4 addresses, whether attached to a service or idle. Its public material set the published rate at USD 0.005 per IP hour, while its NAT gateway pricing also charges for gateway hours and data processed. Google Cloud prices in-use external IPv4 addresses and also counts external IP addresses used by Cloud NAT in its network pricing table. Azure charges for NAT Gateway resource hours and data processed, and its public IP address pricing treats public IPv4 prefixes as charged per IPv4 per hour unless they derive from custom BYOIP prefixes. Alibaba Cloud's public Elastic IP model includes data-transfer or bandwidth charges and a configuration or retention fee in many cases, while its BYOIP documentation describes migration of customer public IPv4 ranges so public-facing service IPs can remain unchanged.

The exact rates vary by provider, region, service class, and contract. That variation is not the point. The point is that public IPv4 has returned as a priced unit of cloud design. NAT gateways now sit between two forms of scarcity pricing. One is the cost of the public addresses themselves. The other is the charge for using managed translation as the path from private workloads to the Internet. The charge may be small beside application revenue, but small charges can still reveal who controls a scarce input.

For a small deployment, USD 0.005 per hour is not existential. For a sprawling enterprise estate with hundreds or thousands of public addresses, test accounts, public load balancers, NAT gateways, managed services, and forgotten reservations, the bill becomes visible. Finance teams ask why public IP counts are so high. Security teams ask why every workload needs direct exposure. Architects consolidate egress through NAT. Consolidation reduces address count, but it also concentrates identity. Instead of many public endpoints, the company has a few platform-attached egress identities whose failure, reputation, or account problem can affect many services at once.

The pricing shift therefore encourages two opposite behaviours. It rewards customers for reducing public IPv4 use by using private subnets and NAT. It also rewards customers that already control portable IPv4 because BYOIP can preserve continuity and, in some provider models, avoid some public-address charges. A customer without portable resources optimizes inside the provider's address economy. A customer with portable resources can compare the provider's address price with the opportunity cost of using its own prefix. That comparison is bargaining power.

This is where the Asia-Pacific context matters. The region contains global cloud regions, dense financial hubs, outsourced service platforms, mobile-first markets, cross-border gaming and media services, and public-sector digitisation programs. It also contains operators and enterprises with very different address histories. Some incumbents and institutions hold significant APNIC-recognised IPv4 resources. Many newer firms do not. The cloud platform sees both customers through the same console, but their outside options differ. The incumbent can ask whether to bring a prefix. The new entrant may rent the platform's public identity by default.

That distinction should not be confused with a simple rich-versus-poor argument. The deeper point is capital control. Portable IPv4 has become a capital input. If a company controls it, the company can decide whether to use, lease, transfer, reserve, or bring it into a platform. If it does not, the platform's address pool becomes part of the product. The platform's pricing then becomes not only a cost schedule but an allocation system for public identity.

BYOIP is portability, but not independence

BYOIP is the natural answer to platform address power. If a company already has a public IPv4 range with history, reputation, partner recognition, and APNIC registry evidence, why should it abandon that public identity when moving workloads into the cloud? Bring the range. Let the cloud advertise it. Attach addresses to load balancers, NAT gateways, VMs, or other supported resources. Keep the address stable while moving the infrastructure underneath.

The public documentation from major providers describes that promise clearly. AWS allows customers to bring publicly routable address ranges into Amazon EC2 so the range appears in the customer's account as an address pool. AWS prerequisites include RPKI/ROA authorization for Amazon ASNs and a most-specific IPv4 prefix size for onboarding. Azure's custom IP address prefix feature lets a customer bring a contiguous range into a subscription while Microsoft is permitted to advertise it, and addresses from the custom prefix can be used like Azure-owned public IP prefixes. Google Cloud's BYOIP documentation says imported addresses are managed like Google-provided addresses with important exceptions, including that they are available only to the customer that brought them and that Google does not charge for idle or in-use BYOIP addresses. Alibaba Cloud says BYOIP lets customers migrate public IPv4 ranges to Alibaba Cloud so public-facing service IP addresses remain unchanged, with Alibaba advertising the range on the customer's behalf.

These are powerful features. They also show why BYOIP is not pure independence. The customer's address capital enters the provider through a gate. The provider defines minimum prefix sizes, eligible resources, regions, provisioning sequence, verification process, route-origin authorization, account binding, quota effects, and deprovisioning rules. The customer keeps control in the sense that the range remains the customer's. The provider gains operational custody in the sense that it advertises, allocates, maps, and exposes the range within its product system.

That distinction matters because admission is not neutral. A prefix that can be routed on the Internet may still fail a provider's BYOIP process because the route-origin authorization is wrong, the registry records are unclear, the prefix is too small, the holder cannot prove account authority, the current announcement conflicts with the planned cloud advertisement, or the target service does not support the desired use. Each failure becomes a bargaining moment. The customer wants to preserve address identity. The provider wants to protect routing stability, its own reputation, and its product boundaries. APNIC registry evidence is the customer's proof file. But the provider's portal is the immediate gate.

The platform's custody is also temporal. When a BYOIP prefix is being advertised by a provider, the customer cannot treat it as simultaneously free for every other use. Cloud documentation warns against conflicting announcements and often requires deprovisioning or withdrawal before transfer or movement. This is good routing hygiene. It is also an exit cost. A customer that has placed a prefix into one provider must plan a controlled handoff before the same public identity can be moved to another provider or back to self-operated infrastructure. That handoff includes routes, ROAs, reverse DNS, DNS records, load balancer mappings, firewall rules, partner allowlists, security monitoring, and sometimes contractual notices.

The economics of BYOIP therefore sit between ownership-like control and platform custody. A portable prefix gives the holder leverage. It reduces dependence on the provider's public pool. It preserves reputation and partner allowlists. It may reduce public-address charges. It can make multi-cloud or exit planning credible. But it does not erase platform power. It changes the negotiation from "please rent me your public identity" to "please admit my address capital into your platform on terms that do not trap it."

Account authority becomes address authority

Cloud platforms do not usually exercise address power through dramatic decisions about numbering. They exercise it through account systems. A public IP address is attached to an account, subscription, project, region, VPC, resource group, load balancer, NAT gateway, or elastic address pool. The customer must pay the bill, maintain identity and access management, keep the subscription in good standing, protect credentials, comply with abuse and acceptable-use terms, and preserve the configuration that connects the public address to the workload.

This is familiar to cloud operators. It is less familiar to boards that think of IP addresses as network assets. In a colocation or carrier environment, the address-control file may sit with network engineering, legal, and the registry account holder. In the cloud, the effective address-control file may sit across an organization account, a security administrator, deployment automation, a billing relationship, and a service quota. A mistake in any layer can affect public identity.

The risk is not hypothetical. A compromised cloud account can create, delete, reassign, or expose resources. A suspended account can interrupt services. A misconfigured organization policy can prevent a required public-address operation. A deleted NAT gateway can release or detach an address depending on provider mechanics. A failed automation run can move traffic to a new egress identity before partner allowlists are ready. A billing dispute can become a service-continuity issue. A compliance review can prevent a prefix from being onboarded in time for a migration window.

None of these risks mean cloud platforms are careless. In many cases, provider controls are stronger than what a customer could operate alone. The point is different. Platform account authority becomes address authority because the customer's public identity is mediated through the account. If the customer uses provider addresses, the dependence is direct. If the customer uses BYOIP, the dependence remains during the period the provider advertises and manages the prefix.

This gives large platforms a form of address power that is not captured by raw address holdings. Address inventory matters. So does administrative architecture. The platform controls the APIs through which addresses are allocated, the console where NAT is configured, the identity system that authorizes changes, the billing model that prices public use, the abuse team that responds to complaints, the supported services that may use BYOIP, and the deprovisioning sequence that returns the range to customer control. That is not ownership. It is operational leverage.

APNIC's role in this leverage chain is indirect but important. A clean APNIC record does not secure a cloud account. It does not prevent a billing suspension. It does not force a provider to support every BYOIP use case. It does, however, reduce ambiguity about who controls the prefix, which organization can create routing authorization, and what history counterparties should trust. The more precise the registry evidence, the stronger the customer's hand when cloud account authority and address authority begin to blur.

Address reputation is memory, not inventory

Public IPv4 pricing encourages engineers to count addresses. Address reputation reminds them that not all addresses are equal. A clean prefix with long-standing business use, stable geolocation, coherent reverse DNS, low abuse history, and known counterparty allowlists can be more valuable than a newly assigned address from a provider pool. Conversely, a public address with a history of abuse, spam, scraping, fraudulent signups, or misconfigured services can carry a discount even if it is technically routable.

Academic work on cloud IP reuse and cloud squatting has shown why reputation and latent configuration matter. Public clouds allocate and recycle addresses at scale. When services are poorly decommissioned, stale DNS records, third-party integrations, software callbacks, and customer traffic may still point to an address after it has moved. Researchers have demonstrated that address reuse can expose sensitive traffic and create security risks for prior tenants and later holders. Other work on secure IP allocation at cloud scale treats public cloud address pools as security-sensitive resources because malicious tenants can exploit allocation behavior, reputation, and rate-limit assumptions.

For an Asia-Pacific operator moving a regulated service into the cloud, this is not merely a security-paper concern. Address memory can affect bank integration, customer trust, fraud rating, deliverability, support tickets, and incident response. If the service uses provider-owned NAT addresses, it inherits a slice of the platform's pool reputation and the provider's allocation discipline. If it uses BYOIP, it carries its own history into the cloud. Each option has risks. Provider addresses may be operationally convenient but less portable. Customer addresses may be more portable but require stronger evidence, better hygiene, and careful cloud onboarding.

NAT amplifies the importance of reputation because many workloads share the same public identity. If one service behind the NAT gateway behaves badly, counterparties may see the shared egress address, not the internal workload that caused the problem. If a gateway carries payments, analytics, customer messages, vulnerability scanning, software updates, and administrative calls, reputational fallout can become cross-functional. The internal logs may be precise. The outside party may only see the public IP and a timestamp.

This is another way platforms gain leverage. They can offer managed NAT, logging integrations, abuse processes, DDoS protection, IP reputation tooling, and address insight products. Those services are valuable. They also pull the customer deeper into platform-specific observability and response systems. The more the customer relies on the provider to explain, defend, and repair public egress reputation, the harder it becomes to leave quickly.

Portable addresses do not solve reputation by themselves. They can even make the holder more responsible, because the reputation follows the prefix rather than being absorbed into a provider pool. But that is precisely why address capital matters. A customer with its own prefix has an incentive to maintain reputation as an asset. A customer using provider addresses rents reputation indirectly and may find that the provider's administrative response, not the customer's own evidence, determines the speed of repair.

Exit friction hides inside allowlists

Cloud lock-in is usually discussed through databases, proprietary services, data egress, managed Kubernetes variants, identity systems, and operational tooling. Those are real. But for many regulated and B2B services, public egress identity can be just as sticky. The lock-in is not in a code library. It is in other people's firewalls.

Every partner allowlist is a small coordination cost. A fintech may need banks, payment processors, card networks, analytics vendors, tax agencies, customer-support platforms, fraud vendors, and SMS gateways to accept a new source range. A gaming platform may need anti-cheat vendors, payment gateways, CDN origin rules, publisher tools, moderation systems, and regional compliance interfaces to accept the new identity. A public-sector cloud supplier may need procurement files, security authorizations, penetration-test exceptions, audit reports, and operational runbooks updated. Each counterpart has its own change window, risk appetite, form, and evidence standard.

Provider-owned NAT addresses make the first migration easier because the platform supplies a ready public identity. They make the second migration harder because the identity is not truly the customer's. If the customer leaves the provider, the allowlists must be changed. If the customer consolidates accounts, changes regions, rebuilds NAT gateways, or moves to another provider, counterparties must be contacted. If the provider changes product limits or prices, the customer may discover that its address identity is entangled with a commercial relationship it would rather renegotiate.

BYOIP reverses some of that logic. The first migration is harder because the customer must bring the prefix through provider admission, routing authorization, and account controls. The second migration can be easier because the public identity can move, assuming the provider deprovisions cleanly and the next platform admits the prefix. The customer pays upfront complexity to buy future exit optionality.

That optionality has value even if the customer never exits. A credible outside option changes negotiations. A customer that can say "we can move our public identity" is different from a customer that can only say "we can rebuild our applications and ask every partner to change allowlists." The first customer can compare platforms. The second is negotiating with its own past configuration.

APNIC registry evidence is the quiet support for that outside option. The record says who holds the resource. RDAP and Whois make the resource legible. RPKI and ROAs help show which AS may originate the prefix. Transfer logs and historical records help counterparties understand continuity. None of this is glamourous. It is paperwork in the best sense: the evidence that lets a business move without asking a platform to supply identity.

The APNIC issue is evidence quality, not cloud supervision

It would be a mistake to argue that APNIC should regulate cloud NAT design. A registry should not decide whether a customer uses managed NAT, NAT instances, public load balancers, provider addresses, BYOIP, IPv6, dual-stack, or a hybrid arrangement. Those are operator choices. The registry does not pay the cloud bill, run the application, face the bank integration ticket, or answer the incident call.

The useful APNIC question is narrower. Does the registry layer give Asia-Pacific resource holders clear, reliable, portable evidence of address control? Can a holder prove its authority quickly enough to onboard BYOIP? Can it create or adjust routing authorization without unnecessary friction? Can counterparties inspect public records without ambiguity? Can a transfer, merger, or restructuring be reflected in records at the speed commercial life requires? Can a resource holder preserve continuity if one registry-administrative path becomes slow, captured, or disputed?

This is the narrow-registry view. The registry should protect uniqueness, record control, support contactability, maintain security assertions, record transfers, preserve audit trails, and avoid turning scarcity into discretionary command. Once IPv4 becomes capital, the registry's duty becomes more disciplined, not more expansive. The registry record describes control; it should not become a licence over cloud architecture or customer geography.

That doctrine matters because platform power expands when registry evidence weakens. If a customer's own address proof is hard to use, the platform's address pool becomes easier. If registry records are unclear after a merger, a provider address is easier than BYOIP. If transfer recognition is slow, the buyer may delay cloud onboarding or rent provider addresses temporarily. Temporary rentals then become permanent because allowlists accumulate. A small registry friction at the beginning of a migration becomes platform dependency later.

In this way, registry discretion and platform power can reinforce each other unintentionally. A thick registry process does not necessarily keep power in the public-interest layer. It may push customers into private platform identity because the provider's address is simpler to consume. The platform then earns address rent, logs the traffic, defines the account boundary, handles the abuse process, and becomes the practical public identity for the service. The registry has not protected the operator. It has made the operator's outside option more expensive.

APNIC's best contribution is therefore not to make cloud dependence impossible. It is to make address self-possession usable. That means accurate records, predictable transfer recording, timely RPKI operations, clear holder authority, legible RDAP/Whois, bounded enforcement, and portability-oriented procedures. These are not ideological niceties. They are market infrastructure for cloud customers that want to keep their own public identity.

The cloud provider as address allocator

The traditional registry story says APNIC allocates or records Internet number resources, and cloud providers consume them like everyone else. In practice, large platforms also operate private address economies inside their product systems. They decide how many public addresses customers can reserve by default. They decide which services expose public IPv4. They decide whether public endpoints are automatic or explicit. They decide how NAT scales, how many addresses a NAT gateway may use, how ports are allocated, which logs are available, and what price attaches to each unit.

This resembles allocation, although it is not registry allocation. The platform is allocating access to its own public pool and admission to customer-owned ranges. It rations through quotas, prices, support tickets, product limits, anti-abuse controls, and account reviews. It also uses design defaults to shape behaviour. If a managed service makes private connectivity easy and public IPv4 costly, customers consolidate. If BYOIP is limited to larger prefixes or specific resource types, only some customers can preserve identity. If public addresses are easy to create and hard to audit across accounts, customers accumulate address bills until finance intervenes.

This internal address economy is rational from the platform's perspective. Public IPv4 is scarce. Abuse risk is real. Routing stability matters. Provider pools must be protected. The platform needs clear controls because one customer's misuse can affect many tenants. But rational controls still create bargaining power. A provider that manages millions of customer endpoints can convert operational necessity into product dependency.

The market test is whether customers have credible alternatives. A customer may use provider addresses. It may bring its own addresses. It may lease addresses through a third party and bring them where allowed. It may split egress across clouds. It may maintain colocation for public identity and use private connectivity to cloud workloads. It may use IPv6 where counterparties support it while maintaining IPv4 for the rest. Each option has cost. The important point is that APNIC registry evidence lowers the cost of several options and provider custody raises the cost of others.

This also explains why public IPv4 prices inside cloud platforms should not be dismissed as small. A USD 3 to USD 4 monthly address line item is not what gives a hyperscale provider power. Power comes from the bundle: public address inventory plus NAT product plus account system plus logging plus support plus abuse process plus partner allowlist inertia plus BYOIP admission. The price makes the address visible. The bundle makes the platform consequential.

Why this is different from growth pressure and CGNAT

APNIC's region faces real growth pressure. Mobile demand, cloud onboarding, fintech reachability, public-sector digitisation, and incumbent address depth all affect who can expand quickly. That is a separate article's center of gravity. The cloud NAT problem is narrower. It asks what happens after a customer has decided to use a platform and must choose whose public address identity will face the Internet.

CGNAT is also adjacent but distinct. Carrier-grade NAT shifts the cost of shared public IPv4 identity into subscriber attribution, lawful requests, application failures, fraud friction, support calls, and static-address premiums. Cloud NAT shifts the cost into provider egress products, public IP charges, account authority, partner allowlists, address reputation, BYOIP admission, and exit friction. The shared concept is translation. The economic surface is different.

In carrier NAT, the end user may not know that a shared public address is shaping application behaviour. In cloud NAT, the customer usually chooses the architecture, but the choice is constrained by provider products and external counterparties. In carrier NAT, the hard evidence problem is often mapping subscriber, port, and time. In cloud NAT, the hard evidence problem is mapping workload, account, public address, partner exception, and address-control proof across a commercial platform.

The distinction matters because remedies differ. A CGNAT remedy might focus on logging precision, support burden, lawful-request discipline, public-IP product availability, and IPv6 readiness. A cloud NAT remedy focuses on address portability, BYOIP transparency, provider-neutral evidence, allowlist migration planning, account-control governance, and registry records that can be used outside a single platform.

The accounting view: rent, capital, and option value

A simple way to read the cloud NAT economy is to separate rent from capital. Provider public addresses are rented identity. BYOIP addresses are customer-controlled capital admitted into the provider's environment. NAT gateways are translation infrastructure that can either use rented identity or customer capital. Partner allowlists are relationship-specific investments that attach value to whichever identity is chosen.

If the customer rents provider identity, the upfront cost is low. There is no transfer file, no ROA preparation, no prefix admission, no concern about whether the block is clean enough to bring, and no need to coordinate external routing for a customer-owned range. The customer pays the provider and moves. That is efficient when the service is new, low-risk, temporary, or not deeply allowlisted. It is less efficient when the service is regulated, reputation-sensitive, multi-cloud, acquisition-prone, or intended to last for years.

If the customer uses address capital, the upfront cost is higher. The holder must maintain APNIC records, control the right account authority, prepare route-origin authorization, satisfy provider verification, plan cutover, protect reverse DNS and reputation, and manage deprovisioning discipline. But the customer buys option value. It can preserve external identity across providers. It can avoid some provider address scarcity charges where BYOIP is exempt. It can demonstrate continuity to counterparties. It can keep address reputation on its own balance sheet rather than inside the provider's pool.

Option value is often underpriced in migration projects because the migration business case focuses on immediate savings. A spreadsheet compares monthly compute, database, storage, data transfer, NAT gateway, support, and staffing. It rarely assigns value to being able to leave without asking two hundred counterparties to update allowlists. It rarely prices the difference between a provider-owned egress address and an APNIC-recognised prefix with ten years of business history. It rarely asks whether account suspension, acquisition, dispute, sanctions review, or provider policy change could interrupt public identity.

That omission favours platforms. Platforms understand lifetime value. Customers often budget by project. The platform sells a clean migration now and captures exit friction later. The customer's best defence is not hostility to cloud. It is asset-aware architecture. If public identity matters, treat it as a strategic asset before the first allowlist is filed.

What good governance would look like

Good governance in this area does not require APNIC to become a cloud referee. It requires three disciplines across different actors.

First, cloud customers should inventory public egress identity before migration. The question is not merely "how many public IPs do we need?" It is "which external relationships depend on these addresses, who owns them, what reputation do they carry, and what would it cost to change them?" A regulated or high-volume service should have an address-control file just as it has a domain-control file and certificate-control file. That file should identify the holder, registry evidence, ROAs, reverse DNS, cloud account mapping, NAT gateway configuration, partner allowlists, abuse contacts, and exit sequence.

Second, platforms should make BYOIP admission and deprovisioning more transparent. Minimum prefix sizes, supported resources, regions, expected timelines, ROA requirements, account-transfer limits, simultaneous-announcement risks, reverse-DNS processes, abuse escalation, and return-to-customer steps should be predictable enough that customers can price them before committing. Providers can protect their networks without turning admission into an opaque privilege. The more predictable the process, the less platform power hides inside support tickets.

Third, APNIC should treat registry evidence as market infrastructure. Its value to cloud customers is not that it can tell them which provider to use. Its value is that it can make customer-controlled address capital legible to providers, partners, lenders, auditors, and counterparties. That requires accurate records, timely updates, reliable RDAP/Whois, usable RPKI, historical visibility, predictable transfer recording, and a clear boundary against discretionary control over already embedded operational assets.

These disciplines are modest. They also cut against several institutional temptations. Customers prefer speed and discover exit cost later. Platforms prefer product-specific stickiness. Registries can be tempted to answer scarcity with more control. But the network economy works better when evidence is portable and control sits with the actor bearing the cost.

The public-sector and fintech stakes

The issue becomes sharper in public-sector and fintech settings because address identity often carries a compliance aura. A ministry supplier moving document-processing workloads to cloud may need approved outbound addresses for secure filing, audit retrieval, or inter-agency APIs. A payments company may need stable addresses for bank connectivity. A health platform may need to reassure counterparties that cloud migration does not change endpoint trust. A regional gaming operator may need stable egress for payment, anti-cheat, and moderation vendors.

These cases are not rare edge conditions. They are the normal work of digitising mature services. The more a service interacts with old institutions, the more likely public IP identity remains part of the trust file. The public narrative may celebrate zero-trust, service identity, and API-level authorization. The operational form still contains IP allowlists because they are simple, auditable, and familiar across organizational boundaries.

That makes cloud NAT a governance issue. The NAT gateway is where modern platform architecture meets legacy trust infrastructure. It allows private workloads to participate in old allowlist systems. It also decides whether the public face belongs to the provider or to the operator. When the provider's address is used, the public institution or bank is effectively trusting the customer's account inside a platform-owned address economy. When BYOIP is used, the institution or bank can tie trust to a portable resource whose control is visible through registry evidence.

Neither model is universally better. Provider addresses may be appropriate for new services, low-risk workloads, or cases where the provider's controls are the main assurance. Customer-controlled prefixes may be better for services with durable counterparties, multi-provider strategy, acquisition risk, or high reputation value. The error is to make the decision accidentally because the default NAT wizard was fast.

Platform power is strongest when invisible

The largest address-power shifts are rarely announced as power shifts. They are announced as pricing updates, product improvements, security requirements, quota changes, abuse controls, new BYOIP features, or cost-optimization guidance. Each may be defensible. Together they move the customer's public identity into the platform's administrative domain.

An engineer sees fewer public endpoints. A finance team sees an IPv4 line item. A security team sees better private-subnet discipline. A compliance team sees stable allowlists. A platform sees more workloads flowing through managed gateways and public address products. An APNIC resource holder sees the difference between using its own prefix and renting the provider's. The same architecture can be a security improvement, a cost optimization, and a power transfer.

This is why the question should be asked early and plainly: after this migration, who controls the public address identity of the service? The answer may be "the provider, and that is acceptable." It may be "the customer, through BYOIP, with provider custody during advertisement." It may be "a hybrid, with provider addresses for commodity workloads and customer prefixes for regulated egress." What matters is that the answer is deliberate.

For APNIC governance, the lesson is equally plain. Scarcity has made IPv4 an asset, and cloud platforms have made public egress identity a product. The registry should not respond by trying to become more sovereign over cloud use. It should respond by becoming a better ledger: thinner, faster, more accurate, more portable, and more predictable. A registry that gives operators reliable evidence strengthens their ability to bargain with platforms. A registry that turns evidence into discretion weakens them.

The Singapore fintech's migration ends, in the best case, with a small table of public egress addresses. Behind that table sits a much larger institutional settlement. The company may have rented provider addresses and accepted future allowlist friction. It may have brought an APNIC-recognised prefix and accepted the work of BYOIP admission. It may have split workloads by risk. Whatever the design, the public address is no longer a background detail. It is the hinge between cloud architecture and business authority.

Cloud NAT is therefore not the end of IPv4 scarcity. It is one of scarcity's most modern forms. It hides private complexity behind a few public addresses, then prices and administers those addresses through platforms. The better the APNIC evidence layer works, the more operators can decide whether to rent that identity or carry their own. The worse the evidence layer works, the more platform identity becomes the default. In an Internet that still recognizes services by public numbers, that difference is power.

Sources and Further Reading