Summary

  • LACNIC cloud-provider address-power analysis asks how hyperscale address pools, BYOIP admission, NAT dependency, egress cost and route reputation affect enterprise portability.
  • IPv4 scarcity gives large platforms a structural advantage over smaller regional operators because address inventory can be internalised into cloud account economics.
  • A narrow regional ledger cannot solve cloud concentration, but it should not add a second gatekeeper over scarce resources that platforms already use as leverage.

The migration that exposes the address layer

A Latin American payments company begins with a practical plan. Its main application runs in a large public cloud, because that is where engineers can add capacity quickly, managed databases are available without a procurement cycle, and international reachability is already familiar. Its fraud team, however, wants part of the traffic to leave through a regional network in São Paulo. Its compliance staff want a separate path in Bogotá. Its sales team wants a lower-latency link to customers in Mexico. Its finance director wants cloud bills to stop rising every time data is moved between systems that the company already owns. Nothing in the plan is ideological. It is a normal attempt to use cloud where cloud is useful and regional infrastructure where regional infrastructure is better.

The network problem appears only after the commercial plan is approved. Customers have whitelisted existing IPv4 addresses. Banks recognize them. Card processors score them. Suppliers have written firewall rules around them. Fraud systems have accumulated history against them. An abuse desk somewhere has decided that traffic from one block is ordinary while traffic from another looks suspicious. Geolocation databases, risk engines, reverse DNS entries, TLS endpoints, API policies and access logs all carry memory. The company thought it was moving compute. In fact it is moving a public network identity.

The cloud provider can offer addresses from its own pool. It can also offer managed NAT, load balancers, private interconnects, elastic public addresses, and, in some cases, a bring-your-own-IP route for customers that already control suitable prefixes. Each option has a different technical shape. Each also has a different power structure. If the company uses the cloud provider's addresses, it receives reachability but accepts dependency. If it uses shared NAT, it gains simplicity but loses some accountability. If it brings its own addresses, it keeps identity but must enter an admission process controlled by the platform. If it moves to a regional ISP, it may gain bargaining room on connectivity while losing the reputation and routing comfort attached to the cloud platform's address estate.

That is the real subject. This is not primarily an essay about Latin American data-centre demand, though more capacity is being built and capacity matters. Nor is it mainly an essay about Internet fragmentation, though bad registry design can push trust in that direction. The narrower issue is cloud-provider address power. It emerges when large platforms convert address inventory, admission rules and embedded customer dependency into bargaining leverage. In a region served by LACNIC, that power does not disappear merely because a regional registry maintains a ledger. The ledger can preserve uniqueness, accuracy and portability. It cannot, by itself, make a platform less dominant.

But the ledger can make the problem worse if it becomes a second gatekeeper. A company already dependent on a cloud provider's address rules should not also be forced through a regional administrative layer that treats portability, leasing, transfers or customer geography as matters of discretionary approval. The basic institutional question is therefore not whether LACNIC can defeat hyperscale concentration. It cannot. The question is whether LACNIC remains a thin, neutral record layer that helps operators preserve optionality, or whether it adds regional gatekeeping on top of platform gatekeeping. A narrow regional ledger cannot solve cloud concentration, but it must not add a second gatekeeper. In the economics of cloud-provider address power, that distinction is decisive.

From address capacity to public identity

An IPv4 address is easy to misunderstand because it begins as a number. In a deployment ticket it appears as a line item. In a firewall it appears as a rule. In a cloud console it appears as an assignable object. In a registry it appears as an entry. These views are technically correct and commercially incomplete. Once a number is used by a production service, it begins to gather external memory. Over time that memory can become more valuable than the numerical resource itself.

Enterprises discover this through inconvenience. A new IP range is not just a routing change. It can require customer notices, bank approvals, supplier firewall updates, security reviews, penetration-test revalidation, email reputation warming, API allowlist changes, payment processor checks, VPN policy updates and incident-room patience. The effort is often larger than the price of the address itself. The renumbering cost is not measured only in engineering hours. It is measured in the number of outside parties that must believe the new address is the same business as the old one.

This is why the address layer now resembles identity infrastructure. A corporate domain name has long been understood as identity. A phone number has long been understood as identity. A payment account, a merchant identifier and a certificate chain are identity. Public IP addresses can become identity when counterparties rely on them as evidence of known traffic. They are not identity in the rich legal sense of a person or company. They are network identity in the practical sense that the outside world has learned to recognize a repeated public path, price the risk attached to it, and punish abrupt movement.

Cloud platforms did not create this condition. They industrialized it. By offering elastic addresses, load balancers, NAT gateways, private endpoints and interconnect products, they taught enterprises to think of public reachability as a managed feature. That feature is convenient, and convenience has economic consequences. The more a customer lets a platform assign the public numbers through which the customer is known, the more the customer's ability to leave depends on the platform's terms, the customer's tolerance for renumbering pain, and the patience of counterparties that must update controls.

