AWS Cloud Practitioner #8: Amazon RDS - Databases Gestionadas

Setup:
1. Lanzar EC2 instance
2. Instalar PostgreSQL manualmente
3. Configurar networking, security groups
4. Setup backups (scripts cron)
5. Configurar monitoring
6. Implementar replication (manual)
7. Gestionar patches y updates
 
Responsabilidades continuas:
- Aplicar security patches mensualmente
- Monitorear disk space
- Gestionar backups
- Manejar failover manualmente
- Escalar storage (downtime)
- Optimizar performance (tuning)
 
Costo tiempo: 10+ horas/mes
Riesgo: Alto (error humano en backups, patches, etc.)

Setup:
1. aws rds create-db-instance --engine postgres --db-instance-class db.t3.micro
 
Responsabilidades continuas:
✅ Backups automáticos
✅ Patches automáticos
✅ Monitoring incluido
✅ Multi-AZ failover automático
✅ Scaling con zero downtime
 
Costo tiempo: <1 hora/mes
Riesgo: Bajo (AWS gestiona casi todo)

AWS gestiona:
✅ OS installation y patches
✅ Database software installation
✅ Automated backups
✅ High availability (Multi-AZ)
✅ Scaling infrastructure
✅ Monitoring básico
✅ Security patches
 
TÚ gestionas:
📌 Database schema (tables, indexes)
📌 Query optimization
📌 Application connection strings
📌 User management y permissions
📌 Security Groups
📌 Cuándo escalar

AWS-proprietary, compatible con MySQL y PostgreSQL
 
Características especiales:
✅ 5x más rápido que MySQL, 3x más que PostgreSQL
✅ Auto-scaling storage (hasta 128 TB)
✅ 15 Read Replicas (vs. 5 para otros engines)
✅ Backtrack (volver a punto en tiempo sin usar backup)
 
Pricing:
~20% más caro que RDS MySQL/PostgreSQL
Pero performance puede compensar con less instances
 
Usa cuando:
- Necesitas máximo performance
- Apps enterprise críticas
- Necesitas muchos Read Replicas

Open-source, más popular
 
Versiones: 5.7, 8.0
Max storage: 64 TB
Read Replicas: Hasta 5
 
Pricing:
db.t3.micro: ~$15/mes (free tier eligible)
db.m5.large: ~$122/mes
 
Usa cuando:
- Migrando app existente con MySQL
- Comunidad grande (muchos recursos)
- Costo-efectivo

Open-source, features avanzados
 
Versiones: 11, 12, 13, 14, 15
Max storage: 64 TB
Read Replicas: Hasta 5
 
Features únicos:
- JSON support nativo
- Advanced indexing (GiST, GIN)
- Full-text search
 
Usa cuando:
- Necesitas JSON/NoSQL features en SQL database
- Complex queries y analytics
- ACID compliance estricto

MySQL fork, compatible con MySQL
 
Versiones: 10.3, 10.4, 10.5, 10.6
Similar a MySQL pero con features adicionales
 
Usa cuando:
- Quieres evitar Oracle (MySQL owner)
- Necesitas features de MariaDB específicos

Enterprise database
 
Licencias: License Included o BYOL (Bring Your Own License)
Ediciones: Standard, Enterprise
 
Pricing:
Mucho más caro que MySQL/PostgreSQL
License Included: $0.35/hora (db.t3.small)
BYOL: Más barato si ya tienes licencia
 
Usa cuando:
- App legacy requiere Oracle
- Enterprise features específicos de Oracle
- Ya tienes licencias Oracle

Database de Microsoft
 
Ediciones: Express, Web, Standard, Enterprise
Licencias: License Included o BYOL
 
Pricing:
Express: Gratis (limited to 10 GB)
Web: ~$0.05/hora
Standard/Enterprise: Significativamente más caro
 
Usa cuando:
- App .NET existente
- Requieres T-SQL
- Integración con Microsoft stack

Configuración:
- Retention period: 1-35 días (default: 7)
- Backup window: Elige cuándo corren (ej: 3am-4am)
- Point-in-time recovery: Restaura a cualquier segundo dentro de retention
 
