let's think back to Amazon RDS 🤔

RDS stands for Relational Database Service. It's a managed DB service for DB use SQL as a query language. It's allows you to create databases in the cloud that are managed by AWS.

Advantages over using RDS versus deploying DB on EC2:

AS we already know that RDS is a managed service. Automated provisioning, OS patching. Continuous back and restore to specific timestamp(Point in Time Restore). Read replicas for improved read performance. Multi AZ setup for DR( Disaster Recovery). Monitoring dashboards. Maintenance windows for upgrades. Storage backed by EBS(gp2 or io1). Scaling capability (vertical and horizontal). BUT we cannot SSH into EC2 instance.

RDS - Storage Auto Scaling:⚓️

When RDS detects you are running out of free database storage, it scales automatically. Help you increase storage on your RDS DB instance dynamically but avoid manually scaling your database. Actually you have to set Maximum StorageThreshold (maximum limit for DB storage). RDS is useful for applications with unpredictable workloads. Support all RDS database engines(PostgreSQL, MariaDB, MYSQL, SQL server,Oracle). Automatically modify storage if free storage is less then 10% of allocated storage. Low-storage lasts at least 5 minutes or 6 hours have passed since last modification.

RDS Read Replicas vs Multi AZ 🏄🏿‍♂️

RDS-Read Replicas for read scalability

• Up to 15 Read Replicas

• Within AZ, Cross AZ or Cross Region

• Replication is ASYNC, so reads are eventually consistent

• Replicas can be promoted to their own DB

• Applications must update the connection string to leverage read replicas

Use Case:

Let’s assume you have a production database that is taking on normal load. You want to run a reporting application to run some analytics and you create a Read Replica to run the new workload there. The production application is unaffected as Read Replicas are used for SELECT (=read) only kind of statements (not INSERT, UPDATE, DELETE).

Network Cost:

In AWS there is network cost when data goes one AZ to another. In spite of that for RDS Read Replicas within the same region, you don’t pay that fee.

RDS Multi AZ (Disaster Recovery):

A SYNC replication. One DNS name – automatic app failover to standby. Increase availability. Failover in case of loss of AZ, loss of network, instance or storage failure. No manual intervention in apps. Not used for scaling. Note: The Read Replicas be setup as Multi AZ for Disaster Recovery (DR)

RDS – From Single-AZ to Multi-AZ:

1-Zero downtime operation (no need to stop the DB)

2-Just click on “modify” for the database

3-The following happens internally:

• A snapshot is taken

• A new DB is restored from the snapshot in a new AZ

• Synchronization is established between the two databases

RDS Multi AZ – Failover Conditions:

An Availability Zone outage or a manual failover of the DB instance was initiated using Reboot with failover. The primary DB Instance

• Failed

• OS is undergoing software patching

• Unreachable due to loss of network connectivity

• Modified (e.g., DB instance type changed)

• Busy and unresponsive

• Underlying storage failure

RDS Proxy for AWS Lambda:

By default, your Lambda function is launched outside your own VPC (in an AWS-owned VPC). Therefore, it cannot access resources in your VPC (RDS, Elastic Cache, internal ELB….). You must define the VPC ID, the Subnets and the Security Groups. Lambda will create an ENI ( Elastic Network Interface) in your subnets. AWSLambdaVPCAccessExecutionRole is created for ENI.

• When using Lambda function with RDS, it opens and maintains a database connection.

• This can result in a “TooManyConnections” exception

• With RDS Proxy, you no longer need code that handles cleaning up idle connections and managing connection pools

• Supports IAM authentication or DB authentication, auto-scaling

• The Lambda function must have connectivity to the proxy (public proxy => public Lambda, private proxy => Lambda in VPC)

RDS Parameters Groups:

You can configure the DB engine using Parameter Groups. Dynamic parameters are applied immediately however, Static parameters are applied after instance reboot. You can also modify parameter group associated with a DB (must reboot). You can also see documentation for list of parameters for a DB technology.

Must-Know parameters:

• PostgreSQL/SQL Server: rds.force_ssl=1=> force SSL connections

• MySQL/Maria: require_secure_transport=1 => force SSL connections

RDS- Backups and Snapshots:

Backups

• Backups are “continuous” and allow point in time recovery

• Backups happen during maintenance windows

• When you delete a DB instance, you can retention period you set between 0 and 35 days

• To disable backups, set retention period to 0

Snapshots

• Snapshots takes IO operations and stop the database from seconds to minutes

• Snapshots taken on Multi AZ DB don’t impact the matter-just the standby

• Snapshots are incremental after the first snapshot (which is full)

• You can copy and share DB snapshots

• A good point manual snapshots don’t expire

• You can take a “final snapshots” when you delete your DB

Note: Restoring from Automated Backups or Snapshots create a new DB instance

RDS Snapshots Sharing:

As we know, manual snapshots can be shared with AWS accounts, however, automated snapshots can not be shared, we need to copy first. You can only share unencrypted snapshots and snapshots encrypted with a customer managed key. If you share an encrypted snapshots, you must also share any customer managed keys used to encrypt them.

RDS Events & Event Subscriptions:

• RDS keeps record of eventsrelated to -DB instances, Snapshots, Parameter groups, security groups etc, for instance DB stats changed from pending to running

• RDS Event Subscriptions -Subscribe to events to be notified when an event occurs using SNS. Specify the Event Source (instances, SGs,…) and Event Category ( creation, failover,….)

• RDS delivers events to Event Bridge

RDS Database logs File:

Considering, your RDS database instance has some logs. For example, general logs, audit logs, error logs, slow query logs that kind of things. So, you can send these logs into CloudWatchLogs, and the you can apply a metric filter on top of CloudWatch Logs. Foe example, you can have a look at the Error Keyword, and in case it happens too many times or too often, then you can set up a CloudWatch Alarm on top of it. So, it allows you to do some log alerting. And then this CloudWatch Alarm can send an alert, for example, to an SNS topic, and then this SNS topic can send a notification to the database admin. So, this allow you to do some more alerting and some more eventing on top of your RDS database, based, this time, not on the database events, but on the logs themselves.

RDS & CloudWatch:

CloudWatch metrics associated with RDS ( gathered from the hyperisor):

• Database Connections

• SwapUsage

• ReadOPS/WriteIOPS

• ReadLatency/WriteLatency

• ReadThroughPut/WriteThroughPut

• DiskQueueDepth

• FreeStorageSpace

Enhanced Monitoring (gathered from an agent on the DB instance):

Useful when you need to see how different processes or threads use the CPU. You can access to over 50 new CPU, memory, file system, and disk I/O metrics

RDS Performance insights:⛹🏿‍♀️

Visualize your database performance and analyse any issues that affect it. With the performance insights dashboard, you can visualize the dashbase load and filter the load:

• By Waits=> find the resource that is the bottleneck ( CPU, IO, Lock, etc….)

• By SQL statements=> find the SQL statement that is problem

• By Hosts=> find the server that is using the most our DB

• By Users=> find the user that is using the most our DB

• DB Load= the number of active sessions for the DB

• You can view the SQL queries that are putting load on your database

In conclusion, I hope this overview of “AWS RDS DB has provided a refreshing perspective." ⛳️