Amazon RDS vs RDS Custom vs Self-Managed Database on EC2: Choosing the Right Control Boundary

Every database deployment on AWS involves a trade-off between how much AWS manages and how much control you retain. The three options — Amazon RDS, RDS Custom, and a self-managed database on EC2 — represent three distinct positions on that spectrum. Picking the wrong one either leaves you paying for management you didn’t need or fighting AWS automation for access you should have had from the start.

The Control Spectrum

There are roughly five layers where control matters:

Amazon RDS controls all five on your behalf. RDS Custom gives you access to OS and some database binary layers while AWS still manages infrastructure. Self-managed EC2 gives you all five but makes you responsible for all five.

Amazon RDS

RDS is a fully managed relational database service. AWS handles provisioning, OS patching, database engine patching, backups, Multi-AZ failover, and read replica management. You interact with the database through its endpoint — there is no SSH, no OS shell, no direct filesystem access.

What You Get

• Automated backups with point-in-time recovery up to 35 days
• Multi-AZ deployments with automatic failover (typically under 60 seconds)
• Read replicas (up to 15 for Aurora, 5 for standard RDS engines)
• Storage autoscaling — the volume grows automatically when free space drops below a threshold
• Parameter groups for database-level configuration
• Option groups for adding features like Oracle TDE or SQL Server native backup

What You Give Up

You cannot:

• SSH into the underlying EC2 instance
• Install OS packages or custom monitoring agents at the OS level
• Apply database patches on your own schedule
• Use database features that require OS-level access
• Access transaction log files directly on disk

When RDS Is the Right Choice

• Your workload uses a standard engine configuration without custom OS-level requirements
• The team does not have dedicated DBAs who need low-level access
• You want automated patching, backups, and failover without building the tooling yourself
• You are running a SaaS product where operational simplicity at scale matters more than tuning flexibility

RDS is the correct default for most production workloads. The managed overhead it removes (patch cycles, backup validation, failover testing) is genuinely expensive to replicate yourself.

RDS Custom

RDS Custom sits between fully managed RDS and self-managed EC2. It gives you SSH access to the underlying EC2 instance and direct access to the database binary and OS, while AWS still manages the infrastructure primitives.

RDS Custom currently supports Oracle and SQL Server — specifically because enterprise Oracle and SQL Server deployments frequently require OS-level customisation that standard RDS does not permit.

What You Get Beyond Standard RDS

• SSH access to the underlying EC2 instance via AWS Systems Manager (SSM)
• OS-level access — install agents, modify OS parameters, run OS-level scripts
• Database binary access — apply custom Oracle patches, configure Oracle options that require OS interaction
• Custom database configurations that require editing files directly on disk
• Shared responsibility for patching — you own OS and database patch application; AWS manages the underlying EC2 host and EBS volumes

The Automation Boundary

RDS Custom introduces the concept of a pause automation window. If you make changes that AWS automation does not expect, first pause RDS Custom automation, make the changes, then resume. If you skip this step, AWS automation may detect the unexpected state and attempt to remediate it — potentially undoing your changes.

When RDS Custom Is the Right Choice

• Running Oracle Database and need features that require OS access: Oracle GoldenGate, custom keystore configurations, specific Oracle patches not yet available in standard RDS
• Running SQL Server with requirements for custom CLR assemblies, linked server configurations that depend on OS-level authentication, or custom SQL Server Agent jobs that interact with the OS
• Migrating an existing on-premises Oracle or SQL Server installation that cannot be refactored to work within standard RDS constraints

Self-Managed Database on EC2

Running your own database engine on an EC2 instance gives you complete control over every layer. You also own every failure.

What You Get

• Full OS access — any Linux distribution, any kernel, any OS-level tuning
• Any engine version — including versions AWS does not support in RDS, or engines RDS does not offer (CockroachDB, YugabyteDB, TiDB, Cassandra, etc.)
• Direct storage access — choose between io2 block express, gp3 with custom IOPS and throughput, or instance store NVMe for the highest I/O performance
• Custom replication topologies — Patroni for PostgreSQL HA, Orchestrator for MySQL
• No managed service overhead — no RDS licensing premium on top of instance costs

What You Own

Everything RDS handles automatically becomes your operational responsibility:

• OS patching — schedule, test, and apply kernel and package updates
• Database patching — track CVEs, download patches, test in staging, apply in production
• Backups — build or configure the backup pipeline (pg_dump, xtrabackup, EBS snapshots)
• Point-in-time recovery — WAL archiving to S3 with pgBackRest or WAL-G
• High availability — deploy and operate Patroni, Pacemaker, or a similar HA solution
• Failover automation — Route 53 health checks and DNS failover, or a cluster manager
• Storage management — monitor disk usage, extend volumes, manage RAID
• Monitoring — CloudWatch agent, Prometheus exporters, slow query logs — all configured manually

When Self-Managed EC2 Is the Right Choice

• You need a database engine that RDS does not support
• You need storage performance beyond what RDS offers (>80,000 IOPS, >2,000 MB/s throughput)
• You have a database team with the expertise and capacity to own patching, HA, and recovery
• You are running a stateful distributed database (Cassandra, ScyllaDB) where the cluster topology is application-managed

Self-managed EC2 is not the right choice because “we want more control” in the abstract. The operational cost is real and recurring.

Side-by-Side Comparison

The Cost Reality

RDS charges a premium over raw EC2 pricing for the same instance family. For a db.r6g.2xlarge (8 vCPU, 64 GB RAM) in ap-southeast-1:

• RDS (PostgreSQL, Multi-AZ): $0.96/hour ($691/month)
• EC2 (r6g.2xlarge, on-demand): $0.404/hour ($291/month)

The gap narrows significantly with Reserved Instances. At reserved pricing, the operational cost of self-managing often exceeds the savings unless the team already has the tooling built and the expertise in-house.

Aurora Serverless v2 changes the calculus for variable workloads — it scales in 0.5 ACU increments, paying for actual consumed capacity rather than a fixed instance size. For workloads with significant idle periods, Aurora Serverless v2 can be materially cheaper than a fixed RDS instance.

Decision Framework

Start with RDS unless you have a specific reason not to. Then work through these questions:

Is the engine supported by RDS?

• No → Self-managed EC2.
• Yes → Continue.

Do you need OS-level access or custom Oracle/SQL Server configurations?

• Yes → RDS Custom (if Oracle or SQL Server).
• No → Continue.

Do you need storage performance beyond RDS limits, or a replication topology RDS cannot provide?

• Yes → Self-managed EC2, but budget for the operational overhead.
• No → RDS.

Do you have a dedicated DBA team with capacity to own patching, HA, and recovery tooling?

• No → RDS, regardless of other preferences.
• Yes → Any option is viable; let the technical requirements drive the choice.

The control boundary is not about preference. It is about which failure modes you are equipped to handle and which ones you would rather outsource.

Further Reading

• Amazon RDS documentation
• RDS Custom documentation
• pgBackRest
• Patroni
• AWS Database Blog