Cloud Infrastructure Fundamentals · Module 08 of 12

Cloud databases

Understand managed relational databases, NoSQL basics, backups, Multi-AZ availability, read replicas and secure database connectivity.

Learning objectives

By the end of this module, you should be able to:

Explain what a managed relational database service operates for you and what remains your responsibility.
Distinguish Multi-AZ availability, read replicas and backups.
Recognize when a NoSQL data model may suit key/value or document access patterns.
Design private, least-privilege database connectivity and recovery controls.

Managed databases remove infrastructure work, not data ownership

The provider can operate hosts, patch service components and automate backups depending on configuration. Teams still design schemas, access controls, retention, query behavior and application recovery.

High availability and read scaling are different objectives

A synchronous or managed standby may exist primarily for failover, while read replicas can serve read traffic and may replicate asynchronously. Architecture must match the service’s documented behavior.

Backups are a recovery capability

Define recovery point objective (RPO) and recovery time objective (RTO), then configure backup frequency/retention and test restores. A backup that has never been restored is unproven.

Relational and NoSQL services optimize for different data/access models

Relational databases organize data into tables with defined relationships and SQL query semantics. NoSQL services may expose key/value, document, wide-column or other models that optimize different access patterns and scaling characteristics.

Choose from data consistency, query, transaction, scale and operational requirements—not from the label “cloud native.”

Database connectivity belongs on controlled private paths

Applications should reach databases over explicitly allowed network paths using dedicated identities/credentials. Avoid public database exposure unless a documented requirement and compensating controls justify it.

Disaster recovery strategy follows RTO, RPO, cost and complexity

Backup-and-restore is usually the lowest-cost approach but takes longer because infrastructure/data must be restored after disruption. Pilot light keeps critical data/core components ready while much of application capacity is recreated during recovery. Warm standby keeps a smaller functional environment running. Multi-site active/active serves traffic from multiple sites and can reduce recovery time further at higher cost and operational complexity.

These patterns are not interchangeable with ordinary Multi-AZ high availability. Define the failure scope first: instance, zone, region, data corruption or another event may require different recovery controls.

Worked examples

See the idea in practice.

Recovery objectives

RPO = maximum acceptable data loss window
RTO = maximum acceptable time to restore service

A 15-minute RPO does not automatically imply a 15-minute RTO.
Multi-AZ availability does not replace retained backups.

DR strategy ladder

Backup & restore → lowest steady-state cost / slower recovery
Pilot light       → core data/services ready / scale more during recovery
Warm standby      → smaller full stack already running
Multi-site active → multiple sites serve traffic / highest complexity

Tighter RTO/RPO generally requires more continuously available recovery capability.
Backups remain relevant even when replication is used because replication can copy corruption or deletion.

Core lab · Modes 1–2 · Concept + local simulation

Lab — Evaluate a database recovery policy

Goal: Calculate whether a hypothetical backup policy meets stated RPO/RTO goals.

Before you start

Python 3 only.

STEP 1

Define policy

cat > /tmp/db-recovery.json <<'EOF'
{"backup_interval_minutes":15,"retention_days":7,"restore_test_minutes":35,"required_rpo_minutes":30,"required_rto_minutes":60}
EOF

STEP 2

Evaluate

python3 - <<'PY'
import json
p=json.load(open('/tmp/db-recovery.json'))
print('RPO met:',p['backup_interval_minutes']<=p['required_rpo_minutes'])
print('RTO met:',p['restore_test_minutes']<=p['required_rto_minutes'])
assert p['backup_interval_minutes']<=p['required_rpo_minutes']
assert p['restore_test_minutes']<=p['required_rto_minutes']
PY

STEP 3

Challenge the policy

Change restore_test_minutes to 90 and rerun; identify which objective fails.

STEP 4

Select a strategy from objectives

python3 - <<'PY'
def strategy(rto_minutes,rpo_minutes):
    if rto_minutes<=5 and rpo_minutes<=1: return 'multi-site / hot standby candidate'
    if rto_minutes<=30 and rpo_minutes<=5: return 'warm standby candidate'
    if rto_minutes<=120 and rpo_minutes<=30: return 'pilot light candidate'
    return 'backup-and-restore candidate'
for x in [(240,60),(90,15),(20,5),(5,1)]: print(x,'->',strategy(*x))
PY

Verify

The original policy meets both numerical objectives.
A 90-minute restore test violates the 60-minute RTO.
You can explain why a tighter RTO/RPO generally increases continuously provisioned recovery capability, complexity or cost.

Expected outcome

You can translate recovery objectives into measurable backup/restore controls.

Diagnose / troubleshoot

If backup_interval_minutes exceeds required_rpo_minutes, the backup schedule cannot meet the stated RPO.
If measured restore_test_minutes exceeds required_rto_minutes, the recovery procedure—not the RTO target—must change or be explicitly renegotiated.
If a team chooses warm standby only because it sounds safer, ask for the failure scope, RTO/RPO and cost constraint that justify it.

Real-world connection

Production database resilience requires tested restores, credential rotation, monitoring, capacity planning and carefully managed schema changes.

Mode 3 · Optional AWS lab

Optional AWS — inspect managed database metadata

Inspect existing RDS and DynamoDB metadata without creating database capacity.

Resources created

None — this is a read-only inspection lab.

Estimated cost / risk

Expected incremental resource cost: none because the supplied commands are read-only.
Existing resources in the account can still incur their normal charges; confirm current AWS pricing for the selected Region/account.

Prerequisites

Optional sandbox AWS account and AWS CLI.
Use a least-privilege or federated identity; do not paste long-lived access keys into course files.

AWS 1

aws rds describe-db-instances --query 'DBInstances[].{Id:DBInstanceIdentifier,Engine:Engine,MultiAZ:MultiAZ,Public:PubliclyAccessible}' --output table

AWS 2

aws dynamodb list-tables --output table

Verify

Existing managed relational/NoSQL resources are visible if the sandbox contains them.
No AWS resources are created by the supplied commands.

Cleanup

No AWS cleanup is required because this lab creates no AWS resources.

Warnings

Optional only: not required for course completion or the main validator.
Do not create RDS instances for this course; database instances can incur ongoing compute/storage charges.
Do not modify Multi-AZ, backups or public-access settings in a shared environment.

Avoid these traps

Common mistakes

Treating a read replica as a guaranteed zero-loss backup.
Never testing restore procedures.
Placing database credentials directly in application source code.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does RPO measure?

The maximum acceptable amount of data loss measured in time.

2What does RTO measure?

The maximum acceptable duration to restore service after disruption.

3Why are read replicas not the same as backups?

They serve availability/read-scaling goals and can replicate logical mistakes or corruption; backups provide independent recovery points.

4Scenario: the business requires service recovery within 20 minutes with only a few minutes of acceptable data loss. Which DR pattern is a stronger starting point than backup-and-restore?

Warm standby is a strong candidate because a scaled-down functional environment is already running; the exact strategy still depends on tested service behavior, cost and failure scope.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.