AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 53“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

RDS, Aurora and DynamoDB Operations

TechLearningPro’s learner profiles, enrollments, and session metadata do not care how elegant your TGW matrix is if the database is single-AZ, unrestored, or throttling during exam

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

RDS, Aurora and DynamoDB Operations

AWS Cloud & DevOps Engineering · Lesson 53 · Advanced Platforms and Networking

Lesson Overview

TechLearningPro’s learner profiles, enrollments, and session metadata do not care how elegant your TGW matrix is if the database is single-AZ, unrestored, or throttling during exam week. This lesson is an operations lens on Amazon RDS, Amazon Aurora, and Amazon DynamoDB: Multi-AZ and failover behavior, backup/restore and point-in-time recovery concepts, read replica roles, Aurora storage and cloning awareness, DynamoDB on-demand vs provisioned capacity (and autoscaling concepts), PITR and TTL ops concerns, and the alarms/runbooks operators live by. It deliberately does not deep-dive relational modeling or DynamoDB single-table design—those belong in application courses and /learn/dynamodb—nor lakehouse pipelines in /learn/data-engineering. You will leave with checklists that keep data services reliable, restorable, and cost-honest inside the accounts and private networks built in lessons 48–52.

Continuity: HA/DR from High Availability and Backup & DR, encryption from KMS, FinOps from lesson 47, private data paths from PrivateLink/endpoints. Tag Project=tlp-lesson53. Databases are expensive when left on—budgets first; snapshot-and-destroy labs; never load production learner PII into sandbox.

Learning Objectives

Position RDS vs Aurora vs DynamoDB as operational platforms (not schema workshops).
Explain RDS Multi-AZ standby failover concepts per engine family awareness.
Operate automated backups, retention, and PITR for RDS/Aurora.
Distinguish read replicas from Multi-AZ standbys (purpose and lag).
Describe Aurora storage durability/replication across AZs at a conceptual level.
Use Aurora cloning and backtrack concepts where applicable—verify feature availability per engine/version in docs.
Choose DynamoDB on-demand vs provisioned capacity with traffic pattern reasoning.
Configure DynamoDB autoscaling concepts for provisioned tables.
Enable DynamoDB PITR and explain restore-to-new-table operational impact.
Apply TTL operationally (cleanup jobs vs TTL; restore implications).
Place databases in private subnets with SG least privilege and endpoint strategies.
Build CloudWatch alarm sets for CPU, storage, connections, throttling, replica lag.
Plan restore drills that meet RPO/RTO narratives from lesson 45.
Estimate cost dimensions (instance hours, storage, I/O, RCUs/WCUs, backups)—verify pricing pages.
Troubleshoot failover storms, storage-full, and hot-partition throttling (ops symptoms).
Document maintenance windows and minor version strategies.
Prepare interview answers comparing managed SQL vs DynamoDB ops trade-offs.
Clean up lab DB instances/tables; keep budgets on.

Prerequisites

VPC private subnet literacy; IAM/KMS basics; lessons 45–47 resilience and cost habits.
Sandbox account for small RDS/Aurora/DynamoDB labs or design-only if quotas block.
No production data in student labs.

Detailed Core Concepts

Operational selection (short)

RDS — managed engines (PostgreSQL, MySQL, etc.) with familiar admin knobs; good for relational workloads TechLearningPro already modeled relationally.
Aurora — MySQL/PostgreSQL-compatible cloud-native storage layer with faster crash recovery/replication characteristics; ops differ (storage autoscales conceptually; replicas share storage).
DynamoDB — serverless key-value/document at any documented scale; ops center on capacity, throttling, PITR, global tables awareness—not SQL admin.

Deep modeling → /learn/dynamodb. Analytics warehouses → later lessons / /learn/data-engineering.

RDS Multi-AZ

Synchronous standby in another AZ (behavior details per engine—confirm docs). Failover updates DNS endpoint; clients must reconnect. This is HA, not read scaling. Maintenance and AZ impairment are why you buy Multi-AZ for prod.

Backups and PITR (RDS/Aurora)

