Summary
- Large cloud platforms do not need to own the internet registry to turn public IPv4 into bargaining power.
- The meeting looks like an ordinary cloud migration review.
The migration room discovers that public identity is the asset
The meeting looks like an ordinary cloud migration review. A North American SaaS company has outgrown its hosting estate. A hospital-platform supplier is moving regulated workloads into managed services. A public-sector contractor is preparing a cross-border bid. A payments provider is splitting its environment across accounts so auditors, engineers and finance staff can see who controls what. The diagrams show virtual networks, load balancers, private subnets, managed databases, security appliances, edge services and recovery regions. The invoice shows compute, storage, egress and support. It looks modern.
Then someone asks which public IPv4 addresses will identify the service after the move. The question changes the room. The company can use provider-owned addresses from the platform. It can try to bring its own prefix. It can lease or buy a small block. It can use a partner's space. It can place more traffic behind managed egress. It can redesign account boundaries so one business unit controls the public endpoints and another only consumes them. None of these choices is merely technical. The answer decides what sits in customer allowlists, bank API files, fraud-scoring systems, procurement records, firewall policies, security logs, reverse-DNS plans, route-origin authorisations, abuse contacts, geolocation corrections and recovery playbooks.
The people at the table are not debating internet governance in the abstract. They are asking who will own the public identity that customers and counterparties will learn to trust. If the company takes provider-owned addresses, the platform can make deployment fast. The addresses are available inside the account, routed by the provider's backbone, visible in the cloud bill and supported by the provider's public reputation. If the company brings its own prefix, the provider will ask for evidence. Is the range registered to a business or institution? Is the holder record current? Is there a route-origin authorisation? Who controls reverse DNS? Is the abuse contact credible? Does the range have a clean history? Can the public record connect the customer, the account and the intended origin without a private detective story?
That is where ARIN enters the cloud file. The American Registry for Internet Numbers does not choose the architecture. It does not set the platform's price list, admit the customer's prefix by itself or promise that every counterparty will accept the plan. Its value is more modest and more decisive. It supplies an independent public record for number resources in a region where hyperscale cloud, large enterprise procurement, legacy address holdings, mature IPv4 transfers, security vendors, public-sector buyers and small edge networks all meet. If that record is trusted, a customer can preserve public identity instead of renting it entirely from the platform. If the record is slow to update, hard to read or entangled in broad discretion, the platform's own address pool becomes the conservative choice.
The economic problem is not crude lock-in. A cloud provider can offer real performance, security, support, automation and global reach. A customer may rationally choose provider addresses for a short-lived service, a low-risk endpoint or a workload that does not need durable public identity. The problem appears when scarcity, reputation and evidence turn convenience into bargaining power. Once a public address is inside partner firewalls, payment callbacks, customer contracts and incident histories, changing it is expensive. The provider does not need to forbid departure. It only needs the independent path to look slower, riskier or less certain than staying with the platform's address system.
Platform address power starts with scarce inventory
Cloud providers now act as address institutions. They allocate public addresses inside accounts, charge for them, monitor idle use, validate customer-owned prefixes, advertise accepted space, police reputation and place address control inside product boundaries. They are not registries, but they increasingly decide the address plan for customers that need stable public identity. ARIN matters because its record is the outside evidence that makes customer-owned and leased alternatives credible. Without that evidence, the cloud address becomes the easiest public identity a cautious buyer can approve.
Cloud-provider address power begins with provider-owned inventory. A large platform holds, acquires, manages and advertises public IPv4 at scale. It can make addresses appear in a console, tie them to virtual machines or load balancers, expose them through managed endpoints and recover them when resources are deleted. The customer experiences inventory as availability. The platform experiences it as a scarce asset that can be priced, rationed and embedded in account rules.
The next control is admission. Bringing a customer-owned prefix into a cloud is not the same as announcing it from the customer's own router. The platform must decide whether to accept the range into its systems, associate it with an account, allow it in a region or global scope, advertise it through its backbone and attach derived addresses to supported services. That private acceptance usually rests on public evidence: registry data, route-origin authorisation, reverse-DNS control, holder identity, clean reputation, a letter or other proof of authority, and an account relationship that lets the platform assign risk to the right customer.
Pricing and inventory discipline add a third control. Once a platform charges for in-use or idle public IPv4, the address is no longer a harmless default. It becomes a measured input. Engineers see warnings. Finance sees an hourly line. Cloud teams ask whether public exposure is necessary. Security teams ask whether private connectivity or a managed endpoint can reduce the footprint. The platform can present this as conservation and cost visibility, and that is partly true. But the same pricing also makes platform-owned public addresses part of a managed scarce-number economy inside the account.
Account architecture is the fourth control. Address authority may sit at the organisation, project, subscription, VPC, VNet, load balancer, global accelerator, managed egress, Kubernetes ingress, managed database, firewall appliance, API gateway or edge-service level. The same company may have multiple cloud accounts, each with its own permissions and purchasing history. A contractor may operate in a customer's subscription. A parent company may hold the address range while a subsidiary runs the service. A managed-service provider may control the account that holds the public endpoint. Whoever controls that boundary can make address movement easy or costly.
Routing, naming and reputation complete the bundle. A public address is useful because others believe the route, trust the reverse naming enough for operations, know where to send abuse reports and understand who can authorise a change. Route-origin authorisation, RPKI, routing-registry entries, reverse-DNS delegation, public contacts and geolocation are not decorations. They are the documentary surface around public identity. Public addresses also collect history in fraud tools, mail systems, bank allowlists, procurement files, incident reports, customer logs and security products. Reputation makes public identity durable, which means it also makes the holder of that identity powerful.
Exit friction is the result. Cloud power does not depend on a clause that says the customer may not leave. It depends on the cost of changing the public identity that everyone else has accepted. If departure requires customer notices, allowlist updates, bank testing, fraud-model resets, reputation warm-up, route-origin changes, reverse-DNS handover, audit explanations and procurement amendments, the customer is less free than the architecture diagram suggests. Platform address power is the conversion of scarce public IPv4, account control and reputation into leverage over customers that need to remain recognisable.
ARIN's region makes the platform bargain sharper
The ARIN region gives this problem a distinctive shape. The United States concentrates major cloud providers, large data-centre markets, content networks, security vendors, federal contractors, healthcare platforms, payment systems, universities, old enterprise allocations and specialist IPv4 transfer expertise. Canada adds sophisticated public and private networks with procurement, privacy and telecom expectations that often require a clean public record. The Caribbean and North Atlantic add smaller edge economies where a modest address range can support a government portal, a hosting product, a hospital supplier, a port system or a tourism platform. The same registry record is read by all of them.
Cloud concentration matters because the region's dominant platforms are not peripheral suppliers. They are places where new services are built, old estates are migrated and public-sector buyers test resilience. A North American company can place workloads in multiple regions, use managed load balancing, buy security services, connect through private links, publish APIs and scale quickly. That makes platform-owned addresses attractive. It also means that a platform's address admission rules become part of ordinary enterprise governance. BYOIP is not a specialist curiosity. It is a board-level question for companies whose public identity should survive supplier change.
Enterprise and public procurement make the question stricter. A hospital supplier, defence contractor, state technology office, provincial service provider or payments company cannot treat public endpoints as disposable. It may have customers whose security teams take weeks to change allowlists. It may have regulators who ask how access is controlled. It may have insurers and auditors who expect documented network identity. It may have customer contracts that mention source addresses, recovery sites or notification periods. A cloud address decision made early in engineering can become a legal and commercial dependency later.
Legacy holdings sharpen the outside option. The ARIN region contains many older allocations that predate today's cloud and transfer economy. Some belong to enterprises, universities, carriers, manufacturers and public institutions that now use only part of the space. Some records are clean and modern. Others carry corporate-history issues, stale contacts or service-boundary questions. Those ranges can become valuable alternatives to provider inventory if they can be regularised, transferred, leased or imported into cloud with credible evidence. They remain weaker bargaining instruments if counterparties cannot easily connect old records to current authority.
The transfer economy matters for the same reason. ARIN operates in a mature environment of brokers, facilitators, counsel, escrow providers and buyers who understand that IPv4 capacity has capital-like value even if the legal vocabulary remains specialised. A portable prefix can discipline platform address power because it gives the customer another way to obtain public identity. But that discipline works only if transfer or lease evidence is reliable, updateable and accepted by clouds, banks, customers and network operators. An outside option that requires weeks of explanation is still an outside option, but a discounted one.
Security vendors and reputation systems add a further regional layer. Many fraud, mail, threat-intelligence, compliance and geolocation providers are located in or heavily influenced by the ARIN market. Their products read public addresses as risk signals. They may be correct, cautious or slow, but customers have to satisfy them. A public IP plan that looks clean to a cloud provider may still need reputation work outside the platform. A registry record that is precise and current lowers that work. A vague record lets private reputation vendors become additional gates.
The Caribbean and North Atlantic edge makes the regressive effect visible. A small operator may need only a /24 for a public-service contract or managed hosting product, yet face the same proof chain that a large enterprise can spread across a legal department and cloud centre of excellence. Provider-owned addresses then look cheap because the provider has already paid the institutional cost of being trusted. ARIN's regional specificity is therefore not merely North America as a map. It is a market structure in which public address identity is read by many powerful private systems, while the smallest users have the least capacity to re-prove it.
Public IPv4 pricing turns scarcity into account discipline
Public cloud has made IPv4 scarcity visible as a management signal. A business that once treated public addresses as part of a hosting bundle now sees them as a line in cloud pricing, an account inventory item and a design review issue. One major platform lists hourly charges for both in-use and idle public IPv4 associated with customer resources, while saying customer-brought space through the relevant paths is not charged as platform public IPv4. Another lists charges for in-use static and ephemeral external IPv4 addresses on standard virtual machines and a higher idle reserved-static rate, while treating customer-brought addresses differently. Microsoft describes custom IP prefixes as customer-owned ranges brought into a subscription, with no charge to provision or use the custom prefixes or derived public IPs, even though ordinary traffic charges still apply.
Those examples should be read as market evidence, not as a vendor comparison. The point is not whether one price is better than another. The point is that public IPv4 has become a priced, metered and governed input inside cloud accounts. An idle address is no longer just untidy. It may cost money or appear in an inventory tool. A public endpoint is no longer a default that disappears into a server bill. It has to be justified against private connectivity, managed endpoints, IPv6 readiness, managed egress, load balancing and customer-facing continuity.
Pricing changes behaviour. Finance teams ask why a development account still holds public addresses. Security teams ask whether a service truly needs direct reachability. Platform teams create internal chargebacks. Architects reduce public exposure. This discipline is not bad. IPv4 is scarce, and careless use creates costs for everyone. But the same discipline teaches customers that platform-owned public addresses are controlled by the provider's rules. The platform can make public identity convenient, charge for it, withdraw unused inventory, require cleanup and embed address decisions in account governance.
BYOIP changes the bill but not the dependence. A customer may avoid some platform public-IP charges by bringing its own range, and it may preserve reputation and allowlists. Yet the customer still has to pass the platform's admission process. The address must be accepted into the provider's product model, placed in a region or account, advertised at the right time and associated with supported resources. The customer trades one form of platform dependence for a more complex arrangement: public identity remains portable in principle, but its cloud use depends on registry evidence and provider acceptance.
Managed egress services intensify the issue without making metering the centre of the story. A cloud design may reduce the number of public endpoints by putting many private workloads behind a small set of public exit addresses. That can save effort and simplify security posture. It can also concentrate public identity. A few addresses become the face of bank APIs, fraud systems, partner firewalls, monitoring services and incident records. If those addresses are provider-owned, the dependency is concentrated in the platform. If they are customer-owned, the customer needs evidence strong enough to bring them in and move them out.
Inventory gives platforms strategic optionality. A provider with large public IPv4 holdings can offer quick launch, clean account association, global advertising and integrated abuse handling. A customer with a portable prefix can negotiate against that convenience only if its own evidence is equally acceptable. If ARIN's record is precise, current and service-specific, the customer can compare provider addresses, BYOIP, leasing and purchase on ordinary commercial grounds. If the record creates avoidable doubt, platform inventory becomes the safer asset even when it is more expensive over time.
The visible price per public IPv4 may look small next to compute, data transfer or security tools. That is not the full cost. The larger price appears after the address has been learned by outsiders. A public endpoint that costs little per hour can become expensive to move after it sits in a bank allowlist, a customer procurement file, a fraud model, a mail reputation system or an incident archive. Cloud pricing makes scarcity visible at the start. Reputation makes the decision durable later.
BYOIP converts ARIN evidence into private platform admission
BYOIP is the place where ARIN's public record becomes private platform evidence. A cloud provider cannot safely allow any customer to announce any prefix through a global backbone merely because the customer asks. The provider must protect its network, its reputation, other customers and routing relationships. It therefore asks for proof that the customer or a recognised authorising party controls the range, that the route announcement is allowed, that the prefix is large enough and suitable for global routing, that the address history is not too dirty, and that the cloud account is the right place to carry the risk.
The mechanics differ by provider, but the economic pattern is consistent. AWS's EC2 BYOIP path ties imported ranges to Regional Internet Registry registration, /24 IPv4 granularity, business or institutional registration, RDAP-linked verification, route-origin evidence and clean-history review. Google Cloud uses customer-only imported prefixes, route-origin and reverse-DNS validation, overlap warnings and project-scoped prefix structures. Azure describes custom IP prefixes through validation, provisioning and commissioning, with ownership, advertisement authorisation and reputation continuity as central reasons for import.
These are product facts, not universal rules of internet legitimacy. A cloud provider may change a product path, create a different verification method, alter a prefix-size limit or impose additional account checks. The institutional point is deeper: private platforms convert registry facts into cloud admission. Holder recognition, route-origin authority, reverse-DNS control, clean status, abuse contactability, prefix size, account association and route history all become part of the platform's decision. The public record is not sufficient by itself, but without it the private decision becomes slower and more discretionary.
ARIN matters because it can lower the verification cost. A customer bringing ARIN-region space should be able to show who is recognised, which entity can authorise use, which origin is intended, which contact channel is accountable, which reverse-DNS path is controlled, whether a transfer or lease is relevant, and whether any status affects service. The platform should not have to interpret an old corporate story, a broad dispute label or a private claim with no public anchor. The customer should not have to buy provider-owned addresses merely because the independent evidence is hard to package.
BYOIP also reveals the boundary between public record and private acceptance. ARIN can supply facts; the cloud provider can still reject a range for product, security or reputation reasons. That separation is important. It would be dangerous for a registry to force a platform to advertise a prefix. It would also be dangerous for a platform's private acceptance rules to become the only practical source of public identity. The balance works when ARIN makes the customer's authority cheap to verify and the cloud provider remains responsible for its own network risk.
The difficult cases are the ones modern business actually uses. A parent company may hold the prefix while a subsidiary runs the service. A managed-service provider may operate the cloud account. A public agency may contract through an integrator. A lessor may remain the recognised holder while a customer uses the range for a fixed term. A company may be acquiring a business and staging a migration before every corporate record has been modernised. These arrangements are not automatically suspicious. They are ordinary ways to organise scarce resources. They become risky only when the authority chain is hidden, stale or hard to prove.
The registry's task is not to approve every business arrangement. It is to make the relevant facts legible. Who is recognised? Who is authorised for this use? Who can change route-origin statements? Who controls reverse DNS? Who receives abuse reports? What happens if the lease ends, the account is recovered, a transfer completes or a dispute appears? If those answers are precise, BYOIP is a real outside option. If they are vague, the cloud's own addresses win by default.
Account boundaries decide who can move the address
Cloud address power often hides inside account boundaries. The public address may be attached to a virtual machine, but the authority to allocate it may sit higher in the organisation. It may belong to a project controlled by a platform team, a subscription owned by a procurement unit, a shared-services account, a managed-service provider's account, a landing-zone team, a security appliance, a Kubernetes ingress controller, a global load balancer or a provider-managed edge service. The person who can deploy code may not be the person who can move the public identity.
That distinction matters because public identity is more durable than many cloud resources. A virtual machine can be rebuilt. A container cluster can be replaced. A database can be replicated. A load balancer can be swapped. The public address, however, may sit in external systems that do not move on the cloud team's schedule. If account authority is unclear, a simple migration becomes an internal governance problem. Who may release the address? Who may associate a BYOIP range with another account? Who may authorise a route change? Who may delegate reverse DNS? Who can answer the platform if abuse occurs? Who can recover control if a contractor leaves?
Large organisations often create the problem while trying to manage risk. They separate live-service and development accounts, isolate business units, use centralised network accounts, place security tools in shared services and restrict who can advertise public prefixes. These controls are sensible. They can also make address movement depend on internal politics. A division may own the customer contract but not the public endpoint. A central platform team may own the address but not the regulatory duty. A contractor may have technical access without corporate authority. A cloud account may be tied to a procurement entity that is not the ARIN-recognised holder.
Provider-owned addresses make the first deployment easier because the platform's account model decides. If the address is allocated to a load balancer in an account, the customer follows the platform's permissions. But that simplicity can create future leverage. Moving the service may require releasing and replacing the provider address, or recreating the same public identity through another product path that does not support it. The customer is then bound not by a legal prohibition but by the fact that public address identity was born inside the platform account.
Customer-owned prefixes reduce that dependence only if account architecture is planned. BYOIP should not be treated as a late migration ticket. The company needs to know which legal entity holds the prefix, which cloud account imports it, which business unit may use derived addresses, which service can advertise them, how sub-prefixes are delegated, who can withdraw the announcement, and how emergency recovery works if an account is locked or a staff member departs. Without that map, customer-owned space can still be trapped inside a cloud account.
Managed endpoints add another layer. A global accelerator, content edge, API gateway, managed database, security appliance or cloud firewall can hide address decisions behind a service abstraction. The abstraction may improve performance, failover and security while making public identity depend on product boundaries the customer does not fully control.
ARIN cannot design the customer's cloud organisation. It can, however, make account authority easier to prove and recover. Clear public records, role-specific contacts, route-origin timing, reverse-DNS handover paths, precise status labels and accepted equivalent proof all help when a cloud provider asks whether the account requesting use is connected to the recognised holder. Account boundaries will always matter. They should not turn public identity into a hostage of internal cloud administration.
Reputation and allowlists make public addresses sticky
Public addresses become powerful because they are remembered. A partner's firewall remembers them. A bank API gateway remembers them. A fraud system assigns history to them. A mail receiver associates them with prior sending. A geolocation provider places them in a country, region or city. A procurement file lists them as an approved endpoint. A security operations centre searches logs by them. An insurer, auditor or public buyer may not care how the cloud account is organised; it cares whether the same public identity remains stable and accountable.
Reputation is not always accurate. Address history can be contaminated by prior users, stale geolocation, old abuse records, shared cloud pools, dynamic assignment, mail spikes or private lists that are difficult to correct. But reputation does not need to be perfect to create switching cost. If a customer's current address is accepted by enough counterparties, any replacement address has to be warmed, explained and tested. That process has a cost even if the new address is technically clean.
Cloud providers understand this. Their own materials describe customer-brought IP as useful for retaining established reputation and continuing to pass externally controlled allowlists. That is an admission of economic reality. Customers bring their own addresses not because they enjoy registry paperwork, but because the outside world has already invested trust in those numbers. The platform can host the workload. The customer wants to keep the identity.
The same logic applies to provider-owned addresses, but in reverse. A provider-supplied address starts as convenience and becomes a reputation asset. A SaaS company launches an API, customers allowlist the address, incident teams learn it, fraud vendors classify it, and mail or notification systems build history. Two years later the company may want to move to another platform, split a business unit, create an active-active design or replace a managed service. It discovers that the address is not portable because the identity belongs to the platform's pool. The provider did not seize anything. The customer allowed public trust to form around a rented identifier.
Abuse handling is part of the stickiness. Public addresses need a credible complaint path. In a provider-owned pool, the cloud provider can receive, triage and enforce at scale. That gives counterparties confidence but also gives the platform control over reputation response. In a customer-owned prefix, the holder or authorised user must maintain abuse contactability, evidence of responsibility and a path to isolate bad downstream behaviour. If the public record is weak, counterparties may prefer the provider's abuse machinery even when the customer wants portability.
Reverse DNS, geolocation and procurement records reinforce the same effect. PTR names help mail systems, logs, abuse desks and customers understand what service they are seeing. Location databases and customer files may lag long after routing changes. A migration that preserves addresses but mishandles these surrounding records can still look sloppy. Stable public identity reduces that support and sales cost. Losing it gives leverage to the party that controls the old identity.
Reputation therefore changes the economics of cloud choice. The address a company uses at launch may be cheap. The address it has taught everyone else to trust is not cheap. ARIN's record supports competition by making that second address portable where the customer or authorised holder has the right evidence. Without portability, reputation becomes an annuity for the platform whose pool supplied the address first.
Managed endpoints quietly write address policy
Modern cloud customers rarely attach every public address directly to a server. Public identity is often mediated by a managed endpoint: load balancer, API gateway, edge service, accelerator, managed egress, firewall, managed Kubernetes ingress, platform-managed database endpoint, VPN gateway or private-link front door. These services are useful because they reduce operational burden. They also convert product design into address policy.
A managed load balancer may support provider addresses by default and customer-brought ranges only under certain conditions. A global edge service may use the provider's anycast pool. A managed egress service may concentrate many private workloads behind a few public exit addresses. A managed Kubernetes service may allocate addresses through a controller controlled by the platform account. A security appliance may terminate traffic in a shared-services account. A database may expose a managed public endpoint that cannot carry the customer's own prefix. The address plan is then shaped by product compatibility, not just by resource ownership.
This product layer can make platform addresses look inevitable. Engineers choose the managed service because it is reliable, observable and supported. Later they discover that the public identity created by the service cannot move cleanly. If the product does not support the customer's prefix, or supports it only in a narrower scope, a business continuity decision has been made through a feature matrix. The result may be technically reasonable. It should not be invisible.
Public-IP pricing reinforces the design. If direct public addresses are charged, architectures move toward fewer managed endpoints and more private addressing. That may reduce public exposure, but it also concentrates trust. The addresses that remain are more important. They become the egress identity for many services, the ingress identity for many customers or the failover identity for a whole platform. The fewer public addresses a company uses, the more each one matters.
Managed egress should stay in proportion. It can become expensive and strategically important, but the deeper issue here is not egress metering by itself. It is the public identity behind managed exit and managed entry. If a company's partners allowlist the public exit addresses, those addresses become exit-critical. If they are provider-owned, leaving the platform requires partner work. If they are customer-owned and properly admitted, the company can change the underlying service while preserving the public face.
Product design also affects recovery. A company may want active-active deployment across regions or providers. Provider-owned managed endpoints may not be portable across that boundary. A customer-owned prefix may help, but only if each provider accepts it and if route-origin timing is handled carefully. A global service may promise resilience while still leaving the customer dependent on a platform-specific address pool. The distinction should appear in procurement and architecture reviews before the service becomes customer-facing.
ARIN cannot force platforms to support every customer-owned prefix in every product. It can make the public evidence for accepted prefixes sharper and faster. Cloud providers will continue to decide product scope. Customers will continue to choose convenience. The registry's contribution is to ensure that when a platform says "bring your own address if you can prove it," the proof path is not artificially expensive. Managed public endpoints should compete on service quality, not on the customer's inability to make portable identity credible.
Transfers and leasing keep an outside option alive
The outside option to platform address dependence is a portable prefix. In the ARIN region, that option usually comes through legacy holdings, specified transfers, mergers and acquisitions, leasing, address-management specialists or an existing holder within a corporate group. Each path can give a customer public identity that is not born inside a cloud platform. Each path also carries evidence, cost and timing.
Purchase gives the strongest psychological sense of control, but it is not simple. The buyer must verify that the seller is the recognised holder or valid successor, that the range is eligible and not subject to a blocking dispute, that transfer requirements can be met, that route-origin state will be cleaned up, that reverse DNS can move, that contacts will be updated and that reputation issues are understood. The legal and registry file can be larger than the block itself for small deals. A large enterprise can absorb that. A smaller SaaS company, hospital supplier or Caribbean hoster may find the fixed cost high.
Leasing can be more flexible. A company may need address capacity for a contract term, a cloud migration, a recovery site, a mail pool, a regional expansion or a customer-specific service. Leasing allows use without permanent purchase. It can also place registry-facing risk with a specialist holder. That structure may be commercially sensible where the customer wants continuity of use but does not want to manage the full registry relationship. The tradeoff is that authority must be clear: who can authorise origin, who controls reverse DNS, who handles abuse, what happens at renewal, and how the range is withdrawn or preserved if a dispute appears.
Address-management firms and brokers reduce search and evidence costs. They know which holders have supply, which ranges have clean history, how transfer files are prepared and what cloud platforms ask for. Their expertise is valuable. It also shows that the market still depends on specialised translation. If every ordinary cloud-import case requires an intermediary to explain the address story, the outside option is not as strong as it should be. A mature record should reduce the need for private interpretation.
ARIN's transfer architecture can discipline platform power when it behaves like a predictable settlement layer. Source authority, recipient identity, dispute status, fee standing, route-origin handover, reverse-DNS continuity and public contacts should be clear enough for customers and clouds to plan around. Needs-based or compatibility rules, where they apply, should be narrow and predictable. Broad uncertainty around whether a buyer's future use is satisfactory suppresses the outside option that makes platform address power contestable.
Leasing is especially sensitive to legitimacy. If a lessee can show a credible chain from recognised holder to authorised cloud use, leasing becomes a useful bridge between scarce supply and customer need. If leasing is treated as inherently suspect, parties may keep arrangements private, making abuse response and accountability worse. The registry does not need to bless every lease price or customer plan. It needs to preserve accurate records and make authorised use legible enough for counterparties to trust.
The outside option must also be updateable. A portable prefix that cannot update ROAs quickly, change reverse DNS, recover account authority or correct contact data is less portable than it appears. A customer considering platform exit will ask whether those changes can be made on a migration clock. A cloud provider considering import will ask whether the evidence will remain true after onboarding. A bank or public buyer will ask whether the address plan survives renewal, acquisition or account recovery. Portability is not one document. It is the continuing ability to keep public identity aligned with control.
The ARIN region's mature transfer economy is therefore both strength and warning. The strength is that customers can assemble outside options more readily than in a less developed address market. The warning is that maturity can hide fixed costs. If the outside option works only for large buyers with counsel, brokers and cloud specialists, platform inventory will still dominate small and mid-sized customers. A portable-prefix market disciplines cloud power only when its proof path is cheap enough for ordinary serious operators.
Exit leverage works before contracts forbid anything
The strongest form of platform address power is quiet. A cloud provider does not need to say that the customer may not leave. The customer remains free to export data, rebuild services, change vendors and sign a new contract. Yet the public identity layer can make exit feel like a controlled transaction. Every partner allowlist, bank callback, VPN endpoint, mail pool, fraud rule, procurement notice and incident history becomes a small vote for staying.
Exit leverage begins with notification. Customers that have embedded an address in their own systems need notice, testing windows and rollback plans. Some will move quickly. Others will ask for paperwork. Banks, public bodies, healthcare partners and enterprise customers may have slow controls. A migration that changes public addresses can become a customer-success campaign rather than an infrastructure event. The platform that owns the existing addresses benefits from that inertia.
The second cost is security retesting. A new public address may need firewall changes, DDoS policy updates, WAF rules, SIEM tuning, vulnerability scanning, certificate review, route-origin validation and incident-response updates. None of these tasks is unreasonable. Together they make exit more expensive. If the current address is provider-owned and cannot move, the customer must pay this cost to leave. If the customer owns or controls a portable prefix, the cost is much lower because public identity can move while underlying infrastructure changes.
The third cost is reputation warm-up. Mail systems may require gradual sending. Fraud vendors may need time to relearn. API partners may require test transactions. Geolocation databases may lag. Threat-intelligence tools may carry old labels. Even a clean address can be treated as unknown. An unknown address is not the same as a bad address, but cautious counterparties often price the difference. Provider-owned identity becomes leverage because it already has history.
The fourth cost is evidence synchronisation. Exit may require new ROAs, updated route-origin records, changed reverse-DNS delegation, revised abuse contacts, cloud withdrawal of an imported prefix, release of a provider address, updated public records, and customer-facing assurance that no unauthorised party can continue using the old identity. These changes sit on different clocks. If one clock misses the migration window, the customer may delay exit even after the new platform is technically ready.
The fifth cost is audit explanation. A regulated company may have to explain why public endpoints changed, who approved the move, how partners were notified, how logs will be correlated, what happened to old addresses, and whether customer data or network access was exposed during transition. If the company is leaving provider-owned addresses, it must show that the public identity shift was controlled. If it is moving its own prefix, it can show continuity through registry evidence and platform admission records.
This is why exit leverage should not be measured only by contract terms or data portability. Public identity can be more stubborn than data. A customer can copy a database in hours and still spend months persuading counterparties to trust new addresses. The platform with the trusted address pool holds a quiet bargaining position. It can raise prices moderately, alter product terms, change support levels or shape architecture decisions while knowing that address exit carries high social cost.
The answer is not to treat every use of provider addresses as a mistake. Short-lived workloads and low-risk public endpoints may not need portable IPv4. The answer is to identify where public identity has strategic value and make portability part of the design. For those services, provider addresses are rented identity; customer-owned or properly leased space is bargaining capital. ARIN's role is to keep that capital credible enough that exit remains practical.
A weaker registry record would strengthen the largest platforms
AFRINIC is a cautionary comparator, not the subject of the ARIN analysis and not a prediction. The institutional histories, legal settings, market depth and cloud geography differ. ARIN operates in a mature North American environment with deep transfer expertise, large cloud providers, sophisticated enterprise buyers and a widely read public record. AFRINIC's recent institutional stress has made registry legitimacy, litigation, continuity and address-value disputes more visible. The useful comparison is narrow: when registry legitimacy weakens, platforms and larger intermediaries gain from selling clean public identity.
The mechanism does not require collapse. A registry record can remain online while counterparties ask for more proof. A route can continue to propagate while a cloud provider slows BYOIP acceptance. A holder can still use a prefix while a customer discounts its portability. The premium appears as delay, extra warranties, higher diligence, lower valuation, narrower leasing, more reliance on intermediaries and stronger platform bargaining power.
That premium is regressive. Large platforms can carry address risk because they have pools, counsel, security teams, abuse operations, routing staff and customer leverage. Large enterprises can assemble evidence packages. Smaller operators and customers pay the fixed cost most painfully. If independent address space looks uncertain, they choose provider addresses, not because that is always the best long-term strategy, but because it is the path least likely to fail an approval desk.
The general lesson is that a registry should reduce uncertainty, not become another source of it. Protecting the record means preserving uniqueness, accurate holder records, contactability, reverse DNS, route-origin publication, transfer history, dispute precision and continuity for running services. It does not mean turning every cloud use, lease, geographic use or monetisation plan into a broad permission question. The more important the registry record becomes, the narrower and more auditable its power should be.
The comparator also clarifies why platform address power should not be fought by expanding registry discretion. If a registry makes customer-owned or leased space harder to use in cloud because it dislikes out-of-region use, leasing, speculation or large platforms, customers do not stop needing public IPv4. They move toward platform-owned addresses. The platform then sells not only compute, but clean public identity. A registry that intended to restrain cloud power may strengthen it by weakening the outside option.
ARIN's stronger institutional setting gives it a chance to avoid the smaller version of the same problem. The risk is not visible crisis. It is quiet overbreadth: vague status labels, slow authority recovery, unpredictable proof demands, service locks that affect more than the service at issue, and uncertainty over routing or reverse-DNS timing. These frictions may look orderly in a mature market. They still make platform inventory more attractive.
The constructive lesson from the comparator is therefore pro-record and anti-chokepoint. Make facts precise. Preserve last verified operational state where safety allows. Record disputes narrowly. Accept equivalent proof for the fact that must be proved. Keep running services separate from unrelated institutional fights. Let customers, clouds, carriers, banks and courts make their own decisions on top of a reliable public record. Weak registry legitimacy transfers trust creation to the strongest private participants. Strong, narrow registry legitimacy keeps trust cheap enough for customers to own.
ARIN's constructive test is narrow proof, continuity and recovery
The public rule for cloud-era address portability can be stated plainly. Protect the record. Reduce verification cost. Preserve portability. Separate registry facts from discretionary control. Keep acceptance evidence narrow. Prevent private or institutional chokepoints from becoming hidden capital controls. These principles are not anti-registry. They are the reason a registry remains legitimate in a scarce address economy.
Protecting the record means being strict about the facts that matter. The recognised holder should be accurate. Successor identity should be verified. Contact roles should work. Route-origin statements should match authority. Reverse-DNS delegation should follow control. Transfer history should be preserved. Disputes should be recorded when they affect reliance. Fraud, forged authority, account compromise and duplicate claims should be handled firmly. A weak record does not help customers against platforms. It makes platform addresses look safer.
Reducing verification cost means naming the fact to be proved and accepting evidence that proves that fact. A legacy holder may not have the same document set as a modern venture-backed SaaS company. A public body, university, hospital system, carrier, family-owned ISP, estate, receiver or reorganised enterprise may prove authority differently. If the fact is current signer authority, ask for that. If the fact is route-origin authority, ask for that. If the fact is reverse-DNS control, ask for that. Broad proof requests turn record maintenance into a private compliance market.
Preserving portability means treating public identity as a reliance layer around running services. A customer should be able to move a prefix across cloud, carrier, hosting and recovery environments when authority is clear. That does not require careless approval. It requires service-specific timing, clear handover states, emergency correction, and a presumption that unrelated institutional concerns should not disturb live route-origin, reverse-DNS or contact continuity unless the service itself is at risk.
Separating registry facts from discretionary control means keeping business-model judgments out of recognition unless a defined rule and evidence category require them. The registry can ask whether the holder authorises a lessee. It need not decide whether leasing is admirable. It can record that a prefix is imported into a cloud under authority. It need not decide whether the customer should prefer local hosting. It can respond to a court order. It need not convert every caution into a broad market hold. Scarce public identifiers should not become instruments for hidden industrial policy.
The practical test starts with equivalent proof for BYOIP. A holder or authorised user should be able to assemble a standard evidence package that clouds can understand: recognised holder, authorised account or user, route-origin authority, reverse-DNS control, abuse contact, prefix scope, known transfer or lease context, and any service-specific limitation. Equivalent proof should be accepted where it proves the same fact. A legacy university, a Canadian public body, a Caribbean operator and a Delaware SaaS company should not be forced into one corporate template if their evidence answers the relevant question.
The next test is clear status language and service-specific restraint. A cloud provider, customer, lender or public buyer should not see a vague label and wonder whether routing, transfer, reverse DNS, account authority, payment standing or contact correction is affected. If an account risk affects route-origin changes, restrict route-origin changes. If a reverse-DNS authority question exists, address reverse DNS. If a transfer is paused, say whether ordinary contact maintenance remains available. Precision lets counterparties respond proportionately.
The same discipline should preserve last verified state for running services when safety allows. If a dispute, account issue or evidence gap does not directly require a live route-origin statement, reverse-DNS delegation or abuse contact to change, the safer state should often be preservation while the narrow issue is resolved. Preservation is not a decision on every private right. It prevents customers from becoming collateral damage when a registry question can be isolated.
Routing-authorisation timing and reverse-DNS handover should also be treated as market facts. Cloud import, platform exit, transfer and recovery all depend on route-origin evidence changing on the right clock. A cloud-customer prefix may need PTR continuity during import, exit, lease renewal, service split or acquisition. ARIN should make it clear who can create, modify or withdraw authorisations, how pending transfers affect that authority, how emergency correction works and how routine and exceptional timing behaves in aggregate. Without timing visibility, customers build cushions that make portability less attractive.
Account-authority recovery is the final practical test. Cloud address plans often fail because the wrong person, contractor, subsidiary or old role controls a step. Recovery paths must be practical for legitimate holders without weakening security: role-specific contacts, current organisation validation, successor evidence, emergency escalation for live services, and audit trails that show who requested what. Account recovery should not become a private bargaining tool for whoever last held a login.
Customers should price public identity before it becomes history
The customer lesson is to price public identity before it becomes history. A company planning a cloud migration should classify public endpoints by strategic value. Some addresses are disposable. Some belong to temporary testing, consumer-facing services without static partner controls or low-risk sites that can be moved with ordinary DNS and customer notice. Others are strategic: payment APIs, hospital integrations, public-sector portals, enterprise VPNs, mail pools, customer-facing SaaS endpoints, fraud-sensitive services, supplier gateways and recovery fronts. The second group deserves an address strategy before launch.
The first question is ownership of identity. Will the service use provider-owned addresses, a customer-owned prefix, leased space, a partner range or a hybrid? Provider-owned addresses may be right where speed and simplicity matter more than future portability. Customer-owned or leased space may be right where customers will build durable trust around the endpoint. A hybrid may place low-risk traffic on provider addresses and critical endpoints on portable ranges. The wrong answer is not one option or another. The wrong answer is discovering the distinction only after the address is embedded in customer systems.
The second question is admission evidence. If the company wants BYOIP, it should gather evidence early: holder record, account authority, route-origin plan, reverse-DNS control, abuse contact, clean-history review, geolocation plan and cloud account association. If a lessor or parent entity is involved, the authority chain should be documented in language a cloud reviewer, bank, auditor and customer can understand. Waiting until cutover turns evidence into a crisis.
The third question is account architecture. Which account imports the prefix? Which team can allocate addresses? Which service can advertise them? Can a managed endpoint use them? Can a subsidiary, contractor or managed-service provider deploy them without gaining unnecessary control? Can the company withdraw or move the prefix if a platform account is locked? Address authority should be separated from unrelated permissions but not so fragmented that no one can act.
The fourth question is reputation. What external systems will learn the address? Which customers will allowlist it? Which banks, fraud vendors, mail receivers, procurement files, logs, geolocation services and security tools will treat it as stable? How will the company warm, monitor and correct reputation? How will it explain a change? Reputation planning is not a marketing exercise. It is the human work that makes technical reachability acceptable.
The fifth question is exit. What would it take to leave the platform while preserving public identity? If the answer is "renumber all critical counterparties," the company should know that before it accepts the first provider-owned address. If the answer is "withdraw and re-advertise our prefix under a planned route-origin change," the company should rehearse that path. Exit rights are credible only when the public identity layer has been tested.
The sixth question is procurement language. Customers and public buyers should ask whether endpoints are provider-owned or portable, what evidence supports BYOIP, who controls reverse DNS, how abuse is handled, and what happens if the cloud account or lessor relationship changes. Buyers do not need to become registry specialists to recognise that public address identity can be a supplier lock.
The seventh question is cost allocation. Public IPv4 charges are visible, but portability costs may be hidden in staff time, legal review, cloud support, broker fees, reputation correction, customer notices and audit work. A provider-owned address may be cheaper in the first month and more expensive after it becomes trusted. The comparison should price bargaining power, not only the hourly address charge.
Customers that ask these questions early will still choose cloud. Many should. The difference is that they will buy cloud services without unknowingly renting their entire public identity from the platform. They will know when provider-owned addresses are convenience, when BYOIP is strategic, when leasing is a bridge and when a platform product creates future exit cost.
Return to the migration room. The company still needs cloud services. It still values managed databases, security tools, global backbones and elastic capacity. But the decisive question is no longer only where the workload will run. It is whose public identity the workload will carry after customers, banks, auditors and security systems have learned to trust it. In the ARIN region, the answer should not be determined by avoidable registry uncertainty or by the quiet convenience of the largest address pools. A fast, narrow and trusted record is the public counterweight to cloud-provider address power.