Ejemplo:
Database corrupted a las 2:30pm
Puedes restaurar a:
- 2:29pm (1 minuto antes)
- 2:00pm (30 minutos antes)
- Cualquier segundo de los últimos 7 días

# Habilitar automated backups
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --backup-retention-period 7 \
  --preferred-backup-window "03:00-04:00"
 
# Restaurar a punto en tiempo
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier mydb \
  --target-db-instance-identifier mydb-restored \
  --restore-time 2025-11-16T14:29:00Z

✅ Backups son GRATIS (storage incluido hasta 100% de DB size)
✅ Retention hasta 35 días
✅ Backups se toman durante backup window (puede afectar performance)
❌ Si borras DB instance, backups automáticos se borran también
   → Usa snapshots para retention long-term

Automated Backups vs. Snapshots:
 
Automated Backups:
- Automáticos
- Retention: 1-35 días
- Se borran cuando borras DB instance
- Incluye transaction logs (point-in-time)
 
Snapshots:
- Manuales (tú los creas)
- Retention: Indefinido (hasta que lo borres)
- NO se borran cuando borras DB instance
- Full backup (no point-in-time)

# Crear snapshot
aws rds create-db-snapshot \
  --db-instance-identifier mydb \
  --db-snapshot-identifier mydb-snapshot-before-migration
 
# Restaurar desde snapshot
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier mydb-restored \
  --db-snapshot-identifier mydb-snapshot-before-migration
 
# Copiar snapshot a otra región (disaster recovery)
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789012:snapshot:mydb-snapshot \
  --target-db-snapshot-identifier mydb-snapshot-backup \
  --region eu-west-1

✅ Antes de migration/upgrade mayor
✅ Compliance (mantener snapshot por años)
✅ Disaster recovery (copiar a otra región)
✅ Dev/test (restaurar snapshot de prod en dev)
 
Ejemplo:
Antes de migrar de MySQL 5.7 → 8.0:
1. Crear snapshot
2. Realizar migration
3. Si falla → restaurar desde snapshot
4. Si funciona → borrar snapshot después de validar

Arquitectura:
 
Primary DB (AZ-1a)          Standby DB (AZ-1b)
     │                            │
     │──── Synchronous ───────────│
     │     Replication            │
     │                            │
Application ────┐                 │
                │                 │
                └─ DNS endpoint ──┘
                   (automatic failover)
 
Si Primary falla:
1. RDS detecta (60-120 segundos)
2. DNS endpoint apunta a Standby
3. Standby se promueve a Primary
4. Total downtime: 1-2 minutos

✅ Replication SÍNCRONA (no data loss)
✅ Automatic failover (sin intervención)
✅ Standby NO es accesible (no puedes leer de ella)
✅ Solo para high availability, NO para scaling reads
 
Pricing:
~2x costo (pagas por standby instance)
 
db.t3.micro Single-AZ: $15/mes
db.t3.micro Multi-AZ: $30/mes

✅ Production databases críticas
✅ Apps que requieren 99.95%+ uptime
✅ Compliance (muchas regulaciones requieren HA)
 
❌ NO usar para:
❌ Dev/test environments (costo innecesario)
❌ Apps que toleran downtime
 
Ejemplo:
eCommerce checkout database:
→ Multi-AZ (downtime = pérdida de ventas)
 
Internal analytics database:
→ Single-AZ (downtime de 30 min es aceptable)

Sin Multi-AZ:
Maintenance → Downtime
 
Con Multi-AZ:
1. Apply patches a Standby
2. Failover a Standby (ahora Primary)
3. Apply patches a old Primary (ahora Standby)
4. Total downtime: ~2 minutos (solo failover)

Arquitectura:
 
Primary DB (Read + Write)
     │
     │──── Async Replication ────┬──→ Read Replica 1 (Read only)
                                  │
                                  ├──→ Read Replica 2 (Read only)
                                  │
                                  └──→ Read Replica 3 (Read only)
 
Application:
- Writes → Primary
- Reads → Load balance entre Replicas

