You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Database Options on AWS
Database Options on AWS
Choosing the right database is one of the most consequential decisions you will make when designing a cloud application. AWS offers more than a dozen purpose-built database services, each optimised for a specific data model and access pattern. This lesson provides a bird's-eye view of every major option, explains when to choose relational versus NoSQL, and introduces the cost and operational trade-offs that will guide you through the rest of the course.
Why Purpose-Built Databases?
Historically, organisations used a single relational database for everything — transactions, analytics, caching, and search. That approach works for small workloads but quickly creates performance bottlenecks and expensive licensing costs at scale. AWS advocates a purpose-built database strategy: pick the engine that best matches each workload's data model, latency requirements, and scale profile.
Benefits of this strategy include:
- Optimised performance — a key-value store can deliver single-digit-millisecond reads that a relational join cannot match
- Cost efficiency — you pay only for the capabilities you actually need
- Operational simplicity — managed services remove patching, backup, and replication burden from your team
Relational vs NoSQL — When to Choose Each
| Criterion | Relational (SQL) | NoSQL |
|---|---|---|
| Data model | Tables with rows and columns; strict schema | Key-value, document, wide-column, or graph; flexible schema |
| Query language | SQL — powerful joins, aggregations, subqueries | Varies — DynamoDB API, MongoDB query language, Cypher for graphs |
| Consistency | Strong (ACID transactions) | Often eventual; some offer strong consistency per-item |
| Scalability | Vertical (bigger instance) + read replicas | Horizontal (partition data across many nodes) |
| Best for | Complex relationships, regulatory compliance, analytics | High-throughput, low-latency, unpredictable or rapidly changing schemas |
Rule of thumb: if your application needs complex joins across many tables and strict transactional guarantees, start with a relational database. If you need sub-millisecond latency at any scale with simple access patterns, choose a NoSQL option.
Overview of AWS Database Services
Relational
| Service | Engine(s) | Key Differentiator |
|---|---|---|
| Amazon RDS | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server | Managed relational database with automated backups, patching, and Multi-AZ failover |
| Amazon Aurora | MySQL-compatible, PostgreSQL-compatible | Cloud-native architecture with up to 5× throughput of MySQL and 3× of PostgreSQL |
| Amazon Redshift | PostgreSQL-compatible | Columnar data warehouse optimised for petabyte-scale analytics |
NoSQL
| Service | Data Model | Key Differentiator |
|---|---|---|
| Amazon DynamoDB | Key-value / document | Serverless, single-digit-millisecond latency at any scale |
| Amazon DocumentDB | Document (MongoDB-compatible) | Managed document database for JSON workloads |
| Amazon Keyspaces | Wide-column (Apache Cassandra-compatible) | Serverless Cassandra-compatible service |
| Amazon Neptune | Graph (property graph + RDF) | Purpose-built for highly connected datasets |
| Amazon Timestream | Time series | Serverless time-series database for IoT and operational metrics |
| Amazon MemoryDB for Redis | In-memory key-value | Redis-compatible, durable in-memory database |
Caching
| Service | Engine(s) | Key Differentiator |
|---|---|---|
| Amazon ElastiCache | Redis, Memcached | Fully managed in-memory cache with microsecond latency |
The AWS Shared Responsibility Model for Databases
AWS manages the infrastructure layer — hardware, networking, operating system patches, and engine installation. Your responsibilities depend on whether you use a managed service or run a database on EC2:
| Responsibility | Self-managed on EC2 | Managed (RDS / DynamoDB) |
|---|---|---|
| Hardware & data-centre security | AWS | AWS |
| OS patching | You | AWS |
| Database engine install & patches | You | AWS |
| High availability & failover | You | AWS (with configuration) |
| Backups | You | AWS (automated) |
| Schema design & query tuning | You | You |
| Data classification & encryption choices | You | You |
Cost Dimensions to Consider
Database costs on AWS are determined by several factors:
- Instance type — vCPU, memory, and network capacity (e.g., db.r6g.xlarge for RDS)
- Storage — provisioned IOPS SSD, general-purpose SSD, or magnetic
- I/O — Aurora charges per million I/O requests; DynamoDB charges per read/write capacity unit
- Data transfer — cross-AZ and cross-Region transfer incurs charges
- Backups beyond the free tier — RDS provides backup storage equal to your DB size at no extra charge; additional storage is billed per GB-month
- Licensing — Oracle and SQL Server carry licence costs; open-source engines (MySQL, PostgreSQL, MariaDB) do not
Pricing Comparison at a Glance
| Service | On-Demand (approx.) | Reserved / Savings |
|---|---|---|
| RDS db.r6g.large (MySQL) | ~$0.26/hr (us-east-1) | Up to 40% off with 1-yr RI |
| Aurora db.r6g.large | ~$0.29/hr (us-east-1) | Up to 40% off with 1-yr RI |
| DynamoDB on-demand | $1.25 per million write request units | Provisioned mode + reserved capacity for predictable workloads |
| ElastiCache cache.r6g.large | ~$0.25/hr (us-east-1) | Up to 40% off with 1-yr RI |
| Redshift ra3.xlplus | ~$1.086/hr (us-east-1) | Up to 50% off with 1-yr RI |
Prices are approximate and vary by Region. Always consult the AWS pricing page for current rates.
Decision Framework
When selecting a database service, walk through these questions:
- What is the data model? Tabular → relational. Key-value or document → DynamoDB. Graph → Neptune. Time series → Timestream.
- What are the latency requirements? Microsecond → ElastiCache. Single-digit millisecond → DynamoDB. Low millisecond → RDS / Aurora.
- What is the expected scale? Millions of requests per second → DynamoDB. Gigabytes to low terabytes → RDS. Petabytes of analytics → Redshift.
- Do you need ACID transactions across multiple tables? Yes → RDS or Aurora. DynamoDB supports transactions within a single account and Region but not cross-table joins.
- What is the operational budget? Serverless options (DynamoDB, Keyspaces, Timestream) minimise ops overhead. RDS and Aurora require instance sizing.
Summary
AWS provides a rich portfolio of purpose-built databases. Rather than forcing every workload into a single engine, you should match the data model, latency requirements, and scale profile to the right service. In the lessons that follow, we will dive deep into each of the most popular options — starting with Amazon RDS.