Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Charge for Idle Database Connections
Transcript
- Lucas: If you're running an Aurora PostgreSQL cluster and you've got a few Lambda functions that open a connection, do some work, and then close it, you might have noticed something new on your bill. A line item for database connection hours. Not storage, not compute — just the time a connection stays open. Luna: Wait, they're charging for the act of holding a connection open? That used to be bundled into the compute cost, right? Lucas: Exactly. Until about six months ago, you paid for the database instance — the underlying EC2 or equivalent — and you could open as many connections as the instance's memory could handle. Now AWS, Azure, and Google Cloud are all rolling out separate metering for connections. For AWS, it's called 'connection hours' for RDS and Aurora. Azure has 'DTU connection minutes' for SQL Database. GCP charges based on 'connection slots' for Cloud SQL. Luna: And of course, the price isn't trivial. I saw a case where a SaaS company with 500 Lambda functions saw their monthly database bill jump by about 12% — just from connections that were sitting idle for a few seconds between requests. Lucas: Right. That's the key. Idle connections. The cloud providers are basically saying: if you open a connection and don't do anything with it for a while, you're still consuming resources on our end — database server memory, kernel data structures, network state. And they want to get paid for that resource usage directly. Luna: So it's similar to how they started charging for VPC flow logs or container registry scans — turning previously free or bundled overhead into a line item. Lucas: Yeah, that's the pattern. And it makes sense if you think about it from the provider's perspective. A database instance can handle maybe a few hundred or a few thousand connections total. If you're only using a few but someone else is using most of them, the provider can't oversell as aggressively. So they unwrap that cost. Lucas: Let me give you a concrete number. On AWS, for a db.m6g.large Aurora instance, the connection hour rate is currently about $0.002 per connection per hour. That's small per connection. But if you have 300 Lambda functions that each open a connection and keep it alive for a minute per invocation, and you do a million invocations a month, that's 300 million connection minutes — which translates to about 5,000 connection hours — or roughly ten bucks a month extra. Not huge, but for a larger fleet it adds up. Luna: And for Azure SQL Database, it's similar. They charge per DSU minute for connections above a baseline. A standard tier S2 database includes a certain number of free connection minutes, then overage is charged. Lucas: If these conversations are useful for what you're building or running, that's exactly why we do this show. We deliberately don't run ads on these episodes — no sponsors, no midroll interruptions. If you want to support that choice and help keep it that way, the link is buy me a coffee dot com slash fexingo. Luna: Yeah, it's a small gesture that lets us stay editorial and not chase advertiser-friendly topics. Lucas: Exactly. So back to database connections: what do you do about it? The obvious fix is connection pooling. Instead of each Lambda opening its own connection, you use a service like RDS Proxy or Azure SQL Connection Broker to maintain a pool of persistent connections that get reused across invocations. Luna: But those proxies cost money too. RDS Proxy has its own hourly charge — $0.015 per hour for the proxy itself, plus data transfer. So you have to run the math. Lucas: Right. For a low-traffic app, the proxy might cost more than the connection overage. But for high-volume apps, pooling can reduce the number of connections dramatically. I've seen a case where a company reduced their connection count from 400 to 20 by using a proxy, cutting their connection costs by 95%. Luna: Another approach: tune your application to close connections faster. If your Lambda function only needs the database for 200 milliseconds, don't hold the connection open for 15 seconds while you process the rest of the result. Use connection timeouts aggressively. Lucas: Yes, and some teams have moved to a 'disconnect after every request' pattern — opening a fresh connection per invocation. That avoids idle time but increases the connection setup overhead, which can affect latency. It's a classic trade-off. Lucas: There's also a architectural change: use serverless databases like Aurora Serverless v2 or Azure SQL Serverless. Those services charge per ACU or per DTU, and connection costs are bundled into the compute. Although, some say that bundling is just a different pricing model that may not be cheaper. Luna: Right. And I've seen GCP's Cloud SQL for PostgreSQL has added a 'connection pooling' option built into the database itself — a feature called 'pgBouncer integration' — so you can pool on the server side without a separate proxy. Lucas: That's smart. It shows that the big three are aware that this new metering is a friction point, so they offer tools to mitigate it — but the mitigation tools often have their own costs. It feels like a deliberate unbundling strategy. Luna: Do you think this trend will continue? I mean, now that they've done connections, what's next? CPU credits? Memory reservation bytes? Lucas: I think so. The hyperscalers are moving toward hypergranular billing. Look at the pattern: a few years ago, they started charging for EBS IOPS, then for NAT gateway data processing, then for VPC Flow Logs, then for API calls for services like Secrets Manager. Connection hours are just the latest. I expect we'll see metering for things like 'number of concurrent transactions' or 'index maintenance operations' soon. Lucas: Exactly. And that's why FinOps teams are now adding connection counts to their dashboards. They're treating connections as a measurable unit like compute hours or storage bytes. Some companies are even setting connection budgets per team. Lucas: One more thing: the new metering doesn't just affect serverless apps. Traditional always-on applications that use persistent connection pools — like a Java app with a JDBC pool — they also get charged per connection, but they usually keep connections alive for hours, so the costs can be higher. Luna: Right, because a persistent pool might have 50 connections open 24/7. That's 50 connection hours per hour, or 36,000 connection hours per month. At $0.002 per connection hour, that's $72 a month just for the connections. On a small instance that might be a noticeable percentage. Lucas: That's the classic case. So the advice is: reevaluate your pool size. Many teams set it too high as a safety margin. If your application only needs 10 concurrent connections, don't configure a pool of 50. Lucas: Good point. On Aurora, you can set the 'idle_in_transaction_session_timeout' parameter to kill connections that are stuck in an open transaction but doing nothing. Luna: I think the broader takeaway is: read your cloud provider's new billing blog posts. They announce these changes quietly. Last quarter, AWS published a post about 'new RDS connection metering' that many missed. Lucas: Yeah, and if you're on a reserved instance or savings plan, check whether your commitment covers connection hours. Typically, reserved instances cover the database compute but not the connection metering — that's a usage-based charge always. Lucas: So, to sum up: connection hours are a new, real cost. Mitigate with pooling, timeouts, or serverless databases. And expect more granular billing to come. Luna: And if you're building a new app, maybe design your database access pattern with these costs in mind from the start. Lucas: Exactly. Thanks everyone for listening.