Scaling AWS RDS Databases

Database usage can be challenging to predict, especially for startup companies or companies rolling out a new feature. If you allocate too much computing power or memory, your costs will be higher than necessary. On the other hand, configuring too little will cause outages or lag for your users. 

Instead of requiring your predictions to be correct, developers can apply auto-scaling to your database instances. Auto-scaling can be applied internally by AWS or external tools can autoscale for you.

Features of AWS RDS

Amazon Web Services’ Relational Database Service (RDS) allows users to create, maintain, and scale relational databases in the cloud. RDS supports different relational database engines such as MySQL, PostgreSQL, SQLServer, and Amazon’s Aurora. AWS also provides a series of instance types that each database engine may run on. Each instance type prioritizes different aspects of managing your relational databases, such as performance during usage spikes, memory capacity, and bandwidth. 

Multiple Availability Zones

Infrastructure failures may occur, but with AWS’s distributed infrastructure, these tend to be limited to a single Availability Zone (AZ). AWS RDS can be provisioned to deploy database instances to multiple AZs.  Users gain enhanced availability and durability when the Multi-AZ instance is configured. Each AZ will run a physically distinct, replicated version of the database. Once the failure has been resolved, the primary database is automatically restored, limiting the downtime of your system. 

Optional Read Replicas

Some instance types allow read replicas to be created. A read replica is a second database instance created using a snapshot of the first. In the case of Amazon Aurora, replicas are read using an SSD-back virtualized storage layer, which gives the added benefit of lowering costs. Read replicas allow you to scale your database capabilities beyond the limits of a single Availability Zone for read-only events. They also ensure if a single AZ is down, read events can still occur against a replica.

Automatic Instance Backups

AWS RDS will create a snapshot of your database instance during your backup window. This snapshot backs up the entire instance and not just a single database so the entire instance can be recovered. Users configure the retention period of the snapshot to any time between 0 and 35 days. If you set this period to 0 days, the automated backups will be turned off. Users can also create a backup manually if necessary. 

Capacity Type Settings in Amazon Aurora

Amazon Aurora is a fully managed relational database run on AWS RDS. When you use the Aurora instance, you get enhanced speed and scalable storage. You can also choose between provisioned and serverless capacity. The latter gives a method to autoscale the capacity of your instance.

Provisioned Capacity

Provisioned capacity is suited for databases with a predictable and known load. Cost is calculated per hour with the cost depending on the instance size chosen. Choosing too high a capacity results in preventable cost overages. On the other hand, choosing too low a capacity will result in outages when usage exceeds capacity. If loads are known, a correct instance can be chosen to keep costs and a standard and efficient rate.  

Serverless Capacity

Serverless capacity settings for Aurora can be used when the load on the system is not consistent or predictable. There are two versions of serverless capacity settings, with the newer Version 2 in preview by AWS. 

Serverless capacity Version 1 allows users to set a maximum and minimum capacity, between which the database will autoscale the read replicas available in RDS. There are no outage times during this autoscaling. This type of scaling is ideal when you have bursty requirements and want to only pay for the database when it is in use. 

Serverless capacity Version 2 is only available in preview and for Aurora with MySQL. AWS built upon its predecessor to create a more fine-tuned capacity scaling system. Scaling with Version 2 supports not only read replicas but global database and mutli-AZ deployments as well. Bursty database usage can still be scaled, but Version 2 can also help to scale enterprise databases, and scaled out databases split between multiple servers and availability zones. 

Scaling AWS RDS

Scaling databases is needed when your database cannot keep up with throughput demands. Scaling options include both vertical scaling and horizontal scaling. 

Vertical scaling changes your instance size to handle a larger number of Input/Output operations per second (IOPS), a higher throughput, or a lower latency value. Of course, if you have overprovisioned your instance, you can scale down the instance size instead. 

Horizontal scaling uses the addition of read replicas to alleviate traffic on the primary instance. Read requests instead are diverted to one of the replicas to increase the throughput of the instance. 

Horizontally scaling write capacity is more complex, with no internal methods readily available. Users could employ techniques like sharding, but this involves custom, external development. If that is not possible, vertically scaling write capacity is the only scaling option. 

Scale Manually 

The AWS CLI can be used to modify settings specifically for a database instance. You can check the existing instance settings with the CLI to determine if your existing instance is sufficient for your needs. You can modify the database instance to scale your instance when changes are required.

You can also scale your RDS instance manually using the AWS console. The console will show you your existing instance settings so you can scale as needed. By using the console, you can modify the instance type, size, and also the allocated storage. The console also allows the change to occur immediately, or to occur at a later time. This feature is available since scaling does cause an outage of the database while the process is running. 

Scale Automatically

AWS RDS includes the ability to autoscale databases’ storage size. Users set a desired maximum storage size, and the AWS-managed RDS will detect when your storage size is limited based on currently available storage. RDS will automatically increase storage size when certain preset conditions are met. 

Auto-scaling your cluster based on workload requirements is only available with Amazon Aurora. AWS will automatically adjust the number of Aurora replicas in the cluster to manage your workload. Scaling occurs based on a preset minimum and maximum capacity, as well as a cooldown period between scales.

When vertical scaling must be applied automatically, a feedback DevOps loop can be used. Set up metrics to detect when your database is limited in capacity. If a change in the instance is required to prevent outages, a command can be triggered using external platforms that can apply autoscaling.

Considerations for Scaling AWS RDS

Before scaling your RDS instance, you will need to ensure minimal disruption for your platform. Changing the instance type will cause a temporary outage to your database during the upgrade. The scaling can be scheduled for a routine maintenance window, or to minimize the outage time, you can use some of the existing features of RDS.

If you use the Multi-Availability Zone environment, downtime is minimized on upgrades. This is because the standby database is the first to be updated, then the primary database is updated while a failover mechanism points to the standby. This limits the time that users will see a delay or failure due to the upgrade.

Before applying any scaling, be aware of your commercial database license. These apply if using a commercial engine like SQL Server or Oracle. Commercial engines use licenses to restrict your available CPU sockets or cores. If you scale beyond your license, the scaling in AWS may not take effect. 

The instance type and storage allocation are separate settings in RDS. Changing your instance type will not change the amount of allocated storage and vice versa. Before scaling, developers must determine what is needed for both of these parameters and update accordingly.

Summary

Predicting capacity requirements for your relational databases requires a steady and established load. For bursty or unpredictable data requirements, autoscaling your RDS database will help keep your platform running smoothly without unpredictable outages. 

AWS RDS requires separate scaling of storage capacity and instance throughput. Storage capacity can be autoscaled using AWS auto-scaling tools for more database types. Instance capacity scaling can cause outages when vertical scaling is employed. AWS does provide horizontal auto-scaling on some database types like Amazon Aurora.

If you need to vertically scale a database instance, a third-party or custom tool could be required. Since AWS autoscaling does not apply to instance changes, the only way to make such a change is using something outside of the normal AWS flow.