Skip to main content
resource · gcp

Regional IP Address

schedulable
no
category
networking-services

Does ZopNight manage Regional IP Address?

A reserved regional external IP bills by the hour whenever it is not attached to a running resource, making orphaned reservations pure waste. ZopNight discovers every regional address via Cloud Asset Inventory, checks its attachment state, and flags unattached reservations as immediate cleanup candidates in its recommendations.

Rules that fire on Regional IP Address

no live rules

No active rule family targets Regional IP Address today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.

Browse every live recommendation for this platform →

A reserved regional external IP address provides a stable endpoint for VMs and load balancers. Google charges for reserved addresses that are not attached to a running resource, making orphaned IPs pure waste.

The hourly meter on a reserved regional IP

The billing logic on a regional address inverts the usual cloud pattern: you pay for it when it is doing nothing. An address attached to a running VM or forwarding rule serves traffic and, depending on the attachment, costs little or nothing extra; the same address sitting reserved but unattached accrues an hourly charge for holding a scarce IPv4 number out of the pool. The meter never grows with usage and never stops on its own. An orphaned reservation from a deleted VM keeps producing the identical line item every month until someone releases it.

Attachment state is the whole story

Because the charge hinges entirely on whether the address is in use, the only fact an audit needs per address is its attachment. ZopDev discovers reserved addresses via Cloud Asset Inventory and flags unattached addresses as immediate cleanup candidates in recommendations. There is nothing to schedule here, because an IP has no on and off state a scheduler could toggle. The entire savings motion is detection followed by a release decision.

Regional address waste patterns ZopNight surfaces

Two patterns account for most of the waste. First, teardown leftovers: a VM is deleted, but the static address that was promoted from its ephemeral IP survives the deletion and begins billing as unattached. Second, just-in-case reservations: addresses reserved for a migration or a firewall allowlist that never happened, held for months on the theory that releasing them is risky. The risk is real only if external systems (DNS records, partner allowlists) still reference the address, which is exactly what should be checked before release rather than a reason to keep paying indefinitely.

Reviewing regional IPs in the console

Google Cloud console → VPC network → IP addresses lists every reservation with a Region column and an In use by column. Filter to external addresses and sort by In use by: every row showing no attachment is billing hourly for holding a number.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·