Skip to content

Delete Cluster/Instances - how to check for resources associated to these Cluster/Instances

0

Hi,

At the moment, we don't have an official documentation with regards to 'decommissioning' of an Aurora or RDS databases so I am trying to write some documentation of some sort.

Is there any way of finding out what other resources may be related to the Aurora or RDS database that we are trying to decommissioned besides the fact that whoever has created them or has been managing them should have known?

Currently, we do as below

  • shutdown the Aurora or RDS instance for 2 weeks and checks if any users complain about it otherwise proceed as below
  • delete the cluster/instance
  • delete manual snapshots
  • turns out secrets are in use too, so we delete these manually too or schedule its deletion
  • pipeline files, we moved them to an archive folder and do a push to the repo
  • If this is the last resource in the account, then disable and remove the account

I guess we need to check Cloudformation stacks/template as well and Cloudwatch Alarms and Lambda Functions? And maybe some more other things that we have not thought about? :(

There may or may not be a way of knowing what else to remove, I am posting here just in case someone thinks there is a way to do. Thanks in advance.

1 Answer
0

When decommissioning Aurora or RDS databases, it's important to identify all associated resources to ensure a complete cleanup. Here's a comprehensive approach to finding related resources:

Before deletion:

  1. Check for instances associated with your cluster by using the describe-db-clusters command to list all instances that need to be deleted first
  2. Verify if deletion protection is enabled on your cluster, as this needs to be disabled before deletion

Additional resources to check for and clean up:

  • Database snapshots and automated backups
  • Subnet groups, parameter groups, and security groups
  • AWS Backup plans associated with your database resources
  • RDS Proxies that might be connected to your databases
  • Service discovery instances if using service discovery
  • CloudWatch alarms and metrics related to the database
  • CloudFormation stacks that created or reference the database
  • AWS Secrets Manager secrets storing database credentials
  • Lambda functions that interact with the database
  • Any VPC endpoints configured for database access

Your current approach of stopping the database for a testing period before deletion is a good practice. Using AWS Cost Explorer with grouping by usage type can help identify any remaining resources that might be causing charges after you believe everything has been cleaned up.

If you're still unsure about associated resources after checking these items, AWS Billing Support can provide a detailed analysis to identify any hidden resources that might be causing ongoing charges.
Sources
Deleting an Amazon DocumentDB cluster - Amazon DocumentDB
How to stop Relational Database Service? | AWS re:Post
Trying to turn off on services in my account | AWS re:Post
Troubleshoot Amazon ECS cluster deletion issues | AWS re:Post
Deleting Aurora DB clusters and DB instances - Amazon Aurora

answered 3 months ago
EXPERT
reviewed 3 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.