Summary

  • RDS cannot reduce storage already allocated to the same DB instance. Clearing data can leave the purchased capacity, and its storage charge, unchanged.
  • A supported blue/green deployment can replace an eligible MySQL instance with a smaller environment. The move and the retention of the old recovery history can delay the savings.

The emergency purchase becomes the furniture

Storage autoscaling has an excellent sales pitch: the database gets more room before the lack of it becomes somebody's urgent problem. The application keeps working. An engineer avoids a hurried intervention. Nobody needs to assemble a purchasing committee beside a nearly full disk.

Then the exceptional workload ends. Data is cleared, free space returns, and the larger allocation stays. The emergency purchase has become the furniture.

Amazon RDS documents that asymmetry plainly. Its storage autoscaling guide says allocated storage cannot be reduced on the same DB instance. Neither autoscaling nor a manual instance modification supplies that downward step. Switching off the automatic feature leaves earlier increases in place.

For RDS for MySQL, the storage pricing basis is provisioned capacity, with changes during a month prorated. Occupied space is a different number. Even a cleanup that releases actual filesystem space can leave the purchased allocation untouched. The availability dashboard has improved; the storage line on the bill has no corresponding reason to fall.

The feature has done useful work. The organisational mistake is to treat that work as the whole lifecycle of the purchase. Avoiding a full database and deciding what capacity to retain after a spike are separate jobs. One has been automated. The other still needs an owner.

The smaller number belongs to another database

AWS offers a route down. For supported configurations, a blue/green deployment can create a smaller green environment and then switch production into it. AWS also describes creating a smaller new instance, manually migrating the data and changing database endpoints. Both routes involve a replacement.

The creation guide requires a storage reduction target to exceed current usage by at least 20%. Consider an arithmetic illustration: 500 GiB allocated, half of it occupied, means 250 GiB in use. The documented formula produces a 300 GiB minimum target. Configuration eligibility and growth during preparation still need room in the decision. No customer invoice or realised saving is hiding inside that calculation.

Reducing storage initiates a storage configuration upgrade, an I/O-intensive operation that can lengthen creation. Finance may see a large number waiting to become a smaller one. Operations sees another environment that must be copied, checked and made ready to accept production writes.

The concrete case here is an eligible RDS for MySQL instance. The support matrix also lists supported MariaDB and PostgreSQL versions; Db2, SQL Server and Oracle do not support this blue/green feature. The product family name alone does not establish an available shrinking route.

A familiar endpoint with a different past

The managed switchover checks replication health and lag, among other conditions. RDS stops new writes, drops connections, waits for the green environment to catch up, and renames instances and endpoints before allowing connections and writes into the new production environment. Separately promoting the green instance by hand would break the deployment's replication relationship. It is a different operation, not an abbreviated switchover.

The familiar endpoint name can therefore return while a different resource does the work. Each instance keeps its own immutable resource identity. That distinction matters when someone needs yesterday rather than today.

AWS's blue/green considerations say the old production instance's point-in-time recovery history does not carry over to the new one. The new instance has its own history beginning when the green environment was created. The old blue instance retains its history and automated backups until it is deleted.

A business that still needs those earlier recovery points must account for keeping the old environment. AWS explicitly warns that a retained, running blue instance continues to incur compute and storage charges. A successful move into a smaller production database can therefore coexist with a temporarily larger total expense.

Even deleting the blue/green deployment leaves the blue environment unaffected. Removing the deployment arrangement and retiring its billable resources are separate acts. Merely stopping a MySQL instance also leaves storage charges running.

The customer's actual rates, overlap duration, recovery needs and migration effort are missing from any numerical claim of net savings. The decision can still be framed correctly: compare the smaller continuing footprint with the cost of reaching it and preserving the required recovery window. A declining utilisation chart is an invitation to investigate. It is not the completed move.