AWS RDS: Managed Relational Database Service
If you aren't familiar with relational databases, check out our DBMS Course for a foundational understanding.
Why Choose AWS RDS Over EC2 for Databases?​
While you can run a database on an EC2 instance, using AWS RDS offers several advantages. Here's a comparison to help you understand why RDS might be a better option:
| Aspect | DB on EC2 | AWS RDS |
|---|---|---|
| Maintenance | You need to manually install, configure, and maintain the database software, including handling patches and updates. | RDS automates common administrative tasks such as backups, patch management, and database recovery. |
| Scalability | Scaling databases on EC2 instances requires manual intervention, such as adding more resources or setting up replication and clustering. | With just a few clicks, you can scale your database's compute and storage resources without downtime. |
| Backup and Recovery | Regular backups and setting up automated recovery processes must be done manually. | RDS provides automated backups and enables point-in-time recovery. |
| High Availability | Requires complex configurations for replication, failover mechanisms, and managing secondary instances. | RDS offers Multi-AZ deployments for automatic failover and enhanced availability. |
| Security Management | Security settings, including encryption, access control, and network security, must be configured manually. | RDS integrates with AWS Identity and Access Management (IAM) for access control and supports encryption at rest and in transit. |
Key Features of AWS RDS​
Automated Backups​
Imagine you run an e-commerce website with a MySQL database hosted on AWS RDS. Every night, RDS automatically backs up your database during a specified backup window. One day, a developer accidentally deletes some crucial data. Thanks to automated backups, you can restore your database to any point in time within the backup retention period, effectively recovering your data without significant downtime.
Transaction Logs​
Transaction logs capture all changes made to the database. They are recorded continuously (usually every 5 minutes) and are used to track changes since the last snapshot. AWS manages these logs, ensuring that even recent changes can be restored.
Snapshots​
Snapshots are full backups of your database instance at a specific point in time. They capture the entire state of the database, including data and schema. While similar to automated backups, there are key differences:
| Feature | Automated Backups | Manual Snapshots |
|---|---|---|
| Creation | Automatically created daily | User-initiated at any time |
| Retention | Configurable from 1 to 35 days | Retained until manually deleted |
| Includes | Daily snapshots + transaction logs | Full database snapshot |
| Management | Managed by AWS | Managed by the user (usually stored in S3) |
| Use Case | Routine backups and point-in-time recovery | Specific backup needs and archiving |
Point-in-Time Recovery (PITR)​
With PITR, you can restore your database instance to any specific time, typically up to the last five minutes before the current time.
Example:
You have an RDS MySQL database with automated backups enabled, and the backup window is set to 12 AM every night. At 3 PM, a table is accidentally deleted. Using point-in-time recovery to 2:55 PM, your database can be restored to its state just before the deletion, ensuring the data remains intact.
Replication​
As your web application grows, you may notice that read operations on your MySQL database cause performance bottlenecks. AWS RDS allows you to create read replicas of your primary instance to distribute read traffic, improving performance and response times.
Example:
Suppose you have a primary RDS instance in the us-east-1 region and users in Europe need low-latency access.
-
Create a read replica in the
eu-west-1region. -
Data is asynchronously replicated from
us-east-1toeu-west-1. -
European users can direct read queries to the replica in
eu-west-1, reducing latency and improving performance. You can use Geolocation-based DNS routing to direct users from Europe to the nearest read replica.
Multi-AZ Deployment​
For applications that require high availability and disaster recovery, you can configure your RDS database in a Multi-AZ deployment. RDS automatically provisions a synchronous standby replica in a different Availability Zone. If the primary database instance fails, RDS automatically fails over to the standby instance, ensuring minimal interruption.
AWS regions can have multiple Availability Zones (AZs). For example, the Mumbai region might have one AZ in South Mumbai and another in North Mumbai, providing geographic redundancy.