What Is Amazon RDS? Relational Databases in Plain English
Amazon RDS is a database server that AWS runs for you: you pick an engine — MySQL, PostgreSQL, and four others — AWS installs it on a machine you will never see, keeps it patched, backed up, and running, and hands you one thing: an address to connect to. Here is the part that surprises everyone the first time: you cannot log into the server. Ever. There is no SSH key, no desktop, no file system you can browse. That is not a missing feature — it is the entire product.
Jake spent a whole evening once looking for the SSH key to his new database server. He checked the console twice, re-read the creation wizard, and finally typed the question into a search bar feeling a little embarrassed. He shouldn't have — the console never actually tells you, in plain words, that the door he was looking for doesn't exist. The design hides its biggest idea. So let's say it plainly, the way the wizard should have.
What Amazon RDS actually is — and the server you'll never see
RDS stands for Relational Database Service. Under the hood it is genuinely a server — a machine with CPU and memory (an instance class, like EC2's), attached to storage volumes (EBS, the same block storage we covered earlier). If you have read the EC2 post, you already understand 70% of RDS: it is an EC2-style machine with a database pre-installed — and with the operating system permanently locked away from you.
What AWS does with that locked door is the value: automatic patching of the database engine, automated daily backups you can restore from any point in the last 1 to 35 days, failure detection, optional standby copies in a second data center, and monitoring — the unglamorous 2 a.m. work that database administrators used to be paid to lose sleep over. In plain English: RDS is a database with the babysitting included, and the babysitting is what you are paying for.
What you get instead of a login is an endpoint — an address like mydb.abc123.us-east-1.rds.amazonaws.com on a port (3306 for MySQL, 5432 for PostgreSQL). Your application connects to that address with a database username and password, exactly as it would to any database anywhere. The application cannot tell the difference. Only your on-call schedule can.
RDS vs. a database on EC2: what the babysitting buys you
You could absolutely install MySQL on a plain EC2 instance yourself. It is even a little cheaper. Here is the honest comparison:
| Job | Database on EC2 (you) | Amazon RDS (AWS) |
|---|---|---|
| Install & configure the engine | You, an afternoon | Done in the wizard |
| Security patches for the engine | You, forever, monthly | Automatic (maintenance window) |
| Backups that actually restore | You script it, you test it | Automatic, point-in-time, 1–35 days |
| Server dies at 2 a.m. | Your phone rings | Multi-AZ fails over by itself |
| OS access (SSH) | Full control | None — by design |
| Odd engine plugins/versions | Anything you want | Only what RDS supports |
The last two rows are the honest trade. If you need an exotic PostgreSQL extension or root access to tune the OS, RDS will frustrate you — that control is exactly what it took away. For the other 95% of projects, the left column is a part-time job nobody wanted.
The six database engines RDS runs — MySQL to Db2
RDS is not one database; it is a service that runs your choice of six engines: MySQL, PostgreSQL, MariaDB (a MySQL cousin), Microsoft SQL Server, Oracle, and — since late 2023 — IBM Db2. The first three are open source and cost only the AWS resources. SQL Server, Oracle, and Db2 carry commercial licensing on top, either bundled into the hourly price or brought from your own agreement.
For learning and for most new projects, the practical shortlist is two: MySQL if the tutorials you follow use it, PostgreSQL if you want the engine most modern applications are choosing. You cannot go badly wrong with either, and the RDS experience around them is identical.
What is Amazon Aurora — and is it RDS?
Inside the RDS console you will meet a seventh option called Aurora, and it causes endless confusion, so here is the plain version: Aurora is AWS's own database engine, built in-house, that speaks MySQL or PostgreSQL — your application connects to it exactly as if it were one of them. Underneath, AWS redesigned the storage layer: an Aurora database's storage grows by itself as your data grows (up to 128 TiB) and copies your data six ways across three data centers automatically.
It is managed through RDS, so yes — it lives under the RDS umbrella. But it is priced differently, behaves differently in exams, and is genuinely a different animal. The one-line rule: start on ordinary RDS MySQL or PostgreSQL; move to Aurora when your scale or uptime needs start justifying its price. Beginners choosing Aurora on day one are usually paying extra to solve problems they don't have yet.
Launching your first RDS database — the honest walkthrough
The console offers two paths: Easy create, which hides most decisions, and Standard create, which shows you every knob. Use Standard once, even for a toy — the knobs are the education. The choices that actually matter, in the order the wizard asks:
Template: pick Free tier (or Dev/Test on a newer account) — this one dropdown pre-sizes everything cheap and switches Multi-AZ off. Credentials: you are creating the master database user here; store the password properly (or let AWS keep it in Secrets Manager — a few dollars a month, but nothing to leak). Instance class: db.t4g.micro — more on classes below. Storage: 20 GB gp3 and tick storage autoscaling; that checkbox is the difference between "disk filled overnight" being a non-event or an outage. Connectivity: the wizard defaults to Public access: No — correct for real apps, but if you plan to connect from your laptop for learning, you will need either Yes-plus-a-tight-security-group or an EC2 machine inside the same VPC to hop through. Decide now; changing it later means modifying the instance. Then Create, and watch the status walk from Creating through Backing up to Available.
While it spins up, open the Connectivity & security tab — the endpoint is already printed there, waiting.
RDS instance classes in plain English: db.t, db.m, db.r
The class names look like airline codes and decode in one sentence each. db.t classes (t3, t4g) are burstable — small, cheap, and fine for anything that mostly sits idle, which is every learning database and most small apps; the "g" in t4g means AWS's own Graviton ARM chips, slightly cheaper for the same work. db.m classes are general purpose — steady CPU for steady production traffic. db.r classes are memory-optimized — databases love RAM (that is where indexes and caches live), so when a production database slows down, the answer is more often db.r than more CPU. The honest ladder: learn on t4g.micro, launch real products on m-class, reach for r-class when your working set outgrows memory.
RDS security in plain English: encryption, TLS, and the checkbox you cannot add later
Three layers, one warning. Encryption at rest: a single checkbox at creation encrypts the storage, the backups, and the snapshots with a KMS key — and here is the warning: it cannot be switched on later. An unencrypted instance stays unencrypted; the fix afterward is snapshot → copy-with-encryption → restore, a full migration. Tick it at birth; it costs nothing and is invisible in daily use. Encryption in transit: every engine supports TLS connections — your connection string decides, so use it, especially over public access. Who may even knock: the security group (network-level, covered above) plus optional IAM database authentication, which lets applications log in with short-lived AWS credentials instead of a password baked into config files — the same identity story we told in the IAM post, extended to the database door.
Maintenance windows and parameter groups — the two knobs people find too late
Two settings quietly govern your instance's behavior. The maintenance window is the weekly slot where AWS applies patches — set it deliberately (Sunday 3 a.m. in your users' timezone, not the default random slot), because minor-version upgrades can mean a short restart. The parameter group is the engine's configuration file, managed as an AWS object since you have no file system to edit — timeouts, character sets, max_connections if you must. The default group is locked; to change anything you clone it, edit the clone, attach it. Most people meet parameter groups for the first time at 1 a.m. while chasing a setting; now you have met them at a reasonable hour instead.
When NOT to use RDS — the honest section
RDS is the wrong tool when the thing you need is exactly what it removed. You need root on the box or an exotic engine build or an extension RDS does not ship — self-manage on EC2. Your workload is caching at microsecond speeds — that is ElastiCache's job, not a relational database's. You are running heavy analytics over billions of rows — that is warehouse territory (Redshift), and forcing it through RDS just buys you a bigger instance bill. And a static blog with ten visitors a day does not need a $12/month database humming beside it — flat files and SQLite have carried bigger sites than that. The mark of actually understanding a service is knowing where it ends.
RDS vs. DynamoDB: which database, when
We covered DynamoDB — AWS's serverless NoSQL database — earlier in this series, and the two are the classic fork in the road:
| Amazon RDS | Amazon DynamoDB | |
|---|---|---|
| Data shape | Tables with relationships, JOINs, SQL | Key-value lookups, no JOINs |
| A server exists? | Yes — you size it and pay hourly | No — serverless, pay per request |
| Idle cost | Runs (and bills) 24/7 | Can be nearly $0 when idle |
| Typical home | Business apps, anything with SQL, WordPress, reporting | Shopping carts, sessions, game state, serverless apps |
The honest rule of thumb: if you find yourself needing JOINs and ad-hoc queries, you want RDS. If you need fast lookups by a key at any scale, you want DynamoDB. Plenty of real systems use both — RDS for the books, DynamoDB for the traffic.
What Amazon RDS costs — and the Free Tier catch
Three meters run at once, and knowing them is most of AWS billing sanity:
1. The instance, per hour. The smallest sensible class, db.t4g.micro, runs at roughly $0.016/hour in us-east-1 at the time of writing — about $12 a month if it runs continuously. Sizes go up from there fast: a mid-size production instance is hundreds per month.
2. The storage, per GB-month. Around $0.115 per GB-month for general purpose (gp3) storage in us-east-1 — a 20 GB learning database adds about $2.30/month.
3. Multi-AZ doubles the instance meter. The standby copy in a second Availability Zone is a full second instance. Worth every cent in production; pure waste on a study database.
The Free Tier catch, 2025 edition: the old promise you will still see in tutorials — 750 hours of db.t2/t3/t4g.micro free per month for 12 months — applies only to AWS accounts created before mid-July 2025. Newer accounts get a credits-based Free Tier instead (a sign-up credit pot rather than per-service free hours). If your account is new, treat RDS as costing real money from hour one and set the budget alarm from the billing post before you click Create.
And the trap that catches almost everyone: you can stop an RDS instance to pause the hourly charge — but a stopped RDS instance starts itself again after seven days. That is documented behavior, not a bug: AWS restarts it so its patching doesn't fall behind. Ethan's version of this story involved a "stopped" study database, a two-week vacation, and a bill that had quietly resumed counting on day eight. The design assumes you'll come back soon; the vacation didn't. If you are done with a database for more than a week, don't stop it — snapshot it and delete it. Restoring from the snapshot later recreates it whole, and a snapshot costs cents.
Multi-AZ, read replicas, and backups — the three copies, in plain English
RDS offers three different kinds of "another copy of my database," and exams love to blur them, so here they are unblurred:
Multi-AZ is for surviving failure: a synchronized standby in a second Availability Zone that takes over automatically — usually within a minute or two — if the primary dies. You can't read from it; it exists to be ready.
Read replicas are for sharing load: extra copies (same region or another) that your app can read from, updated asynchronously — so they can lag seconds behind. A replica can be promoted to a standalone database, which also makes it a rough disaster-recovery tool.
Automated backups are for undoing mistakes: point-in-time restore to any moment in your retention window (1–35 days), plus manual snapshots you keep as long as you like. Note the fine print that surprises people: restoring never overwrites your database — it always creates a new instance with a new endpoint.
One sentence each, for the exam and for life: Multi-AZ survives outages, replicas absorb readers, backups undo mistakes. None substitutes for the others.
The 1 a.m. RDS failure modes — connection timeouts, storage full, sudden slowness
The series tradition (S3 got its own 1 a.m. errors post) — the three ways RDS actually bites beginners:
"Connection timed out" from your app or laptop. Ninety percent of the time this is not the database — it is the security group. A new RDS instance defaults to Publicly accessible: No and a security group that admits nobody. Fix: allow inbound on the engine's port (3306 MySQL / 5432 PostgreSQL) from your app's security group — not from 0.0.0.0/0; a database open to the whole internet is how breach stories start. The mechanics are the same dance as in our IAM and EC2 posts: nothing in AWS is reachable until something explicitly allows it.
"Too many connections." RDS derives the connection limit from instance memory — a t4g.micro allows dozens, not thousands. Serverless apps (hello, Lambda) are the classic culprit, opening a connection per invocation. The grown-up fix is RDS Proxy or connection pooling; the honest student fix is closing connections properly.
Storage full. A database that runs out of disk stops accepting writes and can wedge badly. Turn on storage autoscaling at creation — it's a checkbox — and this failure mode simply never visits you.
Where RDS sits on the AWS certification exams
Cloud Practitioner wants the concept: managed service, you trade OS control for operations AWS handles. Solutions Architect Associate lives in the previous two sections — Multi-AZ vs. read replicas vs. backups is close to a guaranteed question, usually dressed as a scenario ("the application's reports are slowing down the database — what do you add?" — that's a read replica). For the ML certification track this series feeds, RDS is background scenery: know it exists, know when relational beats DynamoDB, and move on.
Try it yourself — the fifteen-minute tour
Reading about RDS is like reading about swimming. The safe tour: create a db.t4g.micro PostgreSQL instance with the Free tier / lowest-cost template, watch the status walk from Creating to Available, find your endpoint on the Connectivity tab, then — this is the important part — take a snapshot and delete it before you close the tab. The whole exercise costs a few cents if it costs anything at all.
Questions People Actually Ask
Can I SSH into an Amazon RDS instance?
No — RDS provides no operating-system access at all, by design. You interact with the database through its endpoint using normal database tools and credentials. If you need OS access, you want a self-managed database on EC2 instead.
Is Amazon RDS free?
Only conditionally. Accounts created before mid-July 2025 have the legacy 12-month Free Tier (750 hrs/month of a micro instance + 20 GB storage). Newer accounts get credits instead of free hours — for them, a db.t4g.micro costs about $12/month once credits run out.
What is the difference between RDS and Aurora?
Aurora is AWS's own MySQL/PostgreSQL-compatible engine with auto-growing storage and higher resilience, managed under the RDS umbrella but priced and built differently. Ordinary RDS runs the standard open-source or commercial engines as-is.
Does stopping an RDS instance stop the billing?
It pauses the instance-hours charge only — storage and backups still bill — and RDS automatically restarts a stopped instance after 7 days. For anything longer, snapshot and delete instead.
What does RDS stand for in AWS? (the full form)
RDS stands for Relational Database Service — Amazon's managed service for running relational database engines like MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, and Db2 without administering the underlying server.
Should I use RDS or DynamoDB?
RDS when your data is relational and you need SQL and JOINs; DynamoDB when you need key-based lookups at scale with no server to manage. Many production systems deliberately use both.