SW BBANG E

Una de las situaciones más frustrantes al empezar con Lambda es cuando la función simplemente no puede alcanzar la base de datos RDS que vive en una subnet privada. El timeout llega después de 30 segundos, no hay ningún mensaje de error claro en CloudWatch, y la pregunta inevitable es: ¿necesito configurar algo de VPC en mi Lambda? La respuesta corta es sí — pero la configuración incorrecta puede dejarte igual de bloqueado, o peor, con una Lambda que perdió acceso a internet sin que te des cuenta. TL;DR: Lambda Conectando a RDS Privado Componente Qué configurar Error típico si falta VPC en Lambda Misma VPC que RDS Timeout de conexión (no hay ruta) Subnets en Lambda Subnets privadas con ruta a RDS Timeout de conexión Security Group en Lambda SG que RDS acepta como origen Conexión rechazada o timeout Security Group en RDS Regla inbound desde SG de Lambda Conexión rechazada (puerto 5432/3306) Rol IAM de...

Tu base de datos RDS empieza a mostrar latencias altas y el dashboard de CloudWatch confirma lo que ya sospechabas: las mismas consultas se ejecutan cientos de veces por minuto devolviendo exactamente los mismos datos. Añadir ElastiCache Redis como capa de caché delante de RDS es una de las intervenciones más efectivas en producción para este patrón específico, pero aplicarla mal genera inconsistencias de datos que son difíciles de depurar. TL;DR — Cuándo usar ElastiCache Redis con RDS Señal Indica caché Acción Mismas consultas SELECT repetidas con alta frecuencia Sí Cache-aside sobre esas queries Datos que cambian raramente (catálogos, configuración) Sí TTL largo, invalidación explícita Datos de sesión de usuario Sí Redis como session store Escrituras frecuentes con lectura inmediata del mismo registro Con cuidado Write-through o invalidar en escritura Consultas con JOINs complejos y resultados únic...

Cuando un equipo habilita Multi-AZ en una instancia RDS por primera vez, la pregunta inevitable es: '¿esto también mejora el rendimiento, o solo sirve para el failover?' La confusión es legítima — AWS menciona réplicas, sincronización y standby en el mismo párrafo, y es fácil mezclar Multi-AZ con Read Replicas. Esta guía aclara exactamente qué compras cuando activas Multi-AZ, qué no compras, y cuándo el failover automático puede sorprenderte en producción. TL;DR — Beneficios de RDS Multi-AZ Aspecto Con Multi-AZ Sin Multi-AZ Alta disponibilidad ✅ Failover automático (~60-120 s) ❌ Recuperación manual Durabilidad de datos ✅ Replicación síncrona ⚠️ Solo backups Rendimiento de escritura ❌ Sin mejora (standby no sirve lecturas) — Rendimiento de lectura ❌ Sin mejora (usar Read Replicas) — Mantenimiento con downtime reducido ✅ Failover antes del parche ❌ Ventana de mantenimiento completa Backups...

El repositorio es privado, el equipo es pequeño, la fecha de entrega es mañana — y la contraseña de la base de datos termina incrustada directamente en el código fuente. Es una decisión que se toma en segundos y que puede costar semanas de trabajo de remediación cuando ese repositorio se clona en un entorno de CI, se expone en un log de error, o simplemente un ex-colaborador conserva acceso al historial de Git. AWS Secrets Manager existe precisamente para eliminar esta clase de deuda de seguridad antes de que se convierta en un incidente. TL;DR — Secrets Manager vs. credenciales hardcodeadas Dimensión Credencial hardcodeada AWS Secrets Manager Exposición en repositorio Permanente en historial de Git El código nunca contiene la credencial Rotación de contraseña Manual, propensa a omisión Automática vía Lambda integrada Auditorí...

Cuando un ambiente de producción empieza a comportarse mal y la única salida es un snapshot, la primera pregunta que aparece es si restaurar va a pisar la instancia actual o va a crear algo nuevo. La respuesta tiene implicaciones directas en el endpoint de conexión, en los grupos de seguridad y en cuánto tiempo va a estar caído el servicio — y si no se entiende el modelo antes de ejecutar, el incidente se puede complicar más. TL;DR: Restaurar un snapshot de RDS siempre crea una instancia nueva Restaurar desde un snapshot en RDS nunca sobreescribe la instancia de origen. El proceso crea una instancia completamente nueva con un endpoint distinto. La instancia original permanece intacta y en ejecución. Para apuntar las aplicaciones a la instancia restaurada, se debe actualizar el string de conexión o redirigir el DNS manualmente. Aspecto Comportamiento real Instancia original Permanece intacta, sin modificaciones Ins...