Floating / Reserved IP¶
Service ownership
Owner: network-platform (network-pm@clouddigit.ai) — Status: GA — Last audited: 2026-05-11
Persistent public IPs that you own at the project level — attach to a VM, detach when that VM goes away, attach to its replacement.
What it is¶
A floating IP is a public IP allocated to your project, not to a specific resource. You associate it with an ENI (on a VM), an LB, or a NAT gateway, and can move it between targets as part of operational workflows — failover, blue/green deploys, controlled cutovers.
Use cases¶
| Pattern | Why floating IP |
|---|---|
| Active/standby database with manual failover | Move the IP to the new primary, no DNS TTL wait |
| Blue/green VM cutover | Keep DNS pointing at the IP, switch which VM holds it |
| Out-of-cluster bastion | Stable public address even as you rebuild the bastion |
| BYO HA tooling | Keepalived / Pacemaker + IP-takeover script |
Allocation¶
```bash
Reserve a floating IP¶
cd network ip reserve --region bd-dha-1
Associate¶
cd network ip associate
Move to another VM¶
cd network ip associate
Pricing¶
Reserved IPv4 incurs the standard idle-IP charge whenever it is not associated with a running VM/LB. Once attached, free. IPv6 is free. See Pricing.
Limits¶
- Default 25 floating IPs per project; bumpable
Related¶
Operate this service¶
A floating IP is a public IPv4 that's decoupled from any single resource — you can move it between VMs, LBs, or NAT GWs instantly. The basis for blue/green deployments and zero-DNS-TTL failover.
Floating vs regular Public IP¶
| Property | Public IP | Floating IP |
|---|---|---|
| Tied to VM lifecycle | Yes (released on VM delete) | No (survives VM delete) |
| Can be detached + re-attached | Yes (slow, ~30s) | Yes (instant) |
| Idle billing | Yes | Yes (higher rate) |
| Suitable for DNS A record | Eventually | Yes (recommended) |
When to use a Floating IP¶
- Anything you'd put in a DNS A record
- Blue/green deployment targets (instant swap)
- Failover from primary to standby
- Migrating workloads between VMs without DNS TTL pain
IAM¶
| Role | Can do |
|---|---|
fip.viewer | List floating IPs |
fip.allocator | Allocate / release |
fip.operator | Move (associate / disassociate) |
fip.admin | Above + reverse DNS |
Tagging¶
Tag with the DNS hostname the IP backs. If hostname changes, retag. Makes audit (and DR drills) trivial.
bash cd network fip tag --fip 103.5.7.43 --set dns=mail.acme.com
Quota¶
Floating IPs draw from the same IPv4 pool as Public IPs — combined quota.
Related¶
Move pattern¶
Instant association swap:
```bash
Move FIP from blue to green¶
cd network fip associate --fip 103.5.7.43 --to vm-green-01
Existing connections to old target drop; new connections hit green¶
```
Disassociation is implicit — the old target loses the IP at the moment of new association.
Blue/green deploy¶
```bash
1. Provision green fleet (parallel to blue)¶
2. Smoke test against green's private IP¶
3. Swap FIP¶
cd network fip associate --fip 103.5.7.43 --to lb-green
4. Monitor; on success, decom blue. On failure, swap back:¶
cd network fip associate --fip 103.5.7.43 --to lb-blue ```
The swap is sub-second. DNS TTLs are irrelevant.
Connection draining considerations¶
- TCP connections to the old target are reset, not drained. For long-lived connections, drain at the app first:
- Send
Connection: closeheaders - Wait for active sessions to complete
- Then swap
For LB-fronted services, drain via LB target-group settings before FIP swap.
DNS records¶
A FIP's reverse DNS works the same as a public IP. Set it once, never change (FIPs are stable).
Reservation across regions¶
A FIP is region-bound (can't move BD-DHA-1 → BD-CTG-1). For cross-region failover, use DNS (Authoritative DNS health-checked record) — the FIP gives you in-region instant failover, DNS gives cross-region.
Related¶
Association change didn't take effect¶
Symptoms: After fip associate, traffic still hits old target.
- Client caching ARP — usually self-resolves in <60 s. Hard refresh: client-side connection close.
- Target's outbound traffic still uses the FIP as source — the FIP is associated to new target for inbound; old target may still source from FIP for return traffic on existing connections until they die.
Both resolve naturally; if persistent, ticket.
FIP shows associated but is unreachable¶
| Symptom | Likely cause |
|---|---|
cd network fip show says associated, but ping fails | Target's SG blocks ICMP — not a problem |
| Both ICMP and TCP fail | Target's network stack down |
| TCP fails only on some clients | BGP route propagation (BYOIP) |
cd network reachability test --from internet --to <fip> walks the path.
IpAlreadyAssociated¶
ERROR: IpAlreadyAssociated: fip 103.5.7.43 is associated with vm-blue-01
The previous association wasn't released. cd network fip disassociate --fip <fip> then re-associate. Common cause: scripts that don't wait for state convergence.
Cost surprise on idle FIPs¶
FIPs bill at a higher idle rate than Public IPs (deliberate — they're more flexible, more scarce). Quarterly audit:
bash cd network fip list --associated false
Release any genuine zombies.
Reverse DNS conflict after move¶
If you move a FIP between projects, the PTR stays — including the old hostname. Either update PTR or accept the stale value (it's not a security issue, just confusing).