RDS Blue/Green Deployment causes automatic Elastic IP assignment instead of dynamic Public IP

Question

I performed a Blue/Green deployment to upgrade my RDS instance from t3.small to t4g.small.
After the switchover, I noticed the new RDS instance has an Elastic IP automatically assigned with "Service managed: rds".

This behavior contradicts AWS official documentation, which states:

>"Because the IP address of your instance is dynamic, you can't assign a static IP address or an Elastic IP address to your instance."
>Source: https://repost.aws/knowledge-center/rds-ip-address-issues

Environment:

Region: ap-northeast-2
Engine: MySQL
Original instance: t3.small (Public Access: Yes, dynamic Public IP)
New instance: t4g.small (Public Access: Yes, Elastic IP auto-assigned)

Problem:

The original t3.small instance had Public Access enabled with only a dynamic Public IP (no EIP)
After Blue/Green deployment, the new t4g.small instance automatically received an Elastic IP
I cannot disassociate or release this EIP ("You do not have permission to access the specified resource")
Disabling Public Access releases the EIP, but re-enabling it creates a new EIP again
I need Public Access but want to avoid EIP charges ($0.005/hour)

Question:

Why does the new instance get an EIP instead of a dynamic Public IP like the original?
Is this behavior related to the instance class change (t3 → t4g) or the Blue/Green deployment process?
Is there any way to use Public Access without an Elastic IP?

Thank you.

re:Post Agent · Answer

The behavior you're experiencing is related to the Blue/Green deployment process for Amazon RDS, not specifically to the instance class change from t3 to t4g.

When a Blue/Green deployment switchover occurs, the green environment becomes the new production environment (new blue), inheriting the original names and endpoints from the old production environment. During this process, the system ensures that your applications continue operating without configuration changes by maintaining consistent connectivity.

After the switchover, the DB instances that were in the green environment become the new production DB instances. The names and endpoints in the current production environment are assigned to the newly switched over production environment. The previous blue environment instances are renamed by appending "-oldn" (where n is a number) to their current names.

Regarding the Elastic IP assignment, this appears to be how RDS maintains network connectivity during the Blue/Green switchover process. The service-managed Elastic IP ensures that your database remains accessible at the same endpoint after the switchover.

Unfortunately, there isn't a documented way to use Public Access on an RDS instance after a Blue/Green deployment without the service-managed Elastic IP. Since this is a service-managed resource (as indicated by "Service managed: rds"), you don't have permission to release or modify it directly.

If the Elastic IP charges are a concern, you might consider:
1. Using private connectivity options instead of public access
2. Contacting AWS Support to inquire about this specific behavior and potential alternatives
3. Creating a new instance directly (without Blue/Green) if you need to avoid the Elastic IP charges  
**Sources**  
[Introducing fully managed Blue/Green deployments for Amazon Aurora Global Database | AWS Database Blog](https://aws.amazon.com/blogs/database/introducing-fully-managed-blue-green-deployments-for-amazon-aurora-global-database/)  
[Overview of Amazon RDS Blue/Green Deployments - Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)  
[Using Blue/Green Deployments for Amazon Aurora Global Database - Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-bluegreen.html)

RDS Blue/Green Deployment causes automatic Elastic IP assignment instead of dynamic Public IP

Add your answer

Relevant content