Relational Database ServiceĀ – AWS Security Fundamentals – SCS-C02 Study Guide

Relational Database Service

Relational Database Service (RDS) aims to remove the tasks previously performed by a database administrator who had to be on staff but gave little to no actual value to the end product or project. These tasks include provisioning a new database, creating backups, scaling out to read replicas, patching and upgrading instances, as well as switching over to a high-availability instance when a fault occurs.

RDS streamlines the setup and installation of software and database provisioning. Using the managed RDS also allows an organization to achieve a standard set of consistency when creating and deploying a database. No custom scripts are needed to deploy, set up, or patch the database, as this is all handled in the background.

After deployment, developers and applications obtain a database endpoint that can be accessed readily and connections can be made with a client or authentication application and then queries can be sent to the database.

RDS comes in several different engine formats, including two commercial engines and three popular open-source engines. The two commercial engines supported are Oracle and Microsoft SQL Server. Both commercial engines are used in enterprises, and RDS supports access to Oracle schemas via Oracle SQL. Native tools for Microsoft SQL Server, such as SQL Server Management Studio, are also supported. In the community editions, RDS offers the ability to spin up databases using MySQL, PostgreSQL, and MariaDB. MySQL is one of the most popular community relational databases. AWS runs the community edition, defaulting to InnoDB tables, with the documentation stating that MyISAM storage does not support reliable crash recovery.

PostgreSQL is another extremely popular database with developers for its rich feature set. Postgres on RDS supports standard tools such as pgAdmin or connections via JDBC/ODBC drivers to connect to the database.

After deciding on your engine of choice, you can choose an instance type that will give you varying computing and memory power levels. There are burstable instances (T family) that, mostly, are only used for testing environments. A general (M family) and memory-optimized (R family) instance is preferred over taking your database workloads to a more productized environment.

A significant difference between RDS and the same types of engines that you would run yourself is how replicas work. Read replicas are extremely easy to provision with the click of a button, either in the same or a different Availability Zone. However, these nodes are read-only and do not enable writes. In the same context, you can make your instance highly available, replicating your data asynchronously to the copy of the primary node in another Availability Zone or region. Even if an incident occurs, your application will remain seamless for end users as the domain name used by both the master and replica node does not change. This replicated primary, however, cannot take any load off your main primary server as it cannot serve any other function (such as being a read replica) except for being a failover node. Read replicas can be promoted to a standalone database, and at that point, they can take writes but would no longer stay in sync with the previous master that they were replicating.