Managed IP Addresses: What They Are, When You Need Them, and How to Track Them

Public IPv4 is the only finite resource in modern networking. The regional registries exhausted their free pools years ago, transfers have pushed prices to thousands of dollars per /24, and yet most growing organizations still need public addresses for the same reasons they always did: mail servers that must pass reverse DNS checks, customer facing services that need stable endpoints, and production deployments that cannot live behind a carrier grade NAT forever. Increasingly, the answer teams land on is not buying space at all but leasing it, which is why the phrase “managed IP addresses” shows up across hosting provider pages, ISP contracts, and colocation quotes. The term gets used loosely, and that ambiguity is dangerous, because leased address space behaves very differently from space you own, and the difference determines everything from your renewal calendar to your ability to change providers.

A managed IP address is public IPv4 space where a provider handles the administrative and registry work for you. You get the numbers, and the provider maintains the registry registration, announces the routing, manages reverse DNS delegation, and runs the abuse mailbox, which means you can operate production services without becoming a Local Internet Registry member or filing resource justification reports. The trade is that you never own the block. When the lease ends or you leave the provider, the addresses go back, and everything you attached to them has to move. For teams that lease a /28 for a colocation deployment or a /24 for a SaaS product, the real question is not whether leasing makes sense, it is how to keep track of what you are running on someone else’s address space. The sections that follow cover the distinctions that matter, the scenarios where leasing wins, and the records that keep a rented block under control.

What “Managed” Means in Practice

The distinction starts with the registry relationship. Managed addresses are provider aggregatable (PA) space: the provider holds the allocation from a regional internet registry as a Local Internet Registry, and your lease is recorded as an assignment inside their block. That arrangement is what makes the offering possible, because the provider already holds the registry relationship, pays the membership fees, and carries the compliance burden that would otherwise fall on you. In exchange, the provider’s management covers the operational work that makes the space usable: keeping WHOIS and RDAP records accurate, announcing the block through their upstreams, delegating the reverse DNS zone so you can set PTR records, and receiving abuse reports on a published mailbox.

The contrast is provider independent (PI) space, which your organization holds directly from the registry and keeps when you change providers. PI space is portable and valuable for that reason, but it requires registry membership, utilization justification, and annual fees, which is exactly the burden most teams lease to avoid. For the large majority of workloads, PA space is completely sufficient, and the only real cost is the portability you give up, which is why understanding what you are renting is the first step in tracking it properly.

The division of responsibility is worth being explicit about, because it defines what you still have to manage yourself. The provider owns the registry relationship, the routing announcement, and the abuse mailbox, but everything inside the block is yours: which addresses are assigned to which servers, what hostnames and PTR records they carry, what security policies apply, and whether the space is utilized or sitting idle. In practice that means the part of the work that vanishes with a managed lease is the registry paperwork, while the part that remains is the same IPAM discipline you would need for owned space. Teams that mistake a managed block for a fully outsourced one are the ones that end up with an undocumented /24 and a panic when the renewal comes due.

How Teams End Up With Managed IPs

Managed IPs arrive through several routes, and each one carries different operational details. The most common is dedicated and managed hosting, where the server price includes a set of addresses, the provider announces them, and you manage PTR records through a portal, which is convenient until you realize the addresses are tied to hardware you may move. Colocation and leased blocks work differently: you lease a /29, /28, /24, or larger range from a data center or IP broker, the provider announces it for you, and you partition it across your own equipment. Cloud providers offer their own flavor in elastic and reserved IPs, which are managed within the platform, priced per hour, and locked to that provider’s ecosystem, with no portability to your own network at all. Finally, many transit contracts include address space as part of the bandwidth commitment, so a /28 or /27 arrives attached to your upstream link and leaves again when you renegotiate.

None of these are bad options, but they have different renewal leverage. With hosting, the addresses are incidental to the hardware contract. With a leased block, the lease is a contract of its own with a term, a renewal date, and a price you can negotiate. With transit, the addresses are part of a larger commercial relationship. If you do not record which model each block came from, you cannot answer the question that matters most at renewal time: what happens to these addresses if this contract changes.

Independent IP brokers add a further wrinkle, because they source space from a variety of underlying holders and assemble leases that are not tied to any connectivity service at all. A broker lease gives you addresses you can announce over whatever transit you already have, which is the closest a managed arrangement gets to owning the space, but it still carries the same hard boundary: the block belongs to the broker’s holder, and the lease contract defines your rights. The practical lesson across all four models is that the commercial wrapper matters as much as the technical prefix, so the first thing you document about any managed block is not the CIDR but the contract that grants it to you.

