AWS Databases

AWS database services are managed offerings covering relational, key-value, document, graph, time-series, and in-memory workloads. They handle provisioning, patching, backups, and replication so teams can focus on schema design and query patterns rather than infrastructure.

itCloud computing

Don't Panic — AWS Databases

AWS Databases is a collection of managed database services, not a very large database wearing several hats. That is good news, because applications do not all ask the same questions. It is also bad news, because the service list is happy to look like a buffet when what you needed was a map.

Start with the workload. A data model is the way records and relationships are represented. Tables and joins point toward relational services such as Amazon RDS or Amazon Aurora. Known lookups by a key point toward Amazon DynamoDB. Relationship traversal points toward Amazon Neptune. Measurements arranged around time point toward Amazon Timestream. The product name comes after that evidence, not before it, which saves an impressive amount of confident wandering.

The surprise is that managed does not mean unattended. AWS takes on infrastructure work, but the application still owns schema choices, queries, identities, network paths, connections, recovery behavior, and the awkward moment when a real client meets a failover. An access pattern, the specific way an application reads or writes data, is therefore more useful than a vague requirement for "scale." It gives the database something concrete to be good at.

Keep three ideas in separate boxes. Availability keeps a service reachable through a defined failure. Scale adds useful capacity. Recovery restores service and data after damage. An RDS Multi-AZ standby supports availability, but it does not serve read traffic. A read replica can add read capacity, but it can lag. Backups support recovery, but only a restore rehearsal tells you whether the application returns in time. These are not interchangeable talismans, however much a diagram may wish otherwise.

More than one database can be the sensible answer. Orders might need relational transactions, while predictable session lookups fit a key-value store and a cache serves hot reusable reads. That arrangement is called polyglot persistence. It also creates another schema, security boundary, monitor, backup path, and failure mode for every new service. The sensible choice is not the most exotic service; it is the one whose model and failure behavior match the evidence.

Read the Intro for the portfolio and the decision questions. Use the Slides when the service relationships need a compact map. Keep the Cheatsheet nearby for the selection matrix, recovery distinctions, and monitoring signals. Then use the Practice Reference and exercise to turn a fictional workload into a decision record before any console clicks acquire the confidence of a plan.

Don't Panic — AWS Databases

Relevant careers