Skip to main content
Sponsor @cloudposse

Decide on RDS Technology and Architecture

Problem​

RDS offers a variety of features and deployment options. A specific RDS deployment option needs to be adopted for the application database solution. Options are not mutually exclusive and multiple types of databases can be deployed depending on your requirements.

Context​

Amazon’s RDS Relational Database Service (Amazon RDS) is a fully managed Database-as-a-Service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching and backups.

Considered Options​

There are several ways in which an RDS Cluster can be deployed.

Option 1: Amazon RDS Instances​

Amazon RDS Instances are the original version of RDS and provide simple master-slave replication with multiple read replicas and multi-AZ fail-over capabilities. RDS Instances are best suited for one-off databases (e.g. for microservices or dev environments) where performance is likely not an issue and the ability to do point-in-time restores for a database is required. Point in time recovery allows you to create an additional RDS instance (e.g. it does replace your running instance), based on the data as it existed on your instance at any specific point in time by restoring and replaying the journal to a specific point in time. This feature is not supported yet by RDS Aurora.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html

info

AWS offers push-button migration to convert existing Amazon RDS MySQL and PostgreSQL RDS instances to RDS Aurora.

An RDS Aurora Cluster can be deployed into each VPC. The Aurora DB Cluster must use a DB Subnet Group that spans at least two availability zones.

For more information, see: Creating a DB Cluster (Amazon Aurora).

https://cloudposse.atlassian.net/wiki/pages/resumedraft.action?draftId=1184661505

https://aws.amazon.com/rds/aurora/faqs/

caution

RDS Aurora does not support Point-in-time Recovery (PITR) like with RDS instances. https://aws.amazon.com/blogs/storage/point-in-time-recovery-and-continuous-backup-for-amazon-rds-with-aws-backup/

Option 3: Amazon Aurora Global Database​

Amazon RDS Aurora can be deployed as a global database, with an Aurora DB cluster existing in a designated primary AWS region, and up to 5 additional Aurora DB clusters in designated secondary AWS Regions.

The Aurora DB clusters in the secondary regions are Aurora replicas, but write forwarding can be enabled in order to forward write operations to the primary region DB cluster.

For more information, see: Getting Started with Amazon Aurora Global Databases.

caution

Major version upgrades must be performed manually (E.g. not with terraform)

Major version upgrades can contain database changes that are not backward-compatible with previous versions of the database. This functionality can cause your existing applications to stop working correctly. As a result, Amazon Aurora doesn't apply major version upgrades automatically. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.MajorVersionA transit gateway connection will be required between all regions and accounts participating in the Global Database.

https://cloudposse.atlassian.net/wiki/spaces/REFARCH/pages/1175978124

Option 4: Amazon Aurora Serverless​

Amazon Aurora is also offered as Aurora Serverless. This is an on-demand autoscaling configuration that scales automatically horizontally based on usage, and shuts down when it is not in use.

The downside to Amazon Aurora Serverless is that there is a warm-up cost that can cause connections to hang for up to 30 seconds. This is potentially mitigated using the AWS RDS proxy service.

Amazon Aurora Serverless has two releases: v1 and v2. v2 is currently a preview release. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-2.limitations.html

For more information, see: Using Amazon Aurora Serverless v1.

Known issue: https://github.com/cloudposse/terraform-aws-rds-cluster/issues/81

danger

Don't use Aurora Serverless v2 (preview) for production databases. All resources and data will be deleted when the preview ends.

Other Considerations​

RDS Engine: MySQL or Postgres​

This decision is determined based on the stack(s) of the applications being onboarded and their supported databases.

caution

aurora-postgresql database engine has no minor auto update candidates; therefore, it does not auto update on minor versions. (See Slack Explanation)

RDS Multi-AZ​

Lastly, a regular RDS instance can be deployed in a Multi-AZ configuration. A standby instance allows for Multi-AZ redundancy, and read-replicas can be used to reduce the IO load on the primary RDS instance.

This is a more cost-effective option when compared to the Amazon Aurora offerings, but it is also not as scalable.

For more information, see: High availability (Multi-AZ) for Amazon RDS.

Tenancy: Shared or Dedicated​

Once RDS is deployed, services can either use each database in a shared or dedicated tenancy model.

  1. In the shared model, multiple application databases are provisioned on one database instance (or cluster):

  • This is the most economical option and achieves greater economies of scale.

  • The downside is that one cannot automatically restore an individual database, making recoveries from human error slower and more manual.

  1. In the dedicated model, one application database is provisioned in each database instance (or cluster):

  • This creates the greatest level of isolation.

  • Each database has its own automated backup and can be restored as a point-in-time-recovery (PITR) backup (except for Amazon Aurora).

  • This is the least economical option.

Consequences​

A component for an Amazon Aurora RDS cluster will be created and provisioned in each VPC as needed.