Entradas

Mostrando las entradas etiquetadas como VPC

Lambda Conectando a RDS Privado: Configuración de VPC, Subnets y Security Groups

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...

Cuándo usar ElastiCache Redis: acelera lecturas lentas en RDS con una capa de caché

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...

NAT Gateway vs NAT Instance en AWS: ¿Cuál usar para tus instancias privadas?

Tienes instancias en subredes privadas que necesitan descargar actualizaciones del sistema operativo, paquetes de dependencias o conectarse a APIs externas — pero sin exponer esas instancias directamente a internet. La decisión entre NAT Gateway y NAT Instance parece simple al principio, hasta que te encuentras depurando un problema de conectividad a las 2 AM y descubres que elegiste la opción equivocada para tu caso de uso. TL;DR: NAT Gateway vs NAT Instance Criterio NAT Gateway NAT Instance Gestión operativa Completamente gestionado por AWS Tú gestionas el EC2, parches, HA Alta disponibilidad Redundancia dentro de la AZ incluida Requiere configuración manual (Auto Scaling, scripts) Escalabilidad Escala automáticamente hasta límites documentados Limitada por el tipo de instancia EC2 Costo base...

Conectar Dos VPCs con VPC Peering: Guía Completa de Configuración y Tablas de Rutas

Tienes dos VPCs en la misma cuenta y región, y los recursos en cada una necesitan comunicarse usando IPs privadas — sin pasar por internet. El VPC Peering es la solución nativa de AWS para este caso, pero el error más común no está en crear la conexión: está en olvidar actualizar las tablas de rutas en ambos lados , o en tener bloques CIDR solapados que AWS rechaza silenciosamente hasta que intentas enrutar tráfico. TL;DR — Conectar Dos VPCs con VPC Peering Paso Acción Dónde 1 Verificar que los CIDRs no se solapan Consola / CLI 2 Crear la solicitud de Peering Connection VPC solicitante 3 Aceptar la solicitud VPC aceptante 4 Actualizar tabla de rutas en VPC-A → apuntar al CIDR de VPC-B Route Table VPC-A 5 Actualizar tabla de rutas en VPC-B → apuntar al CIDR de VPC-A Route Table VPC-B 6 Verificar Security Groups permiten el tráfico Instancias destino Cómo Funciona el VPC Peering Un VPC Peer...

EC2 SSH Connection Timeout: Qué revisar en Security Groups para resolver el error

Lanzaste una instancia EC2, intentas conectarte por SSH y recibes un Connection timed out que no da ninguna pista sobre dónde está el problema. Este error de timeout en SSH es uno de los más frecuentes al trabajar con EC2, y casi siempre apunta a una capa de red bloqueando el tráfico antes de que llegue al sistema operativo — no a un problema con el servidor en sí. TL;DR: Resumen rápido del diagnóstico Capa Qué verificar Herramienta Security Group Regla inbound TCP/22 desde tu IP Consola AWS / CLI Network ACL Reglas inbound y outbound para TCP/22 Consola VPC / CLI Tabla de rutas Ruta hacia Internet Gateway (0.0.0.0/0) Consola VPC / CLI IP pública La instancia tiene Elastic IP o IP pública asignada Consola EC2 Subnet La subnet es pública (auto-assign public IP activo) Consola VPC Cómo funciona el flujo de red en EC2 antes de que llegue SSH Antes de diagnosticar, hay que entender qué capas atra...