Relational, NoSQL and in-memory databases, and moving them

What "managed" actually buys

Amazon RDS runs the same database engines people already use — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and the Amazon Aurora engines — which is why moving to it leaves an application's SQL untouched. What changes is who does the chores: AWS operates the host and the database software, so provisioning, minor-version patching, automated backups, recovery and failover stop being somebody's week. What stays yours is everything about your application: schema design, indexes, queries, and who is allowed to connect.

Running the same engine on an EC2 instance instead is a legitimate answer to a different question — an extension RDS does not support, a version it does not offer, or a need to touch the operating system — and the trade is explicit: you have moved the server into AWS and kept every one of the chores. A stem that lists backups, patching and failover rehearsals as the reason for moving has ruled that option out in its first sentence.

Staying up is not the same as keeping up

A Multi-AZ deployment keeps a synchronous copy of the database in a second Availability Zone and fails over to it automatically. Its purpose is availability, and the standby answers no queries — there is no separate endpoint for it, which is exactly what makes a failover invisible to the application. (Amazon RDS also offers a Multi-AZ DB CLUSTER variant whose standbys can serve reads; a question that means that says cluster, and the classic instance deployment is what "Multi-AZ" alone refers to.)

Read replicas are the feature that adds read capacity. They are asynchronous copies, each with its own endpoint, you can have several, and they can live in another Region. Reporting queries that are slowing down customer transactions belong on one. The manager's line in the question — we are already paying for a second copy, just point the reports at it — is the misconception being tested, and the answer is that the two features buy different things: Multi-AZ is for staying up, read replicas are for keeping up.

Pick the database from the access pattern

The pattern, not the size, decides. Lookups by key at any scale, with a flexible document shape and no joins, go to Amazon DynamoDB: single-digit millisecond responses, no instance class to choose in advance, and on-demand capacity that absorbs a launch nobody could forecast. Joins, transactions across tables and existing SQL go to Amazon RDS or Amazon Aurora. Large analytical scans go to Amazon Redshift, whose columnar storage is built for exactly the queries a key-value store is worst at. Graph relationships go to Amazon Neptune.

Two mistakes are worth naming because the exam builds options out of them. The first is choosing relational by habit and then fighting it at scale. The second is the opposite: proposing a migration to a different data model as the answer to a performance problem that has a built-in solution. A requirement that says the existing SQL must keep working rules out DynamoDB however attractive its scaling story sounds.

Replicas spread the work out; caches avoid doing it

When every visitor triggers the same expensive query and the underlying data changes a few times a day, adding a read replica moves that work onto a second machine and still runs it once per visitor. Amazon ElastiCache — managed Redis or Valkey, and Memcached — computes it once and serves the result from memory for the next few thousand requests, which removes the work rather than redistributing it. DynamoDB has its own in-memory accelerator, DAX, and Amazon MemoryDB for Redis is the durable in-memory option.

The cost of a cache is not money, it is staleness. You have to decide how out of date a reader may be and how the cache is invalidated when the data changes, which is why a cache is right for a result that is identical for nearly everyone and rarely changes, and wrong for something read once and never again. Hold the pair as: replicas spread the work out, caches avoid doing it.

Moving a live database without a long outage

AWS Database Migration Service performs a full load and then goes on replicating changes from the source, so the source stays in production the whole time and the outage is only the moment you switch which database the application writes to. That is what makes a "cutover window of a few minutes" achievable. The alternative a question offers — export a dump, copy it, import it — freezes the database for the whole of all three steps, which for a couple of terabytes is hours at best and cannot be shortened below the slowest one.

When the source and target engines DIFFER, as in an Oracle database becoming Aurora PostgreSQL, the schema, stored procedures and data types have to be translated as well, which is the AWS Schema Conversion Tool's job. A homogeneous move — Oracle to Oracle, MySQL to Aurora MySQL — needs DMS alone. That pairing is the whole question in most migration items.