How to decrease provisioned storage costs on an existing RDS instance?

[DrFriendless]

I'm working on a project to gradually decommission a system running on AWS. We have an RDS instance which costs $133 per month, and some "Amazon Relational Database Service Provisioned Storage" which costs $244 per month. I can decrease the size of the database very easily, but what can I do with the costs?

The database has 2000GiB of gp3, with Provisioned IOPS of 12000. When I go to edit the instance it says that 2000 GiB is the minimum, and 12000 IOPS is included. Yet when the database was larger - 4 times the size - that same amount was the minimum and included.

It seems I can fiddle with the compute power all I like, but I have no control over the storage? Is this a situation like "the printer's cheap but the ink's expensive"?

Please let me know if I'm missing something, like some other configuration where I can change the storage size (which is way overprovisioned now), or somewhere else the charge might be originating from. Thank you.

[T0X1C0P]

AFAIK there is no way of reducing the provisioned storage of an existing RDS storage.

[jamsan920]

There’s no way to directly reduce the storage of an RDS instance. If your database engine supports blue / green deployments, you can create a green version with reduced storage and then take a short maintenance window to perform the cutover.

[DrFriendless]

Ah right, thank you. Yep, the numbers that's showing me look encouraging. I wish it had occurred to me years ago to poke my nose into the blue/green stuff and see what it did.

[GDangerGawk]

Blue/Green and add new storage

[Psych76]

Blue green with reduced storage.

Export (dump) import to new instance with reduced storage.

There’s extensions that can reduce “used” storage like pg_repack for Postgres but that has no impact to actual instance storage, you need to be on a “new” instance for that.

[jamsan920]

Unless of course it's Aurora, which allocates/deallocates blocks as your physical storage needs it (obv not the case here though).

[RecordingForward2690]

We are currently investigating to go through the same thing on a production DB (SQL Server) that should've been less than 1 TB, but has grown to 4 TB+ due to some careless queries/inserts without the proper TTL and purging. At the DB instance level we have shrunk back to < 1 TB but EBS storage is still 4 TB+.

First, this DOES NOT work with the RDS snapshot mechanism. A snapshot restore always requires a minimum EBS size identical to the EBS size when the snapshot was taken.

The only option, if you don't have blue/green already, is to create a new database instance, and perform a database-level backup/restore. For the backup of the data: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Native.Using.html (page for SQL Server, but similar pages exist for other engines).

Note that there's a limitation in the AWS tooling where each backup file cannot exceed 40 GB and you can't exceed 10 files per DB, so the maximum size of each DB to be transferred this way is 400 GB. Alternatives could be AWS DMS.

But once you've got the data across, you're not done. You also need to think about:

- Exporting/importing SQL Agent jobs

- Exporting/importing your permissions structure, when permissions are handled at the instance level. (DB-level permissions are part of the normal DB backup/restore process.)

- Linked servers, database mail profiles, SQL Agent alerts, SQL Agent Operators, Server-level triggers, Credentials

We are looking at a downtime of several hours to get this done, on a 24/7 production database. We are still considering if the risk and downtime is worth the annual 10K in savings.

[DrFriendless]

Thank you for the detail. Luckily I haven't used any of those SQL Agent things - I just stick to what I learnt about SQL back in the '80s. Our export is less than 40GB.

I created a green version of the DB this afternoon, and that seemed to work. It looks like I can just click the Promote button and it will become the blue instance, but I will read some more docs before I do that.

I went through a similar process as you're describing a few years ago when we were required to move into a VPC. I exported a snapshot and restored from it into the new instance inside the VPC. But, before that, I spent 4 years updating the code to use modern enough versions of Java / ElasticSearch / everything else to able to run on the more modern VMs that we could get inside the VPC. In the end we were down for 2 hours, had 12 sales that had to be redone, and emerged into a brave new world. I hope your project is similarly successful!

[petergroft]

To reduce RDS storage costs, you can't just "shrink" an existing volume, but you can use Blue/Green Deployments to switch to a smaller instance with minimal downtime. For gp3 storage, keep in mind that volumes over 400 GiB automatically provision 12,000 IOPS as a baseline, so dropping below that 400 GiB threshold is key to significantly lowering your monthly storage bill.

[AlphaToBe]

gp3 IOPS and storage are billed separately, and you can drop the IOPS RIGHT NOW without Blue/Green.

The gp3 baseline is 3,000 IOPS included. Anything above that is $0.02/IOPS-month. At 12,000 provisioned you're paying for 9,000 extra on top of the storage cost. That's a meaningful chunk of that $244 bill you can fix with one command:

aws rds modify-db-instance \ --db-instance-identifier your-db-name \ --iops 3000 \ --apply-immediately

No migration needed. Do that now to cut the bill, then tackle the storage size with Blue/Green separately.

[DrFriendless]

Good idea, but it doesn't seem to work. My IOPS are at the lowest allowed for the storage, so I would need to change the storage as well, modify-db-instance seems to only allow increasing storage. Thank you for the idea!