Automated backups + transaction logs enable point-in-time restore within retention. Manual snapshots for milestones. Test restores—untagged snapshots are FinOps zombies and false comfort.

Read replicas

Asynchronous copies for read scale or cross-Region DR patterns. Lag is real; do not send strong read-after-write to replicas without application awareness.

Aurora ops highlights

Cluster endpoints (writer/reader), storage distributed across AZs, fast replica addition, cloning for brief nonprod refreshes (watch cost/process). Backtrack availability depends on configuration—verify before teaching as universal.

DynamoDB capacity modes

On-demand — pay per request; absorbs spiky unknown traffic; verify current billing model.
Provisioned — set RCU/WCU; optional autoscaling; cheaper for steady predictable traffic when right-sized—check pricing.

Hot partitions cause throttling even when table-level capacity looks fine—ops must watch per-partition symptoms and work with developers (without redesigning the table here).

DynamoDB PITR and TTL

PITR restores to a new table (operational cutover plan required). TTL expires items asynchronously—good for session cleanup; not a substitute for legal hold strategy.

Networking and security ops

Private subnets; SG allow only app tiers; IAM auth options where supported; KMS encryption; Secrets Manager for SQL credentials rotation (continuity). DynamoDB gateway endpoints from lesson 50 reduce NAT dependence.

Architecture and Design Diagrams

mermaid
flowchart TB
  App[App tier multi-AZ]
  RDSmulti[RDS Multi-AZ writer DNS]
  Standby[Standby AZ]
  Replica[Read replica optional]
  Aurora[Aurora writer + readers]
  DDB[DynamoDB table]
  Backup[Automated backups / PITR]
  Alarms[CloudWatch alarms]

  App --> RDSmulti
  RDSmulti --- Standby
  App --> Replica
  App --> Aurora
  App --> DDB
  RDSmulti --> Backup
  Aurora --> Backup
  DDB --> Backup
  RDSmulti --> Alarms
  Aurora --> Alarms
  DDB --> Alarms

mermaid
flowchart LR
  Spike[Traffic spike]
  Mode{Capacity mode}
  OD[On-demand absorbs]
  Prov[Provisioned + autoscaling]
  Throttle[Throttling / hot key]
  Spike --> Mode
  Mode --> OD
  Mode --> Prov
  Prov --> Throttle

Technical Explanation

Failover client behavior

On RDS/Aurora failover, connection pools must recycle. Set timeouts, retry with jitter, and prefer endpoints AWS documents for your API (cluster vs instance endpoints). Test failover in stage during a game day (lesson 40 continuity).

Storage-full and autoscale

RDS storage-full freezes writes—alarm free storage early; understand storage autoscaling features where enabled (verify). Aurora storage manages growth differently—still monitor volume and costs.

Parameter groups and maintenance

Track custom parameters; schedule maintenance windows away from exam peaks; decide auto minor version upgrade policy consciously.

DynamoDB autoscaling and accounting

Autoscaling acts on CloudWatch—rapid spikes may still throttle briefly. On-demand simplifies ops for spiky student traffic. Global tables (awareness) add multi-Region ops complexity and cost—only when product needs them; verify current conflict semantics in docs.

Backup encryption and access

Snapshots inherit encryption; cross-account/Region copy needs KMS grants (lesson 41). Restrict who can share/copy snapshots—data exfil path.

Performance ops (not schema design)

Watch CPUUtilization, DatabaseConnections, FreeStorageSpace, ReplicaLag, DynamoDB ThrottledRequests, ConsumedReadCapacityUnits—confirm metric names in current docs. Correlate with TGW/latency only after DB metrics.

Cost dimensions

RDS/Aurora: instance class hours, Multi-AZ duplication, storage, I/O (engine-dependent), backups, data transfer. DynamoDB: mode-specific request/capacity charges, storage, PITR, streams if enabled. Always open current pricing pages before savings claims. Idle Multi-AZ lab DBs are FinOps anti-patterns.

Security ops

Publicly accessible DB flags must stay off in TechLearningPro prod. Rotate credentials; prefer IAM DB auth where suitable; audit with CloudTrail for modify/delete. Continuity with Config rules detecting public DB snapshots.

