AWS Cloud Practitioner #18: DynamoDB - NoSQL Serverless

Características clave:
✅ Serverless (no instances)
✅ Auto-scaling
✅ Single-digit millisecond latency
✅ 99.99% availability
✅ Encryption at rest
✅ Point-in-time recovery
✅ Global tables (multi-region)
 
No gestionas:
❌ Servers
❌ Patches
❌ Backups (automáticos)
❌ Scaling infrastructure

Table: Users
 
Item 1:
{
  "UserID": "123",          ← Partition Key
  "Name": "Juan",
  "Email": "juan@email.com",
  "Age": 30
}
 
Item 2:
{
  "UserID": "456",
  "Name": "Maria",
  "Country": "Spain",       ← Different attributes OK
  "Premium": true
}
 
Flexible schema: Items pueden tener diferentes attributes

Único identificador del item:
 
Table: Users
Partition Key: UserID
 
Query:
GetItem(UserID = "123")
→ O(1) lookup (ultra-fast)
 
Distribución:
DynamoDB usa partition key para distribuir data
Partition Key → Hash function → Physical partition

Para queries más complejas:
 
Table: Orders
Partition Key: UserID
Sort Key: OrderDate
 
Permite:
- GetItem(UserID = "123", OrderDate = "2025-11-16")
- Query all orders para UserID = "123"
- Query orders entre dates

Pricing: Pay per request
 
$1.25 per million write requests
$0.25 per million read requests
 
Use when:
✅ Unpredictable traffic
✅ Spiky workloads
✅ New applications
 
Example:
100K writes/day = 100K × $1.25/1M = $0.125/day = $3.75/month
1M reads/day = 1M × $0.25/1M = $0.25/day = $7.50/month
Total: $11.25/month

Pricing: Set capacity, pay per hour
 
RCU (Read Capacity Unit): 1 read/sec
WCU (Write Capacity Unit): 1 write/sec
 
$0.00013 per WCU-hour
$0.000065 per RCU-hour
 
Use when:
✅ Predictable traffic
✅ Cost optimization (cheaper for steady load)
 
Example:
10 WCU + 20 RCU provisioned 24/7:
WCU: 10 × $0.00013 × 730 hrs = $0.95/month
RCU: 20 × $0.000065 × 730 hrs = $0.95/month
Total: $1.90/month
 
vs. On-Demand para same usage: $11.25
Savings: 83%

Provisioned with auto-scaling:
 
Min: 5 WCU, 10 RCU
Max: 100 WCU, 200 RCU
Target: 70% utilization
 
Traffic spike → Auto-scale up
Traffic drops → Auto-scale down
 
Best of both worlds:
✅ Cost efficiency de provisioned
✅ Flexibility de on-demand

Table: Users
Partition Key: UserID
 
Quieres query por Email:
 
Create GSI:
GSI Name: EmailIndex
Partition Key: Email
 
Ahora puedes:
Query(EmailIndex, Email = "juan@email.com")
→ Returns UserID = "123"

Same partition key, different sort key:
 
Table: Orders
Partition Key: UserID
Sort Key: OrderDate
 
LSI:
Partition Key: UserID
Sort Key: OrderAmount
 
Ahora puedes query orders por amount

Use cases:
 
1. Audit trail:
   Item updated → Stream → Lambda → Log to S3
 
2. Replication:
   Item inserted → Stream → Lambda → Write to otro table
 
3. Notifications:
   New order → Stream → Lambda → Send email
 
Stream record:
{
  "eventName": "INSERT",
  "dynamodb": {
    "Keys": {"UserID": {"S": "123"}},
    "NewImage": {
      "Name": {"S": "Juan"},
      "Email": {"S": "juan@email.com"}
    }
  }
}

Setup:
Table en us-east-1
Enable global table → replicate to:
- eu-west-1
- ap-southeast-1
 
Beneficios:
✅ Low latency globalmente
✅ Disaster recovery
✅ Multi-region active-active
 
Replication:
Write en us-east-1 → async replicate a otras regiones
Typically <1 second replication lag
 
Conflict resolution:
Last writer wins (based on timestamp)

Without DAX:
App → DynamoDB (5-10ms latency)
 
With DAX:
App → DAX → DynamoDB
Cache hit: <1ms (microseconds)
Cache miss: 5-10ms (DynamoDB)
 
Use when:
✅ Read-heavy workloads
✅ Need sub-millisecond latency
✅ Reduce DynamoDB read costs (less requests)
 
Pricing:
dax.t3.small: $0.04/hour = $29/month

1. Design partition key carefully:
   ✅ High cardinality (many unique values)
   ✅ Uniform access pattern
   ❌ Hot partition (one key accessed 90% of time)
 
2. Use GSIs para access patterns:
   Main table: Query by UserID
   GSI: Query by Email, OrderDate, etc.
 
3. Denormalize data:
   NoSQL = No joins
   Store related data together
   Example: Store OrderItems dentro de Order (nested)
 
4. Use DynamoDB Streams:
   Para audit, replication, triggers
 
5. On-Demand vs. Provisioned:
   Predictable → Provisioned (cheaper)
   Spiky → On-Demand (simplicity)
 
6. Enable backups:
   Point-in-time recovery
   On-demand backups antes de migrations
 
7. Use DAX para read-heavy:
   Cache layer reduces costs + latency

Use RDS when:
✅ Complex queries (JOINs)
✅ Transactions críticos
✅ Relational data (normalize)
✅ SQL expertise en team
 
Use DynamoDB when:
✅ Simple key-value lookups
✅ Massive scale (millions requests/sec)
✅ Serverless (no server management)
✅ Variable workloads
✅ Low latency requirement (<10ms)
 
Example:
eCommerce app:
- Product catalog → DynamoDB (fast lookups)
- Orders/Transactions → RDS (complex queries)
- User sessions → DynamoDB (fast reads)