When Leasing Makes Sense, and When It Does Not

Leasing is the right answer in a specific set of circumstances, and the first is speed. Buying space means waiting on registry transfer approvals that take weeks, or joining waiting lists with multi year queues, while a lease from a broker or ISP can be live in days because the provider already holds the allocation. The second is cost at scale: cloud provider IPs run between $2.90 and $5.80 per IP per month, while dedicated lease rates have hovered around $0.40 per IP per month, so a footprint of a few hundred addresses is dramatically cheaper to lease outright. The third is avoiding registry administration, because a lease comes with the provider’s registry relationship included, and you never have to file utilization reports or maintain an LIR membership to keep using the space.

Leasing is also worth considering when you need addresses in a specific region without establishing a legal presence there, since a regional provider’s block gives you local geolocation and routing. But there are equally clear cases where you should not lease. If a single server sits behind NAT, or your entire workload runs inside one cloud provider and its address abstractions are sufficient, paying for dedicated space is pure waste. And if a service already gives you addresses as part of the product, you are already on a managed model and should focus on documenting it rather than buying more. The decision framework is straightforward: lease when you need real, public, stable addresses and the numbers justify it; skip it when an abstraction already provides what you need. Either way, a deliberate IP planning process keeps the decision from being made by default.

The threshold is mostly a numbers question, and it shifts with your footprint. A handful of addresses inside a cloud VPC costs almost nothing and is not worth the administrative overhead of a lease. But once your public footprint crosses a few dozen addresses, the per IP math flips, because cloud pricing scales linearly while a /24 lease is a fixed monthly line with room to grow. The same logic applies to stability: if your addresses only need to survive for the life of a project, the cloud’s abstraction is fine, while anything with a multi year horizon deserves space you can plan around. Think of the lease decision the way you think about compute, as a capacity choice with a cost curve, rather than a one time procurement event, and the right answer for each environment becomes obvious.

What It Really Costs

The economics of leased space are worth stating precisely, because they change how you treat the addresses operationally. Dedicated lease rates in 2026 have been averaging around $0.40 per IP per month, with small blocks like a /24 running $97 to $128 per month and large blocks like a /16 costing less per address, while cloud IPs remain roughly seven to fourteen times more expensive per IP. Leases typically run 12 to 36 months, and some providers charge a setup fee or a premium for month to month terms. Buying, for comparison, costs $30 to $45 per IP for a /24, plus transfer fees and the registry relationship you would have to maintain.

The consequence is that leased addresses are a recurring operational expense, not a capital asset, and that changes what you must track. An empty leased block still costs you every month, so utilization is a budget discipline rather than a technical nicety. A lease renewal is a deadline with production impact, because missing it can pull addresses out from under running services. And the cost per block becomes a line item that finance will eventually ask about, so you need the answer at hand: what is this block, what does it cost, how full is it, and when does it renew.

Rates also vary in ways worth understanding before you sign. Small blocks like /24s carry a premium because demand for them is targeted and steady, while very large blocks trade at a discount per address because fewer buyers can absorb them. Region matters too: supply constrained registries and markets see higher lease rates, and a block with a long clean reputation history costs more than one that has been through abuse incidents. Setup fees and minimum terms are negotiable in practice, especially when you are leasing multiple blocks or bundling with transit, which is why the commercial details are exactly the kind of thing you want recorded somewhere other than an email thread. A rate change at renewal is common enough to plan for, and a block’s documented history gives you the baseline to judge it.

The comparison you actually make at budget time is between leased space and every alternative at once: cloud IPs at several dollars per address, purchased space with its one time cost and registry obligations, and carrier grade NAT with its quality trade offs. Because each option plays out over different time horizons, the honest way to compare them is with the numbers recorded: current utilization, unit cost, and expected growth, side by side.

The Catch: Renumbering and Portability

The defining limitation of managed space is that it is not portable, and renumbering is the real price of the convenience. When you leave a provider, PA space returns to them, and every A record, TLS certificate, firewall allowlist, partner integration, and email reputation tied to those addresses has to migrate to the new block. Teams that have been through it describe the renumbering project as worse than the original migration, because it touches not just your own systems but every third party that ever pinned your addresses in a configuration file. The mitigations are the boring, unglamorous ones: address services by DNS name rather than literal IP, keep allowlists small and documented, and maintain the assignments so that a migration is a scripted exercise rather than an archaeology project.