✅ Replication ASÍNCRONA (puede haber lag)
✅ Se puede leer de Replicas (scaling reads)
✅ Hasta 5 Replicas (15 para Aurora)
✅ Pueden estar en diferente región
✅ Pueden promover a standalone DB
 
Pricing:
Pagas por cada Replica + data transfer
 
db.t3.micro Primary: $15/mes
db.t3.micro Replica: $15/mes
Total con 3 Replicas: $60/mes

✅ App con mucho más reads que writes (ej: 90% reads)
✅ Reporting/analytics (offload de primary)
✅ Disaster recovery cross-region
 
Caso de uso:
Blog con 100,000 lectores/día, 10 writers/día
 
Sin Read Replicas:
Primary DB handling 100% del traffic
→ CPU al 80%, slow queries
 
Con 3 Read Replicas:
Primary: 100% writes + 25% reads (CPU 30%)
Replicas: 75% reads distribuido (CPU 25% cada uno)
→ Performance 3x mejor

# Promover Read Replica a standalone DB
aws rds promote-read-replica \
  --db-instance-identifier mydb-replica-1
 
Casos de uso:
1. Disaster recovery:
   Primary en us-east-1 falla completamente
   → Promote Replica en eu-west-1
 
2. Migration entre regions:
   Crear Replica en nueva región
   → Promote
   → Update application to point to new region

Problema:
Write a Primary → Toma 2 segundos replicar a Replica
User ve data vieja en Replica
 
Solución:
CloudWatch metric: ReplicaLag
Si lag > threshold → envía reads a Primary

✅ AES-256 encryption
✅ Managed by AWS KMS
✅ Encrypts:
   - Database storage
   - Automated backups
   - Snapshots
   - Read Replicas
 
⚠️ Debe habilitarse al crear DB (NO se puede agregar después)

# Crear DB con encryption
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --engine postgres \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
 
# Para encriptar DB existente (no encriptada):
# 1. Snapshot
# 2. Copy snapshot con encryption
# 3. Restore desde encrypted snapshot

✅ SSL/TLS connections
 
# PostgreSQL example
psql "host=mydb.123456789012.us-east-1.rds.amazonaws.com port=5432 dbname=mydb user=admin sslmode=require"
 
# MySQL example
mysql -h mydb.123456789012.us-east-1.rds.amazonaws.com -u admin -p --ssl-mode=REQUIRED

# Cambiar de db.t3.micro a db.t3.small
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.small \
  --apply-immediately
 
Downtime:
Sin Multi-AZ: 5-10 minutos
Con Multi-AZ: 1-2 minutos (failover durante upgrade)

# Aumentar storage de 20GB a 100GB
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --allocated-storage 100
 
Downtime: NO (online operation)
 
⚠️ Puedes AUMENTAR storage, pero NO disminuir

# Habilitar auto-scaling
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --max-allocated-storage 1000
 
RDS automáticamente aumenta storage cuando:
- Free space < 10%
- Condition persiste por 5 minutos
- 6 horas desde último scaling
 
Beneficio: Nunca te quedas sin espacio

✅ Quieres managed service (menos admin overhead)
✅ Necesitas automated backups y point-in-time recovery
✅ Multi-AZ alta disponibilidad
✅ Read Replicas para scaling
✅ Automatic patching
✅ Monitoring integrado
 
Ejemplo:
Startup con 2 developers
No tienen DBA dedicated
→ RDS (AWS gestiona todo)

✅ Necesitas acceso root al OS
✅ Database engine no soportado por RDS
✅ Custom configurations no disponibles en RDS
✅ Necesitas features específicos de OS
 
Ejemplo:
App legacy con Oracle RAC (Real Application Clusters)
→ RDS no soporta RAC
→ EC2 con Oracle RAC manual

¿Necesitas HA?
└─ SÍ → Multi-AZ
 
¿Read-heavy workload?
└─ SÍ → Read Replicas
 
¿Necesitas máximo performance?
└─ SÍ → Aurora
 
¿Budget limitado + open-source?
└─ SÍ → MySQL/PostgreSQL
 
¿Compliance requiere custom OS config?
└─ SÍ → EC2 + Database (no RDS)