Regional networks face the inverse problem. A regional ISP may offer better local support, lower latency to domestic users, cheaper traffic exchange or stronger knowledge of local regulation. Yet it may not be able to supply clean, portable, globally trusted IPv4 space on the same terms as a hyperscaler. Even if it can route customer-owned space, the customer has to control suitable space, pass the necessary platform or routing requirements, and coordinate migration without breaking external trust. The regional provider's physical and operational competence may therefore be weaker in the sales conversation than the cloud provider's address convenience.

This is a structural form of lock-in. It is not the crude lock-in of a contract that says the customer may not leave. It is the softer lock-in of accumulated dependency. The customer can leave in theory. It may even have multi-cloud diagrams and regional failover plans. But if its production identity is bound to addresses supplied by one platform, leaving means asking every important counterparty to relearn where the business lives. In a regulated or high-trust sector, that can be slow enough to function as captivity.

The economics resemble office relocation in a city where every customer, courier, bank and security guard has learned one entrance. The company may own the furniture and the applications. It may have a better building available nearby. Yet if the address on which others rely changes, the move becomes a relationship-management exercise. IPv4 has acquired that quality because the Internet's administrative record is now tied to reputation systems, security rules and commercial history. Address power follows from that connection.

Hyperscale pools and the conversion of scarcity

Large cloud platforms hold IPv4 at a scale that changes the bargaining environment. They acquired, received, leased and accumulated address space over many years, and they have the capital to keep doing so where market supply is available. For them, address inventory is not merely a cost of networking. It is an input into product packaging. A public address can sit behind a virtual machine, a load balancer, a NAT service, a database endpoint, a container platform, a security product or a managed edge. The same scarce number can support many dollars of monthly cloud revenue, especially when secondary-market scarcity has raised the cost of obtaining an equivalent number outside the platform.

That conversion is what makes hyperscale address pools powerful. The platform does not have to sell IPv4 as a separate asset to extract value from it. It can internalize address scarcity inside a broader service bundle. A customer sees a cloud instance, a network charge, a public IP fee, a NAT gateway line, an egress bill and a support plan. The address is only one component. The platform sees something different: a scarce public identifier that makes the rest of the service reachable and billable.

Smaller providers experience scarcity more directly. A regional ISP or hosting company that needs more IPv4 must source it from the secondary market, lease it, acquire it through transfer, or persuade customers to bring their own. The cost is visible, the registry process is closer, and any abuse problem or routing reputation issue is harder to absorb. A hyperscaler can spread acquisition, compliance, reputation management and network engineering across a global customer base. A smaller network often has to explain the same costs to each customer in a market where margins are thinner.

This asymmetry does not mean cloud providers are villains. It means they are rational firms with large pools of a scarce input. The institutional point is colder. When one class of firms can internalize scarcity and another must buy it at the edge, address scarcity becomes a source of bargaining power for the first class. A cloud platform can tell a customer that public reachability is available, that the provider's addresses are integrated, that reputation is managed, that support knows the product, and that migration away will involve complexity. A regional provider may be able to match only the connectivity part of that proposition.

Inventory also lets platforms set conditions without appearing to ration. When public IPv4 becomes more expensive, the platform can introduce tiered pricing, limit free allocations, charge for idle addresses, encourage private addressing, steer customers toward IPv6 where useful, or wrap public reachability into higher-value services. These moves may be economically sensible. They are also ways of turning address control into product strategy. The platform decides which forms of public reachability are easy, which are expensive, and which require special approval.

The customer experiences this as architecture. Should it expose a service through provider addresses, place a NAT gateway in front of private subnets, use a load balancer, pay for static egress, buy a private interconnect, or bring its own prefix? Each choice has engineering consequences. Each also has a dependency structure. A product menu is not a neutral catalogue when the supplier controls a scarce ingredient that the customer cannot easily reproduce elsewhere or finance quickly from the market.

In Latin America, where many enterprises are trying to balance global cloud capabilities with regional connectivity, the platform's address pool can therefore become a hidden determinant of network architecture. It can decide whether a workload looks portable or sticky. It can decide whether a regional ISP is a genuine alternative or only a supporting access provider. It can decide whether the customer's public identity remains attached to the customer or drifts toward the platform. The address pool becomes strategic not because addresses are expensive in isolation, but because they make other services reachable, trusted and difficult to move.

BYOIP and the politics of admission

Bring-your-own-IP looks, at first, like the answer. If the customer can bring its own prefix into a cloud, it can preserve network identity while changing the delivery environment. The address no longer belongs to the cloud provider's pool. It remains tied to the customer's registration, lease or continuity structure. Workloads can move while counterparties continue to see the same public numbers. For serious enterprises, that continuity can be more valuable than a small reduction in monthly infrastructure cost.

