AWS Database Services
Learn the core AWS database services: managed and purpose-built databases, relational databases with Amazon RDS and Amazon Aurora, NoSQL and in-memory databases like Amazon DynamoDB and Amazon ElastiCache, and database migration with AWS DMS.
AWS gives you a database built for each kind of workload instead of forcing every problem onto one engine. This topic covers that purpose-built approach: what changes when AWS manages the database for you, and which service fits relational, NoSQL, in-memory, and migration scenarios on the AWS Certified Cloud Practitioner exam.
The lessons move from the general idea to specific services. You start with the difference between a managed service and running a database yourself on Amazon EC2, then work through relational databases with Amazon RDS and Amazon Aurora, NoSQL and in-memory options like Amazon DynamoDB and Amazon ElastiCache, and finally the tools that move an existing database into AWS.
What This Topic Covers
- the difference between a managed database service and running a database yourself on Amazon EC2
- relational versus non-relational data and the idea of purpose-built databases
- managed relational databases with Amazon RDS, including Multi-AZ high availability and read replicas
- Amazon Aurora and Aurora Serverless, and how they differ from the standard RDS engines
- NoSQL with Amazon DynamoDB and in-memory data with Amazon ElastiCache and Amazon MemoryDB
- moving databases to AWS with AWS Database Migration Service and the AWS Schema Conversion Tool
Why It Matters
Database questions on the exam usually describe a scenario and ask which service fits. If you can match relational, key-value, in-memory, and graph workloads to Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, and Amazon Neptune, you can answer most of them without second-guessing.
These services also build on earlier topics and feed later ones. RDS and Aurora run inside the Regions and Availability Zones from the global infrastructure topic, Multi-AZ is a concrete example of the high availability you met there, and the managed-versus-self-managed tradeoff connects straight back to the shared responsibility model. Once you know what each database is for, the networking, security, and pricing lessons have a foundation to build on.