| Relational Database Service (RDS) | • managed relational DB service → AWS handles provisioning, patching, backups, failover, scaling • engines → MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, plus Aurora • runs on an EC2 instance class you choose, with EBS storage (storage autoscaling available) • scale up by resizing the instance; scale reads with read replicas; HA with Multi-AZ • you own schema, queries, tuning; AWS owns the undifferentiated admin • not serverless (except Aurora Serverless) → you pay for the running instance • exam → "managed relational DB, reduce admin overhead" = RDS | | --- | --- | | RDS multi AZ deployments | • HA feature → synchronous standby replica in a different AZ • automatic failover (~60-120s) on AZ outage, instance failure, or maintenance • standby is not readable → availability/DR only, not read scaling • same endpoint → DNS flips to the standby on failover (transparent to the app) • Multi-AZ DB cluster → newer option with 2 readable standbys + faster failover • exam → "high availability / automatic failover" = Multi-AZ; "scale reads" = read replicas | | RDS read replicas | • asynchronous read-only copies → scale read-heavy workloads • up to 15 (Aurora) / 5 (other engines); can be cross-region • each has its own endpoint → app directs reads there • can be promoted to a standalone read/write DB (breaks replication) • cross-region replica → aids DR + lowers read latency for distant users • exam → "offload / scale reads" = read replica (not Multi-AZ) | | synchronous vs asynchronous replicas | • synchronous → write is confirmed only after the standby also commits ◦ zero data loss; used by Multi-AZ standby + Aurora storage ◦ small write-latency cost • asynchronous → the replica catches up after the primary writes ◦ used by read replicas ◦ possible replica lag → eventually consistent reads • exam → Multi-AZ = synchronous (HA/durability); read replica = asynchronous (scaling) | | RDS backups + snapshots | • automated backups → daily full + transaction logs → point-in-time recovery (PITR) ◦ retention 1-35 days (0 disables); stored in S3 • manual snapshots → user-triggered, kept until you delete them (survive DB deletion) • restoring always creates a new DB instance with a new endpoint • snapshots can be copied + shared across regions/accounts • exam → keep backups beyond 35 days = manual snapshot; recover to a moment in time = automated backups/PITR | | RDS encryption | • at rest → AWS KMS (AES-256); covers the DB, automated backups, snapshots, + read replicas • must enable at creation → to encrypt an existing DB: snapshot it, copy the snapshot as encrypted, restore • in transit → SSL/TLS • encrypted snapshot → encrypted restore; replicas inherit encryption • exam → "encrypt an existing unencrypted RDS" = snapshot → copy with encryption → restore | | Amazon Aurora | • AWS cloud-native relational DB, MySQL + PostgreSQL compatible • up to 5x MySQL / 3x PostgreSQL throughput at ~1/10 the cost of commercial DBs • storage auto-scales in 10 GB increments up to 128 TB • 6 copies of data across 3 AZs, self-healing • up to 15 low-latency read replicas + fast failover • fully managed, distributed, fault-tolerant storage • exam → "MySQL/Postgres-compatible, high performance + availability, managed" = Aurora | | aurora architecture | • compute (DB instances) is separated from a shared distributed storage volume • storage → 6 copies across 3 AZs; writes acknowledged by a 4-of-6 quorum • single writer (primary) + up to 15 readers share the same storage → minimal replica lag • cluster endpoint (writes) + reader endpoint (load-balanced reads) • continuous backup to S3, self-healing storage • failover → a reader is promoted in ~30s • exam → shared storage is why Aurora replicas are faster + lag-free vs RDS | | aurora serverless | • auto-scales DB capacity (ACUs) up/down with load → no instance sizing • v2 → fine-grained, fast scaling; supports replicas, Multi-AZ, + global (production-grade) • pay per ACU-second consumed • use for → variable, unpredictable, intermittent workloads, dev/test • exam → "unpredictable or spiky DB load, don't want to manage capacity" = Aurora Serverless | | aurora global database | • 1 primary region + up to 5 secondary (read-only) regions • storage-level replication, typically < 1s lag • DR → promote a secondary region in < 1 min (RTO), RPO ~1s • low-latency global reads + cross-region resilience • exam → "global reads + cross-region DR for a relational DB" = Aurora Global Database | | Amazon DynamoDB | • fully managed, serverless NoSQL key-value + document database • single-digit millisecond latency at any scale; auto-scales, no servers • multi-AZ by default; 99.999% availability with global tables • virtually unlimited throughput + storage • integrates with Lambda (streams), IAM, point-in-time recovery • exam → "serverless NoSQL, massive scale, low latency, no admin" = DynamoDB | | dynamodb data model | • table → items (rows) → attributes (fields); schemaless beyond the key • primary key: ◦ partition key (hash) → decides which partition stores the item ◦ optional sort key (range) → composite key, orders items within a partition • items ≤ 400 KB; choose a high-cardinality partition key to spread load • exam → good partition key = even distribution; bad key = throttled hot partition | | dynamodb secondary indexes | • Global Secondary Index (GSI) → different partition + sort key ◦ own capacity, eventually consistent, can add anytime • Local Secondary Index (LSI) → same partition key, different sort key ◦ shares table capacity, supports strong consistency, must be created with the table • indexes let you query on non-key attributes • exam → query a non-key attribute after creation = GSI; strong consistency on an alt sort key = LSI | | dynamodb capacity modes | • On-Demand → pay per request, instant scaling, no planning → unpredictable/spiky traffic, new apps • Provisioned → set RCUs + WCUs (with optional auto scaling) → predictable traffic, cheaper at steady high volume • 1 RCU = 1 strong (or 2 eventual) reads/s of 4 KB; 1 WCU = 1 write/s of 1 KB • exam → spiky/unknown = on-demand; steady + cost-sensitive = provisioned | | dynamodb read consistency | • eventually consistent (default) → may miss a very recent write; cheaper, higher throughput • strongly consistent → always the latest data; costs 2x RCU, slightly higher latency, not available on GSIs • transactional reads/writes → ACID across multiple items • exam → "must read the latest write" = strongly consistent read | | dynamodb streams | • ordered, time-sequenced change log of item-level changes (insert/update/delete) • 24-hour retention; triggers Lambda for event-driven processing • use for → replication, aggregations, notifications, audit, global tables • exam → "react to a DynamoDB change / trigger a function on write" = Streams + Lambda | | dynamodb accelerator (DAX) | • fully managed in-memory cache purpose-built for DynamoDB • microsecond read latency (vs single-digit ms), no app rewrite (DynamoDB-compatible API) • write-through cache; for read-heavy + bursty workloads • not for strongly consistent reads (pass through) or write-heavy apps • exam → "speed up DynamoDB reads to microseconds with minimal code change" = DAX | | Amazon ElastiCache | • managed in-memory cache (Redis / Memcached) → microsecond latency • offloads read-heavy DB workloads; stores sessions, leaderboards, real-time data • reduces DB load + cost; you add cache logic in the app • strategies → lazy loading (cache-aside), write-through, TTL • exam → "reduce DB load / sub-ms reads for any database" = ElastiCache | | Elasticach engines | • Redis → persistence, replication, Multi-AZ failover, backups, pub/sub, sorted sets, transactions, geospatial ◦ use for → HA caching, leaderboards, sessions, rich data types • Memcached → simple, multi-threaded, horizontally scalable, no persistence/replication ◦ use for → simple key-value caching, scale-out across nodes • caching patterns: ◦ lazy loading (cache-aside) → load on a miss; data can be stale ◦ write-through → write cache + DB together; fresh but extra writes ◦ TTL → expire keys to bound staleness • exam → need persistence/HA/replication = Redis; simplest scale-out cache = Memcached | | elasticach vs dynamodb dax | • DAX → purpose-built cache for DynamoDB only; transparent (same API, no app logic) • ElastiCache → general-purpose cache for any data source; you write the cache logic • exam → cache DynamoDB with no code changes = DAX; cache RDS/other or custom data = ElastiCache |