The block also carries obligations regardless of who owns it. Reverse DNS must be kept accurate, because a missing or mismatched PTR record sends your mail to spam folders and erodes your sending reputation. Abuse handling follows the space, so you need a mailbox that responds and a process for remediating compromised hosts before the provider does it for you. None of this is unique to managed space, but it is easier to ignore when the addresses feel like a subscription, and that complacency is exactly how a block ends up blacklisted.

Because renumbering is the price of every managed block, it deserves planning in advance rather than panic at departure. The practical playbook is well established: keep DNS TTLs low on public records well before the move, add the new addresses alongside the old during a transition window instead of swapping overnight, and use the documented assignments to script the cutover rather than rediscovering what runs where. The teams that survive provider changes painlessly are the ones whose address records were already complete, which is a strong argument for treating the documentation of a leased block as a condition of using it, not a chore to defer until someone asks for it.

What You Need to Track on a Leased Block

The tracking discipline for managed space starts with the block itself: the CIDR notation, the usable range after network and broadcast addresses are removed, and the gateway. From there you need the commercial record, the provider, the lease term, the renewal date, the monthly cost, and the abuse contact, because those are the details that turn a service outage into a contractual dispute. Operationally you need the site or region where the block terminates, the VLAN or VRF that carries it, and every address assignment tied to a device, VM, interface, or hostname. Reserved addresses for gateways, load balancers, and future growth need to be marked explicitly, because an unrecorded reservation is indistinguishable from an exhausted pool. Keep the technical and commercial records in the same place, because they decay at different speeds and either one can bite you independently.

None of this stays accurate by accident. Addresses get reassigned during maintenance, leases get renegotiated, servers get decommissioned, and each event quietly invalidates the previous state of your records. The failure mode is familiar: a block that looks exhausted because half of it is assigned to dead services, a renewal missed because the contract lived in someone’s inbox, an incident where the first question, which server owns this IP, takes an hour to answer. Structured records built into your normal workflow avoid all three, and they turn a leased block from a source of anxiety into just another documented part of the network. When you need to know how many usable addresses a proposed block actually carries, a quick pass through an IPv4 range calculator settles it before you commit to the lease.

This is also a team problem, not just a personal one. A spreadsheet in a shared drive can hold the same data, but it offers no validation, no conflict detection, and no access control, so two engineers can quietly edit the same block in contradictory ways and nobody is the wiser until an outage surfaces the discrepancy. Managed address space has a way of being touched by everyone, network engineers for the routing, platform engineers for the servers, and finance for the invoices, which is exactly the scenario where a single editable document fails fastest. The records need to be authoritative, structured, and accessible to the people who act on them, which means the tracking system has to be part of your regular infrastructure workflow rather than a file that gets updated when someone remembers.

Done properly, the payoff is concrete at each stage of the lease lifecycle. During procurement you can see existing blocks and their utilization to size the next lease with real numbers. During operation you can answer allocation questions without walking a rack or reading a router config. At renewal you can walk into the conversation with the provider knowing exactly how much of the space you use and what it costs you per address. And at audit time, whether internal or regulatory, you can produce a complete history of who assigned what address to which device and when. That is the difference between treating managed IPs as a recurring bill and treating them as a managed asset, and the gap between the two is entirely a documentation discipline.

Tracking Managed IP Addresses with Obelinf

Obelinf gives every leased block the same structured home as the rest of your network, so managed space stops being a parallel spreadsheet nobody trusts. Create the block as a subnet with its CIDR validated at entry, link it to the site where it terminates and the VLAN or subnet or VRF that carries it, and record the lease details, provider, and cost in the description field so the commercial context lives next to the technical record. Reserved addresses for the gateway and infrastructure are marked explicitly, and every usable address is assigned to a device interface or VM with a hostname, which is what lets you answer “which server owns this IP” from your source of truth instead of from memory.

Because the same IP address management data model covers leased and owned space alike, utilization is calculated in real time on every subnet, so a block approaching exhaustion shows up before you run out during a launch, and an underused lease becomes visible as the budget line it is. Every change carries an automatic field level changelog with the responsible user and timestamp, giving you the audit trail for renewals, security reviews, and provider disputes without extra effort. And when an address is linked through its device to the network topology, tracing a reported address to the physical path takes minutes, not hours.

The value compounds exactly where managed space hurts most: at the boundaries of the lease. When the renewal lands, you know precisely how full each block is and what it costs per address, so the negotiation starts from facts rather than a guess. When a provider change is forced, the assignments are already recorded, which turns a renumbering project into a migration you can execute instead of an investigation. And because leased space lives in the same system as everything else, it gets the same validation, the same change history, and the same visibility as the space you own. Leased addresses are someone else’s space, but with Obelinf they are fully your documentation.