Introduction

I recently rebuilt two Lightsail instances (dev and production) and had my first real encounter with Static IPs. They look like EC2's Elastic IPs, but the billing and behavior differ in subtle ways. Everything I learned boils down to five rules — and one framing that makes all five obvious: a static IP is not a property of the server; it's an asset of your account.

The mistake that started it — copying yesterday's choice

When creating the production instance, I traced the exact steps from the dev instance I'd built the day before — and ended up on the $7 plan, even though we had decided production would be $5. Copying yesterday's choice was the mistake.

Normally this would hurt: recreating an instance means a new public IP, which means re-registering the allowed source IP with our payment gateway. But because a static IP was attached, recovery took 10 minutes: delete → recreate on $5 → re-attach the same static IP. That incident became a live test of all five rules.

The five rules

1. A static IP is a new address you attach, not your current one frozen

Creating a static IP doesn't "pin" your current public IP. It allocates a new address, and the moment you attach it, the old dynamic public IP disappears. If the old IP is registered anywhere (DNS, external services), update it around the attach.

2. Deleting the instance does not delete the static IP

The static IP belongs to your account (per region), not to the instance. Delete the instance and the IP stays, detached, ready to re-attach to a new instance. That's exactly why my $7 → $5 rebuild took 10 minutes.

3. Free while attached, billed while detached

An attached static IP costs nothing. Leave it detached and hourly charges begin. Combined with rule 2, the trap is obvious: the IP that survives your deleted instance is the one that starts billing. Release it if you're done with it.

4. It cannot cross regions

A static IP only works within the region it was allocated in. You cannot move a Seoul IP to a Tokyo instance — a region migration always means a new IP.

5. Stopped instances bill at full price

Lightsail is a monthly bundle, so Stop does not stop the cost. The only way to stop billing is deletion. This is the biggest difference from EC2's stopped-instance pricing.

Where the console fought back

The re-attach dialog uses a Cloudscape custom dropdown — not a native <select>. Clicking an option can fail to update internal state, leaving the Attach button disabled. The reliable sequence: click the textbox → click the option → confirm the button actually enabled.

The firewall rule form is a React controlled input. Setting the value programmatically (e.g., via browser automation) shows "443" on screen while the state stays empty; typing on top appends to the phantom value and you get "443443" plus an "invalid port" error. I typed it by hand. Ten seconds.

Verification

Before and after the rebuild, check the server's own egress IP:

curl -s https://checkip.amazonaws.com

Same address after delete → recreate → re-attach, matching the value registered with the payment gateway. Zero re-registration work.

Incidentally, the dev server got a static IP too — so the payment gateway's source-IP registration could be done once. For production, attaching the static IP to the new instance before cutover collapsed "migration" and "IP pinning" into a single IP change.

Summary

  • Attaching a static IP swaps your address (the old public IP is gone)
  • It survives instance deletion — which makes rebuilds cheap
  • Free while attached, billed while detached and idle
  • Region-locked
  • Stop doesn't stop billing — only deletion does

Think "account asset," not "server property," and all five rules derive themselves. The $7 mistake was fixable in 10 minutes precisely because the IP had been secured as an asset first.