What is Amazon RDS? A plain-English explainer
Amazon RDS (Relational Database Service) is AWS’s managed relational database service: you get a working MySQL, PostgreSQL, MariaDB, Oracle or SQL Server database without installing, patching or operating the underlying server yourself. You still design your schema, write your queries and manage your data exactly as you would with any relational database — RDS takes over the operational layer beneath that: provisioning the server, applying patches, taking backups and handling scaling as demand changes. It is the managed-service answer to a very old cloud question — do you want to run a database server yourself, or hand that operational burden to the provider and keep your attention on the data. Here is what “managed” actually buys you, which engines RDS supports, and when it is — and isn’t — the right choice.
What “managed” actually means
Running a relational database yourself, even on a virtual server like an EC2 instance, means you are responsible for installing the database engine, keeping it patched against vulnerabilities, configuring backups, monitoring for failures and handling the server-level work of scaling it up as load grows. None of that is specific to your data or your application — it is the same undifferentiated operational work almost every team running that engine has to repeat.
RDS takes that layer off your plate. AWS provisions the underlying compute and storage, applies engine patches on a schedule, runs automated backups you can restore from, and offers options for scaling and for replicating the database for higher availability. You interact with the database itself — connecting, querying, managing schemas and data — while AWS operates everything underneath it.
Which database engines RDS supports
RDS is not one database technology — it is a managed wrapper around several established relational engines: MySQL, PostgreSQL, MariaDB, Oracle Database and Microsoft SQL Server. That matters because it means adopting RDS does not force you onto an unfamiliar engine; if your team already knows PostgreSQL, RDS for PostgreSQL behaves like PostgreSQL, with the operational layer managed by AWS underneath it.
AWS also offers Amazon Aurora, its own cloud-native relational database that is compatible with the MySQL and PostgreSQL engines but built specifically for AWS’s infrastructure, generally aimed at higher performance and availability than the equivalent standard engine. Aurora sits alongside RDS in AWS’s relational database line-up rather than replacing it, and the choice between them is its own topic — this article is about RDS as the general managed-relational-database service.
When to use RDS
RDS is the natural choice whenever your application’s data genuinely fits the relational model — structured records with defined relationships between them, where you need transactions and consistency, such as customer records, orders, financial transactions or anything you would naturally describe as tables with foreign keys. If you already know you want a relational database, RDS answers the follow-up question of who operates the server underneath it.
It is a different decision from choosing whether your data belongs in a relational database at all. Some workloads — very high-scale, simple lookups, flexible or rapidly changing data shapes — fit a NoSQL database better than a relational one. Our relational-vs-nosql-databases explainer covers how to make that choice; RDS only becomes the relevant question once you have decided relational is right.
RDS versus running your own database
The alternative to RDS is installing a database engine yourself on a virtual server and operating it — patching, backups, failover and scaling all become your responsibility rather than AWS’s. That route buys you more low-level control: access to configuration options or engine versions RDS may not expose, or the ability to run an engine RDS does not support at all. Most teams building a standard application find the operational savings of RDS outweigh that extra control, which is why RDS, not self-managed databases on EC2, is the default recommendation in most AWS reference architectures.
How RDS is priced
RDS follows AWS’s general pay-for-use approach: you pay for the database capacity and storage you provision and consume, rather than a fixed licence-and-hardware cost paid upfront. The specific pricing structure varies by engine and by the options you choose, and it changes over time, so this article does not quote figures — AWS’s RDS pricing page has the current detail. The concept worth taking away is that RDS shifts the cost model from capital spend on hardware and licences to ongoing, usage-based operating cost, on top of removing the operational work itself.
Where RDS appears in certification study
RDS is core material on AWS Certified Solutions Architect – Associate, which tests when to choose a managed relational database, how to design for availability, and how it fits alongside other data services in an architecture. AWS Certified Developer – Associate covers connecting applications to RDS and working with it programmatically, and AWS Certified Data Engineer – Associate covers it as one part of a broader data-platform picture. Our /revision study library breaks that detail down lesson by lesson.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.