Choosing a database is one of the earliest and most consequential decisions in any cloud application project. On AWS, that decision has two dimensions: which database technology to use, and how to run it — as a fully managed AWS service or self-hosted on EC2 instances you control. This guide walks through the major options and the trade-offs involved.
Two Fundamental Approaches to Databases on AWS
Every database workload on AWS falls into one of two operational models:
- Managed database services — AWS provisions, patches, backs up, and (in some cases) scales the database engine for you. You interact with the database through a wizard or API and pay an hourly or per-request fee.
- Self-hosted on EC2 — You launch one or more EC2 instances, install and configure the database engine yourself, and take full responsibility for replication, failover, backups, patching, and security.
Neither approach is universally better. The right choice depends on your team’s expertise, your existing EC2 footprint, your budget, and whether you are moving toward serverless architectures.
Managed Relational Databases: Amazon RDS
Amazon Relational Database Service (RDS) is AWS’s managed offering for SQL-based databases. When you create an RDS instance, AWS handles engine updates, automated backups, and Multi-AZ failover configuration. You still select an underlying instance type, so a server does run in your account and is billed by the hour — but the operational overhead is significantly lower than self-hosting.
RDS supports the following database engines:
- MySQL — The most widely used open-source relational database.
- MariaDB — A community-developed MySQL fork with some additional features.
- PostgreSQL — A powerful open-source RDBMS with strong standards compliance and extensibility.
- Oracle — Available with Bring Your Own License (BYOL) or License Included options; carries significant additional licensing cost.
- SQL Server — Microsoft’s relational engine, also available with licensing included at added cost.
- Amazon Aurora — AWS’s own cloud-native relational engine, compatible with either MySQL or PostgreSQL (you choose at creation time). Aurora is architected for higher availability and throughput than standard RDS MySQL or PostgreSQL, though it costs more per instance-hour.
RDS includes a free tier, but the free-tier instance size is modest and suitable only for development or very low-traffic workloads.
Managed Non-Relational (NoSQL) Databases on AWS
AWS offers several managed NoSQL and specialty database services for workloads that don’t fit the relational model:
Amazon DynamoDB
DynamoDB is AWS’s fully managed, serverless key-value and document NoSQL database. It has been available since 2012 and is billed on a per-request or provisioned-capacity basis — there is no underlying instance to size or manage. Because DynamoDB is serverless, self-hosting is not an option. AWS does provide DynamoDB Local, a downloadable version of the service, but this is strictly a development and testing tool and must not be used in production.
Amazon DocumentDB
DocumentDB is AWS’s managed document database service designed to be compatible with MongoDB clients and drivers. It is implemented on proprietary AWS infrastructure rather than running the MongoDB open-source codebase directly, which is an important distinction for teams that need specific MongoDB features or rely on its exact wire-protocol behavior.
Amazon Neptune
Neptune is AWS’s managed graph database service. It supports popular graph query languages and is compatible with Apache TinkerPop Gremlin and the SPARQL query language. Graph databases excel at workloads that require traversing highly connected data, such as social networks, recommendation engines, and fraud detection graphs.
Amazon QLDB (Quantum Ledger Database)
QLDB is a purpose-built, fully managed ledger database. It maintains a cryptographically verifiable history of all changes to your data, making it suitable for use cases that require an immutable audit trail — such as financial transaction records or supply chain tracking. Like DynamoDB, QLDB is serverless and does not require instance sizing.
Managed Service vs. Self-Hosted on EC2: The Cost Question
For the managed services that do require an instance type — RDS, DocumentDB, Neptune, and Aurora — you will notice that the per-hour pricing for database instances is generally higher than a comparable EC2 instance of the same size. The premium is more pronounced for Oracle and SQL Server due to licensing costs folded into the price.
This creates a legitimate cost-saving opportunity: if you already have EC2 capacity headroom, installing an open-source database engine (MySQL, PostgreSQL, MongoDB, etc.) on an existing instance is effectively free of incremental database-license cost. The trade-offs are real, however:
- You own operations — Replication, failover, backups, point-in-time recovery, and engine patching all become your responsibility.
- You own security — Network security groups, encryption at rest and in transit, and access control must be configured and audited by your team.
- You own scaling — Vertical scaling requires instance resizing; horizontal scaling requires configuring sharding or read replicas manually.
A straightforward cost comparison — managed instance price vs. equivalent EC2 instance price plus your team’s operational time — is the right starting point for this decision.
The Serverless Shift Changes the Calculation
Traditionally, teams running EC2 instances for application workloads found it easy to co-locate a database engine on one of those servers at little extra cost. As organizations migrate application logic from EC2 into AWS Lambda or other serverless compute services, that spare EC2 capacity disappears — and with it, the easy justification for self-hosting.
Teams going serverless should re-evaluate their database strategy in parallel. DynamoDB is a natural fit for Lambda-based architectures due to its serverless billing model, low-latency access patterns, and tight AWS integration. Aurora Serverless is another option that provisions relational capacity on demand, though it has specific use-case constraints worth investigating for your workload.
Decision Framework: How to Choose
Use the following questions to guide your choice:
- What is your data model? Structured relational data with complex joins → RDS or Aurora. Flexible document or key-value data → DynamoDB or DocumentDB. Highly connected graph data → Neptune. Immutable audit trail → QLDB.
- Do you have existing EC2 capacity? If yes, and your team has database administration skills, self-hosting open-source engines may be cheaper in the short term.
- Are you moving to serverless compute? If yes, plan to adopt serverless-compatible databases (DynamoDB, QLDB, Aurora Serverless) rather than locking yourself into an EC2-resident database.
- What is your team’s operational bandwidth? Managed services reduce DBA toil but cost more per compute unit. Factor in the real cost of engineering time, on-call burden, and incident response when comparing prices.
- Do you need Oracle or SQL Server? If so, RDS is often more practical than managing licensing compliance yourself on EC2, despite the higher per-hour cost.
Summary
AWS provides a comprehensive portfolio of database services covering relational, document, key-value, graph, and ledger use cases. Managed services reduce operational burden but carry a price premium over self-hosted EC2 deployments. The optimal choice depends on your data model, existing infrastructure, team capabilities, and architectural direction — particularly whether you are embracing serverless compute. Run the numbers for your specific instance sizes, factor in operational labor costs, and revisit the decision as your architecture evolves.