Thursday, June 4, 2026

Cohort 3 | Project CloudIgnite Topics: Amazon RDS, Amazon Aurora, Amazon DynamoDB Duration: ~3 hours

Key Takeaways

• Amazon RDS: fully managed relational DB; AWS handles patching, backups, scaling, hardware
• Multi-AZ = high availability (failover); Read Replica = scalability (read performance) — this distinction is heavily tested
• Amazon Aurora: AWS-native RDS engine; MySQL/PostgreSQL compatible; faster; slightly more expensive
• DynamoDB: fully managed NoSQL; key-value store; flexible schema (no ALTER TABLE needed)
• DynamoDB partitioning: partition key determines storage location; sort key orders items within partition
• DynamoDB Global Tables: multi-region replication for low latency and disaster recovery
• DAX: in-memory cache for DynamoDB (like Redis, but DynamoDB-specific)
• Labs 274–275: Aurora MySQL-compatible cluster + DynamoDB table creation and querying

Table of Contents

1. Amazon RDS (Relational Database Service)
2. Multi-AZ vs. Read Replicas
3. RDS Scaling
4. Amazon Aurora
5. Amazon DynamoDB
6. DynamoDB: Keys & Partitioning
7. DynamoDB: Global Tables & DAX
8. Lab Summary
9. CLF-C02 Exam Highlights

1. Amazon RDS

What is RDS?

• Managed relational database service — AWS handles setup, patching, backups, and hardware.
• Think of it as an EC2 instance dedicated exclusively to running a database server.
• Supports multiple database engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora.

Why Use RDS Over Self-Managed DB?

Key RDS Features

• Massive storage scalability — storage can grow and shrink automatically.
• High availability — managed by AWS as part of the service.
• Automatic backups — configurable backup windows; snapshots stored in S3.
• Database monitoring — built-in performance monitoring.
• Fully managed — no need to manage OS, software, or hardware upgrades.

DB Instance Classes (similar to EC2 instance types)

• General Purpose: T3
• Memory Optimized: M, R
• High Performance: X

Storage Types

Creating an RDS Instance — Two Methods

• Easy Create — Minimal configuration; uses AWS recommended best practices.
• Standard Create (Full Configuration) — You configure everything: availability, security, backup, maintenance.

2. Multi-AZ vs. Read Replicas

📝 Exam Tip — This is a frequently asked question on the CLF-C02 exam.

Multi-AZ Deployment

• Purpose: High Availability / Resilience
• Deploys a primary instance and a standby instance in different Availability Zones.
• Data is synchronously replicated from primary to standby.
• If the primary fails → traffic automatically redirects to the standby instance (failover).
• The standby is NOT used for read or write operations while the primary is healthy — it exists purely as a failover.

Primary DB (AZ-1)  ←──── All traffic
      ↓ (sync replication)
Standby DB (AZ-2)  ←──── Only used if primary fails

Read Replicas

• Purpose: Scalability / Performance
• Creates one or more copies of the database that can serve read (SELECT) queries.
• Write operations still go to the primary instance only.
• If your app is read-heavy, traffic is distributed across replicas, reducing load on the primary.

Primary DB  ←── All WRITE operations
  ↓   ↓   ↓
Replica 1  Replica 2  Replica 3  ←── READ operations distributed

Key Difference Summary

3. RDS Scaling

• Vertical Scaling (Scale Up): Change the DB instance class (e.g., T3 → M5) to increase CPU/RAM.
• Storage Scaling: Increase storage capacity on an existing instance with zero downtime (unlike EBS volumes on EC2, which require stopping the instance).

4. Amazon Aurora

What is Aurora?

• Amazon's proprietary, cloud-native relational database engine.
• Part of the RDS family — it IS an RDS database engine.
• Compatible with MySQL and PostgreSQL — existing tools and applications work without modification.
• Generally faster than standard MySQL/PostgreSQL on RDS.
• Slightly more expensive, but offers more features.

Aurora Clusters

• Aurora can be deployed as a cluster (one or more instances grouped together).
• Primary DB Instance — handles both reads and writes.
• Aurora Replica — read-only instances (similar to RDS Read Replicas).
• Aurora uses read endpoints and writer endpoints to route traffic appropriately.
• Aurora automatically maintains availability, typically across multiple Availability Zones.

Aurora Use Cases

• Enterprise applications
• SaaS (Software as a Service) platforms
• Online and mobile gaming

Aurora vs. Other RDS Engines (Quick Comparison)

5. Amazon DynamoDB

What is DynamoDB?

