Published on

A Tale of Two Clouds - AWS RDS Proxy vs. Tencent Cloud CAM

Authors

The story starts with a headache. Recently, my team and I were working on a security compliance requirement: Database Password Rotation.

We were using Spring Boot with MongoDB. We quickly realized that the official MongoDB Java Driver is designed with immutable credentials. It does not support dynamic password refreshing out of the box. To achieve "zero downtime" rotation, we had to consider crazy ideas like destroying and rebuilding connection pools at runtime or using Java Agents to modify bytecode.

It felt wrong. Security should not make application code complex and fragile.

This problem made me look back at the "ideal state." In my previous role within the AWS ecosystem, RDS Proxy was the go-to solution for this. It left a deep impression on me because of how elegantly it handled these security challenges.

However, currently, I work for a Multinational Corporation (MNC). While we operate globally, there are specific scenarios where we build our infrastructure on Tencent Cloud.

Realizing that many of my peers in other markets might not have had the chance to touch this platform, I want to take this opportunity to share this implementation to open up some new perspectives.

Recently, I implemented Tencent Cloud’s "CAM Database Authentication" for MySQL. I found it to be a fascinating case study in how different cloud providers approach the same problem: Getting rid of hard-coded passwords.

The "Middleware" Pattern: AWS RDS Proxy

First, let's look at the AWS approach. This is what I consider the "heavy infrastructure" approach.

AWS RDS Proxy acts as a middleware between your application and the database.

How it works:

  1. Authentication Offloading: The application uses an IAM Token to connect to the Proxy. It never touches the real database password.
  2. The Secret Manager: The Proxy talks to AWS Secrets Manager to get the real credentials and connects to the database.
  3. Connection Multiplexing: The Proxy maintains a pool of physical connections to the database and shares them among many application connections.

The killer feature here is Transparency. When the security team rotates the password in Secrets Manager:

  1. The Proxy notices the change.
  2. The Proxy starts using the new password for new backend connections.
  3. Crucially, the frontend connections (your app) are not dropped. The Proxy handles the switch internally.

Your application code does not need to change. It does not even know the password changed.

The "Direct Connect" Pattern: Tencent Cloud CAM

Now, let's look at Tencent Cloud. They offer a feature called MySQL CAM Authentication.

When I first read the name, I thought it might be similar to RDS Proxy. But after implementing it, I realized it follows a completely different philosophy: The "Client-Side" pattern.

How it works:

  1. Control Plane (The Token): Your application uses its cloud API keys (AK/SK) to call the Tencent Cloud CAM API. It asks: "Please give me a token."
  2. Data Plane (The Access): The API returns a temporary AuthToken.
  3. Direct Connection: Your application uses this AuthToken as the password to connect directly to the MySQL IP address (port 3306).

There is no middleman. There is no proxy.

This architecture difference becomes very important when we talk about key rotation.

Because there is no Proxy to buffer the change, the application client must handle the complexity of token expiration.

If the token expires or the password is rotated while your application is running, the connection might fail. You cannot rely on the infrastructure to hide this from you.

In fact, the official Tencent Cloud documentation is very honest about this. They include two specific warnings that every architect must read carefully:

"仅对可以轻松重试的工作负载使用 CAM 身份验证。"

Translation: "Only use CAM authentication for workloads that can be easily retried."

And:

"请尽可能使用长连接访问数据库。"

Translation: "Please use long-lived connections to access the database as much as possible."

Why do they say this?

  1. "Easily Retried": This admits that connections will fail. If a rotation happens, your current token becomes invalid. If your app tries to create a new connection with an old cached token, it will fail. Your code must catch this error, request a new token, and retry.

  2. "Long-lived connections": Authentication usually happens only during the TCP handshake. If you keep the connection open (Long Connection), you bypass the need to constantly re-authenticate. If you use short connections, you might hit a "Thundering Herd" problem where thousands of requests fail simultaneously when a token expires.

Expanding Horizons

This is not to say one cloud is "better" than the other. They are just solving the problem at different layers.

  • AWS RDS Proxy solves both Security (No passwords) and Traffic (Connection pooling). It is a robust infrastructure solution.

  • Tencent Cloud CAM (and strictly speaking, AWS IAM Database Auth) solves only Security. It is a lightweight, client-side solution.

As engineers working in a global environment, we must recognize these patterns.

  • If you use Tencent Cloud CAM, do not expect it to behave like a Proxy.
  • You must write robust retry logic in your code.
  • You must manage your connection lifecycle carefully.

If you need the connection pooling and seamless rotation capabilities on Tencent Cloud, you shouldn't rely solely on CAM. You would need to provision their "Database Proxy" service separately.