Pulling up a client’s Cost Explorer, I found RDS Proxy responsible for 70% of their total CloudWatch Logs ingestion cost — while their actual “RDS Proxy” line item looked completely normal.

Hi everyone 👋

My first reaction, and the first reaction of nearly every client I’ve shown this number to, is always the same: “I’m already paying for RDS Proxy by the vCPU-hour — why is it also eating into my CloudWatch bill? Aren’t those two completely separate things?”

This isn’t a one-off. I’ve heard almost the exact same question across different accounts — same surprise, same follow-up: “So what is this, and can I turn it off?”

😱 Two bills that look unrelated, but aren’t

RDS Proxy has its own pricing model, simple and predictable: billed per vCPU-hour of the underlying capacity, with a 2 vCPU minimum. That line item is separate and rarely surprises anyone.

CloudWatch Logs has its own pricing model too: billed per GB ingested, roughly $0.50/GB for the first 10 TB (us-east-1). On paper, these are two completely separate services — you don’t “buy” CloudWatch Logs when you provision RDS Proxy.

The catch is that RDS Proxy automatically pushes data into CloudWatch Logs, continuously, as a side effect that isn’t advertised anywhere prominent. For some systems — especially ones built around a lot of short-lived connections — that volume is large enough to dominate the account’s total CloudWatch ingestion cost, not just a small slice of it.

🔍 What is that 70% actually made of?

Digging into the /aws/rds/proxy/<proxy-name> log group, what’s being written there is an INFO-level entry for every single connect and disconnect between a client and the proxy — not error logs, not query logs, just connection lifecycle events.

This is default behavior, not a misconfigured feature. Multiple independent threads on AWS re:Post confirm the same thing: RDS Proxy writes this log regardless of whether “Enhanced Logging” is enabled — Enhanced Logging is a separate, more verbose option that auto-disables after 24 hours. The baseline connect/disconnect logging has nothing to do with that setting, and it runs indefinitely.

Systems with a lot of short-lived, frequently opened/closed connections — typically architectures with many Lambda functions hitting the database through the proxy — generate a lot more of this log volume, since every open/close is a new log line, regardless of whether the query behind it was heavy or trivial. That’s how this number can grow to dominate a CloudWatch account’s total ingestion cost, even though CloudWatch serves dozens of other services in that same account.

And it’s not an isolated case, either — engineers on AWS re:Post have reported a similar pattern: CloudWatch made up 18–20% of their total AWS bill, with roughly 60% of that coming from RDS Proxy’s PutLogEvents calls alone. The exact ratio varies by system, but the underlying mechanism is identical.

❓ So, can you turn it off?

No. This is the part that frustrates clients the most once they hear the answer.

🛠️ What you can actually do

  1. Set retention on the log group the moment you create the proxy (a few days is plenty for debugging) — this cuts accumulated storage cost, though not the daily ingestion cost.
  2. Reduce how often your application connects and disconnects — reusing connections instead of opening new ones constantly is the only thing that actually reduces the log volume generated, since it scales with connect/disconnect count, not query volume.
  3. Track this log group separately in Cost Explorer, don’t lump it into “CloudWatch” as a whole — as shown here, a single log group can dominate total ingestion cost without anyone noticing if you only look at the aggregate.
  4. Treat this as a fixed cost of running RDS Proxy, and factor it into the comparison from the start, instead of comparing only the proxy’s vCPU-hour price against self-managed connection pooling.

💡 What I took away

“I’m already paying for RDS Proxy, why is it also costing me CloudWatch” is a fair question — the answer just isn’t a misconfiguration on anyone’s part, it’s a default side effect with no off switch. If you’re considering turning on RDS Proxy, or you’re already seeing your CloudWatch bill creep up for no obvious reason, the /aws/rds/proxy/* log group is the first place worth checking.

📚 References