Databases on AWS: managed or self-hosted, relational, NoSQL and in-memory, and migrating with DMS and SCT

Why this matters

Almost every application keeps its important data in a database: orders, customer accounts, stock levels, game scores. When a business moves to AWS, the database is usually the part people worry about most, because it is where the money and the history live. AWS offers several database services, each built for a different shape of data, and picking the wrong one means either rewriting the application or paying people to run something AWS would have run for them.

A manager needs to know what "managed database" actually takes off the team's plate, and what it does not. A salesperson needs to tell a customer with a MySQL system from one with a MongoDB system, because the answer is a different AWS service. A junior engineer needs to know which tool converts a database from one engine to another and which one moves the data. These are short, concrete distinctions, and the exam tests them through scenarios.

The lesson

AWS database services

A database stores data so that an application can find, change and protect it reliably. AWS does not offer one database for everything. It offers purpose-built databases, each matched to a type of data and a pattern of access. The in-scope services fall into four families:

• Relational: Amazon RDS and Amazon Aurora, for structured data in tables queried with SQL.
• Key-value and document (NoSQL): Amazon DynamoDB, and Amazon DocumentDB for MongoDB-compatible documents.
• Graph: Amazon Neptune, for data where the relationships between things matter most.
• In-memory: Amazon ElastiCache, for very fast reads from memory.

You will also meet Amazon Redshift in answer options. It is a data warehouse, built for analysing large volumes of historical data rather than for running an application's day-to-day transactions. It is covered with the analytics services in lesson 20.

All of these are managed services: AWS runs the servers, storage and software underneath. That idea is central to the next sections.

Database migration

Moving a database to AWS is a project in its own right. Two questions shape it.

First, is the engine changing? A database engine is the software that runs the database, such as MySQL, PostgreSQL, Oracle or Microsoft SQL Server. A move that keeps the same engine (MySQL on premises to Amazon RDS for MySQL) is called homogeneous. A move to a different engine (Oracle to Amazon Aurora PostgreSQL-Compatible Edition) is heterogeneous, and it needs the database's structure and code converted as well as its data copied.

Second, can the business stop while it happens? Usually it cannot. A shop that takes orders all day cannot switch its database off for a weekend. So AWS's migration service copies the data while the source database keeps working, then keeps replicating new changes until the business is ready to switch over, a moment called cutover. This continuous copying is the "database replication" approach to migration, one of the strategies discussed in lesson 3.

Deciding between EC2-hosted and AWS managed databases

There are two ways to run a relational database on AWS.

Self-managed on Amazon EC2. You launch virtual servers (EC2 instances, lesson 14) and install the database yourself. You get full control: any engine, any version, any setting, and access to the operating system, so you can install a third-party agent directly on the database host. In return you do all the work: patching the operating system and the engine, configuring backups, building high availability and failover, and recovering when something breaks.

Managed, with Amazon RDS or Aurora. AWS provisions the hardware, applies operating system and engine patches in a maintenance window you choose, replaces failed hardware, automates backups and can fail over to a standby automatically. You do not get access to the underlying host. That is the trade: less control, much less administration.

Moving to a managed service does not hand AWS everything. The customer still:

• creates database users and decides what each may do;
• designs the schema, tables and indexes for its own queries;
• chooses what to encrypt and who can read the data;
• controls which networks can reach the database, using security groups.

This is the shared responsibility model from lesson 6 in action: the line moves towards AWS as you go from EC2 to RDS, but the data and who can reach it stay yours.

On the exam, phrases such as "least operational effort", "no database administrators" or "does not want to handle patching and backups" point to a managed service. Phrases such as "needs operating system access", "custom software on the host" or "an engine version AWS does not offer" point to a database on EC2.

Relational databases: Amazon RDS and Amazon Aurora

A relational database stores data as rows in tables. Each table has a fixed schema, a defined set of columns with types. Tables are linked through keys, and you query them with SQL (Structured Query Language), including joins that combine related tables in one query. This suits structured data with complex queries, such as an order system that joins customers, orders and products.

Amazon RDS (Relational Database Service) runs familiar engines for you, such as MySQL, PostgreSQL, MariaDB, Oracle and Microsoft SQL Server. Because the engine is the same, an application moved from an on-premises MySQL server keeps its SQL unchanged. You choose a database instance class, which sets the compute and memory size. Two features come up often:

