CLOUD DATABASE ENGINEERING
The database is only one layer of the production system.
Modern AWS database engineering spans architecture, migration, automation, monitoring, performance, security boundaries, and recovery evidence.
AUR
Amazon Aurora PostgreSQL
Architecture, endpoints, failover, upgrades, parameter strategy, performance engineering, backup/recovery, and operational resilience.
MY
Amazon Aurora MySQL
MySQL-compatible cluster architecture, endpoints, failover, reader scaling, binlog/CDC, capacity, upgrades, and evidence-led operations.
DMS
AWS DMS
Assessment, source/target endpoints, full-load and CDC patterns, validation, LOB considerations, throughput analysis, and migration observability.
IaC
Infrastructure Automation
Repeatable provisioning and operational workflows using infrastructure-as-code and orchestration rather than undocumented console-only changes.
OBS
Observability
Cloud metrics, database telemetry, logs, workload evidence, performance analysis, recovery signals, and actionable diagnostics.
DOC
Amazon DocumentDB
MongoDB compatibility assessment, document and index migration, DMS change data capture, cutover validation, and recovery engineering.
01 Assess source, target, workload
→
02 Build repeatable infrastructure
→
03 Migrate full load + CDC
→
04 Validate data + performance
→
05 Operate observe + recover
AWS DATABASE DECISION LAB
Amazon RDS or Aurora?Flip the requirement—not a coin.
Amazon RDS supports multiple relational database engines, including Amazon Aurora. The practical decision is whether Aurora’s cloud-native architecture fits the workload better than another RDS engine.
↻ Select any card to reveal the DBA checks
01 ENGINE FIT RDS
Preserve the database engine
Oracle, SQL Server, Db2, MariaDB, MySQL, or PostgreSQL must remain the selected engine.
View DBA checks ↗
START WITH RDS
Compatibility is the requirement.
Confirm engine version, edition, options, and licensing.
Validate extensions, parameter access, storage, and tooling.
Design Multi-AZ, backups, replicas, patching, and monitoring.
Return to use case ↙
02 RESILIENCE AURORA
Build for rapid failover and read scale
A MySQL- or PostgreSQL-compatible workload needs shared cluster storage, multiple readers, and managed failover.
View DBA checks ↗
ASSESS AURORA
Architecture supports the availability goal.
Test connection recovery through the correct cluster endpoint.
Measure failover time under real application retry behavior.
Validate SQL, extensions, parameters, and replica lag.
Return to use case ↙
03 ELASTICITY SERVERLESS V2
Capacity demand changes quickly
Traffic is variable, bursty, multi-tenant, or difficult to size without overprovisioning.
View DBA checks ↗
TEST ELASTIC CAPACITY
Scaling does not remove capacity planning.
Set and test minimum and maximum Aurora Capacity Units.
Observe scale-up response, connections, memory, and cache behavior.
Model cost using the actual load profile—not idle assumptions.
Return to use case ↙
04 MULTI-REGION GLOBAL DB
Regional recovery is a business requirement
The design needs cross-Region disaster recovery or low-latency reads near global users.
View DBA checks ↗
ASSESS GLOBAL DATABASE
Async replication makes RPO measurable.
Define RTO and RPO before selecting the topology.
Monitor cross-Region lag and application endpoint behavior.
Exercise managed failover, write controls, and failback.
Return to use case ↙
05 OPERATIONS RDS
Modernize operations without changing engines
The workload is predictable and the priority is managed backups, patching, recovery, monitoring, and availability.
View DBA checks ↗
MANAGE THE EXISTING ENGINE
Reduce infrastructure work, retain engine behavior.
Compare Single-AZ, Multi-AZ instance, and cluster patterns.
Validate maintenance windows, backup retention, and restore.
Right-size compute, storage, IOPS, replicas, and observability.
Return to use case ↙
06 DECISION GATE PROVE IT
The architecture is still undecided
Both options look viable, but no measured workload, recovery, compatibility, or cost evidence exists yet.
View DBA checks ↗
RUN A CONTROLLED PROOF
Choose from evidence—not service labels.
Replay representative load and compare latency and throughput.
Test failover, restore, upgrade, extension, and connection paths.
Calculate total cost with compute, storage, I/O, replicas, and DR.
Return to use case ↙
Source discipline · AWS documentation, checked September 2026