Yet BYOIP is not pure liberation. It is an admission regime. The platform decides what size prefix it will accept, what proof of control is required, which routing and security signals are mandatory, which regions support the service, how long propagation will take, what happens during withdrawal, how abuse history is assessed, and how support handles incidents. The customer brings the address, but the platform determines the conditions under which that address becomes usable inside the platform's network.

This is understandable from the platform's side. A cloud provider cannot let arbitrary customers inject arbitrary routes without control. It must protect its routing table, reputation, abuse posture, upstream relationships, customers and compliance obligations. Proof of control, route authorization, clean registration, security validation and operational discipline are not ornamental requirements. They are necessary for a platform that carries traffic at hyperscale.

The power issue lies in the boundary between necessary admission and commercial leverage. If the customer depends on the platform to make its own address usable in cloud, the platform can shape the customer's portability. It can make BYOIP a premium support experience, a region-limited feature, a process with queue times, or a product tied to other services. It can define the minimum acceptable block size in ways that exclude smaller holders. It can require reputation remediation before admission. It can treat some customer address histories as too risky. It can delay, reject, or constrain the mechanism that is supposed to reduce lock-in.

For a large multinational, these conditions are manageable. It has counsel, network engineers, cloud architects and vendor managers. It may control address blocks large enough to satisfy admission thresholds. It can run tests, negotiate support and stage migration. A mid-sized Latin American enterprise may not have that luxury. A fintech in Peru, a logistics company in Chile, or a software exporter in Colombia may need only a modest stable footprint that follows it between cloud and regional networks. If BYOIP effectively requires scale, procedural expertise and time, portability becomes a privilege of firms that already have bargaining strength.

This produces a subtle hierarchy. Provider-assigned addresses are easy but sticky. Customer-owned or customer-controlled addresses are portable but require admission. Shared NAT is cheap but weakens accountability. Smaller prefixes may be commercially useful but operationally awkward. Clean address history matters, but reputation systems can punish innocent later users of previously abused space. The customer is told that portability exists, but often only as a managed exception inside the platform's rules.

The platform's rulebook then becomes a market gate. A customer choosing between cloud and regional network is not simply comparing latency, price and service quality. It is comparing address admission terms. The platform that controls the easiest route to public reachability gains leverage over workloads that, in theory, could run elsewhere. BYOIP reduces one kind of dependency while revealing another: the customer's identity can be portable only when the destination network agrees to carry it on tolerable terms.

This is why registry neutrality matters. If a regional registry adds its own discretionary layer around transfers, leasing, use geography or eligibility, it does not free the customer from platform power. It makes the customer's address less portable before the platform admission process even begins. A narrow ledger that verifies control, preserves accuracy and supports clear transfers helps BYOIP work. A thick registry that treats address mobility as a policy favor helps the platform remain the easier option.

NAT, accountability and the price of being reachable

NAT is one of the great pragmatic inventions of the IPv4 Internet. It allowed private networks to grow while public addresses remained limited. It made home broadband scale. It made enterprise segmentation manageable. It let carriers serve many users with fewer public numbers. It gave cloud architects a default pattern: private subnets inside, public egress outside. Without NAT, the economics of IPv4 would have been harsher and many migrations would have stalled much earlier.

But NAT also changes accountability. Shared egress can make many users look like one user. Carrier-grade NAT can blur the boundary between households, devices and applications. Cloud NAT can make traffic from many workloads appear through a smaller set of provider-controlled addresses. This is useful for scale and awkward for trust. A bank, a fraud desk or a supplier does not always want to know that traffic came from a plausible cloud region. It wants to know that traffic came from the expected business.

The more an enterprise depends on shared NAT, the more it borrows reputation from a pool it does not control. If another customer pollutes that pool, the enterprise may suffer. If a security vendor downgrades traffic from a shared egress range, the enterprise may need to plead through support. If a platform changes how public egress is assigned, the enterprise may have to update counterparties. The cloud provider can manage some of this through reputation work and product design. The customer still lacks direct identity, and that absence is felt most sharply when it tries to move.

Dedicated public IPv4 solves part of the problem, but it creates another. If the address is provider-assigned, the customer becomes attached to the provider. If the provider changes pricing, support quality, routing posture or product direction, the customer can move the application but not easily the public identity attached to it. If the address is customer-controlled, the customer must pay for the address layer, maintain clean records, manage routing security and pass destination admission. There is no free form of reachability.

IPv6 does not remove this tension. It can reduce address scarcity in the narrow numerical sense, and many networks should operate it where it serves users. But Latin American enterprises cannot build public reachability strategy on the assumption that every customer, bank, supplier, regulator, consumer ISP, security appliance and partner API is fully IPv6-native. For the foreseeable production horizon, IPv4 remains the common denominator for many high-value interactions. Dual-stack operation is therefore not an escape from address economics. It is an additional operating surface layered on top of the old dependency.

