Database Reservations - lock in long term database computation to gain discounts

Database capability in the cloud is achieved via a database instance and attached disk storage volumes. Cloud consumption charges are based upon the database instance family type, its size and its database system, and charged at an hourly value represented in the on-demand rate card. These database instances can have purchased commit reservations to achieve database Reserved Instances, in a similar way to compute reservations - BUT – there is no normalisation, so unique purchases to align against the specific database instance need ( family, size, database type and region ) must be purchased.

The upfront purchase commit, is again based upon a 12 month or 36 month period, ideally to be applied to database instance need where 24*7 run time is required ( yes you can stop database instances, thus stop the hourly billing charge – where the “data” is on the disk storage that is not lost when instance stopped, but the storage is continually charged even when the instance is stopped and not charged ).

Again the Cloud provider reflects what the full on-demand rate card charges are, and what the discounted reservation savings can be achieved and what the resulting hourly rate equivalent after the discount works out to be.

In my experience, over a varied number of instance types and sizes, I see an average of 40% discount savings being achieved.