<p>Yes you can change the name of the RDS instance, but it is highly discouraged to do so in LIVE Production environment. It would change the EndPoint which might impact other resources actively accessing the RDS server (like an application server).</p>

<p>This would probably require a property / env-variable change in your code or configs (which would ideally end up for a release of config through config management)</p>

<p>To avoid disruption (In future) and rollout changes with lesser RTO , you can create an intermediate DNS entry (CNAME) in Route53 for your RDS server and use the intermediate URL in your application. When the RDS server name changes you could just change the DNS CNAME of the new RDS Endpoint. <strong>NOTE:</strong> During the name change your RDS server would be unavailable (with old name) for few minutes and this might cause disruption</p>

<p>That being said, you are already biased on a solution (change of RDS names) for your problem. BuT</p>

<p>There are multiple solutions for your actual problem (managing RDS servers for each project)</p>

<p>A. Try to avoid using AWS Console as much as possible. Why dont you start looking into AWS CLI (which can pull the tags) and write a wrapper Python/Bash script to list all the RDS servers - with Project Names, from this output you could manage these servers, like take a snapshot , backup etc. You can also use mysql --login-path (If you are on mysql for DB administration)
<a href="https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/" rel="nofollow noreferrer">https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/</a>.  </p>

<p>B. (Cost agnostic approach) If you have anyways decided to change the RDS Names, then there is something you can do without any impact. </p>

<pre><code>B.1 When the next code/config release happens try to bring in the intermediate DNS change into action.

B.2 (Optional) Enable Multi AZ in RDS (HA and twice the price). This will help your application to access the secondary active slave when there is any disruption due to name change. There is an option called Reboot with failover which would reboot the master while failing over to the active secondary 

B.3 Enable replication (read-replica) (this will give you a new RDS end-point). Name the read replica properly with your project names

B.4. Once replication is complete (and during your SLA / maintenance window) promote your read replica (this will break replication) and make the intermediate DNS point to the new RDS (with your proper names)
</code></pre>

<blockquote>
  <p><strong>NOTE</strong>  All the above approaches would not guarantee data integrity and improper data updates due to in-flight transactions. So it is
  always better to stop all transactions (by stopping all application
  accessing and deploying a maintenance page and do the operations)</p>
</blockquote>

CC BY-SA 3.0
2017-08-13T11:27:24.910Z
I appreciate your input, though I have noticed that the weird (useless) names come specifically from using the CLI. Creating an RDs instance from the console gives them meaningful names.
Danny Schoemann
CC BY-SA 3.0
2017-08-13T11:28:18.303Z
it is also very difficult (impossible?) to do billing analysis from the CLI, as well as watching usage graphs.
Danny Schoemann
CC BY-SA 3.0
2017-08-14T20:21:03.973Z
**#1** Ohh, for creation you can take a look at Cloudformation (where you can define the RDS names), when I said CLI I was referring to reading RDS list (for easy parsing in grep use `--output=text`.   **#2** and yes for billing analysis, console is a must, you should consider creating an IAM user with billing-role and hand it over to your finance person.
Ameen Ibrahim Raffic - 'AIR'
CC BY-SA 3.0
2017-08-13T08:20:46.610Z
2017-08-13T08:20:46.610Z
Ameen Ibrahim Raffic - 'AIR'
<p>Yes, you can rename an RDS instance... at your own peril.</p>

<blockquote>
  <p>When you rename a DB instance, the [DNS] endpoint [hostname] for the DB instance changes, because the URL includes the name you assigned to the DB instance. </p>
  
  <p><a href="http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RenameInstance.html" rel="noreferrer">http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RenameInstance.html</a></p>
</blockquote>

<p>Your application code requires configuration changes to be coordinated, for this reason.</p>

<p>See the link above for the other implications.  This is a supported and generally safe operation, but only in your maintenance window, because there will necessarily be a brief disruption as the DNS is changed and your app code is cycled in with the new database hostname.</p>

CC BY-SA 4.0
2024-01-18T11:03:05.243Z
Just a small remark: You cannot rename a RDS instance when its stopped. Make sure to rename the instance before shutting it down to avoid any delays.
ploth
CC BY-SA 3.0
2017-05-11T17:43:42.383Z
2017-05-11T17:43:42.383Z
Michael - sqlbot
<p>I have inherited a collection of RDS MySQL instances with random (useless) <em>DB Instance</em> names.</p>

