🚨 GCP Error Guide: 'Quota IN_USE_ADDRESSES exceeded' — Fix External IP Limit

Overview

Compute Engine rejects a request that would consume another external IP address once your project hits its regional IN_USE_ADDRESSES quota. The literal error reads:

Quota 'IN_USE_ADDRESSES' exceeded. Limit: 8.0 in region us-central1.

The same limit blocks Terraform applies and instance creates that request an ephemeral or static external IP:

Error waiting for instance to create: Quota 'IN_USE_ADDRESSES' exceeded. Limit: 8.0 in region us-central1.

The trap is the word in use: this quota counts every external IP that is attached to a resource (an instance, a forwarding rule, a NAT gateway). Reserved-but-unattached static IPs count against a different quota (STATIC_ADDRESSES), so teams often look at the wrong number and can’t explain why they’re at the ceiling.

Symptoms

• Instance creation, MIG scale-up, or load balancer provisioning fails with IN_USE_ADDRESSES exceeded.
• Terraform/Deployment Manager applies fail in a specific region while another region is fine.
• Autoscaling stalls because new nodes/instances can’t get an external IP.
• The failure is region-specific; the quota is per-region, not global.

Common Root Causes

• Genuinely at the regional limit — the default limit (often 8) is simply too low for the workload.
• Orphaned/unattached static IPs — reserved addresses left behind after instances or LBs were deleted, still billed and still consuming quota if attached to a lingering resource.
• IP sprawl from ephemeral IPs — every instance created with a default external IP consumes one; a large fleet exhausts the quota quietly.
• Load balancer and NAT forwarding rules — each external forwarding rule and Cloud NAT gateway address counts.
• Wrong quota inspected — confusing IN_USE_ADDRESSES (attached) with STATIC_ADDRESSES (reserved) and tuning the wrong one.
• Instances that don’t need public IPs — attaching external IPs to backends that should be private and reached via NAT or a load balancer.

Diagnostic Workflow

Check the actual quota and current usage in the affected region:

gcloud compute regions describe us-central1 \
  --format='table(quotas.metric, quotas.limit, quotas.usage)' \
  | grep -i address

List every external address and its status — this separates in-use from reserved:

gcloud compute addresses list \
  --filter='addressType=EXTERNAL' \
  --format='table(name, region, address, status, users.scope())'

Find addresses that are RESERVED (reserved, and if unattached, billed for nothing) vs IN_USE:

gcloud compute addresses list --filter='status=RESERVED AND addressType=EXTERNAL' \
  --format='table(name, region, address)'

Find instances carrying an external IP that may not need one:

gcloud compute instances list \
  --format='table(name, zone, networkInterfaces[0].accessConfigs[0].natIP)' \
  | grep -v 'None'

Example Root Cause Analysis

A managed instance group failed to scale up in us-central1 with IN_USE_ADDRESSES exceeded. Limit: 8, even though the team believed they had only three running instances.

Diagnosis: gcloud compute addresses list showed eight IN_USE external addresses. Five belonged to instances that had been deleted weeks earlier — but their static IPs had been re-attached to a set of forgotten test forwarding rules, so they still counted as in use. The team had been looking at the STATIC_ADDRESSES reserved count (which was low) and couldn’t reconcile it.

Root cause: not a genuinely undersized quota — five of the eight in-use addresses were consumed by orphaned forwarding rules from deleted infrastructure, and the wrong quota metric had been inspected.

Fix: delete the orphaned forwarding rules (releasing their addresses), release the now-unattached static IPs, and the MIG scaled immediately. A modest quota increase was then requested to give real headroom.

Prevention Best Practices

• Give backends private IPs and reach the internet via Cloud NAT; reserve external IPs only for resources that truly need to be publicly reachable.
• Periodically audit gcloud compute addresses list for RESERVED unattached addresses — they cost money and can pin quota.
• Tag/label external IPs with their owning service so orphans are obvious after teardown.
• Include address cleanup in Terraform destroy paths so deleting a stack releases its IPs.
• Request quota increases proactively per region when planning a fleet, and monitor IN_USE_ADDRESSES usage against the limit.
• Distinguish IN_USE_ADDRESSES (attached) from STATIC_ADDRESSES (reserved) when diagnosing — they are separate quotas.

Quick Command Reference

# Show address quotas and usage in a region
gcloud compute regions describe REGION \
  --format='table(quotas.metric, quotas.limit, quotas.usage)' | grep -i address

# List external addresses with status and users
gcloud compute addresses list --filter='addressType=EXTERNAL' \
  --format='table(name, region, address, status, users.scope())'

# Release an unattached static IP
gcloud compute addresses delete ADDRESS_NAME --region=REGION

# Request a quota increase
gcloud compute regions describe REGION   # note current limit, then request via Console/Quotas

Conclusion

Quota IN_USE_ADDRESSES exceeded is usually not a case of needing more quota — it is IP sprawl and orphaned addresses consuming the limit you already have. Because this metric counts attached external IPs (and is separate from the STATIC_ADDRESSES reserved quota), the first move is always to list addresses by status and reclaim the ones tied to deleted or forgotten resources. Give backends private IPs behind Cloud NAT, audit reserved addresses regularly, and only then request a per-region increase sized for real headroom.