EC2 Public IP Changed After Restart? Why Stop/Start Changes It, Elastic IP Setup, Is It Free, Pricing, and Adding or Removing a Public IP

An EC2 instance's auto-assigned public IPv4 address changes when you stop and start it (or hibernate it), because AWS releases the address back to its pool on stop and gives you a new one on start; a plain reboot keeps it. The private IP and any IPv6 addresses stay the same. To keep a fixed public address, allocate an Elastic IP (a static IPv4 address that belongs to your account) and associate it with the instance; it survives stops and starts until you release it. Elastic IPs are not free: since February 2024, AWS charges $0.005 per hour (about $3.65 a month) for every public IPv4 address, attached or idle, including auto-assigned ones. The old public IP cannot be recovered once released. Below: exactly when the IP changes, how to allocate and attach an Elastic IP (console, CLI, Terraform), how to add or remove a public IP on an existing instance, why a public IP may not be reachable, the limit of 5 Elastic IPs per Region, and options that avoid fixed IPs altogether.

The shop's small website ran on one EC2 instance for years without trouble. One Saturday Ethan stopped it to switch to a larger instance type, started it again five minutes later, and the website was gone. The server was fine. The DNS record still pointed at the old public IP, and the instance had a new one. Then, when he moved the DNS to the new address, his SSH client refused to connect at all, with a warning that something had changed. Two surprises, one cause: a public IP that was never meant to be permanent.

New to EC2 networking? The cards below cover connection errors, Elastic IP costs, static IPs for load balancers and connecting without a public IP.

The three kinds of IP address on an EC2 instance

Your instance does not actually "see" its public IPv4 address: inside the operating system, ip addr or ipconfig shows only the private address. AWS translates between the public and private addresses at the edge of the VPC. To see the public one from inside, ask the metadata service, or run curl https://checkip.amazonaws.com.

Jake: "So the public IP was borrowed, not ours?"

Ethan: "Borrowed for as long as the instance was running. Stop it, and the address goes back on the shelf for someone else."

Exactly when an EC2 public IP changes

Stops you did not start yourself count too: if AWS schedules maintenance that requires a stop and start, the instance comes back with a new auto-assigned address.

Two subtler cases: if the instance has a second network interface attached, or a secondary private IP with an Elastic IP, AWS does not assign a new auto-assigned public IP after a release. And once a public IP is released, it goes back into Amazon's pool: there is no way to get that exact address back.

The public DNS name (ec2-54-210-12-34.compute-1.amazonaws.com) is built from the public IP, so it changes too. Anything pointing at either one, a DNS record, a firewall allow-list, a client's configuration, an SSH shortcut, breaks after a stop/start.

Keep a fixed public IP: allocate and associate an Elastic IP

In the console:

1. Open the EC2 console in the instance's Region and choose Elastic IPs under Network & Security.
2. Choose Allocate Elastic IP address, keep "Amazon's pool of IPv4 addresses", and choose Allocate.
3. Select the new address, choose Actions, Associate Elastic IP address.
4. Choose Instance, pick your instance (and its private IP if it has several), and choose Associate.
5. Give the address a Name tag, such as "shop-web", so nobody releases it by mistake.
6. Update your DNS record to the Elastic IP once, and it stays valid through every future stop and start.

With the CLI:

# Allocate (returns an AllocationId such as eipalloc-0abc...)
aws ec2 allocate-address --domain vpc \
  --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=Name,Value=shop-web}]'

# Associate with the instance
aws ec2 associate-address --instance-id i-0123456789abcdef0 \
  --allocation-id eipalloc-0abc1234def567890

# List your Elastic IPs and what they are attached to
aws ec2 describe-addresses \
  --query "Addresses[].[PublicIp,InstanceId,AllocationId]" --output table

Terraform:

resource "aws_eip" "web" {
  domain = "vpc"
  tags   = { Name = "shop-web" }
}

resource "aws_eip_association" "web" {
  instance_id   = aws_instance.web.id
  allocation_id = aws_eip.web.id
}

Keeping the association as a separate resource means you can replace the instance without losing the address: Terraform re-associates the same Elastic IP with the new instance.