The result is a hierarchy of reachability. Private addressing is cheap and flexible inside the platform. Shared NAT is convenient for outbound traffic but weak as identity. Provider-assigned public IPv4 is easy but sticky. Customer-controlled IPv4 is portable but institutionally demanding. IPv6 is abundant but not a universal replacement for existing counterparties. Every serious enterprise has to choose where in that hierarchy each workload belongs.

Cloud providers benefit because they can offer the whole menu from inside one commercial relationship. A regional ISP may offer excellent connectivity, but it may not offer the same integrated path from private addressing to managed NAT to public egress to BYOIP to security products. The platform can frame the customer's choices as technical optimization while retaining control over the scarce public identity layer. That is not a conspiracy. It is vertical integration around reachability.

The enterprise at the start of the story wants to move workloads while preserving IPv4 reachability. NAT helps with some traffic. It does not preserve the identity that customers, banks and suppliers have learned. Public IPv4 does that. The economic question is who controls it, who can move it, who can admit it, who can price it, and who bears the cost when it becomes difficult to change.

Egress, reputation and the cost of leaving

Cloud lock-in is often discussed through compute, databases and proprietary services. Those matter. Network identity adds another layer. Egress charges make data expensive to move out. Managed databases make stateful migration complex. API gateways and security services create operational habits. Public addresses add a different form of gravity: the outside world remembers where traffic came from, and that memory can outlast the workload that first created it.

Route reputation is part of that memory. A prefix that has been used for clean enterprise traffic for years can be easier to trust than one recently obtained from a murky past. A block associated with spam, scraping, credential attacks or proxy abuse can remain contaminated in private scoring systems long after registration data changes. Geolocation errors can place traffic in the wrong country. Some counterparties manually maintain allowlists. Others rely on commercial intelligence feeds whose correction cycles are opaque. Public reachability is therefore not just a matter of announcing a route. It is a matter of being believed at the other end.

Hyperscale platforms invest heavily in managing this belief. They operate abuse desks, maintain relationships with transit providers and security vendors, monitor reputation, and absorb the cost of customer misconduct across large pools. A regional ISP may do the same with less scale. An enterprise moving from cloud to a regional network may find that the regional path is technically sound but commercially unfamiliar to counterparties. If traffic suddenly arrives from a new block, the move can look risky even when nothing about the business has changed.

Egress pricing reinforces this. If moving data out of a cloud is costly, the platform already has a lever. If leaving also means renumbering or rebuilding address reputation, the lever becomes stronger. The customer may conclude that a regional network is cheaper on bandwidth and better on latency but still too expensive in transition risk. The bill that matters is not only the cloud invoice. It is the hidden bill of convincing banks, suppliers, customers and automated risk systems to accept a new network identity.

This is where address power becomes bargaining power. The platform does not need to threaten the customer. It can simply price egress, define public IP products, control BYOIP admission, maintain integrated reputation, and offer support that regional alternatives cannot easily match. The customer then chooses the path of least disruption. Rationally, it stays.

Such power is strongest when the customer's own address position is weak. If the enterprise has no portable addresses, it must either use provider-assigned space or obtain space under pressure. If it has addresses but they are small, dirty, poorly documented or hard to route, BYOIP may be difficult. If regional transfer and leasing rules are slow or uncertain, acquiring clean portable space becomes harder. If the registry framework discourages mobility, the cloud provider's embedded addresses become more attractive. The platform wins not only because it is large, but because the surrounding address economy gives customers too few clean exits.

The market for IPv4 can help. Leasing, transfer, managed address services and continuity products can separate identity from delivery. They can let a company use cloud, regional ISPs, SASE providers and data centres without rebuilding public identity every time the delivery path changes. But these arrangements require clear records, predictable rights and low-friction recognition. If every movement of address use is treated as a suspicious exception, portability becomes theoretical.

For LACNIC, the lesson is not that cloud platforms should be ignored. They are central actors in the region's digital economy. The lesson is that platform lock-in becomes more severe when the regional address layer is hard to move through. A neutral, predictable ledger gives customers and smaller networks more ways to resist platform gravity. A discretionary ledger turns cloud convenience into the default answer.

Secondary scarcity and the smaller ISP

Latin America and the Caribbean are not a single network market. The region includes large telecom groups, cable operators, mobile carriers, state-linked infrastructure, regional fibre specialists, enterprise ISPs, hosting firms, IXPs, fintechs, exporters, broadcasters, universities and small access providers serving difficult geographies. Their bargaining positions differ sharply. So does their exposure to IPv4 scarcity and to the platforms that can soften that scarcity for their own customers.

For a large carrier, a secondary-market purchase may be a balance-sheet decision. For a smaller ISP, the same purchase can be a strategic risk. The smaller operator has fewer engineers to handle transfer paperwork, fewer lawyers to review contracts, less cash to hold inventory, less tolerance for delay and less ability to absorb a bad reputation history. It also has less leverage with cloud platforms, transit providers and security vendors. A problem that is operationally irritating for a large network can be existential for a small one.

