<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rds on LeanerCloud</title><link>https://leanercloud.com/tags/rds.html</link><description>Recent content in Rds on LeanerCloud</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 20 Aug 2026 02:08:40 +0200</lastBuildDate><atom:link href="https://leanercloud.com/tags/rds/index.xml" rel="self" type="application/rss+xml"/><item><title>Converting Aurora Serverless to provisioned for cost and performance</title><link>https://leanercloud.com/blog/2025-07-16-converting-aurora-serverless-to-provisioned-rds.html</link><pubDate>Wed, 16 Jul 2025 10:26:20 +0000</pubDate><guid>https://leanercloud.com/blog/2025-07-16-converting-aurora-serverless-to-provisioned-rds.html</guid><description>&lt;h2 id="serverless-is-a-scaling-tool-not-a-default"&gt;Serverless is a scaling tool, not a default&lt;/h2&gt;
&lt;p&gt;Aurora Serverless scales capacity up and down automatically, which is genuinely useful when your load is bursty or unpredictable. The trouble is that it gets adopted as a default for databases whose load is nothing like that, and at scale the per-capacity-unit price makes it an expensive way to run a steady workload.&lt;/p&gt;
&lt;p&gt;I think of Aurora Serverless less as a permanent home for a steady database and more as a temporary configuration that helps you discover the capacity a database actually needs, so you can then move it to a right-sized provisioned instance. If a database has been running at a roughly constant capacity for a year, it is not a Serverless workload.&lt;/p&gt;</description></item><item><title>Finding and cutting unused and idle RDS databases</title><link>https://leanercloud.com/blog/2025-04-08-finding-and-cutting-unused-idle-rds-databases.html</link><pubDate>Tue, 08 Apr 2025 11:48:32 +0000</pubDate><guid>https://leanercloud.com/blog/2025-04-08-finding-and-cutting-unused-idle-rds-databases.html</guid><description>&lt;h2 id="the-databases-nobody-is-using-anymore"&gt;The databases nobody is using anymore&lt;/h2&gt;
&lt;p&gt;On almost every non-trivial AWS account I look at, some RDS databases are running that nobody uses. They were spun up for a migration that finished, a service that got decommissioned, or a test that became permanent. They still run 24/7, still carry storage, and still show up on the bill every month.&lt;/p&gt;
&lt;p&gt;The problem is not that these are hard to fix. Deleting an unused database or dropping an instance a size is a few minutes of work. The problem is finding them. On an account with dozens of databases spread across several regions, the waste is spread thin, and no single database is obviously wrong to an engineer who does not stare at RDS metrics all day.&lt;/p&gt;</description></item><item><title>The cross-AZ data transfer costs hiding in your database traffic</title><link>https://leanercloud.com/blog/2024-09-20-cross-az-data-transfer-costs.html</link><pubDate>Fri, 20 Sep 2024 22:24:02 +0000</pubDate><guid>https://leanercloud.com/blog/2024-09-20-cross-az-data-transfer-costs.html</guid><description>&lt;h2 id="the-line-item-nobody-can-explain"&gt;The line item nobody can explain&lt;/h2&gt;
&lt;p&gt;Cross-AZ data transfer is one of the least understood costs on an AWS bill. It does not map to a resource you can point at, it just shows up as data transfer charges, and it grows silently as traffic increases. A common source is an application instance talking to its database across an Availability Zone boundary, paying per gigabyte in both directions for traffic that could have been free.&lt;/p&gt;</description></item></channel></rss>