An Elastic IP can be moved between instances in seconds (associate it with the new one; it detaches from the old). That makes it a simple failover tool for a single-server setup: build a replacement, move the address, done. The one side effect: SSH clients remember the old server's host key for that address and will refuse the new server until you remove the old entry, which is exactly the warning Ethan saw. Our "Host key verification failed" guide covers the fix.

Is an Elastic IP free? Public IPv4 pricing

No. Since February 1, 2024, AWS charges for every public IPv4 address, whether it is an Elastic IP or an auto-assigned one, attached to a running instance or sitting idle:

• $0.005 per IP per hour, which is about $3.65 per month (730 hours) for each address.
• The same rate applies to in-use and idle addresses. Before 2024, an attached Elastic IP was free and only idle ones cost money; that is why older articles say "Elastic IPs are free while attached". They no longer are.
• Switching from an auto-assigned IP to an Elastic IP does not add cost: it replaces one public IPv4 with another, so you still pay for one.
• Load balancers, NAT gateways and other services with public IPv4 addresses are charged per address too.

For one small server, $3.65 a month is the price of a permanent address. Across an account with dozens of forgotten addresses it adds up; our guide to idle Elastic IPs and load balancers shows how to find and clear them. In the Billing console, these charges appear under Amazon VPC as public IPv4 address usage, and VPC IP Address Manager's Public IP Insights lists every public IPv4 address in your account.

Jake: "So the fixed address costs about the same as a coffee a month?"

Ethan: "And the borrowed one costs the same. You were already paying; now you get to keep it."

Add or remove a public IP on an existing instance

Adding a public IP to an instance that has none (launched in a private subnet, or with auto-assign turned off):

• The simple way: associate an Elastic IP, as above. The instance must be in a subnet whose route table sends 0.0.0.0/0 to an internet gateway, or the address will exist but nothing will reach it.
• An auto-assigned address: the instance's network interface has an Auto-assign public IP setting you can change after launch: EC2 console, Network interfaces, select the instance's primary interface, Actions, Manage IP addresses, and turn auto-assign on. Changing the subnet's setting only affects instances launched afterwards.

Removing a public IP (for example to move a server behind a load balancer and stop paying for its address):

• Elastic IP: disassociate it (aws ec2 disassociate-address --association-id eipassoc-...), then release it if you no longer need it (aws ec2 release-address --allocation-id eipalloc-...). An allocated but unattached Elastic IP still costs the same per hour.
• Auto-assigned: turn off Auto-assign public IP on the network interface in the same Manage IP addresses dialog.

Before you remove a public IP, make sure you have another way in: EC2 Instance Connect Endpoint and Session Manager both reach instances with no public address. Our EC2 Instance Connect guide covers the endpoint option.

Planning a stop and start without losing the address

Most IP surprises come from a planned change: resizing the instance type, which requires a stop, or a maintenance event that forces one. A few minutes of preparation keeps the address:

1. Check what the instance has now. In the console's Networking tab, an Elastic IP appears as such; if the public address is listed only as "Public IPv4 address" with no Elastic IP, it will change.
2. Allocate and associate an Elastic IP before stopping, if you want to keep a fixed address from now on. Association replaces the auto-assigned address at once, so update DNS to the Elastic IP immediately, while the server is still running.
3. Lower the DNS record's TTL a day ahead if you cannot use an Elastic IP, so the change you make afterwards spreads quickly.
4. Stop, change, start, then confirm the address with describe-instances and test the site and SSH before calling the job done.

The old auto-assigned address cannot be reserved or recovered; once released at stop, it goes back to the pool and may be given to another customer. That is the one step with no undo, which is why the Elastic IP comes first.

Changing the private IP, subnet or VPC of an instance

Public addresses come and go; the private side is the opposite, and that surprises people the other way. An instance's primary private IPv4 address belongs to its primary network interface for the life of the instance: it survives stops and starts, and it cannot be changed. What you can do instead:

