AWS环境下RDS旧端点流量重定向至新端点的问题与最佳实践咨询

Let's break down what's going wrong first, then walk through solutions and best practices tailored to your scenario.

Why Your CNAME Attempts for AWS-Generated RDS Endpoints Failed #

The core problem here is that you don't have DNS control over AWS-managed domains like rds.amazonaws.com. When you created a hosted zone for cy336nc8sq5l.us-east-1.rds.amazonaws.com in Route53, that zone is completely invisible to the global DNS system—AWS owns and operates the authoritative DNS servers for rds.amazonaws.com, so your custom records in that self-created zone will never be resolved by any client. That's why those CNAMEs didn't work, but your custom domain (like abc.example.com) CNAMEs did: you own the example.com domain and control its DNS.

You also can't create a CNAME pointing from the old AWS-generated endpoint (old.cy336nc8sq5l.us-east-1.rds.amazonaws.com) because you don't have permission to modify DNS records for AWS's own domains. That endpoint is hard-linked to your old RDS instance by AWS, and there's no way to redirect it via DNS.

Temporary Workaround to Redirect Traffic (Without Changing All Apps Immediately) #

Since you can't redirect the old endpoint via DNS, here's a practical temporary fix to keep apps running while you migrate:

• Set up data sync between old and new RDS instances: Use AWS Database Migration Service (DMS) or native database replication (like MySQL/MariaDB master-slave, PostgreSQL streaming replication) to keep the new instance in sync with the old one.
• Make the old instance read-only: Update the old RDS instance's parameter group to enforce read-only mode. This way, apps using the old endpoint can still fetch data, but all write operations will fail—giving you a clear signal to update those app configurations to point to the new instance or your upcoming custom CNAME.
• Use a database proxy: Deploy AWS RDS Proxy (or a self-hosted proxy like ProxySQL) and update apps incrementally to point to the proxy instead of the old endpoint. Once all apps are using the proxy, you can switch the proxy's backend to the new RDS instance without any further app changes.

Long-Term Best Practices (Aligning with Your Custom CNAME Plan) #

To avoid this headache in the future and simplify migrations, follow these steps:

1. Create a custom domain alias for your new RDS instance:
   • In Route53, create an Alias Record (not a CNAME) for a subdomain you control (e.g., db.yourdomain.com) pointing to your new RDS endpoint new.cy336nc8sq5l.us-east-1.rds.amazonaws.com. Alias records are free, avoid extra DNS lookup latency, and are more reliable than CNAMEs for AWS services.
2. Migrate apps incrementally: Update each application's configuration to use the custom alias instead of the old AWS-generated endpoint. Take your time with this—you can test one app at a time to ensure stability.
3. Retire the old RDS instance: Once all apps are using the custom alias and you've verified data consistency, you can safely terminate the old RDS instance.
4. Standardize on custom aliases for all RDS instances: Going forward, never use AWS-generated endpoints directly in your apps. Always map them to a custom alias in your own domain. This way, if you need to migrate to a new RDS instance, you only need to update the alias record in Route53—no app code or configuration changes required.

内容的提问来源于stack exchange，提问作者Himanshu dua