• Multi-AZ deployment: RDS keeps a standby copy in a second Availability Zone and fails over to it automatically if the primary fails. This is about availability, inside one Region.
• Read replicas: extra copies that serve read queries, so a read-heavy application can spread its load.

Amazon Aurora is a relational engine that AWS built for the cloud. It is compatible with MySQL and PostgreSQL, so existing applications and tools work with it, and its storage grows automatically as data is added, with copies kept across several Availability Zones. An Aurora Serverless option adjusts capacity to demand. If a question asks for a relational database that is cloud-native, MySQL- or PostgreSQL-compatible and grows its own storage, the answer is Aurora.

NoSQL databases: Amazon DynamoDB, DocumentDB and Neptune

NoSQL means non-relational. These databases drop the fixed table schema in exchange for flexibility and scale.

Amazon DynamoDB is a serverless key-value and document database. Each item is found by its key (a partition key, sometimes with a sort key), and items in the same table can have different attributes. "Serverless" here means there are no instances to choose or size: you create a table and AWS handles servers and scaling, from a handful of requests to millions per second. It is a durable database, not a temporary cache. It does not perform SQL joins across tables; you design around access by key. Its global tables feature replicates a table across chosen AWS Regions, and every copy accepts both reads and writes, so users in each Region work locally. Do not confuse this with RDS Multi-AZ, which protects against the loss of one Availability Zone within a single Region.

Amazon DocumentDB is a managed document database compatible with MongoDB. A company with JSON documents in MongoDB can move to it and keep its existing MongoDB code and drivers. DynamoDB can also store JSON-like items, but it uses its own API, so it is not the MongoDB-compatible choice.

Amazon Neptune is a managed graph database. It stores entities (people, products, places) and the relationships between them, and follows those connections quickly. "Friends of friends who share an interest" or fraud rings linking accounts are graph problems; in a relational database they become many slow joins.

In-memory databases: Amazon ElastiCache

Reading from memory is far faster than reading from disk. Amazon ElastiCache is a managed in-memory data store, compatible with the open-source Valkey, Redis OSS and Memcached engines, that returns data with sub-millisecond latency.

Its two classic jobs are:

• Caching in front of a database. If product pages run the same read queries against Amazon RDS thousands of times a minute, ElastiCache can hold the results so that most repeated reads do not reach the database, which lowers its load.
• Shared session store. When several EC2 instances sit behind a load balancer, each user's session data must be readable by whichever instance answers next. Keeping sessions in ElastiCache gives every instance the same fast copy.

ElastiCache usually sits alongside a durable database rather than replacing it. "In memory", "sub-millisecond" and "cache" in a scenario point here.

AWS DMS and AWS SCT: the database migration tools

AWS Database Migration Service (AWS DMS) moves the data. It copies a database to AWS while the source stays fully operational, and its ongoing replication captures changes on the source and applies them to the target, so the two can stay in sync for days or weeks until cutover. DMS handles both homogeneous and heterogeneous moves.

AWS Schema Conversion Tool (AWS SCT) converts the structure. When the engine changes, it rewrites the source schema and code objects, such as stored procedures, views and functions, into a form the target engine understands. It can also produce an assessment report estimating how much of the conversion it can do automatically. It does not move or replicate data.

Put together:

• Same engine (MySQL to RDS for MySQL): no schema conversion is needed, so AWS SCT is not required. Use AWS DMS.
• Different engine (Microsoft SQL Server to Aurora MySQL, or Oracle to Aurora PostgreSQL): AWS SCT converts the schema first, then AWS DMS moves the data.

Watch for distractors. AWS Backup protects data but does not migrate engines. AWS Glue prepares data for analytics. AWS Storage Gateway connects on-premises storage to AWS. AWS Migration Hub tracks the progress of migrations across tools, but does not convert or move anything itself.

What the exam is really asking

Most database scenarios turn on one clue word. "SQL" or "joins" means relational: RDS or Aurora. "Key-value", "serverless" or "millions of requests" means DynamoDB. "MongoDB" means DocumentDB. "Relationships" or "graph" means Neptune. "In memory" or "cache" means ElastiCache. "Analytics on historical data" means Redshift. For migrations, ask whether the engine changes: if it does, SCT and DMS together; if not, DMS alone.