• Add secondary private addresses to the network interface (aws ec2 assign-private-ip-addresses --network-interface-id eni-... --private-ip-addresses 10.0.1.50), then configure the operating system to use them. Useful when software must listen on a specific address.
• Attach a second network interface with the address you need. A secondary interface can be moved between instances in the same Availability Zone, taking its private address with it, which is a classic way to give a service a "floating" private IP.
• Launch a replacement with the address you want: create an AMI of the instance, then launch from it with --private-ip-address 10.0.1.25 in the target subnet, if that address is free.

The same replacement route is the only way to move an instance to another subnet or VPC. A network interface lives in one subnet, so there is no "change subnet" button. Create an AMI (with the instance stopped, for a consistent copy of its disks), launch a new instance from it in the target subnet with the same instance type, security groups and IAM role, move the Elastic IP across if there is one, check that everything works, and then terminate the old instance. Moving to a subnet in a different Availability Zone works the same way, because the AMI's snapshots can be used anywhere in the Region.

Jake: "So the private address is glued on, but the Elastic IP can hop between machines?"

Ethan: "Exactly. That's why the DNS points at the Elastic IP: we can swap the server underneath and nobody notices."

IPv6 on EC2: an address that does not change, with no hourly charge

An instance's IPv6 address behaves the way many people expect the IPv4 one to: it stays the same across stops and starts, and it is released only when the instance is terminated or you remove it. And unlike public IPv4, IPv6 addresses carry no hourly charge. Turning it on takes five steps:

1. Add an IPv6 block to the VPC: VPC console, select the VPC, Edit CIDRs, add an Amazon-provided IPv6 CIDR block.
2. Give the subnet a slice of it: edit the subnet's IPv6 CIDRs and add a /64.
3. Route it: in the subnet's route table, add ::/0 pointing at the internet gateway.
4. Allow it: add security group rules with source ::/0 (or a narrower IPv6 range) for the ports you need. IPv4 rules do not cover IPv6 traffic.
5. Assign an address to the instance: aws ec2 assign-ipv6-addresses --network-interface-id eni-... --ipv6-address-count 1, or turn on IPv6 auto-assign for new instances in the subnet.

The catch is reach: visitors whose networks have no IPv6 cannot connect to an IPv6-only address. For a public website that means keeping IPv4 as well (dual-stack), or putting an IPv4-capable load balancer or CloudFront in front. For servers reached only by your own team, from networks that support IPv6, an IPv6-only setup removes the public IPv4 charge entirely, and AWS supports IPv6-only subnets for exactly that purpose.

Public IP not reachable: the checklist

An instance with a public IP that does not answer is a different problem from an IP that changed. Check, in order:

1. You are using the current IP. After any stop/start, look it up again in the console or with aws ec2 describe-instances --instance-ids i-0123456789abcdef0 --query "Reservations[].Instances[].PublicIpAddress".
2. The subnet is public. Its route table must have 0.0.0.0/0 pointing at an internet gateway (igw-...). A route to a NAT gateway makes it a private subnet: outbound works, inbound does not.
3. The security group allows the port from your address: 22 for SSH, 3389 for RDP, 80/443 for a website, with a source that includes your current public IP.
4. The network ACL allows the port inbound and the ephemeral ports (1024 to 65535) outbound for the replies.
5. The OS firewall and the service. Windows Firewall, ufw or firewalld can block the port; the service must listen on all addresses (0.0.0.0), not only 127.0.0.1.
6. The instance passed its status checks. A failed system or instance status check means the problem is inside or under the instance, not the network.

Our guide to connection timed out, refused and denied goes through what each error message points to, and our guide to pinging an EC2 instance explains why ping failing does not mean the server is down.

Fixing DNS after the IP changed

If the IP has already changed and your domain points at the old one:

• Update the A record to the new address (or, better, to an Elastic IP so you never repeat this). In Route 53, edit the record in the hosted zone; at another registrar, edit it in their DNS panel.
• Expect a delay while caches expire. The record's TTL decides how long resolvers keep the old answer; propagation can take up to a day for long TTLs. Lowering the TTL before a planned change makes the switch faster.
• Use an alias or a name instead of an address where you can: behind a load balancer, point the domain at the load balancer's DNS name (a Route 53 alias record), which never changes when servers do.

