Amazon Relational Database Service (RDS)

In this example:

• educative-instance is the instance identifier.

• abcdefghijkl is the unique identifier that gets created based on your region and AWS account.

Within a specific region under a specific AWS account, this unique identifier will remain the same for all DB instances.

DB engines

A database engine is a software that runs on the DB instance. Each version of an engine specifies certain functionalities and features. RDS maintains parameter groups for clusters and instances based on the engine version that defines the configurations of the DB engine. Currently, Amazon RDS supports the following database engines:

• Amazon Aurora 

• MySQL

• PostgreSQL

• Oracle

• Microsoft SQL Server

• IBM Db2

• MariaDB

DB instance classes

DB instance class defines the computational resources we require for our application or business. Price is calculated based on the instance we choose for our database. That’s why it is very important to select the right instance from the class that best suits our needs. Database instances are categorized into the following four classes based on their usage and requirements:

• General-purpose

• Memory-optimized

• Burstable-performance

• Optimized Reads

DB instance types

An instance type is a computational resource with specific resources associated with it, and we select an appropriate type of instance based on our application’s requirements. Each DB instance will have its resources based on the selected instance type. RDS supports a wide range of instance types to run our database on, and each instance type comes with an associated cost based on memory, vCPU, network bandwidth, and storage.

DB instance storage

All database engines except Amazon Aurora use Amazon Elastic Block Storage (Amazon EBS) for data and log storage. Amazon Aurora uses shared cluster storage architecture. Amazon RDS has the following three types of storage for engines that support Amazon EBS:

• General Purpose SSD

• Provisioned IOPS SSD

• Magnetic

Scope of DB instances

DB instances are provisioned in Availability Zones closer to our client/audience. An AWS Region can consist of many AZs, and we can provision our resources in any supported AZ. DB instances can be provisioned in a single availability zone, but we can spread our instances across multiple availability zones to achieve high availability and durability.

Amazon RDS deployment options

Currently, Amazon RDS supports three deployment options: single-AZ Instance, multi-AZ Instance, and multi-AZ DB Cluster. The availability of these options depends on the choice of the DB engine. We must know our workload and requirements to choose the right deployment option. In the following subsections, we’ll discuss all the available options and their usage.

Single-AZ Instance

In this option, Amazon RDS launches a DB instance in a single availability zone in a selected region. All the applications deployed in the same or different AZs across the region make all the write and read requests on the same DB instance. The following diagram can better show the Single-AZ instance deployment.

Because there is no secondary DB instance, if the AZ in which the primary DB instance is launched goes down, all the applications will go down until the AZ is recovered. There won’t be automatic failover if some failure happens on the database instance side. The recovery point objective (RPO) is generally around 5 minutes and can vary based on the underlying architecture. However, the recovery time objective (RTO) can vary from a few minutes to hours.

Multi-AZ instance

Multi-AZ instance deployment launches two DB instances in two different AZs. The first is called a primary instance, and the second is a standby instance. Like the Single-AZ instance, the primary instance entertains all the read and write operations, and the data is replicated synchronously to the secondary instance. The illustration below depicts the Multi-AZ instance deployment scenario:

When the failure happens, the failover process takes place, promoting the secondary instance to the primary instance role. The failover process normally takes 1–2 minutes, and the RPO is zero because the data was backing up synchronously.

Note: Multi-AZ instance is a good option for the production environment where High Availability and automatic failover are required. The secondary instance can’t be used for entertaining the read requests.

Multi-AZ DB cluster

This deployment option creates a DB cluster with one primary instance and two readable instances in different AZs. Data is replicated from the primary to the readable standby instances in a semi-synchronized way that if any of the standby instances acknowledges, the data change will be committed. The primary instance can take both read and write requests, but we can route all the read-only traffic to the standby instances to minimize the workload on the primary instance. The illustration below depicts the Multi-AZ cluster deployment scenario:

When a failure occurs in this architecture, Amazon RDS automatically fails over to a reader DB instance in another AZ. The failover process normally takes up to 35 seconds, but it can take longer depending on the outstanding transactions of the failed writer instance.

Note: Multi-AZ cluster deployment is only available for MySQL and PostgreSQL.