An EC2 instance launched into an AWS VPC public subnet receives a public IPv4 address automatically. What happens to that address when the instance is stopped and started again, and how does allocating an Elastic IP change the picture?

## Two kinds of public IPv4 address A VPC instance can end up with a public IPv4 address in one of two ways, and interviews probe whether you know the difference because the failure modes are completely different. **Auto-assigned public IPv4.** Subnets carry a setting that decides whether instances launched into them get a public address by default, and the launch request can override it. When it applies, AWS lends the instance an address from a regional pool. It is bound to that instance for as long as it is *running*. There is no name for it in your account, you cannot choose it, and you cannot get the same one back. **Elastic IP.** This is an address you explicitly allocate to your AWS account. It exists independently of any instance, has an allocation ID, and stays yours until you release it. You associate it with an instance or, more precisely, with an elastic network interface — and you can disassociate and re-associate it elsewhere at will. ## The lifecycle rule that catches people The distinction only becomes visible across the instance lifecycle: - **Reboot** — the auto-assigned address is kept. A reboot does not release the instance's placement or its networking. - **Stop, then start** — the auto-assigned address is released back to the pool. The started instance gets a *different* public address. This is the one that breaks things. - **Terminate** — the address is gone either way. An Elastic IP is unaffected by all of these; it stays associated across a stop/start, and stays allocated to your account even after the instance is terminated (which is exactly when people forget it exists and keep paying for it). So the moment anyone outside your account has to know the address — a DNS `A` record, a partner's firewall allow-list, an on-premises IPsec peer, an SFTP counterparty — an auto-assigned address is the wrong tool. Either use an Elastic IP or, better, put the workload behind a load balancer or a DNS name so the address stops being part of your contract with the outside world. ## The address is not on the instance A detail that surprises people the first time they look: the operating system inside the instance has no idea about the public address. The interface is configured only with the VPC private address. The internet gateway performs the one-to-one translation on the way out and the way back, entirely outside the guest. That is why you cannot discover the public address by inspecting the instance's own interface configuration — you look it up through the instance metadata service, or through the EC2 API, or from outside. ## Where Elastic IPs are mandatory A **public NAT gateway** must have an Elastic IP; there is no auto-assigned option, precisely because the whole point of the NAT gateway is to be a stable, known source address for everything behind it. That stability is why partners are willing to allow-list it. You can also associate additional Elastic IPs with a public NAT gateway. That is not about vanity addresses — each address brings its own set of source ports, which is how you expand a NAT gateway's simultaneous-connection capacity toward a single busy destination. ## The cost change nobody noticed Until 2024, an Elastic IP was free while attached to a running instance and charged only when idle — the classic "don't hoard addresses" incentive. Since **1 February 2024** AWS charges an hourly rate for **every public IPv4 address in use**, including auto-assigned ones on running instances and the addresses on NAT gateways and load balancers. Individually the rate is small; across a fleet of hundreds of instances that each did not need a public address, it is a real line item, and it turned "does this thing need a public IP at all?" into a cost question as well as a security one. The standard responses are the ones you would want anyway: put instances in private subnets behind a load balancer, share one NAT gateway's address instead of giving every instance its own, and adopt IPv6 where the workload allows it, since IPv6 addresses are not charged this way. ## What to say in the interview Lead with the lifecycle rule — reboot keeps it, stop/start loses it — because that is the concrete, checkable fact. Then give the reason to care: anything external that depends on the address needs stability, which is what an Elastic IP buys. Finish with the modern framing: the best answer to "which address do I need?" is often "none, put it behind a load balancer or a NAT gateway", and that answer is now cheaper as well as safer.