This is where anti-market language often misleads. Treating IPv4 commercialization as the enemy of poorer or smaller operators assumes that the alternative is benevolent allocation. In practice, need-based and discretionary systems often reward those already able to document need, pay staff, survive review and navigate process. The fixed cost of procedure is regressive. A large operator spreads it across millions of users. A small operator feels it in every new customer and every delayed expansion.

Scarcity with visible prices is painful, but it can be budgeted. Scarcity hidden inside discretionary review is harder to finance. A small ISP can compare lease offers, seek a transfer, partner with a continuity provider, or pass a known cost into service plans. It cannot easily price the risk of an open-ended approval process, a utilization interpretation, an uncertain policy change or a registry position that treats commercial address use as suspect. Uncertainty favors the large because the large have time, cash and staff to wait.

Cloud providers benefit from this indirectly. If smaller ISPs cannot obtain, lease, route or maintain clean address space easily, enterprises will use cloud addresses instead. If regional providers cannot productize BYOIP delivery, the platform will remain the safer default. If transfer friction suppresses liquidity, firms with existing pools become more powerful. Rules that are presented as protecting the region can therefore strengthen the very platforms that already internalize scarcity.

The effect is not limited to access providers. Regional software companies, managed security firms, payments platforms and enterprise network specialists also need stable public identity. If they cannot acquire or carry it efficiently, they build around cloud-native egress. Once built, the design is hard to unwind. A generation of Latin American digital firms can then become address-dependent on platforms whose strongest advantages were accumulated before those firms had bargaining power or a mature local alternative.

There is an important distinction between speculation and liquidity. A well-functioning address market should not reward fraud, false control, route hijacking or abuse. Records must be accurate. Disputes must be visible. Proof of control must be reliable. Transfers must not corrupt uniqueness. But suppressing liquidity in the name of moral comfort is not the same as protecting the Internet. Illiquid scarcity favors incumbents with inventory. Liquid scarcity gives smaller actors at least a chance to buy, lease or finance access.

For smaller ISPs, the relevant public policy is therefore mundane. They need transparent records, clean transfer paths, recognized leasing structures, predictable dispute handling, reliable reverse DNS and routing-security support. They need low fixed costs and fewer discretionary surprises. They need a registry that records and verifies rather than judges commercial destiny. The more LACNIC keeps to that role, the less the region's smaller networks must rely on cloud providers as the default source of public reachability.

Why platform address power is not solved by a regional ledger

A regional registry can preserve a shared record. It can prevent duplicate claims. It can maintain registration accuracy. It can support reverse DNS and routing-security publication. It can record transfers. It can make disputes legible. It can help counterparties verify who controls a resource. These are important functions. They are also narrow functions, and their narrowness is part of their value.

They do not solve cloud concentration. LACNIC cannot make a hyperscale platform's database cheaper to leave. It cannot make egress prices disappear. It cannot force a platform to accept every BYOIP prefix on every timetable. It cannot give a small ISP the same balance sheet as a global cloud provider. It cannot erase customer preferences for managed services. It cannot make decades of address accumulation irrelevant.

The danger is that a registry, confronted with platform concentration, starts to imagine that broader control over address use is a remedy. That would repeat the familiar mistake of treating the address book as an industrial-policy tool. If cloud providers are powerful because they have inventory and admission rules, adding regional discretionary rules does not neutralize them. It burdens the firms that lack inventory and need mobility, while the firms with inventory continue operating from inside their own pools.

A narrow ledger is not weak because it is narrow. It is strong because it is trusted. Its legitimacy comes from doing the one thing everyone needs: preserving a consistent, accurate and neutral record of unique number use. The more it expands into judgments about business models, customer geography, leasing morality or platform rivalry, the more it risks becoming one more political actor in a stack already full of private power.

Neutrality is not indifference to outcomes. It is a discipline about institutional role. A registry that remains neutral can still enforce objective record integrity. It can reject fraud. It can prevent duplicate claims. It can publish accurate status. It can require defensible proof of control. It can maintain secure publication. What it should not do is convert its position in the ledger into a general right to decide which business arrangements deserve recognition or which providers should be easier to use.

For Latin American enterprises, the practical value of a neutral LACNIC is optionality. An enterprise should be able to hold or lease addresses, use them with a cloud, move them to a regional network, withdraw them from one provider, announce them through another, and keep counterparties confident that the record is accurate. The registry should make that possible by reducing ambiguity. It should not make every move feel like a petition.

The same principle helps regional providers. A provider that can route customer-controlled addresses has a better chance of competing with cloud. A provider that can help customers keep identity while changing delivery path can sell continuity rather than just bandwidth. A provider that can trust the registry record and build products around it can turn BYOIP from an exception into a service. But that requires a record layer that does not punish mobility.

