Prepare EC2 stop-start changes around ephemeral storage and public addresses

A stopped instance persists, but every runtime dependency may not survive the restart.

Source facts

AWS supports stop/start for EBS-root instances. Starting typically moves the instance to another host and assigns a new public IPv4 address. Stopping erases data on instance-store volumes. AWS recommends copying required instance-store data to persistent storage before the stop and warns that bypassing graceful shutdown risks data integrity.

Source: AWS Documentation.

Applicability

This applies to an EC2 stop/start maintenance operation, not hibernation or termination.

DSE recommendation

DSE recommends identifying instance-store use, address dependencies and application shutdown requirements before scheduling maintenance. Review DNS, allowlists and remote-management access that may depend on the current public address. Preserve required runtime data and confirm the restart procedure with the application owner. Assign someone to validate service recovery, and keep a route to the instance that does not assume the old address remains valid. Record the approved maintenance window and rollback options before stopping the workload. Require the maintenance owner to list the service checks needed after startup, including external callers and stored data. Capture a harmless before-and-after inventory in rehearsal, and make unresolved address or storage dependencies a reason to revise the maintenance plan.

Verification

Proposed verification: rehearse on a representative test instance, compare storage and network identities before and after, and validate the application’s start sequence. Confirm persistent data remains accessible and intentionally ephemeral data is handled correctly before approving the same operation in production.

Official reference

AWS Documentation. Reviewed October 20, 2026.