Amazon RDS Explained: How It Works and When to Use It
Amazon RDS is a managed relational database service that runs MySQL, PostgreSQL, and other SQL engines in AWS. You own the data and the schema. AWS owns everything underneath: the server, the OS patches, the backups, and the failover logic.
Amazon RDS in simple terms
Think of RDS like renting a fully managed office
Running your own database on EC2 is like buying a building. You own it, but you are responsible for the plumbing, electricity, fire alarms, and cleaning. If the boiler breaks at 2am, that is your problem.
RDS is like renting a managed office. The building management handles maintenance, repairs, and inspections. You just show up, do your work, and leave when you are done. You give up some control over the building, but you gain back a lot of time.
If you have ever run MySQL or PostgreSQL on a virtual machine, you know what that involves: installing the database, keeping the OS patched, writing backup scripts, figuring out what to do when the disk fills up, and rebuilding the server when something goes wrong. None of that work moves your application forward. It just keeps the lights on.
RDS takes that operational work away. You create a database instance, pick your engine and instance size, and connect to it using the same connection string your application already uses. AWS handles provisioning, patching, backups, and failure recovery.
This page is for developers and engineers evaluating RDS for the first time, migrating from a self-managed database, or deciding between RDS, Aurora, and DynamoDB. By the end you will know what RDS does, how it works, and whether it is the right choice for your workload.
What Amazon RDS actually does
RDS is a managed wrapper around familiar relational database engines. The supported engines are:
- MySQL: Widely used for web applications and content management systems
- PostgreSQL: Strong choice for applications needing complex queries, JSON columns, or advanced data types. See PostgreSQL on Amazon RDS for a setup guide.
- MariaDB: A drop-in MySQL-compatible alternative with open-source guarantees
- Oracle Database: Requires a licence (bring your own or on-demand pricing)
- Microsoft SQL Server: Available in Express, Web, Standard, and Enterprise editions
- Amazon Aurora: An AWS-developed engine compatible with MySQL and PostgreSQL at the protocol level, with a different underlying storage architecture
Aurora deserves a specific mention. You manage it through the RDS service, but it is a distinct product with different performance characteristics and pricing. The RDS vs Aurora comparison covers this in detail.
Engine versions change frequently. Rather than relying on a hardcoded version table, check the AWS console or documentation for currently supported versions when you create an instance.
How Amazon RDS works
When you create an RDS instance, several things happen behind the scenes:
DB instance. AWS provisions a virtual machine in the instance class you chose, installs the database engine, and starts it. You never SSH into this machine.
Storage. RDS stores data on EBS volumes. You choose the storage type (General Purpose SSD or Provisioned IOPS) and the initial size. Storage can be set to auto-scale so AWS expands it when it approaches capacity.
Endpoint. RDS gives you a DNS hostname to connect to, something like mydb.abc123.us-east-1.rds.amazonaws.com. Your application uses this in its connection string. If AWS moves the instance, the endpoint stays the same. You never deal with IP addresses directly.
Automated backups. RDS takes daily snapshots and retains transaction logs continuously, enabling point-in-time recovery to any second within your backup retention window (1 to 35 days). See RDS Backups and High Availability for the full picture.
Maintenance window. AWS applies minor version patches and OS updates during a weekly maintenance window you configure. With Multi-AZ enabled, maintenance happens with a brief failover rather than downtime. Major version upgrades must be triggered manually, since they can include breaking changes.
Multi-AZ failover. If you enable Multi-AZ, AWS runs a synchronous standby replica in a different Availability Zone. If the primary instance fails for any reason, RDS promotes the standby automatically. The endpoint DNS record updates, and your application reconnects to the same hostname.
What AWS manages vs what you manage
| AWS manages | You manage |
|---|---|
| Physical hardware and hypervisor | Database schema and table design |
| Operating system installation and patching | Query optimisation and indexing |
| Database engine minor version patching | Application connection strings and credentials |
| Automated backups and point-in-time recovery | Database users and permissions |
| Storage provisioning and auto-scaling | Major version upgrades (manually triggered) |
| Multi-AZ failover | Application-level caching strategy |
| Read replica creation | Connection pooling |
You do not get OS-level or SSH access to an RDS instance. This is intentional: it is the tradeoff that lets AWS manage patching on your behalf. If you need OS-level access to your database server, you are looking at a self-managed EC2 deployment, not RDS.
When to use Amazon RDS
RDS is a good fit when:
- Your data is relational. You have tables with relationships, and your application uses SQL joins, foreign keys, or transactions.
- You are building a standard web application. User accounts, orders, content, sessions: these are textbook relational workloads.
- You are migrating an existing database. If you already run MySQL or PostgreSQL on-premises or on EC2, moving to RDS is usually straightforward. Your application’s connection string changes; your SQL does not.
- You want managed operations. Your team does not include a dedicated database administrator, and you do not want to spend engineering time on database infrastructure.
- You need point-in-time recovery and automated backups out of the box. RDS gives you these without writing and maintaining backup scripts.
For MySQL specifically, see Running MySQL on Amazon RDS for a step-by-step setup guide.
If you are building a web application with user accounts, orders, or structured content and you are not sure which AWS database to pick, start with RDS. It gives you SQL, automated backups, and managed operations out of the box. You can migrate to Aurora later if your performance requirements outgrow it.
When not to use Amazon RDS
RDS is not the right answer for every database workload:
- High-scale key-value or document access patterns. If your application reads and writes items by a single key at very high throughput, DynamoDB will outperform RDS and cost less at scale. Relational databases are not designed for this access pattern.
- You need higher availability or throughput than standard RDS provides. Aurora offers a different storage architecture with faster replication, better read scaling, and higher availability SLAs. Evaluate Aurora before assuming standard RDS is sufficient for high-demand workloads.
- You need OS-level or database-level control. If your workload requires a custom PostgreSQL extension that RDS does not support, or you need to tune kernel parameters, you may need a self-managed EC2 database. This is rare and comes with significant operational overhead.
- Analytical or data warehouse workloads. RDS is an OLTP database. If you are running large aggregation queries across hundreds of millions of rows, consider Redshift or Athena instead.
When you are unsure which service fits your workload, Choosing the Right AWS Storage Service walks through the decision systematically.
The most common mistake here is forcing relational data into DynamoDB because “NoSQL is faster.” DynamoDB is faster for the right access patterns. For workloads that need joins, transactions, or complex queries, RDS will be simpler to build with and easier to reason about.
Amazon RDS vs running your own database on EC2
The EC2 option gives you more control. The RDS option gives you dramatically less operational work. That is the core trade-off.
| Factor | RDS | Self-managed on EC2 |
|---|---|---|
| Operational overhead | Low: AWS handles patching, backups, failover | High: you handle everything |
| OS-level access | Not available | Full root access |
| Custom extensions | Limited to AWS-supported extensions | Any extension you can compile and install |
| Cost | Higher per-unit price, but no staff time for ops | Cheaper per unit, but add operational overhead |
| High availability | Multi-AZ is a single checkbox | Build, test, and maintain your own replication and failover |
| Automated backups | Included and tested by AWS | You write and maintain backup scripts |
For most teams, RDS is the right choice. The case for self-managed EC2 is narrow: you have a specific extension RDS does not support, genuinely unusual performance requirements, or a dedicated database administrator who manages infrastructure full-time. The operational burden of self-managed databases is consistently underestimated.
Amazon RDS vs Aurora vs DynamoDB
These three services are often confused because they all involve storing data in AWS.
RDS is a managed relational database. It runs standard MySQL, PostgreSQL, and other engines with minimal changes to how you use them. Good default choice for teams moving a relational workload to AWS.
Aurora is also a managed relational database, accessible through the RDS service, but built on a different storage architecture. Aurora Serverless can scale to zero when idle. Standard Aurora generally offers better performance and availability than RDS at a higher price. Choose Aurora when you need higher throughput or stricter availability requirements than standard RDS can provide.
DynamoDB is a fully managed NoSQL database optimised for key-value and document access patterns at any scale. There is no SQL, no joins, and no schema migrations. It is a fundamentally different tool for fundamentally different access patterns.
If your application uses SQL and you are not sure which to pick, start with RDS. Move to Aurora when you hit performance or availability limits. Move to DynamoDB only when your access patterns are key-value or document-oriented.
For the full decision guide, see RDS vs Aurora and RDS vs DynamoDB.
Backups, Multi-AZ, and read replicas
These three features are related but solve different problems. Beginners often conflate them.
Automated backups are about recovery from data corruption or accidental deletion. RDS takes a daily snapshot of your instance and retains transaction logs, allowing point-in-time recovery to any second within your retention window. This protects you if a bad deployment drops a table or an application bug corrupts rows.
Multi-AZ is about availability. It runs a synchronous standby replica in a different Availability Zone. If the primary fails, RDS fails over automatically, typically within 60 to 120 seconds. Multi-AZ does not give you a performance benefit for reads: the standby is not accessible for queries. It is purely a failover target.
Read replicas are about read scale-out. A read replica is an asynchronous copy of your database that accepts SELECT queries. If your application is read-heavy, distributing reads across replicas reduces load on the primary. Promoting a read replica to primary is a manual process, so read replicas are not a substitute for Multi-AZ failover.
Enable both automated backups and Multi-AZ from day one. Read replicas are an optimisation you add when read load becomes a measurable problem. Do not conflate the two: backups protect your data, Multi-AZ protects your availability, and read replicas help your throughput.
See RDS Backups and High Availability for configuration details on all three.
Security basics for RDS
The most important security principle for RDS is straightforward: your database should not be reachable from the internet.
Use private subnets. Place your RDS instance in a private subnet with no route to an internet gateway. Only resources inside your VPC (application servers, Lambda functions, bastion hosts) should be able to reach the database. For background on subnet types, see Subnets in AWS: Public, Private, and Isolated.
Use security groups. The RDS instance’s security group should allow inbound traffic only on the database port (3306 for MySQL, 5432 for PostgreSQL) and only from the security groups attached to your application servers. Not from 0.0.0.0/0. See Security Groups in AWS Explained for how to configure this correctly.
Disable public accessibility. When creating an RDS instance, the --no-publicly-accessible flag (or the equivalent console setting) ensures AWS does not assign a public IP to the instance. In production, this should always be disabled.
Connect from inside the VPC. Your application servers connect to the RDS endpoint over private IP addresses within the VPC. They never need a public route to reach the database. See Connecting to Amazon RDS Securely for the four connection patterns and how to configure them. For background on private vs public addresses, see Private vs Public IP Addresses in AWS.
Rotate credentials. Use AWS Secrets Manager or IAM database authentication rather than hardcoding database passwords in application configuration or environment variables.
Setting —publicly-accessible on an RDS instance exposes your database port to the internet. Even with a strong password, this significantly increases your attack surface. Place RDS in a private subnet and access it from within your VPC.
Cost factors and sizing basics
RDS costs are driven by four things: instance class, storage, Multi-AZ, and backups.
Instance class is usually the largest cost driver. RDS uses instance classes similar to EC2:
- db.t3 / db.t4g: Burstable performance. Inexpensive and appropriate for development and low-traffic environments. These instances rely on CPU burst credits: sustained high CPU drains the credit balance and throttles performance. Do not use t-class instances for production databases with consistent load.
- db.m6i / db.m7g: General purpose, balanced CPU and memory. Appropriate default for most production workloads.
- db.r6i / db.r7g: Memory-optimised. Use when your working set is large enough that holding more of it in RAM reduces disk I/O meaningfully.
A common mistake is choosing the cheapest instance class for production to save money, then discovering under load that the instance is CPU-throttled or memory-constrained. Sizing slightly above your observed needs is cheaper than an emergency instance upgrade during an incident.
Storage costs are per GB per month. General Purpose SSD (gp2 or gp3) is appropriate for most workloads. Enable storage auto-scaling so you do not have to manually increase storage before it fills up.
Multi-AZ roughly doubles your instance cost because AWS runs two instances simultaneously. For production databases, this is almost always worth it.
Backup retention and snapshots are generally low-cost, but manual snapshots you take and forget accumulate charges. Review and delete old manual snapshots periodically. For broader cost strategies, see AWS Cost Optimisation Strategies.
Common mistakes
- Using db.t3 instances in production without monitoring burst credits. T-class instances can handle moderate loads cheaply, but they throttle when CPU burst credits drain. If your database has consistent or spiky CPU usage, monitor the burst credit balance metric and switch to an m-class instance before throttling becomes a production issue.
- Deploying production databases without Multi-AZ. A single-AZ RDS instance is a single point of failure. Hardware failures, maintenance reboots, and AZ disruptions all cause downtime on a single-AZ instance. Enable Multi-AZ for any database that affects production users.
- Setting RDS instances to publicly accessible. Exposing your database port to the internet significantly increases your attack surface. Place RDS in a private subnet, use security groups to restrict access to application servers, and disable public accessibility.
- Leaving backup retention at the default without testing restores. The default 7-day retention period is often too short for production workloads. Increase it to 14 to 35 days depending on your recovery requirements. More importantly, test your restoration procedure before you need it. Discovering that restores are broken during an incident is a painful experience.
- Confusing read replicas with Multi-AZ failover. Read replicas are for distributing read traffic, not for automatic high availability. Promoting a read replica to primary is a manual process. Multi-AZ is the feature that gives you automatic failover.
Summary
- RDS is a managed relational database service. AWS handles provisioning, patching, backups, and failover; you handle schema, queries, and major version upgrades.
- Supported engines include MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. Aurora is a separate product with different characteristics.
- Use RDS for relational workloads with SQL, joins, and transactions. Use DynamoDB for key-value or document access patterns. Use Aurora when you need higher availability or throughput than standard RDS provides.
- Place RDS instances in private subnets, restrict access with security groups, and disable public accessibility in production.
- Enable Multi-AZ for automatic failover and automated backups for point-in-time recovery. These are separate features solving different problems.
- Use db.t3/t4g for development only; db.m6i/m7g for most production workloads; db.r6i/r7g for memory-intensive databases.
Frequently asked questions
What is Amazon RDS in simple terms?
Amazon RDS is a managed relational database service. You pick a database engine (MySQL, PostgreSQL, and others), choose an instance size, and AWS handles the infrastructure: provisioning, patching, backups, and failover. You focus on your schema, queries, and data.
Is RDS the same as Aurora?
No. Aurora is a separate AWS-developed database engine that is compatible with MySQL and PostgreSQL at the protocol level, but uses a different underlying storage architecture. Aurora is generally faster and more available than standard RDS engines, but costs more. You can run Aurora through the RDS service, but they are distinct products.
When should I use RDS instead of DynamoDB?
Use RDS when your data is relational, your app relies on SQL joins and transactions, or you are migrating an existing relational database. Use DynamoDB when you have simple key-value or document access patterns, need massive scale at low latency, or do not need joins.
Do I need Multi-AZ and automated backups?
For production databases, yes to both. Multi-AZ gives you automatic failover if the primary instance fails. Automated backups give you point-in-time recovery. Both are inexpensive insurance compared to the cost of extended downtime or data loss.
Can an RDS database be publicly accessible?
Technically yes, but you should almost never do this in production. Setting an RDS instance to publicly accessible exposes your database port directly to the internet. Place RDS instances in private subnets and access them from within your VPC.