Practical Implementation or Design Walkthrough

Problem

Create an operational checklist and scaling strategy for TechLearningPro: RDS/Aurora Multi-AZ prod posture + DynamoDB capacity mode choice for session store.

Steps

Budget; tag Project=tlp-lesson53.
Pick one relational candidate (enrollments) and one DynamoDB candidate (sessions)—ops only.
Checklist: Multi-AZ, backup retention, encryption, private SG, alarms, maintenance window.
DynamoDB: choose on-demand vs provisioned with written traffic assumptions; enable PITR in stage.
Run a restore drill to a scratch instance/table; record time-to-available; delete scratch.
Optional: small RDS Multi-AZ lab failover observe; destroy.
ADR: when to prefer Aurora vs RDS for new microservices ops criteria.
Cleanup all lab DB resources; budgets on.

Enterprise Real-World Scenarios

Exam-week throttle

Provisioned DynamoDB session table throttled. Short-term: raise WCU / switch on-demand (verify process); long-term: work with app team on keys (/learn/dynamodb)—ops owns the incident bridge.

Untested backup

Restore failed due to missing parameter group/option group. Game day now mandatory quarterly.

Replica used as HA

Team thought read replica equaled Multi-AZ. AZ loss of primary caused outage. Education + Multi-AZ enablement.

Snapshot sprawl

Hundreds of manual snapshots. Lifecycle policy + FinOps showback.

Public RDS lab

Student left publicly accessible true. SCP/Config detect; incident; rotate credentials.

Best Practices

Multi-AZ for prod relational writers.
Private subnets only; no public accessible.
Encrypt with KMS; manage key policy.
Alarm storage, CPU, connections, throttles, lag.
Test PITR/restore drills.
Separate Multi-AZ HA from read replicas.
Match DynamoDB capacity mode to traffic shape.
Enable PITR for critical DynamoDB tables.
Tag Owner/Environment/Project on all DB resources.
Maintenance windows avoid peak exams.
Credentials in Secrets Manager with rotation where supported.
Gateway endpoints for DynamoDB.
Delete lab DBs same day.
Verify engine-specific failover docs before runbooks.
Price-check before “savings” by removing Multi-AZ.

Common Mistakes and Anti-Patterns

Single-AZ prod RDS.
Never-tested backups.
Using replicas as the HA story.
Publicly accessible databases.
Ignoring FreeStorageSpace alarms.
Provisioned DynamoDB without autoscaling on variable traffic.
Assuming table-level capacity fixes hot keys alone.
Leaving Multi-AZ labs running idle.
Inventing Aurora feature availability for all engines.
Restoring PITR over production without cutover plan.

Troubleshooting and Design Review

Symptom	Cause	Action
Failover app errors	Stale connections	Recycle pools; retries
Storage-full	Growth / no alarm	Expand/autoscale; alarm
Replica lag high	Load/network	Reduce replica reads; size up; check metrics
DynamoDB throttling	Capacity / hot key	Adjust mode/capacity; engage app for keys
Restore slow	Size/class	Pre-plan class; measure drills
Auth failures after rotate	Secret not refreshed	Fix rotation consumers

Interview Questions and Answers

Q1: Multi-AZ vs replica? A: Multi-AZ is synchronous HA standby; replica is async read/DR scale.
Q2: Aurora difference ops-wise? A: Shared storage layer, cluster endpoints, fast replica ops—verify engine docs.
Q3: DynamoDB on-demand vs provisioned? A: Spiky/unknown vs steady predictable—price-check.
Q4: PITR DynamoDB? A: Restore to new table; plan cutover.
Q5: First RDS alarm? A: Free storage, CPU, connections among core set.
Q6: Failover client need? A: Reconnect to endpoint; retries/timeouts.
Q7: TTL purpose? A: Expire items asynchronously for lifecycle.
Q8: Why private SG? A: Reduce attack surface; only app tiers.
Q9: Snapshot risk? A: Exfil via share; encrypt and restrict.
Q10: Hot partition symptom? A: Throttling despite spare table capacity.
Q11: FinOps trap? A: Idle Multi-AZ labs and snapshot pileups.
Q12: When global tables? A: Multi-Region needs—with ops complexity justified.
Q13: Link to endpoints? A: DynamoDB gateway endpoints for private path.
Q14: Restore drill metric? A: Measured time-to-usable vs RTO.
Q15: Modeling course? A: Point to /learn/dynamodb—not this lesson.

