In this article
A public address can have its own lifetime and cost. Verify its type, dependencies and owner before releasing it or assuming VM deletion removed it.
A public IP can remain after a GPU VM is powered off or deleted and may continue creating expense. Check the address type, association and provider billing rules separately. Do not release it blindly if DNS, allowlists or other services still depend on it.
Identify the address resource
Clouds distinguish temporary interface addresses from separately allocated static objects. Record resource ID, region, association and project owner. An IP preserved in an old SSH command does not explain its lifetime.
AWS Elastic IP documentation describes an address allocated to the account until release, with public IPv4 charges applying under its rules. Detaching it from EC2 is not the same operation as ending the address allocation.
Compare documented mechanisms
Azure Public IP is also described as a resource with its own properties. Its relationship with a VM does not make their lifecycles identical. Check the specific product and SKU rules rather than assuming one cloud’s experience describes another.
| Example | Documented distinction |
|---|---|
| AWS Elastic IP | Account allocation remains until release |
| AWS public IPv4 | Charging is not limited to idle EIPs |
| Azure Public IP | Independent Resource Manager object |
| Any project address | Needs association and dependency checks |
This is a mechanism comparison, not a current price table. Use the selected service’s current terms for the actual estimate.
Close a demonstration environment
A team deletes its temporary GPU VM but retains an address referenced by DNS. The owner first checks whether the next demonstration needs that identity. If not, update dependencies and release through the documented process. If retained, give the address a reason and review date.
A later operator should understand why an address exists without the original VM. Otherwise it can either remain forgotten and billable or be removed while another legitimate resource depends on it.
Audit before releasing
Look for client configuration, DNS records and permitted-source lists. These references do not disappear automatically when an association changes. Do not assume a released public address can be obtained again; preserve a procedure for updating names and clients.
Review all used projects and regions, not only the current VM list. Add each address’s dependent resource and owner to the inventory. If the purpose is unknown, identify the responsible project before deletion. An empty compute view does not prove the absence of networking components, and an apparently unattached address is not sufficient evidence that nobody needs it.
Turn the check into a practical next step
A public address can have its own lifetime and cost. Verify its type, dependencies and owner before releasing it or assuming VM deletion removed it.
For the documented details, consult the primary documentation; configuration reference. Continue with azure gpu deallocated cost components and cloud gpu resource cleanup audit.