AWS Databases

AWS Databases is a portfolio, not one database. The services use different data models and operating models. Your first task is to match the workload to a model, not to pick the most familiar product name.

Start with the data and the questions the application asks. Relational databases organize structured data into tables and support joins. Key-value databases optimize access through known keys. Document databases store JSON-like records. Graph databases make relationships central. Time-series databases organize measurements around time.

AWS calls this purpose-built database selection. One application can use more than one database type when its parts have different access patterns. That choice can improve fit, but every added database creates another schema, security boundary, failure mode, and operating surface.

Choose the data model before the service

Write down the workload before comparing products:

What entities and relationships must you represent?
Which reads and writes happen most often?
Which queries are known in advance, and which must remain flexible?
Which transactions require strict consistency across several records?
What latency, throughput, availability, and recovery targets apply?
How quickly can traffic and stored data grow?
Which engine features or client protocols must remain compatible?

The answers narrow the field.

Data model	AWS starting point	Typical fit
Relational	Amazon RDS or Amazon Aurora	Structured records, joins, flexible queries, and multi-row transactions
Key-value	Amazon DynamoDB	Known access patterns, large scale, and predictable low-latency requests
Document	Amazon DocumentDB	JSON-like documents and queries across document fields
In-memory	Amazon ElastiCache or Amazon MemoryDB	Caching, session data, and workloads that need very low latency
Graph	Amazon Neptune	Relationship traversal, fraud graphs, recommendations, and knowledge graphs
Time series	Amazon Timestream	Measurements, events, metrics, and queries organized by time
Wide-column	Amazon Keyspaces	Cassandra-compatible workloads with high throughput and low latency
Vector	Several AWS database and search services	Similarity search over vector representations

Amazon Redshift serves analytical data-warehouse workloads. It belongs in the wider data platform, but it is not the default answer for an online transaction path.

Relational services preserve a familiar model

Amazon RDS runs managed relational database engines. Current engine choices include PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle Database, and IBM Db2. AWS manages common infrastructure work such as installation, patching, backups, failure detection, and recovery.

Amazon Aurora is a managed relational service compatible with MySQL or PostgreSQL clients and tools. Aurora separates its distributed storage from database compute and provides cluster endpoints for different connection roles.

Choose a relational service when the workload needs joins, constraints, flexible queries, or transactions across related records. Existing engine compatibility can also make RDS the lowest-change migration target.

Managed does not mean unattended. You still own schema design, indexes, query behavior, connection management, engine upgrades within your policy, data classification, access, and application recovery behavior.

Non-relational services begin with access patterns

DynamoDB is a serverless, fully managed NoSQL database. Its primary key design determines how data is distributed and retrieved. Known access patterns belong in the design before table creation. A relational schema copied directly into DynamoDB usually keeps the old complexity while losing the old query model.

DocumentDB stores document data and provides MongoDB compatibility. Compatibility is not identity. Check the supported APIs, operators, versions, and application behavior before treating it as a drop-in replacement.

Neptune is for connected data where traversing relationships is the main operation. Timestream is for data whose time dimension drives storage and queries. Keyspaces targets Cassandra-compatible wide-column workloads. ElastiCache is primarily a cache, while MemoryDB is a durable in-memory database.

Use a specialized model when the dominant access pattern matches it. Do not add one because its latency claim looks attractive without testing the complete application path.

Availability, scale, and recovery solve different problems

Availability keeps a service reachable through a defined failure. Scale increases useful capacity. Recovery restores acceptable service and data after damage. One feature rarely solves all three.

For an RDS Multi-AZ DB instance deployment, AWS maintains a synchronous standby in another Availability Zone and can fail over to it. The standby does not serve read traffic. An RDS read replica is a separate, read-only copy updated asynchronously. It can reduce load on the primary, but replication lag means a read can be stale.

Backups protect a different path. RDS automated backups retain snapshots and transaction data for point-in-time recovery within the configured retention period. Manual snapshots have a separate lifecycle. Define recovery point and recovery time objectives, configure retention, and rehearse restoration. A backup policy without a tested restore leaves the outcome unknown.

Other services use different availability and recovery mechanisms. Verify the exact service, engine, Region, and deployment mode. Never transfer an RDS assumption to DynamoDB, Neptune, or DocumentDB without checking its documentation.

Security remains shared

AWS secures the cloud infrastructure. You secure your use of the service. Your responsibilities include data classification, identity permissions, database users, network paths, encryption choices, key policies, logging, retention, and application behavior.

Keep databases off public paths unless the workload has a reviewed need. Restrict security groups and service policies to required callers. Store credentials in an appropriate secret system and rotate them. Use transport encryption between clients and databases. Choose and protect encryption keys according to your recovery and compliance requirements.

RDS encryption at rest covers storage, logs, automated backups, read replicas, and snapshots. AWS Key Management Service controls the encryption key. Key access is part of availability: disabling or losing access to a key can make encrypted data unavailable.

Operations begin with workload signals

Monitor the database and the application together. Useful signals include request latency, error rate, connection pressure, CPU, memory, storage, read and write activity, replication lag, throttling, and backup status. The relevant set depends on the service.

CloudWatch exposes service metrics and alarms. RDS also provides Performance Insights and Enhanced Monitoring. These tools show pressure; they do not choose the fix. A slow query may need an index or a different access pattern, not a larger instance.

Plan maintenance before it arrives. Track engine versions, service announcements, quotas, certificates, parameter changes, and deprecated features. Test failover and recovery with the same clients, connection pools, and name-resolution behavior used in production.

Migration is a controlled change, not a copy command

AWS Database Migration Service can discover sources, move data once, or replicate ongoing changes. DMS Schema Conversion assesses and converts schemas and code objects for heterogeneous migrations. Objects that cannot be converted automatically require review and manual work.

Separate the migration into concerns:

Assess the source workload, dependencies, and data quality.
Choose the target from measured access patterns and compatibility needs.
Convert schema and database code when engines differ.
Load data and replicate changes when the cutover needs a short outage.
Validate row counts, constraints, application results, performance, and recovery.
Rehearse cutover, rollback, and credential changes.

A migration that changes the database model is also an application redesign. Treat it as one.

Cost follows resource and request choices

Database cost can include compute, storage, input and output operations, requests, backup storage, replication, data transfer, and supporting observability. Provisioned services charge for allocated capacity even when demand is low. Serverless and on-demand modes move more cost toward actual requests or changing capacity, but they do not remove the need to model peaks.

Compare the whole workload over time. Include replicas, test environments, retained snapshots, cross-Region traffic, migration capacity, licenses, and the engineering cost of operating each model. Validate estimates against current regional pricing before making a commitment.

When AWS managed databases are not the answer

Run a database on Amazon EC2 only when the managed service does not support a required engine, extension, operating-system control, topology, or administration model. You then own installation, patching, backup automation, high availability, monitoring, and recovery.

Keep a workload outside AWS when latency, data-sovereignty, licensing, disconnected operation, or economics require it. AWS DMS supports migration between cloud and on-premises setups, but the application architecture still determines whether that path works.

Your path forward

Learn the relational and non-relational data models.
Record real access patterns, consistency needs, and recovery targets.
Compare only the services that match those requirements.
Build a small model with representative data and queries.
Test failure, restore, security controls, and cost under realistic load.
Study the selected service's limits, APIs, operational guidance, and pricing.
Revisit the choice when workload evidence changes.