The ledger, in other words, is a platform for competition only if it is not itself a gatekeeper. When the record is clean, portable and neutral, the enterprise can compare cloud, ISP, SASE, hosting and interconnect offers on service quality. When the record is discretionary, the enterprise compares vendors on their ability to navigate institutions. That is a less competitive market. It favors the largest firms twice: first because they own inventory, and second because they can survive procedure.

The second gatekeeper problem

The Latin American enterprise in the opening scene already faces a platform gate. If it uses provider-assigned cloud addresses, the platform controls the identity. If it brings its own prefix, the platform controls admission. If it wants to leave, the platform's egress pricing and integrated products influence timing. That is one gatekeeper. A regional registry should not become the second.

The second gatekeeper problem appears when registry rules add uncertainty to every path out of platform dependency. Suppose the enterprise wants to lease a clean block from a specialized provider and use it across cloud and regional networks. If the registry treats leasing as inherently suspect, the enterprise hesitates. Suppose it wants to buy addresses from an underused holder in another part of the region. If transfer review is slow or unpredictable, the cloud's own addresses look easier. Suppose a smaller ISP wants to offer managed BYOIP delivery. If the registry environment makes address control hard to explain to customers, the product never matures.

Each of these frictions sounds small when viewed from the registry desk. Together they alter the market. They reduce the number of credible exits from cloud-assigned identity. They make the platform's address pool more valuable. They discourage the emergence of regional continuity products. They teach enterprises to accept the cloud's network identity because the alternative requires too much institutional navigation.

The irony is that rules framed as regional protection can increase dependence on global platforms. A registry might restrict mobility to keep addresses in the region. A platform with a large internal pool does not need that mobility as urgently as a growing regional provider does. A registry might demand detailed use justification to prevent waste. A hyperscaler can produce documentation more easily than a small ISP. A registry might disfavor leasing to prevent speculation. A platform can avoid the leasing label by bundling addresses into cloud services. The burden lands on the actors the policy claims to protect, while the largest platforms remain least exposed to the rule.

This is the institutional-economics point. Power is not measured only by formal authority. It is measured by who can convert rules into advantage. Hyperscalers can convert scarcity into bundled services. They can convert admission rules into customer dependence. They can convert reputation management into trust. If the regional registry adds discretionary friction, hyperscalers can convert that friction into another reason for customers to stay inside the platform.

Avoiding the second gatekeeper role does not mean deregulated chaos. The ledger still needs objective controls. A transfer should not be recorded if control is false. A route authorization should not be published for the wrong holder. A disputed claim should not be hidden. Abuse history should not be laundered through paperwork. The distinction is between verifiable record integrity and broad commercial discretion. The first is registry work. The second is industrial policy without the accountability of a state and without the balance sheet of a market participant.

For LACNIC, this distinction is especially important because the region needs both cloud and regional networks. Enterprises will use hyperscale platforms for many workloads. They will also need domestic carriers, IXPs, edge networks, managed security providers and sector-specific infrastructure. If address identity can move among these environments, customers gain bargaining power. If it cannot, cloud concentration deepens. The registry's job is not to choose winners. It is to keep the address layer from making exit artificially harder.

What neutrality requires in practice

Registry neutrality is often described abstractly. In the cloud-provider address context it has concrete requirements. The registry record should answer a limited question with high reliability: who has the recognized control claim over this resource, and what security or dispute status attaches to that claim? It should not try to answer whether the holder's business model is socially preferred, whether cloud use is too foreign, whether leasing is morally attractive, or whether an enterprise should use regional infrastructure instead of a global platform.

Neutrality also requires separability. The registry function must be separated from enforcement impulses. If an operator commits fraud, breaches a contract, violates law or harms customers, there are courts, regulators, counterparties and network abuse processes. The address ledger should not become police, prosecutor and judge. Its essential power is too sensitive. Revoking or impairing recognition is not a moderation decision. It can affect customers, suppliers, security systems, financing and public reachability.

A neutral registry should make mobility routine. That means clear transfer records, predictable processing, transparent status, stable historical data, and a clean distinction between record changes and business approval. It means recognizing that address use can move among clouds, ISPs, hosting providers and customer networks without the registry treating movement itself as suspicious. It means supporting the operational reality that a business may separate identity from delivery and may need several delivery paths at once.

Neutrality also means proportionality in risk handling. If a resource is disputed, the dispute should be recorded and isolated where possible. Existing operations should not be destroyed merely because a non-urgent administrative disagreement exists. If a change is contested, the last verified operational state should have weight. If a record needs correction, the correction should be tied to evidence. The ledger must be protected from fraud, but it must also be protected from discretionary overreaction by the institution maintaining it.

For cloud-provider address power, the most important neutrality principle is portability. A resource holder should be able to move registration relationships, routing arrangements and service providers without renumbering every dependent system. Portability disciplines both platforms and registries. If a cloud provider knows a customer can carry identity elsewhere, the provider must compete on service. If a registry knows holders have meaningful exit paths, the registry must remain precise and restrained. Exit is not instability. Exit is what keeps concentrated power honest.

