The plan says 4 to add, 2 to change, 1 to destroy
An infrastructure change adds a subnet, retags some resources, and renames a database module from `db` to `postgres_primary` for clarity. The plan output ends with "Plan: 4 to add, 2 to change, 1 to destroy". The author says the destroy is an old security group and the change is safe to apply during business hours.
The fix that looks right
Applying the plan and relying on the fact that a fresh database will be created immediately after the destroy, so "there is only a brief gap". There is no gap to be brief about — the new instance is empty. The data is gone, the connection endpoint has changed, and the restore is now on the critical path with the whole company waiting. The variant that catches more experienced people: seeing the replacement, deciding to take a snapshot first, and then discovering during the restore that the snapshot schedule had been silently failing since a permissions change three weeks earlier.