Learn how to articulate the key advantages of Relational Database Service over running their own DBMS on-premises or on EC2.
- [Narrator] AWS's Relational Database Service, or RDS, can take a lot of work off your hands when it comes to relational databases. Without RDS, deploying a database to AWS can be a rather involved process. You will provision an EC2 instance, attach storage, say using EBS, EFS, or your own do-it-yourself network storage. You will then have to install and configure the database instance yourself. Patching becomes an ongoing concern both for the database and the OS it's installed on. And if you want a read replica or standby for failover, well, your database platform may provide tools, but you're on your own to implement them.
Good news! RDS manages all of this for you. With RDS, you can select one of six different relational database platforms. Oracle, MySQL, Postgres, SQL Server, MariaDB, and Amazon's own Aurora. I'd like to take a brief aside to talk about Aurora. Amazon Aurora is AWS's proprietary database engine, and it's compatible with MySQL and Postgres and meant to outperform traditional expensive database engines. AWS advertises that Aurora provides five times the throughput of MySQL, and they're positioning Aurora to compete with the likes of Oracle and SQL Server.
Aurora is also highly available and durable, automatically replicating itself across three availability zones. The compatibility with existing engines means that Aurora is an attractive migration target for organizations moving relational databases to the cloud. Back to RDS. When you run a database in RDS, AWS handles the compute for you. You never need to remote into an instance to manage your database processes. Of course, that doesn't mean that an RDS doesn't have compute resources. Your database needs CPU and RAM to run.
With RDS, the details of the underlying compute resource are abstracted away. Under the covers, is this Postgres running on Ubuntu, Red Hat, or Amazon Linux? Who cares! As long as it responds on port 5432 when we want to connect, we don't need to know, but we do need some control over the provisioning of the compute resource, so in a similar way to EC2, RDS provides us with DB instance classes. The instance classes of RDS mirror the naming conventions for those of EC2.
You have the Standard grouping, such as the db.m4 series, the Memory Optimized grouping, such as the db.r3 series, and the Burst Capable grouping, the db.t2 series, much like the T2 EC2 instances. Platform support varies. Some database types only support some instance classes, so be sure to check AWS RDS documentation to be sure. We can convert a database instance to another database class whenever we like, but be aware that this will incur a reboot of the database, just like it does with EC2.
It's possible to reduce the outage time in a situation like this, or perhaps more critically, in the case of an unplanned outage. When you select Multi-AZ Deployment, RDS will automatically, synchronously replicate data to a standby instance of your database and a neighboring Availability Zone. Users continue to read from and write to only the primary instance, but if that one goes down, AWS will update the DNS record associated with your RDS instance, and it will resolve to the quite fresh hot standby. Some applications will still need to reconnect, but the result will be much less problematic than a full-blown outage.
AWS claims that this failover usually occurs in under two minutes. AWS uses a variety of methods to achieve this replication. It varies based on the DB platform and its available tools. Just keep in mind that no matter the platform, synchronous replication means that every time you write, you must wait for that write to replicate to the standby. If your use case can sustain the additional write latency, Multi-AZ is a very attractive failover option. One last note on Multi-AZ instances. A new feature of RDS actually requires you to avoid Multi-AZ, and that's the ability to stop RDS instances.
Until recently, you could not turn off an RDS instance. You could only terminate it. Now you can stop instances, giving you the same flexibility to control uptime and costs that we enjoy with the EC2. Another nice feature of RDS is the ability to create Read Replicas. Read Replicas are copies of your source database that are kept up-to-date as changes are made in the source. RDS Read Replicas are kept in sync using the existing asynchronous data transfer options available in MySQL, MariaDB, and Postgres, meaning those are the only DB platforms supported.
That transfer is encrypted, even when the replica is in another region, and since I mentioned it, yes, your Read Replica can be in another region, giving you great, high availability on the chance that a region goes down. So why create a Read Replica? Well, one big reason is to reduce load on transaction systems. You can point reporting tasks, and now the query only workloads to the replica, ensuring your primary system remains responsive. You can create unique indexes on the replica, if you're using MySQL to enhance its performance, without impacting the primary.
Read Replicas can be promoted to master manually in a scenario where the primary fails. And finally, Read Replicas can be cross-region, giving you additional disaster recovery assurances. One last note about Replicas. MySQL can actually be replicated to Aurora since they're compatible, so even if you don't start with Aurora, you have an easy way to take advantage of its many performance and storage benefits. Back to management, don't forget about patching. Both the underlying OS and the database engine need regular updates, some of which may be critical for security. RDS manages that, too.
We can choose a maintenance window, say one hour every Sunday at midnight, and RDS can automatically apply any OS patches and minor database-level updates that are available for our chosen platform. No downtime, unless the update requires a reboot. OS patches can be scheduled, taken immediately, or deferred, however, AWS will mark some OS update as required and will not let them be deferred indefinitely. As for patching the database engine, well, if this capability gives you pause, don't worry. AWS has considered that not all database updates are backward-compatible or safe for your data.
Auto-Patching is entirely opt in, and it doesn't extend to major releases, and it varies based on platform. Major updates to the database engine, you'll need to initiate yourself. You will want to create snapshots of your data and handle any data conversion that needs to take place. Still, Auto-Patching for minor updates can be a great time saver. RDS also gives you options as to the underlying storage of your database. Much like Instance Class, the Storage Option can be changed with minimal downtime. Magnetic is the cheapest and slowest option, only available for backward compatibility purposes.
General Purpose scales performance with storage size. Provisioned IOPS lets you pay more to specify the performance and size that you want. Finally, let's talk backup. In the same way that you can declare a maintenance window for RDS, you can declare a backup window. By default, RDS creates and keeps seven days worth of daily backups for you, but that can go up to 32. Even better, RDS can restore not only from those daily backups but by replaying transaction logs, it can restore to any point in time within the backup window down to the minute.
Be aware that anytime you restore an RDS instance, you're not restoring it in place. RDS will spawn a new RDS instance using the backup point that you request. So if you need to restore some data into your hot copy, you'll still need to either manually restore data or reconfigure apps to point to the newly restored database.
Join AWS architect Brandon Rich and learn how to configure object storage solutions and lifecycle management in Simple Storage Service (S3), a web service offered by AWS, and migrate, back up, and replicate relational data in RDS. Find out how to leverage flexible network storage with Elastic File System (EFS), and use the new AWS Glue service to move and transform data. Plus, learn how Snowball can help you transfer truckloads of data in and out of the cloud.
- What is data management?
- AWS S3 basics
- S3 bucket creation
- S3 upload and logging
- S3 event notifications
- S3 data lifecycle configuration
- Working with Amazon Elastic Block Store volumes
- Creating and mounting an EFS
- Creating an AWS RDS instance
- RDS backup and recovery
- Moving data with AWS Database Migration Service
- Moving data with Data Pipeline and Glue