RDS vs Aurora vs Self-Managed: Choosing How to Run Your Database on AWS

Three ways to run a database on AWS, and why the choice matters

Almost every team on AWS eventually asks the same question: do we use Amazon RDS, do we pay up for Aurora, or do we run PostgreSQL or MySQL ourselves on EC2? The marketing pages make Aurora sound like a no-brainer and self-managed sound reckless. The reality is more nuanced. Each option trades money for control and operational effort in a different way, and picking wrong can cost you either a fat monthly bill or a 3am pager you were not staffed to answer.

This guide compares the three on the axes that actually decide the outcome: cost model, failover and durability, day-to-day operations, and the scale envelope where each stops making sense.

Amazon RDS: managed, predictable, boring in a good way

RDS runs the standard engines (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle) on instances AWS patches and backs up for you. You still choose the instance class and storage, but you never SSH into the box. Multi-AZ deployments keep a synchronous standby in a second Availability Zone and fail over automatically, typically in 60 to 120 seconds, by flipping a DNS record to the promoted standby.

The cost model is straightforward: you pay for the instance hour, the provisioned storage (gp3 or io2), and IOPS if you go beyond the baseline. That predictability is RDS's biggest advantage. A db.m6g.large Multi-AZ Postgres instance costs the same on a quiet Sunday as on a busy Monday, so you can forecast the bill.

The tradeoffs: Multi-AZ failover has a real interruption window, read replicas use asynchronous replication (so replica lag is a thing you must monitor), and storage does not autoscale as elegantly as Aurora's. For the large majority of workloads under a few terabytes, RDS is the correct default.

Amazon Aurora: cloud-native storage, faster failover, more moving parts

Aurora is MySQL- and PostgreSQL-compatible, but the storage layer is completely re-architected. Data lives in a distributed volume replicated six ways across three AZs, and it autoscales in 10 GB chunks up to 128 TB. Because storage is decoupled from compute, adding a read replica does not copy data, it just attaches another compute node to the same shared volume. Failover to an existing replica is often under 30 seconds, and reader endpoints load-balance across replicas automatically.

Aurora shines on read-heavy, high-connection, or spiky workloads. Aurora Serverless v2 scales compute in fine-grained ACU increments and can shrink during quiet periods, which is genuinely useful for variable traffic. But watch the bill in two places. First, Aurora charges for I/O per request on the standard configuration, and a chatty application can run up I/O charges that dwarf the instance cost. Aurora I/O-Optimized flips that to a flat, higher instance price with no per-I/O charge, and for I/O-heavy systems it is frequently cheaper despite the sticker shock. Second, Serverless v2 that never scales down (because your baseline load keeps it warm) can quietly cost more than a right-sized provisioned instance. Model your actual traffic before assuming serverless saves money.

Self-managed on EC2: maximum control, maximum responsibility

Running Postgres or MySQL yourself on EC2 gives you total control: any extension, any version, any kernel tuning, any replication topology, and no per-I/O surprise. If you need a Postgres extension RDS does not allow, a specific minor version, or you are consolidating dozens of small databases onto one big box to save money, self-managed can win on raw cost per gigabyte.

The catch is that everything RDS and Aurora do for free is now your job: minor and major version patching, backup scheduling and, critically, restore testing, failover orchestration (Patroni, repmgr, or similar), monitoring, and being on call when the volume fills up at 3am. A single self-managed primary with no tested failover is a liability, not a cost saving. Budget for the engineering time honestly. If you cannot staff a rotation that owns the database, do not self-manage a production system.

Cost, at a glance

• RDS: instance + storage + IOPS. Predictable, mid-range. Multi-AZ roughly doubles instance cost for the standby.
• Aurora: higher instance price, plus per-I/O (standard) or flat (I/O-Optimized). Cheaper to add read scale, potentially expensive under heavy I/O if you pick the wrong config.
• Self-managed: lowest raw infrastructure cost, highest hidden cost in engineering time and risk.

Failover and durability

• RDS Multi-AZ: synchronous standby, automatic failover in 60 to 120 seconds, no data loss on commit.
• Aurora: six-way replicated storage, failover to a replica often under 30 seconds, storage survives AZ loss by design.
• Self-managed: whatever you build. Done well with Patroni it can be excellent; done casually it is the weakest of the three.

When to choose which

Choose RDS when you want a managed database with predictable billing, your workload is under a few terabytes, and you do not need sub-30-second failover or exotic read scaling. This covers most startups and most internal services. It is the safe, boring, correct default.

Choose Aurora when you have read-heavy or spiky traffic, need many read replicas, want fast failover, or expect to grow past the comfortable RDS storage range. Use I/O-Optimized if your workload is I/O-intensive, and actually measure Serverless v2 scaling before betting on it.

Choose self-managed only when you have a concrete reason RDS and Aurora cannot satisfy (a blocked extension, extreme cost consolidation, or specialized tuning) and you have a team that owns database operations with tested backups and automated failover.

A common mistake is treating this as a permanent decision. Start on RDS, migrate to Aurora if read scaling or failover speed becomes a real constraint, and reserve self-managed for the narrow cases that truly need it. If getting the sizing and failover strategy right is where you are stuck, our team covers exactly this ground in our DevOps as a Service engagements, and we routinely fold database cost tuning into broader AWS cost optimization work.

The short version

RDS for predictability, Aurora for scale and fast failover, self-managed only when you have a real reason and a real team. Match the option to your traffic shape and your on-call capacity, not to the flashiest feature list, and revisit the choice as you grow.

Want a second opinion on your database architecture without hiring a full-time platform engineer? InstaDevOps puts a senior DevOps engineer on retainer to run this kind of decision with you, from sizing and failover to cost tuning. Plans start at Startup ($2,999/mo) and Business ($4,999/mo), with roughly 48-hour turnaround on requests. Book a 15-minute call to talk through your setup.