<p>I often have to dig into the <em>tags</em> section to find out which project they belong to.</p>

<p>One of the settings I can modify in an RDS is the <code>DB Instance Identifier</code>.</p>

<p>If I change this, what will happen besides for the name change? <strong>Will it affect anybody's code?</strong> Or is it a harmless change?</p>

<p>These are live systems that I cannot afford to bring down.</p>

<amazon-rds>
Can I rename an RDS instance?
Danny Schoemann
# Can I rename an RDS instance?

(Asked by: username_0 on 2017-05-11)

I have inherited a collection of RDS MySQL instances with random (useless) *DB Instance* names.

I often have to dig into the *tags* section to find out which project they belong to.

One of the settings I can modify in an RDS is the `DB Instance Identifier`.

If I change this, what will happen besides for the name change? **Will it affect anybody's code?** Or is it a harmless change?

These are live systems that I cannot afford to bring down.

**Tags:** amazon-rds


---

## 2 answers

### Answer by username_2 on 2017-05-11. Score: 10 | Accepted answer

Yes, you can rename an RDS instance... at your own peril.

> When you rename a DB instance, the [DNS] endpoint [hostname] for the DB instance changes, because the URL includes the name you assigned to the DB instance.
>
> <http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RenameInstance.html>

Your application code requires configuration changes to be coordinated, for this reason.

See the link above for the other implications. This is a supported and generally safe operation, but only in your maintenance window, because there will necessarily be a brief disruption as the DNS is changed and your app code is cycled in with the new database hostname.

> **Comments:**
> **username_3**: Just a small remark: You cannot rename a RDS instance when its stopped. Make sure to rename the instance before shutting it down to avoid any delays.  

---

### Answer by username_1 on 2017-08-13. Score: 3

Yes you can change the name of the RDS instance, but it is highly discouraged to do so in LIVE Production environment. It would change the EndPoint which might impact other resources actively accessing the RDS server (like an application server).
This would probably require a property / env-variable change in your code or configs (which would ideally end up for a release of config through config management)
To avoid disruption (In future) and rollout changes with lesser RTO , you can create an intermediate DNS entry (CNAME) in Route53 for your RDS server and use the intermediate URL in your application. When the RDS server name changes you could just change the DNS CNAME of the new RDS Endpoint. NOTE: During the name change your RDS server would be unavailable (with old name) for few minutes and this might cause disruption
That being said, you are already biased on a solution (change of RDS names) for your problem. BuT
There are multiple solutions for your actual problem (managing RDS servers for each project)
A. Try to avoid using AWS Console as much as possible. Why dont you start looking into AWS CLI (which can pull the tags) and write a wrapper Python/Bash script to list all the RDS servers - with Project Names, from this output you could manage these servers, like take a snapshot , backup etc. You can also use mysql --login-path (If you are on mysql for DB administration)
https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/.  
B. (Cost agnostic approach) If you have anyways decided to change the RDS Names, then there is something you can do without any impact. 
B.1 When the next code/config release happens try to bring in the intermediate DNS change into action.

B.2 (Optional) Enable Multi AZ in RDS (HA and twice the price). This will help your application to access the secondary active slave when there is any disruption due to name change. There is an option called Reboot with failover which would reboot the master while failing over to the active secondary 

B.3 Enable replication (read-replica) (this will give you a new RDS end-point). Name the read replica properly with your project names

B.4. Once replication is complete (and during your SLA / maintenance window) promote your read replica (this will break replication) and make the intermediate DNS point to the new RDS (with your proper names)


NOTE  All the above approaches would not guarantee data integrity and improper data updates due to in-flight transactions. So it is
  always better to stop all transactions (by stopping all application
  accessing and deploying a maintenance page and do the operations)

> **Comments:**
> **username_0**: I appreciate your input, though I have noticed that the weird (useless) names come specifically from using the CLI. Creating an RDs instance from the console gives them meaningful names.  
> **username_0**: it is also very difficult (impossible?) to do billing analysis from the CLI, as well as watching usage graphs.  
> **username_1**: **#1** Ohh, for creation you can take a look at Cloudformation (where you can define the RDS names), when I said CLI I was referring to reading RDS list (for easy parsing in grep use `--output=text`.   **#2** and yes for billing analysis, console is a must, you should consider creating an IAM user with billing-role and hand it over to your finance person.  

---

