So moving to/from Aurora/RDS/own EC2/on-prem should be a matter of networking and changing connection strings in the clients.
Your operational requirements and processes (backup/restore, failover, DR etc) will change, but that's because you're making a deliberate decision weighing up those costs vs benefits.
You can use DNS to mitigate the pain of changing those connection strings, decoupling client change management from backend change process, or if you had foresight, not having to change client connection strings at all.
Nope, nope, nope! When you change DNS entries, they will take effect at some point in the future when the cache expires and when your app decides to reconnect. (Possibly after a restart) At that point, why not be sure and change the config?
I mean, DNS change can work, but when you're doing that one-in-years change, why risk the extra failure modes.
So moving to/from Aurora/RDS/own EC2/on-prem should be a matter of networking and changing connection strings in the clients.
Your operational requirements and processes (backup/restore, failover, DR etc) will change, but that's because you're making a deliberate decision weighing up those costs vs benefits.