Hi folks, I need some advice on whether it’s safe to remove an Aurora MySQL database that appears to be abandoned.
Background:
I’m managing a setup with:
- Multiple EC2 instances (development, staging, production)
- Applications running in Docker containers
- Automated deployment through Bitbucket
- Local MySQL containers (version 8.0.25) handling app data
- Configuration managed through Docker secrets
The Aurora situation:
- Found an Aurora MySQL instance (v5.7) that seems forgotten
- Storage shows around 1 GiB usage
- Looks like it was created during a failed database migration
What I’ve verified:
- CloudWatch metrics show zero connections for over a week
- No database operations or CPU usage
- All environment variables point to local Docker containers
- No Aurora connection strings in any secrets or config files
- CloudTrail logs show no database access
- Local container database is about 376 MB
- Aurora backup shows roughly 1 GiB
The problem: I can’t access the Aurora instance because I don’t know the master password. The previous team never documented it, and they’re no longer available. This makes me think it’s truly unused, but I’m worried about breaking something if I’m wrong.
Questions:
- Am I missing any way to check if Aurora is actually being used?
- Would changing the master password be risky if something IS using it?
- Since I have a snapshot, is deletion relatively safe?
- Does the size difference between local DB and Aurora backup make sense?
Thanks for any guidance you can provide!
Check your load balancer config and database connection pooling settings first - stuff that won’t show up in environment variables. Apps sometimes have fallback database connections hardcoded or hidden in config files you wouldn’t think to look at. The zero CloudWatch activity is good news, but I’ve seen apps configured to try Aurora connections as backup when local containers fail. Since your monitoring shows no activity, just stop the Aurora instance instead of deleting it right away. AWS lets you stop an Aurora cluster for up to seven days, so you can watch for any apps that start throwing errors. If nothing breaks during that week, you’re safe to delete it permanently. Snapshots are fine, but stopping first removes all the guesswork.
This happens all the time during team transitions and botched migrations. Since your monitoring shows zero activity for over a week, that Aurora instance is probably dead weight. But before you delete it, check your application logs for database connection errors or timeouts - sometimes apps fail silently when they can’t reach a secondary database. The size difference between your local DB and Aurora backup is totally normal. Aurora includes transaction logs, system metadata, and allocates storage differently. You’ve got a snapshot and all your environment variables point to local containers, so deletion should be safe. Just download the snapshot locally first since AWS snapshots can get accidentally deleted too. The fact that the previous team didn’t document the master password? That’s pretty strong evidence this was supposed to be temporary infrastructure that got forgotten.
Yes, it seems that this Aurora instance is indeed abandoned. The absence of documentation for the master password and the prior team’s unavailability suggest a migration that didn’t materialize. If you’re hesitant about the safety of deletion, consider changing the master password first; this approach is safer as any application relying on it would encounter authentication errors, allowing you to rollback easily if necessary. The size discrepancy between your local database and the Aurora backup is typical, as Aurora incorporates additional overhead for system tables and indexes not present in your local MySQL containers. Before proceeding with deletion, it’s wise to set up a CloudWatch alarm to monitor connection attempts over the next 24-48 hours. If there are still no signs of activity, the snapshot you have will provide a recovery option, though it seems unlikely you’ll need it.
if nobody’s connected for a week and the password’s lost, that instance is dead. just take a final snapshot and kill it - you’re paying for storage you don’t need. password reset sounds clever but why bother when your apps are already running in local containers?