Dynamic DNS scripts that update a record when an instance starts work, but they are slower and more fragile than an Elastic IP, because of that propagation delay.

Updating DNS automatically when the IP changes

If an Elastic IP is not an option, for example because the instance is short-lived or you want to avoid the extra address while it is stopped, the DNS update can at least be automatic. EC2 sends an event to EventBridge every time an instance changes state; a rule for the running state can trigger a small Lambda function that writes the new address into Route 53:

import boto3

ec2 = boto3.client("ec2")
r53 = boto3.client("route53")
ZONE_ID, NAME = "Z0123456789ABCDEFGHIJ", "shop.example.com."

def handler(event, context):
    instance_id = event["detail"]["instance-id"]
    desc = ec2.describe_instances(InstanceIds=[instance_id])
    for reservation in desc["Reservations"]:
        for inst in reservation["Instances"]:
            ip = inst.get("PublicIpAddress")
            if ip:
                r53.change_resource_record_sets(HostedZoneId=ZONE_ID, ChangeBatch={"Changes": [{
                    "Action": "UPSERT",
                    "ResourceRecordSet": {"Name": NAME, "Type": "A", "TTL": 60,
                                          "ResourceRecords": [{"Value": ip}]}}]})

The EventBridge rule matches the source aws.ec2, detail type EC2 Instance State-change Notification, state running and the instance ID you care about. The function's role needs ec2:DescribeInstances and route53:ChangeResourceRecordSets on the hosted zone. Keep the record's TTL short, as in the example, so resolvers pick up the new address within a minute or two rather than hours. It works well for development servers that are stopped every night; for anything customers rely on, the Elastic IP remains simpler.

The SSH warning after an address moves

Ethan's second surprise is common enough to deserve its own section. SSH remembers each server's host key by the address it connected to. When an address is reused by a different server, for example an Elastic IP moved to a new instance, or a recycled public IP that now belongs to a new machine, SSH sees a different key for a known address and refuses with "REMOTE HOST IDENTIFICATION HAS CHANGED".

When you know why the key changed, remove the old entry and connect again: ssh-keygen -R 3.208.45.67 (or the hostname you use), then accept the new key. To be sure you are talking to your own instance and not something in the middle, compare the fingerprint SSH shows with the one the instance prints to its console at first boot, which aws ec2 get-console-output --instance-id i-0123456789abcdef0 retrieves. Our host key verification guide covers the details, including the Windows OpenSSH paths.

Fixed address options, compared

Read the table from the bottom up when designing something new: the fewer public addresses a design needs, the fewer of this page's problems it can have. Read it from the top down when fixing an existing server in a hurry: an Elastic IP is the one-step answer that works today.

Lightsail, Elastic Beanstalk and other services

Some AWS services handle addresses for you, and their rules differ slightly from plain EC2:

• Lightsail instances also get a new public address on stop and start unless you attach a Lightsail static IP, Lightsail's version of an Elastic IP. Static IPs are free while attached to an instance, and charged when left unattached.
• Elastic Beanstalk single-instance environments attach an Elastic IP automatically, so the address survives instance replacement; load-balanced environments use the load balancer's DNS name instead.
• NAT gateways and Network Load Balancers use Elastic IPs you choose or AWS assigns, and those count toward the same per-Region quota and the same hourly charge.

If a server that "never changed address" suddenly did, check which of these created it: an address that a service managed for you may have been released when the service replaced or rebuilt the instance.

A public address is also a target

Every public IPv4 address on the internet is scanned constantly, usually within minutes of appearing. That is not a reason to panic, but it shapes a few habits:

• Open only the ports the job needs, to the narrowest sources: 443 to everyone for a website, but SSH and RDP only from your office address, or not at all if you use Session Manager.
• Expect noise in the logs. Failed SSH logins from strangers are normal on any public address; keep password logins off and use keys.
• Remember allow-lists elsewhere. If partners allow your server's address in their firewalls, a changed address breaks the integration, and a released Elastic IP that is later given to someone else could, in theory, be allowed into their systems. Tell partners when you retire an address.

AWS Shield Standard protects every public address from common network-level attacks at no extra cost; for anything more targeted, a load balancer or CloudFront in front of the server, with AWS WAF, is the usual next step.

