RDS
Amazon RDS (Relational Database Service) is a managed database service offered by AWS that simplifies the process of setting up, operating, and scaling relational databases in the cloud. It allows you to choose from various database engines such as MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server, and provides automated tasks like hardware provisioning, patching, backup, recovery, and scaling.
Important points to remember:
- You can only enable encryption for an Amazon RDS DB instance when you create it
- You can’t disable encryption on an encrypted DB instance
- You can’t have an encrypted Read Replica of an unencrypted DB instance or an unencrypted Read Replica of an encrypted DB instance
- You can’t restore an unencrypted backup or snapshot to an encrypted DB instance.
- To copy an encrypted snapshot from one region to another, you must specify the KMS key identifier of the destination region.
Underlying instance type
- There are currently over 18 instance sizes that you can choose from when resizing your RDS MySQL, PostgreSQL, MariaDB, Oracle, or Microsoft SQL Server instance.
- For Amazon Aurora, you have 5 memory-optimized instance sizes to choose from.
Behaviour
Replication
- These 2 are the most important points to remember for SysOps exam
- Multi-AZ follows synchronous replication and spans at least two Availability Zones within a single region.
- Read replicas follow asynchronous replication and can be within an Availability Zone, Cross-AZ, or Cross-Region
Source: Working with read replicas
Backup without outages
Amazon RDS creates a storage volume snapshot of your DB instance, backing up the entire DB instance and not just individual databases.
- Single-AZ DB: Creating this DB snapshot on a Single-AZ DB instance results in a brief I/O suspension that can last from a few seconds to a few minutes, depending on the size and class of your DB instance.
- Multi-AZ DB: Multi-AZ DB instances are not affected by this I/O suspension(outages) since the backup is taken on standby.
Feature
Encryption in flight
In the DB parameter groups - You can allow only SSL connections to your RDS for PostgreSQL database instance by enabling the rds.force_ssl
parameter ("0" by default) through the parameter groups page on the RDS Console or through the CLI.
Source: Amazon RDS for PostgreSQL
A root certificate that works for all regions can be downloaded from the AWS website. It is the trusted root entity and should work in most cases but might fail if your application doesn’t accept certificate chains. If your application doesn’t accept certificate chains, download the AWS Region–specific certificate from AWS. Ref: Using SSL/TLS to encrypt a connection to a DB instance
Encryption at rest
You can only enable encryption for an Amazon RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted DB snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.
TDE for Oracle
Oracle Transparent Data Encryption (TDE), a feature of the Oracle Advanced Security option available in Oracle Enterprise Edition. This feature automatically encrypts data before it is written to storage and automatically decrypts data when the data is read from storage.
In order to enable Transparent Data Encryption for your RDS, you need to
- Creating an option group and add Transparent Data Encryption (TDE) option
- Associating the option group to the DB instance
- Creating database encryption key (DEK) on the database and enable encryption on the database
Some DB engines offer additional features that make it easier to manage data and databases, and to provide additional security for your database. Amazon RDS uses option groups to enable and configure these features. An option group can specify features, called options, that are available for a particular Amazon RDS DB instance.
RDS Proxy
TL;DR - RDS Proxy as a connection pool for handling overwhelmed connections / unpredictable surges in database traffic.
Amazon RDS Proxy enhances database efficiency and scalability for applications, including modern serverless ones, by pooling and sharing connections to the database. This helps prevent memory and compute exhaustion caused by frequent opening and closing of connections.
RDS Proxy reduces failover times, integrates with AWS Secrets Manager and IAM for secure access, and efficiently manages variable workloads, allowing multiple application connections to share resources and regulating connection openings. Enabling RDS Proxy requires no code changes or additional infrastructure management, making it a seamless solution for optimizing database performance and application availability.
Enhanced Monitoring
Enhanced Monitoring for RDS provides the following OS level metrics which are free memory, active memory, swap free, processes running, file system used. It is useful when you want to see how different processes or threads on a DB instance use the CPU.
A hypervisor creates and runs virtual machines (VMs). Using a hypervisor, an instance can support multiple guest VMs by virtually sharing memory and CPU. CloudWatch gathers metrics about CPU utilization from the hypervisor for a DB instance. In contrast, Enhanced Monitoring gathers its metrics from an agent on the DB instance.
You might find differences between the CloudWatch and Enhanced Monitoring measurements, because the hypervisor layer performs a small amount of work. The differences can be greater if your DB instances use smaller instance classes. In this scenario, more virtual machines (VMs) are probably managed by the hypervisor layer on a single physical instance.
Reference:
PITR
The automated backup feature of Amazon RDS enables point-in-time recovery (PITR) of your DB instance. When automated backups are turned on for your DB Instance, Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB Instance are made).
When you initiate a point-in-time recovery, transaction logs are applied to the most appropriate daily backup in order to restore your DB instance to the specific time you requested.
Scalability
Read scalability (Horizontal scaling)
Source: Working with read replicas
Horizontal scaling means adding more instances. Instead of having one database instance, you would have two or three for example. Adding read replicas is one of the most straightforward ways of horizontal scaling. If your application only needs to scale for reading reasons, which is often the case, add a read replica and point all read applications to this database.
Another way to increase the performance by scaling horizontally is by adding an RDS proxy. This allows much more connections to the database.
Important points:
- Any updates made to the primary DB instance are asynchronously copied to the read replica.
- Writing to tables on a read replica can break the replication
- If the value for the
max_allowed_packet
parameter for a read replica is less than themax_allowed_packet
parameter for the source DB instance, replica errors occur.
Write scalability
Vertical scaling enhances the current database instance(the actual hardware). For example more memory, more CPU, or more storage. Auto Scaling allows you to scale up and down automatically, based on a policy. A policy can be based on a metric like free storage. A common example is: if there is only 10% free storage → Scale up
For write operations, horizontal scaling can be more challenging due to the need to maintain data consistency and handle conflicts across the distributed environment. In some cases, certain types of databases, such as those that support multi-master replication, can horizontally scale write operations as well, but this often comes with increased complexity.
In general, horizontal scaling is preferred for handling larger scale-out scenarios, especially when read operations dominate, while vertical scaling can be a quicker and sometimes simpler solution for improving both read and write performance up to a point. However, vertical scaling has its limits due to the physical constraints of a single machine, and it often comes with downtime during scaling operations.
Availability
Maintaince downtime
Upgrades to the database engine level require downtime. Even if your RDS DB instance uses a Multi-AZ deployment, both the primary and standby DB instances are upgraded at the same time. This causes downtime until the upgrade is complete, and the duration of the downtime varies based on the size of your DB instance.
Source: How do I minimize downtime during required Amazon RDS maintenance?
Handle failover
Source: Amazon RDS Multi-AZ Deployments
When you provision an RDS Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). It provides enhanced availability and durability for RDS database (DB) instances, making them a natural fit for production database workloads.
- Amazon RDS automatically initiates a failover to the standby, in case the primary database fails for any reason
- RDS applies OS updates by performing maintenance on the standby, then promoting the standby to primary, and finally performing maintenance on the old primary, whic
Limitations for encrypted DB instance
The following limitations exist for Amazon RDS encrypted DB instance:
- You can only enable encryption for an Amazon RDS DB instance when you create it, not after the DB instance is created. However, because you can encrypt a copy of an unencrypted DB snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.
- [important] You can't disable encryption on an encrypted DB instance.
- [important] You can't have an encrypted Read Replica of an unencrypted DB instance or an unencrypted Read Replica of an encrypted DB instance.
- [important] You can't restore an unencrypted backup or snapshot to an encrypted DB instance.
- To copy an encrypted snapshot from one region to another, you must specify the KMS key identifier of the destination region. This is because KMS encryption keys are specific to the region in which they are created in. - The source snapshot remains encrypted throughout the copy process. AWS Key Management Service uses envelope encryption to protect data during the copy process.
OS patch upgrade
On the Amazon RDS console to view if your RDS instance needs OS patching. Periodically, Amazon RDS performs maintenance on Amazon RDS resources. Maintenance most often involves updates to the DB instance's underlying operating system (OS) or database engine version. Updates to the operating system most often occur for security issues and should be done as soon as possible.
Maintenance items require that Amazon RDS take your DB instance offline for a short time. Maintenance that require a resource to be offline include scale compute operations, which generally take only a few minutes from start to finish, and required operating system or database patching. Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently (typically once every few months) and seldom requires more than a fraction of your maintenance window.
DB instances are not automatically backed up when an OS update is applied, so you should back up your DB instances before you apply an update. You can view whether a maintenance update is available for your DB instance by using the RDS console, the AWS CLI, or the Amazon RDS API. If an update is available, it is indicated by the word Available or Required in the Maintenance column for the DB instance on the Amazon RDS console.
Troubleshooting
Error when Backup retention set to 0
RDS retains backups of a DB Instance for a limited, user-specified period of time called the retention period, which by default is 7 days but can be set to up to 35 days.
There are several reasons why you may need to set the backup retention period to 0. For example, you can disable automatic backups immediately by setting the retention period to 0. If you set the value to 0 and receive a message saying that the retention period must be between 1 and 35, check to make sure you haven’t setup a read replica for the instance. Read replicas require backups for managing read replica logs, thus, you can’t set the retention period of 0.