AWS Database cheat sheet

Aurora keeps 6 copies of data across 3 AZs: writes need a 4-of-6 quorum and reads need 3-of-6, so the cluster survives losing an entire AZ plus one more copy without losing write availability.

Choose DynamoDB when access patterns are known up front and scale is extreme; choose Aurora/RDS when ad-hoc queries, joins, multi-statement transactions, or unknown query patterns dominate.

DynamoDB limits: item size <= 400 KB; a single partition serves roughly 3,000 RCU and 1,000 WCU, so uneven partition keys cause throttling even when table-level capacity is free.

DynamoDB GSI: eventual consistency only, own provisioned capacity, can be added or deleted at any time. LSI: must be created with the table, shares the table's capacity, supports strongly consistent reads.

DAX is a write-through, item-level in-memory cache for DynamoDB giving microsecond reads; it does not serve strongly consistent reads.

Redshift is columnar MPP: pick DISTKEY on the column used in joins to co-locate rows, SORTKEY on the column used in range filters; RA3 decouples compute from managed storage.

Purpose-built engines: Neptune for graph traversals, QLDB for an immutable verifiable ledger, Timestream for time-series, Keyspaces for Cassandra-compatible wide-column, OpenSearch for full-text search.

ElastiCache Redis supports persistence, replication, Multi-AZ failover, and rich data structures; Memcached is multithreaded with no persistence, replication, or failover.

Aurora Serverless v2 scales in fine-grained ACU increments (minimum 0.5 ACU) without downtime; Serverless v1 can scale to zero capacity when idle.

AWS DMS moves data for homogeneous and heterogeneous migrations and supports full load plus ongoing change data capture (CDC); AWS SCT converts schema, views, and stored procedures and produces an assessment report of what cannot be converted automatically.

DMS CDC from MySQL requires binary logging enabled with binlog_format=ROW and sufficient binlog retention; from PostgreSQL it requires wal_level=logical and adequate replication slots.

RDS Multi-AZ (instance) is a synchronous standby with automatic failover for high availability and does not serve read traffic; read replicas are asynchronous and exist to scale reads.

Aurora Global Database replicates at the storage layer to secondary regions with typical lag under 1 second, RPO around 1 second, and promotion of a secondary in under a minute.

RDS Blue/Green Deployments create a staging copy, replicate ongoing changes, then switch over by DNS swap, which is the standard path for major engine version upgrades with minimal downtime.

Multi-AZ DB cluster deployments (RDS for MySQL and PostgreSQL) provide two readable standbys and failover in roughly 35 seconds, unlike classic Multi-AZ instance deployments.

Migrating out of Aurora MySQL to an external MySQL is done with binary log replication, requiring binlog_format=ROW on the Aurora cluster.

AWS SCT flags objects it cannot convert (often procedural code and proprietary functions); those objects must be rewritten manually or handled by DMS during the migration.

RDS automated backups have a retention window of 0 to 35 days; setting it to 0 disables automated backups and point-in-time recovery. Manual snapshots persist until explicitly deleted.

Aurora storage grows automatically in 10 GiB increments up to 128 TiB; storage is never provisioned or sized by the operator.

Aurora Backtrack rewinds a cluster in place to an earlier point in time without restoring a snapshot, is available only on Aurora MySQL, and supports a maximum backtrack window of 72 hours.

DynamoDB on-demand backups do not consume provisioned throughput and do not affect table performance; point-in-time recovery keeps a continuous 35-day window and restores to a new table.

RDS Proxy pools and multiplexes connections, is the standard fix for Lambda connection storms, supports IAM authentication, and reduces failover time by holding client connections.

Aurora endpoints: cluster endpoint routes to the writer, reader endpoint load-balances readers, custom endpoints pin a chosen subset of instances, and instance endpoints target one instance.

DynamoDB TTL deletes expired items at no write capacity cost, with deletion typically occurring within 48 hours of expiry; DynamoDB Streams retains records for 24 hours.

Redshift takes automated snapshots roughly every 8 hours or per 5 GB of change, supports elastic resize that adds or removes nodes in minutes, and concurrency scaling adds transient clusters for burst read queries.

Core CloudWatch metrics for RDS and Aurora at 1-minute granularity: CPUUtilization, FreeableMemory, DatabaseConnections, ReadIOPS, WriteIOPS, DiskQueueDepth, and FreeStorageSpace.

Enhanced Monitoring uses an agent on the DB host to capture OS-level metrics at 1-second granularity; Performance Insights reports database load in average active sessions broken down by wait event.

Performance Insights retains 7 days of data at no cost; extended retention is configurable up to 731 days.

Aurora exposes ReplicaLag in milliseconds; sustained lag above roughly 100 ms or a saturated replica CPU indicates the replica cannot keep up with the writer.

For DynamoDB monitor ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, and SuccessfulRequestLatency; Contributor Insights identifies the most accessed and most throttled partition keys.

RDS event subscriptions publish SNS notifications for failover, low storage, backup failure, and maintenance events without polling the API.

CloudTrail records control-plane API activity; row-level or statement-level auditing requires engine logs such as Aurora advanced auditing or the pgaudit extension.

Export slow query and general logs to CloudWatch Logs and tune log_min_duration_statement on PostgreSQL or slow_query_log with long_query_time on MySQL to catch regressions.

RDS and Aurora encryption at rest is chosen at creation time; to encrypt an existing unencrypted instance, take a snapshot, copy the snapshot with encryption enabled, then restore from the encrypted copy.

Encryption at rest uses AWS KMS keys (AWS managed or customer managed); an unencrypted snapshot cannot be restored directly onto an encrypted instance without first copying it with encryption.

IAM database authentication is supported on RDS for MySQL and PostgreSQL and on Aurora; clients request a short-lived token valid for 15 minutes instead of storing a password.

Secrets Manager provides native automatic rotation for RDS and Aurora credentials through a Lambda rotation function on a configurable schedule.

DynamoDB data is always encrypted at rest, using an AWS owned key, an AWS managed key, or a customer managed KMS key selected at table creation.

DynamoDB fine-grained access control uses IAM condition keys: dynamodb:LeadingKeys restricts which partition key values a principal can touch, and dynamodb:Attributes restricts readable or writable attributes.

Enforce encryption in transit with rds.force_ssl=1 for PostgreSQL, require_secure_transport=ON for MySQL and Aurora, and in-transit encryption enabled on ElastiCache replication groups.

Keep databases in private subnets and control access with security groups that reference other security groups; use VPC gateway endpoints for DynamoDB and S3 so traffic never traverses a NAT gateway or the internet.

AWS Config rules and Security Hub evaluate database resource compliance continuously, while GuardDuty flags anomalous access such as unusual RDS login patterns.