There is a regional development argument here, but it is not the usual one. Protecting Latin American digital autonomy does not mean turning LACNIC into a regional industrial planner. It means lowering the institutional cost for Latin American firms to choose among infrastructure providers. A Brazilian retailer should be able to use a global cloud for seasonal peaks, a domestic network for payment traffic, a regional security provider for egress control and a continuity provider for public address identity. The address layer should not force those choices into one platform.

Nor should neutrality be confused with hostility to cloud. Cloud providers are valuable networks. They bring capital, tools, resilience and global reach. Many Latin American firms would grow more slowly without them. The problem is not the existence of cloud. The problem is dependence without clean exit. A neutral registry helps create exit by making address identity verifiable and movable. It does not need to punish platforms to do that. It only needs to avoid strengthening them by accident.

Platform bargaining power and internalized scarcity

Cloud-provider address power emerges when a platform can internalize scarcity and externalize dependency. It internalizes scarcity by holding large pools, managing reputation, designing public IP products and embedding addresses inside broader services. It externalizes dependency when customers bear the cost of renumbering, allowlist changes, egress bills, reputation rebuilding and admission delays if they try to leave.

This is not the same as ownership in the property-law sense. A platform may hold registrations, leases, legacy space, transferred blocks, customer-provided prefixes and provider relationships under different legal arrangements. The economic point is simpler: it controls usable public reachability at the moment the customer needs it. In infrastructure markets, moment-of-use control often matters more than abstract title.

The bargaining power is strongest when the platform can make its own address option feel frictionless and every alternative feel exceptional. A new service can be launched with a provider public IP in minutes. A NAT gateway can be configured through the console. A managed load balancer can receive an address as part of setup. By contrast, obtaining portable space, validating control, cleaning reputation, coordinating route origin authorization, arranging regional delivery and passing BYOIP admission may take planning. The platform sells immediacy. The market sells optionality. Customers under pressure often buy immediacy.

Once the workload is running, the calculus changes. The immediate choice becomes a dependency. The provider address is now in logs, policies and partner records. The NAT design is now in security assumptions. The egress pattern is now part of application architecture. The platform's support team is now the path to reputation problems. Moving later is possible but expensive. The platform's initial convenience has compounded into bargaining leverage.

Large platforms can also arbitrage visibility. When they charge separately for public IPv4, customers see scarcity as a small line item. When they bundle it into services, customers may not see it at all. When they raise egress or network-service prices, the address element is mixed with other costs. When they support BYOIP, the customer sees a portability feature, not necessarily the platform's power to define admission. Scarcity is present throughout the product system, but it is hard to isolate and therefore hard to negotiate.

Smaller regional networks have fewer ways to hide the same economics. They may need to tell customers directly that IPv4 costs money, that clean blocks are limited, that BYOIP support requires engineering, or that abuse remediation takes time. Their honesty can look less attractive than the cloud console's abstraction. Yet the abstraction does not remove scarcity. It moves scarcity inside the platform, where it becomes harder for the customer to see which part of the bill is reachability, which part is convenience and which part is lock-in.

The remedy is not to pretend that all providers are equal. They are not. Hyperscale platforms will remain better at many things. The remedy is to preserve address structures that let customers separate public identity from delivery. If the customer can carry identity, the platform must compete more on compute, reliability, security, tooling and price. If the customer cannot carry identity, the platform competes with a thumb on the scale.

That is why the narrow regional ledger has strategic importance even though it cannot solve cloud concentration. It sits upstream of portability. It can either make address identity a movable business asset or a registry-conditioned privilege. The first outcome weakens platform bargaining power at the margin. The second strengthens it. In infrastructure markets, the margin is often where competition survives.

The regional compact that would actually help

Latin America needs a compact around address neutrality that is practical rather than theatrical. It should begin from the operator's problem, not from institutional self-description. Operators need unique numbers, accurate records, verifiable control, routing credibility, reverse DNS continuity, clean transfer history and usable dispute metadata. Enterprises need public identity that can move among providers. Smaller ISPs need access to address liquidity without being crushed by procedure. Cloud providers need clear admission signals and trustworthy records. Users need services that keep working when the business behind them changes delivery path.

None of those needs require LACNIC to become an economic planner. They require it to be a reliable ledger. A reliable ledger is not passive. It is technically disciplined. It preserves history. It resists forged changes. It publishes coherent data. It supports secure routing artifacts. It processes legitimate transfers. It records disputes without poisoning unrelated operations. It keeps the common layer thin enough that business choices remain outside it.

A useful regional compact would treat address mobility as normal. It would recognize that an enterprise may use a prefix in a hyperscale cloud for one workload, through a regional ISP for another, and through a security platform for a third. It would not mistake movement for evasion. It would not force every address decision into a narrative about regional loyalty. The region is stronger when its firms can choose freely among infrastructure providers without surrendering network identity to the first platform that made deployment easy.

