AWS Solution Architect Associate (SAAC02) Review Material – RDS

General

• A managed Relational Data Service (RDS)
• Supports the following databases:
  • MySQL
  • MariaDB
  • PostgreSQL
  • SQL Server
  • Oracle
  • Aurora
  • Aurora Serverless
• The following does NOT apply to Aurora Serverless:
  • All has to provision a host instance to run the database. However, user will have no access to the instance.
  • The host will have a corresponding ENI so the database has to be placed in an subnet, AZ and VPC.
  • When provisioning the database, users has to:
    • select the instance class/size
    • select the storage type/size, except for Aurora because it does not require to provision a storage.
  • Storage can now be autoscaled (except for Aurora)
  • Backup is enabled by default. Backup retention can be from 0 – 35 days. Default to 7 days.
  • Automated backups are limited to a single AWS Region while manual snapshots and Read Replicas are supported across multiple Regions
  • Encryption is enabled by default.
  • Can enable enhanced monitoring – metrics in real time for the operating system (OS) that the DB instance runs on
  • Can enable deletion protection.

Read Replicas

• Read Replicas are copies of the Master. Replication is asynchronous.
• Support read connections. However, clients must be aware it is only eventually consistent.
• Aurora Serverless does not have Read Replicas.
• Aurora’s maximum number of replicas is 15; the rest is 5.
• Can be placed on the same AZ, across AZ or across regions.
• There’s a fee when replicating across regions.
• Can become a Master but promotion needs to be done manually. So if the Master fails, Replicas do not become a Master automatically.
• Used for scaling.

Multi-AZ

• Creates copies of the Master database synchronously to a Standby database.
• Non-Aurora: Only one is master. The copies do not support read or write connections.
• Aurora: Supports multi-master
• Automatically promoted to Master when the Master fails.
• Used for high availability.
• The number of copies will depend on the number of subnets in the Subnet Group.

In an Amazon RDS Multi-AZ deployment, Amazon RDS automatically creates a primary database (DB) instance and synchronously replicates the data to an instance in a different AZ. When it detects a failure, Amazon RDS automatically fails over to a standby instance without manual intervention.

Multi-AZ DB instance – a primary DB instance with one standby (no read access) DB instance

Multi-AZ DB cluster – three (3) DB instances in a different Availability Zone. It has one primary DB instance and two readable standby DB instances. 

Comparison Table

Amazon RDS Single-AZ or Amazon RDS Multi-AZ with one standby or Amazon RDS Multi-AZ with two readable standbys

Feature	Single-AZ	Multi-AZ with one standby	Multi-AZ with two readable standbys
Available engines	Amazon RDS for PostgreSQLAmazon RDS for MySQLAmazon RDS for MariaDBAmazon RDS for SQL ServerAmazon RDS for OracleAmazon RDS for Db2	Amazon RDS for PostgreSQLAmazon RDS for MySQLAmazon RDS for MariaDBAmazon RDS for SQL ServerAmazon RDS for OracleAmazon RDS for Db2	Amazon RDS for PostgreSQLAmazon RDS for MySQL
Additional Read capacity	None: the read capacity is limited to your primary	None: Your standby DB instance is only a passive failover target for high availability	Two standby DB instances act as failover targets and serve read traffic. Read capacity is determined by the overhead of write transactions from the primary·
Lower latency (higher throughput) for transaction commits			Up to 2x faster transaction commits compared to Amazon RDS Multi-AZ with one standby
Automatic failover duration	Not available: a user, a user-initiated point-in-time-restore operation will be required.This operation can take several hours to completeAny data updates that occurred after the latest restorable time (typically within the last 5 minutes) will not be available	A new primary is available to serve your new workload in as quickly as 60 secondsFailover time is independent of write throughput	A new primary is available to serve your new workload in typically under 35 secondsFailover time depends on length of replica lag
Minor version upgrades downtime	When using Automatic Minor Version Upgrades, minor version upgrade downtime occurs during the Amazon RDS 30-minute maintenance window	When using Automatic Minor Version Upgrades, minor version upgrade downtime occurs during the Amazon RDS 30-minute maintenance window	Typically under 1 second when customers add an open source or Amazon RDS Proxy to their deploymentTypically under 35 seconds with Multi-AZ with two readable standbys alone
Higher resiliency to AZ outage	None: in the event of an AZ failure, your risk data loss and hours of failover time	In the event of an AZ failure, your workload will automatically failover to the up-to-date standby	In the event of a failure, one of the two remaining standbys will takeover and serve the workload (writes) from the primary
Lower jitter for transaction commits	No optimization for jitter	Access to Dedicated Log Volumes	Uses local storage for transactional logs to reduce jitter

Security

• At Rest Encryption:
  • Must be set upon database creation.
  • If the Master is not encrypted, the replicas and their snapshots are also not encrypted.
  • Can’t restore the unencrypted backup to an encrypted database.
  • But you can encrypt an unencrypted snapshot and use that to restore to an encrypted database.
  • Use KMS to store encryption keys.
  • If you copy a snapshot from one region to another you must use that region’s KMS key.
• In-Flight Encryption
  • Use SSL/TLS to encrypt connections to databases. However, each database has its own process of implementing an SSL/TLS connection.
  • PostgreSQL and MySQL can enforce SSL/TLS connection.
• IAM-based:
  • Log in to the database using a token, not a username/password.
  • Only available in PostgreSQL, MySQL and MariaDB
  • To use this feature, the resource with the given role must call an API to get a temporary token (which expires in 15 mins).
  • Then it will use that token to log in to the database.

Aurora

• MySQL and PostgreSQL compatible. It means any clients using these databases’ APIs will work on Aurora.
• 5x faster than MySQL and 3x faster than PostgreSQL
• Storage does not have to be provisioned. It will scale automatically by 10GB increment up to 128TB.
• Faster failover.
• Can have 15 replicas. Can set up autoscaling on Read Replicas.
• Read Replicas can be set up across regions.
• Global Setup
  • 1 Primary region
  • Up to 5 secondary regions. Each region can have 16 Read Replicas.
  • Any region can be promoted to Primary when disaster strikes in the Primary region.
• 6 copies of data across AZ.
  • Only requires 4 copies to write.
  • Only requires 3 copies to read.
• Endpoints:
  • Writer endpoints for writing.
  • Reader endpoints for reading. Distributes reads to all replicas.
  • Custom endpoints to point to selected Read Replicas.
• The standard setup is to have only one writer node. But can be set up for multi-master i.e. multiple writer nodes
• Autoscaling:
  • Add more replicas

Aurora Serverless

• Instances are automatically created and auto-scaled. No need to provision instances and storage.
• Pay per second
• Good for the unpredictable and intermittent workload.