Redundancy for AWS Database Services – Part 1: Relational DB Services

Databases are the backbone of every enterprise application architecture. Keeping them up – or at least being able to restore them in case of a crisis or significant service interruption – is crucial for every IT organization. So, what are the out-of-the-box option AWS provides for relational SQL database-as-a-service  (DBaaS) offerings?

When looking at these DBaaS offerings, engineers realize they fall into two groups: existing database engines deployed in the cloud and cloud-native DBaaS services compatible with widespread database engines but built on AWS-proprietary technology (Figure 1). AWS brands the latter as “Aurora” with the variants MySQL-compatible and PostgreSQL-compatible. The offering with major database engines comprises MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQLServer.

The configuration for the services based on existing engines is rather classical: select your VM size and the needed storage, and afterward, AWS takes over the installation and database management. In the case of MSSQL and Oracle, there is the option to go for “custom” databases, allowing engineers to customize the operating system and database settings.

For the Aurora variants, customers cannot and do not have to configure the storage. AWS handles the storage sizing and expansions for the applications. For Aurora MySQL, customers have to choose a VM size. For the Aurora-PostgreSQL option, customers have a choice. They can define the VM size or “go serverless” and benefit from transparent auto-scaling. AWS scales computing resources based on the actual database service usage in the latter case.

All variants allow enabling automatic backups when creating the database via the portal and switching on deletion protection to reduce the risk of unintended deletions of databases. What eases a service continuation or reduces the service restoration is redundancy. AWS offers the following deployment variants:

• Single Instance is, what the name indicates, just one installation or instance without any failover option. This deployment model is available for all engines and variants. It is suitable for uncritical production workloads and development and testing.
• Multi-AZ-DB Instances / Deployments is a deployment with one master and one standby instance. The standby instance runs in a different available zone and synchronously updates its data. Thus, if the availability zone with the master instance or the master instance itself crashes, there is an automatic failover without any data loss or need for human intervention. Until such an occurrence, the standby instance patiently waits for the master one to crash. This deployment model is available for nearly all RDS engines and variants but the two basic MySQL levels.
• Multi-AZ DB Cluster is similar to Muli-AZ-DB Instances but with one-and-a-half twists. This deployment model also has one master, but two instead of one failover instance in two other availability zones. The significant difference is that the failover instances are not just running idle, waiting for a disaster. They serve as read-only instances, especially helpful for processing large queries and OLAP-style analytics workloads. AWS provides this deployment model for the MySQL and PostgreSQL engine options. I would not be surprised if AWS implements and offers this option for more engines in the future.

The two multi-AZ variants have two characteristics in common. First, they both follow the synchronous replication approach. Thus, a failure of the primary instance does not cause any data loss. Second, synchronous replication requires that the failover data centers, respectively, availability zones are geographically close. Significant events such as regional blackouts can bring both down. Such scenarios require (typically asynchronous) replication to a data center in a different zone. However, for many companies, that is a luxurious scenario they would not have considered before the cloud. Multi-AZ variants with a failover instance and synchronous data replication were something many companies dreamed about, though only big enterprises or SMEs that outsourced to big IT providers had. So, it is fascinating how a data center failure today does not impact the delivery of database services in the cloud – if you configure your cloud database services correctly and pay for redundancy.