The compact would also treat leasing and continuity arrangements as part of the real economy. Not every company should buy address space directly. Direct holding can place registry-layer risk inside the operating company that can least afford disruption. Leasing from a credible first-party provider, or using a continuity structure that separates identity from delivery, can be rational risk placement. The registry should care that records are accurate and control is verifiable. It should not assume that direct holding is always safer or that leasing is automatically suspect.

For smaller ISPs, this approach could open product paths that cloud platforms currently dominate. A regional ISP can become a delivery partner for customer-controlled identity. A managed security provider can offer stable egress without owning every address. A data-centre operator can host customer infrastructure without forcing renumbering when the customer moves. A cloud specialist can help customers use BYOIP rather than provider-assigned addresses. These are modest businesses, but they preserve competition by reducing dependence on platform address pools.

The compact should also be honest about abuse. Address mobility can be abused. Dirty blocks can be laundered. Bad actors can exploit transfer windows. Customers can misrepresent control. But the answer is better verification, stronger reputation transparency, clearer dispute records and faster correction, not discretionary suspicion toward mobility itself. A market with verifiable records is safer than a market where address use is hidden behind platform bundles and private scoring systems.

Finally, the compact should accept that IPv4 remains economically meaningful. It is not made irrelevant by IPv6 advocacy, nor is it made socially dangerous by having a price. IPv4 is scarce, embedded and still necessary for many production relationships. Treating it as a real asset does not harm the region. It gives operators something scarce around which they can build bargaining power. Suppressing that asset quality in the name of administrative comfort leaves the scarcity advantage with the largest platforms.

The narrow institutional conclusion follows. LACNIC's best contribution to cloud competition is not to fight clouds from the registry layer. It is to avoid making address portability harder than cloud already makes it. The region does not need another authority deciding who deserves address mobility. It needs a record layer so reliable, neutral and portable that enterprises and regional providers can build alternatives without asking permission at every turn.

A ledger that does not amplify the platform

Return to the payments company. Its executives do not want an address-governance theory. They want to move some workloads out of the cloud, keep others in it, route sensitive traffic through regional networks, control egress costs, preserve customer trust and avoid weeks of partner reconfiguration. They do not want to discover that their public network identity belongs, in practice, to whichever platform made the first deployment easiest.

If they have portable address identity, their choices widen. They can negotiate with the cloud provider because leaving is not catastrophic. They can use a regional ISP because the ISP can carry known addresses. They can design NAT for scale without making it the identity layer. They can use BYOIP as a normal architecture rather than an emergency exception. They can separate the business question of where a workload should run from the identity question of how the outside world recognizes it.

If they do not have portable identity, every alternative is discounted. The regional ISP may be technically excellent, but the migration risk is high. The secondary-market address may be available, but the process may be uncertain. The BYOIP path may exist, but admission may be slow. The cloud provider's addresses may be more expensive over time, but they are already accepted. That is how bargaining power accumulates without a formal prohibition on exit.

LACNIC cannot remove every cost in that equation. It cannot make banks update allowlists faster. It cannot make reputation vendors more accurate. It cannot make cloud egress cheap. It cannot give every small ISP a hyperscale address pool. What it can do is refuse to add institutional friction where the region needs mobility. It can keep the ledger accurate without turning accuracy into commercial approval. It can support portability without treating portability as disloyalty. It can make its own role small enough that the market around it has room to compete.

That restraint is not a minor administrative virtue. It is a form of economic policy precisely because it declines to become industrial policy. In a world where platforms internalize address scarcity, the neutral ledger protects the possibility that customers and smaller networks can externalize identity from any one provider. The ledger does not create competition by decree. It preserves the conditions under which competition can be attempted.

Cloud-provider address power will grow wherever public reachability, reputation and platform services remain bundled. Latin America is not exempt from that pattern. Enterprises will continue to rely on hyperscale platforms. Regional networks will continue to seek a larger role. IPv4 will remain a scarce input whose value is revealed not only in transfer prices but in the cost of changing numbers that others already trust.

The institutional choice is therefore narrow but consequential. A regional registry can protect uniqueness, records and security while leaving address identity movable. Or it can thicken its role, burden mobility and become a second gatekeeper that platforms are better able to survive than the regional firms it means to protect. The first path does not solve cloud concentration. It does something more modest and more useful. It keeps cloud concentration from being reinforced by the address ledger itself.

The payments company will still have hard choices. It will still weigh latency, data gravity, compliance, support quality, egress charges, security design and engineering capacity. But if its public IPv4 identity can move, those choices remain commercial and technical rather than captive. That is the point of registry neutrality in the age of cloud-provider address power. The ledger should remember who controls the number. It should not decide whether the holder deserves the freedom to use it elsewhere.

Sources and further reading

These references provide the article's public doctrine and background context. They are used for institutional-economic framing, not for adopting any registry or official-sector narrative.