# Global IP Address

> Reserved global external IPs anchor global load balancers on a single anycast address and bill continuously while unattached. ZopNight inventories every global reservation through Cloud Asset Inventory and flags idle ones for cleanup, with a caution: a released global IP is hard to reclaim and DNS may still reference it.

Source: https://zop.dev/integrations/gcp/gcp-global-address
Updated: 2026-08-19

---

A reserved global external IP address anchors global load balancers and other worldwide endpoints. Like regional addresses, reserved-but-unattached global IPs bill continuously for no service.

## Global anycast addresses and their idle charge

A global address differs from its regional sibling in scope, not billing shape: it is a single anycast IP announced from Google's edge worldwide, and it exists to front global external load balancers. While attached to a forwarding rule it is part of a working front door. Reserved but unattached, it bills continuously for no service. That is the same pay-for-idleness inversion as regional addresses, applied to a rarer and more valuable kind of number. Global reservations tend to be created deliberately (for a product launch, a DNS cutover) and then forgotten deliberately too, because everyone remembers they were important once.

## How ZopNight treats global reservations

ZopDev discovers global addresses via Cloud Asset Inventory and flags unattached reservations as cleanup candidates. As with any address, there is no lifecycle to schedule (the resource is either held or released), so the platform's role is inventory and honest flagging rather than automation. The attachment check is what separates a working anycast endpoint from a monthly charge with no traffic behind it.

## Why global IPs deserve a release checklist

The stub's caution is worth expanding: check before releasing, because global IPs are hard to reclaim. Once released, the specific address returns to Google's pool and there is no path to get that exact number back. Anything wired to it breaks quietly: public DNS records with long TTLs, customer firewall allowlists, mobile apps shipped with a pinned endpoint. The right cleanup sequence is: confirm the forwarding rule is gone on purpose, search DNS zones for records answering with the address, notify any partner who allowlisted it, and only then release. An unattached global IP that fails this checklist is cheap insurance; one that passes it is pure waste.

## Console location for global IP reservations

Google Cloud console → VPC network → IP addresses, with the Type column showing Global. The In use by column tells the whole story: rows with no attachment are the cleanup candidates, and 1 minute of checking each against DNS is the difference between savings and an outage.