Hands-On Exercises

Exercise: Operational checklist and scaling strategy

Deliverable: RDS/Aurora prod ops checklist, DynamoDB capacity ADR, alarm list, restore drill evidence, network/SG notes, cleanup, budget.

Challenge ADR

Constraint: exam-week traffic 10× baseline for sessions; enrollments steady. Justify DynamoDB on-demand for sessions and Multi-AZ RDS sizing ethics (no invented prices).

Lab evidence checklist

Checklist; restore timing; alarm screenshots; destroy proof; pricing page dates for any cost notes.

Narrative: the replica myth

On-call treated a cross-AZ replica as Multi-AZ. Primary AZ event took writes down. Postmortem added Multi-AZ and training.

Continuity

Next module lessons continue advanced data (S3 design, Glue/Athena, Redshift). Cross-link /learn/dynamodb and /learn/data-engineering for modeling and pipelines without cloning them here.

Deep dive: blue/green / cloning refresh awareness

Aurora cloning or RDS blue/green features (where available) for safer upgrades—verify current feature names and limits in docs before ADRs.

Deep dive: connection pooling under failover

PgBouncer/Proxy patterns (e.g., RDS Proxy awareness)—confirm capabilities in docs; pools must survive failover DNS changes.

Deep dive: DynamoDB Streams ops tease

Streams enable async consumers; ops owns shard iterator age alarms—app owns consumer logic. Do not expand into full event-driven course here.

Extended enterprise scenario: compliance restore proof

Auditor asks for evidence of quarterly restore. Keep dated drill reports with RTO measurements—not slideware.

Extended enterprise scenario: cost vs HA debate

Finance questions Multi-AZ. Show exam outage cost narrative + delete idle sandboxes the same week (lesson 47 style).

Extended practice scenario 1 — 53 rds aurora and dynamodb operations

Write prod RDS/Aurora ops checklist (≥15 items) for TechLearningPro enrollments DB.

In a timed drill for RDS, Aurora, and DynamoDB operations, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: ops checklists, capacity ADRs, restore timings, alarm configs, destroy confirmation, and destroy confirmation for any lab resources.

Discuss how this lesson connects to HA/DR (45–46), FinOps (47), KMS (41), PrivateLink/endpoints (50), /learn/dynamodb and /learn/data-engineering. List two failure modes you simulated or observed (storage-full; DynamoDB throttling), including detection and fix. Note which billable dimensions may move and when Cost Explorer would show them—verify current pricing pages; never invent rates.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating multi-account networking and data platforms as mystery consoles.

Extended practice scenario 2 — 53 rds aurora and dynamodb operations

DynamoDB capacity mode ADR for session store with traffic assumptions labeled illustrative.

Extended practice scenario 3 — 53 rds aurora and dynamodb operations

Restore drill: PITR or snapshot to scratch; time it; destroy scratch.

Extended practice scenario 4 — 53 rds aurora and dynamodb operations

Alarm pack: list metrics for RDS and DynamoDB; cite docs for metric names.

Extended practice scenario 5 — 53 rds aurora and dynamodb operations

Failover game day plan for stage Aurora/RDS.

Extended practice scenario 6 — 53 rds aurora and dynamodb operations

SG design: app SG → DB SG 5432/3306 only; no 0.0.0.0/0.

Extended practice scenario 7 — 53 rds aurora and dynamodb operations

Enable DynamoDB PITR in lab table; document restore-to-new-table cutover steps.

Extended practice scenario 8 — 53 rds aurora and dynamodb operations

TTL ops note for session expiry vs legal hold data.

Extended practice scenario 9 — 53 rds aurora and dynamodb operations

Snapshot lifecycle policy proposal to curb sprawl.