• AWS's fully managed NoSQL database service.
• Data is stored as key-value pairs — similar to a Python dictionary or JSON object.
• No fixed schema — different items in the same table can have completely different attributes.

NoSQL vs. SQL — Key Differences

DynamoDB Terminology

Flexible Schema Example

Item 1: { ID, Name, Email, Password }           ← 4 attributes
Item 2: { ID, Name, Age }                       ← 3 attributes
Item 3: { ID, Name, Email, Hobbies, FavColor }  ← 5 attributes

All three can live in the same table — no schema changes required.

Primary Key

• Every DynamoDB table must have a primary key.
• Simple Primary Key — single attribute (Partition Key only).
• Composite Primary Key — two attributes combined: Partition Key + Sort Key.

6. DynamoDB: Keys & Partitioning

Partition Key

• Determines which partition (physical storage segment) the item is stored in.
• DynamoDB uses the partition key to distribute data across partitions for fast retrieval.
• Analogy: Like a hotel floor number — you go directly to floor 5 (partition) rather than searching every floor.

Sort Key

• Used within a partition to order items for efficient range queries.
• Together with the Partition Key, forms a Composite Primary Key.
• Analogy: Like the room number within a floor — once on floor 5, you find room 510.

How Partitioning Speeds Up Queries

Without partitioning: Search through 5,000,000 items
With 5 partitions:    Know data is in Partition 3 → search only 1,000,000 items

Key Rules

• No two items can share the same composite key (Partition Key + Sort Key combination).
• The partition key alone does not have to be unique when a sort key is also defined.

7. DynamoDB: Global Tables & DAX

Global Tables

• Replicates your DynamoDB table across multiple AWS Regions worldwide.
• Reduces read/write latency — requests go to the nearest region automatically.
• Provides disaster recovery — if one region fails, another region's replica handles traffic.

DAX (DynamoDB Accelerator)

• In-memory caching layer built specifically for DynamoDB.
• Dramatically improves read performance by serving data from RAM instead of disk.
• Similar concept to Redis/Memcached, but tightly integrated with DynamoDB.

Other DynamoDB Features

• Automatic encryption of data at rest.
• Automatic backups and cross-region replication.
• Combines scalability, availability, and fault tolerance by design.

8. Lab Summary

Lab 274 — Introduction to Aurora

Steps performed:

1. Created an Aurora MySQL-Compatible database cluster in RDS.
   • Template: Dev/Test | Class: db.t3.medium (Burstable)
   • Cluster identifier: aurora | Username: admin
   • VPC: Lab VPC | Subnet Group: DB Subnet Group
   • Public access: No | Security Group: DB Security Group
   • Initial database name: world
2. Launched an EC2 instance and connected via SSM Session Manager.
3. Installed mariadb client: sudo yum install mariadb
4. Connected to Aurora using the writer endpoint:

   mysql -u admin -padmin123 -h <writer-endpoint>
   

5. Ran SQL commands — confirmed Aurora accepts standard MySQL syntax.
6. Explored writer vs. reader endpoints in the RDS console.

Key Takeaway: Aurora behaves like MySQL once connected — all standard SQL commands work as expected.

Lab 275 — Introduction to DynamoDB (partially explored)

Steps performed:

1. Navigated to DynamoDB → Tables → Create Table.
2. Created table music with:
   • Partition Key: artist (String)
   • Sort Key: song (String)
3. Created items with varying attributes (flexible schema demonstrated):

   Item 1: { artist, song, album, year }
   Item 2: { artist, song, album }
   Item 3: { artist, song, length, year }
   

4. Added and modified attributes on existing items.
5. Performed a Query (filter by partition key + sort key).
6. Performed a Scan (filter by any attribute, e.g., year = 1971).
7. Deleted the table via the console.

Key Takeaway: DynamoDB's flexible schema means you can add/remove attributes per item without altering the table. Query uses the primary key (fast); Scan checks all items (slower for large tables).

CLF-C02 Exam Highlights

The following concepts from this lecture are directly relevant to the AWS Certified Cloud Practitioner exam:

Quick Memory Aid

Multi-AZ    → Availability (failover, resilience)
Read Replica → Scalability (read performance, load distribution)

RDS         → SQL / Relational databases (MySQL, PostgreSQL, Aurora, etc.)
DynamoDB    → NoSQL / Key-value (flexible schema, massive scale)

Aurora      → AWS's own engine, faster than MySQL/PG, still part of RDS
DAX         → DynamoDB's built-in cache (like Redis, but only for DynamoDB)

Notes compiled from lecture transcript — June 4, 2026 | AWS re/Start Cohort 3: Project CloudIgnite