Days 17-18 covered storage. Today we shift into databases, starting with the relational side — RDS, which most applications lean on for their primary database, and DMS, the service that gets data into it in the first place.
Amazon RDS (Relational Database Service)
RDS is a service where you can set up, configure, maintain, and secure RDBMS (relational) databases — but here's the important distinction: RDS is not a database, it's a database *service*. You don't install MySQL or PostgreSQL yourself; you tell RDS which database engine you want, and it provisions, patches, backs up, and manages the underlying infrastructure for you.
RDS supports 7 database engines, and it's worth knowing all of them: MySQL and PostgreSQL (both open-source), MariaDB (community-driven, MySQL-compatible), Oracle and Microsoft SQL Server (commercial, licensed engines), IBM DB2, and Aurora — which is AWS's own proprietary engine, built to be compatible with MySQL and PostgreSQL but re-engineered for better performance and availability on AWS infrastructure specifically.
What "fully managed" actually means here: you connect to an RDS database instance only through client tools — a MySQL client, a PostgreSQL client, whatever fits your engine — over the standard database port. You can't RDP or SSH into the underlying instance the way you can with a self-managed database on EC2, because the platform itself is managed by AWS. That's the trade-off: you give up direct OS-level access in exchange for AWS handling patching, backups, and infrastructure maintenance for you.
A few things worth knowing beyond the basics, since these come up constantly in real deployments:
- Multi-AZ deployments give you high availability by maintaining a synchronous standby replica of your database in a different Availability Zone. If the primary fails, RDS automatically fails over to the standby — this is the database-layer equivalent of the failover concept we covered back on Day 13, just applied to a stateful database instead of a stateless web server.
- Read Replicas are a separate concept from Multi-AZ, aimed at scaling read traffic rather than availability. You can create one or more read-only copies of your database, and route read-heavy traffic (reports, analytics queries) to them instead of hammering your primary instance. Aurora specifically supports up to 15 read replicas, far more than the standard engines.
- Automated backups and snapshots — RDS can automatically take daily backups and retain transaction logs, letting you restore to any point within your retention window. You can also take manual snapshots on demand before a risky change.
- Storage autoscaling lets RDS increase your storage automatically as your data grows, instead of you having to manually resize it (similar in spirit to the EBS scaling we covered on Day 17, but handled at the database layer).
- Parameter groups and option groups let you configure database engine settings (like memory allocation or logging behavior) without needing shell access to the underlying instance — the AWS-managed way of tuning a database you can't directly log into.
- Aurora specifically deserves a mention on its own: it auto-scales storage up to 128TB, separates compute and storage for faster failover, and even offers an Aurora Serverless option that scales capacity automatically based on load rather than requiring you to pick a fixed instance size upfront.
AWS DMS (Database Migration Service)
DMS exists for one specific purpose: migrating databases into (or between) AWS, with minimal downtime. It's what you'd reach for when moving an on-premises database to RDS, or migrating between two different database engines entirely.
The mechanics involve three pieces: a source endpoint (your existing database — on-premises, EC2, another cloud, or another AWS database), a target endpoint (typically an RDS instance, though it doesn't have to be), and a replication instance — the actual compute DMS uses to read from the source and write to the target.
Two kinds of migration are worth distinguishing. A homogeneous migration moves data between the same database engine — MySQL to MySQL, for example — which is comparatively simple since the schema and data types line up directly. A heterogeneous migration moves data between different engines entirely — say, Oracle to Aurora PostgreSQL — which requires converting the schema itself, not just copying data. For that, AWS provides the Schema Conversion Tool (SCT), which translates schema objects, stored procedures, and functions from the source engine's dialect into the target engine's equivalent before DMS handles the actual data movement.
One more detail that matters a lot in practice: DMS supports continuous data replication (CDC — Change Data Capture), not just a one-time copy. This means you can keep your source database live and serving production traffic while DMS continuously replicates ongoing changes to the target, and only cut over once the target is fully caught up — minimizing downtime during the actual switch, rather than requiring a long maintenance window to migrate everything at once.
How they work together
A typical migration flow: your existing database (on-premises or elsewhere) becomes the DMS source endpoint, a DMS replication instance continuously copies data — and if needed, the Schema Conversion Tool translates the schema first — into a target RDS instance, and once replication has caught up, you cut your application over to the new RDS database with minimal downtime.
Quick Recap Questions
- Why is it accurate to say "RDS is not a database, it's a database service"?
- What's the difference between Multi-AZ and Read Replicas — what problem does each actually solve?
- What's the difference between a homogeneous and a heterogeneous migration, and why does the second one need the Schema Conversion Tool?
- Why would continuous replication (CDC) matter more than a one-time data copy for a production migration?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 20 | Database — NoSQL, Warehouse & Cache | DynamoDB, Redshift, ElastiCache |
Top comments (0)