Floating IPs

The Network service (OpenStack Neutron) implements floating IPs as public addresses you attach to an instance on a private network when you need reachability from the internet or another external network. Neutron allocates them from a pool tied to a public or provider network; association uses one-to-one NAT so the guest keeps its fixed private address while the floating IP answers from outside.

You can move the same public address to a different instance after maintenance or failover without renaming DNS to a new private IP.

What floating IPs are for#

Private addresses are stable inside your project and work well for east-west traffic. When you run an API, bastion, or web front end that must be reached from outside the cloud, you allocate a floating IP and map it to the instance’s port. Inbound connections hit the public address; the platform translates to the instance’s fixed IP. Outbound flows from instances without floating IPs often use source NAT on a router; floating IPs carry inbound identity and optional symmetric return paths depending on topology.

Floating IPs also pair with reverse proxy instances: a single public address on the proxy can represent many private application backends.

Capabilities and constraints#

You get dynamic association and disassociation: return an address to the pool when you no longer need external access, or reattach it elsewhere. Quotas cap how many floating IPs a project may hold, because public IPv4 space is finite. Security groups and other firewall rules still filter traffic at the port; open only the ports your service requires.

The same conceptual model applies whether clients reach you over IPv4 or, where supported, IPv6: you still think in terms of a provider pool, association to a port, and filtered delivery to the instance.

How floating IPs fit the network model#

Projects see two broad network classes: private networks for instance-to-instance traffic inside the project, and public (or external) networks that reach outside. The external network exposes a pool of addresses; that pool feeds floating IP allocation.

Your instances keep fixed addresses on the private network for stable internal DNS and service discovery; the floating IP is an additional façade that can be remapped without renumbering the guest.

After allocation, you associate the address with an instance (through its port). Traffic to the floating IP is destination-NATted to the instance’s fixed address. When you disassociate, the address returns to the pool for reuse.

DNS and stable endpoints#

Floating IPs give you a stable address you can publish in DNS A or AAAA records while moving the backend instance behind maintenance. That indirection is simpler than updating records on every VM replacement, especially for bastions and small APIs. Pair DNS TTL choices with how fast failover must propagate when you reassociate an address.

Fixed vs. floating IPs#

Each instance on Quake AI receives at least one fixed IP: a private address assigned from the subnet where the instance's port lives. Fixed IPs are stable for the lifetime of the port, internal to your project, and reachable from outside the cloud only when you set up routing or NAT.

Floating IPs are public addresses drawn from an external pool and mapped to an instance's fixed IP through one-to-one NAT.

Most architectures use fixed IPs for internal communication and add floating IPs only where external reachability is required. That limits public exposure while keeping stable public endpoints where you need them.

When to use each#

• Fixed IPs only: Database servers, internal microservices, workers that pull jobs from a queue. These instances talk to other instances on the same network and never need to be reached from outside.
• Fixed + floating IP: Web servers, bastion hosts, public APIs, mail servers. The floating IP provides the public address; the fixed IP handles internal traffic.
• Reverse proxy + floating IP: When multiple instances serve the same endpoint. The floating IP points to the proxy instance, and application backends use only fixed IPs.

Cost, security, and operations#

Public addresses are a quota-backed resource: plan for limits and any billing implications in your organization. Exposing instances increases attack surface, so combine floating IPs with tight security groups, patching, and authenticated services. Track which address is attached to which workload so you do not strand unused allocations or conflict with DNS records.

Release addresses you no longer need so other projects can use scarce IPv4 space and so your inventory stays honest during audits.

Further reading#

On this platform:

• Allocate floating IP addresses: step-by-step setup via Console, CLI, and API
• How to point a domain at a Quake AI resource: map a hostname at your registrar to a floating IP
• Floating IPs console: console reference for floating IP management
• Floating IP CLI reference: all openstack floating ip commands
• Floating IP API reference: Neutron floating IP API endpoints
• Networks: how private and external networks work together

External resources:

• OpenStack Neutron floating IP documentation: upstream implementation details for floating IP and NAT behavior
• RFC 1918: Address Allocation for Private Internets: the standard that defines private IP address ranges