IP rotation
new IP, same server.
Your public IPv4 is a resource you hold separately from the server. Swap it, move it to another machine, or keep several and choose which one goes out.
// teams shipping on Zenlayer
Detach
from the server
then
Replace
new address
then
Re-attach
same server
01
Rotate a server's public IP without rebuilding the server
Rotation is three steps against the elastic IP: detach it from the server, replace the address, attach it back. The machine never restarts. The elastic IP keeps its ID, its bandwidth, and its billing setting, so a rotation costs you one short window instead of a rebuild.
- Detach, replace, re-attach — three calls that go straight into a loop
- Random from the region's pool by default, or a specific target address on request
- Batch it — one replace request carries a list of elastic IPs
Each team gets a monthly IP-change quota. If your rotation schedule needs more than the default, ask us to raise it.
02
Move an elastic IP between servers, gateways, and load balancers
Because the address is a standalone resource, it isn't stuck where you first put it. Detach it from one server and attach it to another, to a NAT gateway, to a load balancer, or to a high-availability virtual IP — in the same region, without renumbering anything.
- Attach and detach over the API, in batches
- Stack several addresses on one server, then set which is the active egress source
- Detaching is idempotent — safe to retry from an automation loop
An address can also live in one region and egress through another, when the exit location matters more than where the IP is registered.
one address, your choice of target
Elastic IPv4
attach where you need it
A server's vNIC
NAT gateway
Load balancer
High-availability VIP
03
Who rotates IPs
Teams whose product depends on which address their traffic leaves from.
VPN operators
Retire an exit address that got blocked and put a fresh one on the same server. The rest of the fleet stays exactly as it is.
VPN infrastructure →Data collection at scale
Give each job its own egress address, then move or replace it between runs from your own scheduler.
Data collection →Multi-tenant platforms
Hand every tenant a dedicated public address, and move it to another server when you rebalance the fleet.
Global VPC →04
Automate IP rotation with the API, SDKs, or CLI
Do the first one by hand in the console, then move the loop into your scheduler: unassociate, replace, associate. The replace call takes a list of elastic IPs and returns the ones that failed, so an empty list means the whole batch landed. Drive it over the REST API, the Go and Node SDKs, or the CLI.
REST API
Go + Node SDKs
CLI
developer_console — bash
# Step 2 of 3 — unassociate first, associate again after
$ curl -X POST https://console.zenlayer.com/api/v2/zec \
-H "Content-Type: application/json" \
-H "X-ZC-Action: ReplaceEipAddress" \
-H "Authorization: <your signed credentials>" \
-d '{
"replaceIps": [
{
"eipId": "eip-xxxxxxxx",
"ownIp": "203.0.113.24"
}
]
}'
# → { "requestId": "…", "failedEipIds": [] }
IP rotation FAQ
How the swap works, how often you can do it, and what carries over.
How do I rotate a server's public IP?
Detach the elastic IP from the server, replace the address, then attach it back. The address can only be replaced while the elastic IP is unbound, so those three steps always go together. Do them in the console, or drive all three from the REST API, an SDK, or the CLI. By default you get a new address from the region's pool; choosing a specific target address is an account setting we enable on request.
How often can I rotate an IP?
Each team has a monthly quota on IP changes. If you need to rotate more often than the default allows, talk to us and we'll raise it for your account.
Can I rotate addresses inside my own IP range (BYOIP)?
No. Elastic IPs created from a CIDR block you brought or reserved can't be replaced, on any surface. Inside your own range you control addressing directly anyway. See the BYOIP page for announcing your prefixes under your ASN.
Does the server see its own public IP?
In the default NAT mode it sees the private address and traffic is translated. Passthrough mode puts the public IP straight on the vNIC so the server sees it, with no NAT in the path. Passthrough is enabled per account on request.
Can one server hold several public IPs and switch which one it goes out on?
Yes. Bind several elastic IPs to the same private IP, then call ConfigEipEgressIp to set which one is the active source address for outbound traffic. This works for IPs bound to a vNIC, not to a NAT gateway or load balancer.
Can I manage this in Terraform?
The elastic IP and its binding are both Terraform resources, zenlayercloud_zec_eip and zenlayercloud_zec_eip_association, so you can create addresses and point them at a vNIC, load balancer, or NAT gateway from your state file. Replacing an address is the exception: the public address is a read-only attribute, so the swap itself runs through the console, the API, an SDK, or the CLI.
What happens to the bandwidth setting when the address changes?
The elastic IP is the resource — its ID, its bandwidth, and its billing setting all survive the swap. The one thing you re-do is the attachment to the server, because the address can only be replaced while the IP is detached.
Is there a gap in connectivity while an IP rotates?
That address stops serving traffic between the detach and the re-attach, so schedule a rotation for a moment the fleet can absorb. If you need the cutover to be instant, keep a second elastic IP on the server and switch the active egress instead — that takes effect without detaching anything.