You stop an EC2 instance and start it again a few minutes later. What changes about how clients reach it, and what stays the same?
answer
- it starts on a different host
- borrowed address goes back
- the network interface stays with the instance
- reboot is not the same operation
- Elastic IP is yours, not the host's
basics
~20 sA stop/start moves the instance onto different host hardware. The auto-assigned public IPv4 address and public DNS name are released and replaced; the instance ID, private IPv4 address and EBS root volume survive. An Elastic IP stays associated.
solid answer
~50 sStopping detaches the instance from the physical host it was running on, and starting it again places it on a different host in the same Availability Zone. Because of that, anything the host lent it goes back: the auto-assigned public IPv4 address and the matching public DNS name are released, and a new pair is handed out on start. Anything belonging to the instance or its network interface survives — the instance ID, the private IPv4 address inside the VPC, the MAC, the security groups, the IAM instance profile, and the EBS root volume with everything written to it. Data on instance-store volumes does not survive, because those disks belong to the old host. If clients need a stable address, associate an Elastic IP, which stays attached across stop/start, or put a DNS name or load balancer in front of the instance.
go deeper
Be ready to say plainly that the auto-assigned public IPv4 address changes across a stop and start while the private address and instance ID do not, and that an Elastic IP is how you keep a fixed address.
Explain the mechanism: a stopped instance is released from its host and starts on new hardware in the same Availability Zone, so anything the host lent it — the public address and instance-store disks — does not come back.
Show how you keep dependents from breaking: an Elastic IP or a DNS/load-balancer indirection, an audit that nothing hard-codes instance addresses, and confirmation that instance-store data is either disposable or already flushed to durable storage.
Own the position that an instance address is never an identity in your architecture. Push naming and service discovery as the contract so any instance can be replaced, resized or migrated without a coordination event with another team.
## What "stopped" actually means An EC2 instance is a virtual machine running on a physical host inside one Availability Zone. `StopInstances` shuts the guest operating system down and then releases the instance from that host: the state goes `running` → `stopping` → `stopped`. While it is stopped nothing of yours is executing anywhere. You still own the instance object, its identifier, its elastic network interface (ENI) and its EBS volumes, but no CPU or RAM anywhere is reserved for it. `StartInstances` then schedules it onto whatever suitable host has capacity, which is almost never the host it left. That single fact — *new host* — explains every difference candidates trip over. ## Addressing: what the host lent you goes back An auto-assigned public IPv4 address is not an asset in your account. It comes from an Amazon-owned pool and is bound to the instance only while it is running. On stop it is released; on start a fresh one is assigned, as long as the auto-assign public IPv4 setting still applies to the instance's subnet. The public DNS name is derived from that address, so it changes with it. The private IPv4 address behaves differently, because it belongs to the ENI rather than to the host. The ENI stays attached across the stop, so the private address, the MAC address, the security-group membership and any secondary or IPv6 addresses on that interface are all unchanged when the instance comes back. An **Elastic IP** is an address allocated to *your account* rather than lent by a host. Its association with the instance survives a stop/start, which is exactly why it exists. Note that an Elastic IP associated with a stopped instance still bills — a stopped instance is not a free instance. ## What survives and what does not Survives a stop/start: - the instance ID and all tags - EBS volumes and every byte on them, including the root volume - the ENI: private IPv4, MAC, security groups, IPv6 - the attached IAM instance profile and the user data blob - an associated Elastic IP Does not survive: - RAM contents and every running process (unless you hibernated rather than stopped) - data on instance-store (ephemeral) volumes, which are physical disks on the old host - the auto-assigned public IPv4 address and the public DNS name derived from it - placement on that specific host, and therefore anything that depended on it ## Reboot is not a stop/start This is the discriminator interviewers reach for. `RebootInstances` is equivalent to an operating-system reboot: the instance stays on the same host, keeps its public IPv4 address, keeps instance-store data, and billing is never interrupted. A stop/start is a host migration wearing the same clothes. If someone tells you "we rebooted it and the IP changed", they stopped and started it. ```bash # same host, address unchanged aws ec2 reboot-instances --instance-ids i-0123456789abcdef0 # releases the host; the instance comes back somewhere else aws ec2 stop-instances --instance-ids i-0123456789abcdef0 aws ec2 start-instances --instance-ids i-0123456789abcdef0 ``` ## Why anyone stops an instance on purpose A stopped instance costs no instance-hours; you keep paying for its EBS storage and any Elastic IP. Stopping is also the only way to change some instance attributes — the instance type, for example, can only be modified while the instance is stopped. Development environments that run office hours, or a machine you want to resize, are the usual reasons. ## Designing so that none of this matters The production lesson is that an instance's address is not an identity. Anything that hard-codes an instance's public address — a firewall allow-list on a partner's side, a monitoring config, a colleague's SSH config — breaks silently the first time the instance is stopped for a resize. The durable answers are the ones the platform gives you: an Elastic IP when a single fixed address really is required, a DNS record you update, or a load balancer that hides instance addresses entirely. Likewise, treat instance-store volumes as scratch: anything you need after the next stop must already be on EBS, in S3, or in a database.
- Does the private IPv4 address change too, and why or why not?No. The private IPv4 lives on the elastic network interface, and the ENI stays attached to the instance across a stop/start. Its MAC address, security groups and any secondary or IPv6 addresses come back unchanged. Only the auto-assigned public IPv4 — which is lent from an Amazon pool while the instance runs — is released and replaced.
- How does a reboot differ from a stop followed by a start?A reboot is an operating-system restart on the same physical host: the public IPv4 address is unchanged, instance-store data is intact, and billing never pauses. A stop releases the instance from its host and a start schedules it onto a different one, which is why the auto-assigned address and instance-store data are lost.
- Why can't you resize an instance while it is running?The instance type determines the CPU, memory and often the host family it is placed on, so changing it means placing the instance on different hardware. AWS requires the instance to be stopped before you modify the instance type; you then start it again, at which point it lands on a host of the new type — and gets a new auto-assigned public IPv4 address in the process.
saying these in an interview costs you the question
- Says the public IP is retained across a stop and start
- Claims the private IP changes along with the public one
- Treats a reboot and a stop/start as the same operation
- Assumes instance-store data survives a stop
- Thinks the instance ID is regenerated on start