Finding the public IP from inside the instance

Scripts on the instance often need to know its own public address, for example to register with a monitoring service. The instance metadata service answers, without any AWS credentials. With IMDSv2, which new instances require by default, you fetch a short-lived token first:

# Linux
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4

# Windows PowerShell
$token = Invoke-RestMethod -Method Put -Uri http://169.254.169.254/latest/api/token `
  -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "300"}
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} `
  -Uri http://169.254.169.254/latest/meta-data/public-ipv4

An Elastic IP shows up there too, since it is the instance's public address while associated. If the request returns a 404, the instance has no public IPv4 address at all. Running ip addr or ipconfig on the instance shows only the private address, because the public one is translated at the internet gateway and never configured on the instance itself, which confuses many people the first time they look.

Windows instances: reconnecting with RDP after the IP changed

On Windows servers, the change shows up as a Remote Desktop file that suddenly cannot connect. The saved .rdp file contains the old address; download a fresh one from the instance's Connect page in the console, or edit the address in the Remote Desktop client. The administrator password is unaffected by a stop and start, so the password you decrypted at launch still works.

If the new address still fails, check the security group's inbound rule for port 3389: rules that allow only "My IP" were written for the address your computer had when you created them, and home connections change too. Better still for Windows administration is Session Manager's port forwarding, which carries RDP through the AWS API with no inbound port open at all: aws ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389", then point Remote Desktop at localhost:13389.

Elastic IP limit: 5 per Region

Each account starts with a quota of 5 Elastic IP addresses per Region. Allocating a sixth fails with an "AddressLimitExceeded" error. To get more, request an increase in Service Quotas under Amazon EC2, "EC2-VPC Elastic IPs", explaining the use case. Before you ask, look for unattached addresses you can release; they are often the reason the quota ran out.

# Elastic IPs that are allocated but not attached to anything (still billed)
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].[PublicIp,AllocationId]" --output table

# Your current quota for Elastic IPs in this Region
aws service-quotas get-service-quota --service-code ec2 --quota-code L-0263D0A3 \
  --query "Quota.Value"

The quota counts addresses allocated to your account, attached or not, in each Region separately, so an address you forgot in another Region does not block you here, but it does still appear on your bill.

For organizations needing many addresses, VPC IP Address Manager can allocate Elastic IPs from a contiguous block of Amazon-provided addresses, and you can also bring your own address range (BYOIP).

Elastic IP extras: reverse DNS, email and moving between accounts

A few Elastic IP features matter for specific jobs:

• Reverse DNS for a mail server. Receiving mail servers often check that an IP's reverse (PTR) record matches the sending host. For an Elastic IP you can set it yourself once the forward A record exists: aws ec2 modify-address-attribute --allocation-id eipalloc-... --domain-name mail.example.com.
• Sending email from EC2. Outbound traffic on port 25 is throttled by default on EC2. To run a mail server, request removal of that limit for the account, or send through Amazon SES, which avoids the reputation problems of a single server's address.
• Moving an address to another account. Elastic IP transfer lets one account offer an address and another accept it, keeping the same IP, which helps when reorganizing accounts without changing allow-lists that partners maintain. The source runs enable-address-transfer with the target account ID, and the target runs accept-address-transfer.
• Tags. Name every Elastic IP with what it is for. An untagged address found in a cost review a year later is the hardest kind to decide about.

Running servers with no public IP at all

The cheapest public address is the one you never use. For servers that only your team needs to reach, two options remove public IPs entirely:

• EC2 Instance Connect Endpoint. Create one endpoint in the VPC (aws ec2 create-instance-connect-endpoint --subnet-id subnet-...), allow SSH from the endpoint's security group to the instances, then connect with aws ec2-instance-connect ssh --instance-id i-0123456789abcdef0 --connection-type eice. The endpoint itself has no extra charge.
• Session Manager. With the SSM agent (included in Amazon-provided AMIs), an instance role allowing Systems Manager, and a route to the Systems Manager endpoints (a NAT gateway or VPC endpoints), you get a shell or a port-forwarding session with no inbound ports open and every session logged.

Either one means the server needs no public address for administration. Combined with a load balancer or CloudFront for the public traffic, a typical web server ends up with no public IPv4 of its own, which removes both the hourly charge and the stop/start problem this page started with.

Finding public IPv4 charges on your bill

Because every public IPv4 address now costs money, it is worth knowing exactly where they appear. In Cost Explorer, filter the service to Amazon VPC and group by usage type; public addresses show up as two kinds of usage, one for addresses in use and one for idle addresses (allocated Elastic IPs attached to nothing). Idle ones are the easiest saving: release them, or attach them to something that needs them.

To see which resources hold the in-use addresses, VPC IP Address Manager's Public IP Insights, available in its free tier, breaks them down by type: EC2 instances, Elastic IPs, load balancers, NAT gateways and others. From the CLI, aws ec2 describe-network-interfaces --query "NetworkInterfaces[?Association.PublicIp].[Association.PublicIp,Description,InterfaceType]" --output table lists every network interface with a public address, including the ones owned by AWS services in your VPC.

For the shop the list was short: the web server's Elastic IP, a NAT gateway, and an Elastic IP left over from a test server deleted months earlier. Releasing that last one paid for the web server's address for the following year.

Auto Scaling, Spot and replaced instances

Everything above assumes a server that lives for years. In an Auto Scaling group, or with Spot Instances, instances are replaced routinely, and every replacement gets a new auto-assigned public address. Pinning addresses there means extra machinery: a script in the launch template's user data, or a lifecycle hook, that associates an Elastic IP from a pool when an instance starts. It works, but it is fiddly, and the Elastic IP quota limits how far it scales.

The usual design avoids the problem instead. Put the group behind a load balancer, so clients use the load balancer's DNS name and never see an instance address; give outbound traffic a fixed address through a NAT gateway; and reach individual instances for administration through Session Manager. Then replacing an instance changes nothing anyone outside can see.

Options that remove the need for a fixed IP

• A load balancer in front of your instances gives you one stable DNS name; instances behind it can change, scale and be replaced. Application Load Balancers have no fixed IP; Network Load Balancers can have an Elastic IP per Availability Zone when clients insist on an address. Our ALB vs NLB guide covers that choice.
• A NAT gateway gives every instance in private subnets one fixed outbound address (the NAT gateway's Elastic IP), the usual answer when a partner needs to allow-list your traffic. Our NAT gateway guide explains the setup.
• EC2 Instance Connect Endpoint or Session Manager for administration, so servers need no public address at all.
• CloudFront in front of a website, which serves visitors from its own addresses and reaches your server as an origin.

For the shop's single web server, an Elastic IP was the right answer: one address, one DNS record, set once. For anything bigger, a load balancer would be.

What the shop changed, in the end

The Saturday outage turned into a short list of changes that took less than an hour:

• An Elastic IP, tagged "shop website", associated with the web server, and the DNS A record pointed at it with a one-hour TTL.
• Reverse DNS set on the address, since the server also sends order confirmation emails.
• SSH closed to the internet, and administration moved to Session Manager, so the security group allows only ports 80 and 443.
• The stale known_hosts entry removed on Ethan's laptop, after matching the fingerprint against the console output.
• One forgotten Elastic IP from an old test server released, which covered the new one's cost.

None of it needed new skills, only knowing which address type the server had and what happens to each on a stop. The next instance resize, three months later, was a non-event: stop, change type, start, and the website came back on the same address before anyone noticed it had gone.

Jake: "So we pay the same three-sixty-five a month, and the address doesn't move any more?"

Ethan: "Same price as before, now with a lease instead of a loan."

Frequently asked questions

The shop's website now has an Elastic IP named "shop-web", one DNS record pointing at it, and a TTL of five minutes for the next time anything changes. Ethan has stopped and started the instance twice since, once for patches and once for a bigger instance type, and the site came back on the same address both times. Jake's note for the team: "Reboot keeps the IP. Stop/start does not. Elastic IP keeps it always, for $3.65."

Revision note. Written October 19, 2026. A public IP on EC2 is lent, not owned, until you make it an Elastic IP.