Extended practice scenario 10 — 53 rds aurora and dynamodb operations

Compare Multi-AZ cost qualitatively vs outage risk—pricing page footnotes.

Extended practice scenario 11 — 53 rds aurora and dynamodb operations

Hot partition incident bridge script (ops questions for developers).

Extended practice scenario 12 — 53 rds aurora and dynamodb operations

Secrets rotation consumer checklist for RDS password.

Extended practice scenario 13 — 53 rds aurora and dynamodb operations

Private networking: DynamoDB gateway endpoint confirmation in VPC.

Extended practice scenario 14 — 53 rds aurora and dynamodb operations

Maintenance window calendar vs exam schedule worksheet.

Extended practice scenario 15 — 53 rds aurora and dynamodb operations

Aurora cloning awareness lab or design for nonprod refresh.

Extended practice scenario 16 — 53 rds aurora and dynamodb operations

RDS Proxy / pooling awareness research with doc links only.

Extended practice scenario 17 — 53 rds aurora and dynamodb operations

Tag audit: find untagged DB resources in lab account.

Extended practice scenario 18 — 53 rds aurora and dynamodb operations

Public accessibility Config rule intent—link lesson 44.

Extended practice scenario 19 — 53 rds aurora and dynamodb operations

Global tables go/no-go criteria one-pager.

Extended practice scenario 20 — 53 rds aurora and dynamodb operations

Teach-back: Multi-AZ vs read replica in two minutes.

Extended practice scenario 21 — 53 rds aurora and dynamodb operations

FinOps: list idle lab DB candidates; delete with evidence.

Extended practice scenario 22 — 53 rds aurora and dynamodb operations

Cross-link reading assignment: one /learn/dynamodb ops-adjacent page without copying content.

Extended practice scenario 23 — 53 rds aurora and dynamodb operations

Budget pre-check before creating Multi-AZ instances.

Extended practice scenario 24 — 53 rds aurora and dynamodb operations

Cleanup sworn list for instances, replicas, tables, snapshots.

Extended practice scenario 25 — 53 rds aurora and dynamodb operations

Dress rehearsal: checklist + capacity ADR + restore drill + alarms + destroy.

Compliance evidence pack for auditors / Finance

Backup retention configs; restore drill reports; encryption evidence; Multi-AZ screenshots; alarm configs; capacity ADRs; pricing verification dates; cleanup records.

Glossary drill

RDS Multi-AZ; failover; automated backup; PITR; read replica; Aurora cluster endpoint; Aurora cloning; DynamoDB on-demand; provisioned capacity; RCU/WCU; autoscaling; hot partition; TTL; DynamoDB PITR; RDS Proxy (awareness).

Budget and cleanup sworn statement

I verified budgets remain enabled. I deleted lab RDS/Aurora/DynamoDB resources and scratch restores named ____. I did not use production PII. I invented no prices or APIs. Signed ________ date ________.

Interview story to memorize

“For TechLearningPro we run Multi-AZ relational stores with tested PITR drills and tight SGs, pick DynamoDB on-demand for spiky session traffic with PITR enabled, alarm throttling and free storage, keep modeling discussions in the DynamoDB course, and never confuse read replicas with HA.”

Self-assessment rubric

Area	Weight
HA/backup ops correctness	25%
DynamoDB capacity ops	20%
Alarming and restore drills	20%
Security/network placement	20%
FinOps + cleanup	15%

Final synthesis before summary

Operators do not win by memorizing SQL dialects; they win by making failover boring, restores proven, capacity matched to reality, and costs tagged. Modeling excellence elsewhere still fails if ops is theater.

Lesson Summary

Operate RDS/Aurora with Multi-AZ, tested backups/PITR, replicas used correctly, private networking, and alarms; operate DynamoDB with deliberate capacity modes, PITR, TTL awareness, and throttle response—without turning this lesson into a modeling course. Point deeper design to /learn/dynamodb and analytics to /learn/data-engineering. Tag Project=tlp-lesson53; destroy lab databases; verify pricing.

Next: continue Module 5 with advanced S3 and analytics lessons (see course roadmap)—carry multi-account and private networking habits forward.