Entradas

Mostrando las entradas etiquetadas como Arquitectura Cloud

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

Beneficios de RDS Multi-AZ: Alta Disponibilidad, Failover y lo que Nadie te Cuenta

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

Entendiendo el Visibility Timeout de SQS: Por Qué Tus Mensajes Se Procesan Dos Veces

Tienes un worker que consume mensajes de SQS, y de repente notas que el mismo mensaje está siendo procesado por dos instancias distintas al mismo tiempo. El primer instinto es buscar un bug en el código, pero la causa real casi siempre está en una configuración que se ignora hasta que el sistema está en producción: el Visibility Timeout de SQS . TL;DR: Visibility Timeout en SQS Aspecto Detalle ¿Qué controla? El tiempo que un mensaje permanece invisible para otros consumidores después de ser recibido Valor por defecto 30 segundos Rango configurable 0 segundos a 12 horas Causa principal de doble procesamiento El procesamiento tarda más que el Visibility Timeout configurado Solución operativa Extender el timeout dinámicamente con ChangeMessageVisibility o ajustar el valor base G...

Modos de Capacidad en DynamoDB: ¿Provisionado o Bajo Demanda?

Cuando lanzas una nueva aplicación en AWS y aún no tienes datos históricos de tráfico, elegir el modo de capacidad incorrecto en DynamoDB puede resultar en throttling inesperado o en facturas que no esperabas. Esta guía cubre los modos de capacidad de DynamoDB desde una perspectiva operacional real: cuándo cada uno tiene sentido, cómo migrar entre ellos, y cómo evitar los errores más comunes. TL;DR — Guía de Decisión Rápida Si no conoces tus patrones de tráfico todavía, empieza con On-Demand (Bajo Demanda) . Migra a Provisionado con Auto Scaling cuando tengas al menos 2-4 semanas de métricas reales de consumo. Criterio On-Demand Provisionado + Auto Scaling Tráfico predecible No óptimo Recomendado Tráfico impredecible o spiky Recomendado Riesgo de throttling Fase de desarrollo / MVP Recomendado Sobreingeniería temprana Costo por millón de solicitudes Mayor por unidad Menor si se utiliza bien Configu...

Route 53 Alias vs CNAME: Cuándo usar cada uno y por qué el Alias es obligatorio en el apex de zona

Estás configurando tu dominio raíz example.com para que apunte a un Application Load Balancer y Route 53 te ofrece dos opciones: CNAME o Alias. Si eliges CNAME, el registro simplemente no funcionará en el apex de zona — y Route 53 ni siquiera te lo permite. Este es uno de esos casos donde la restricción del DNS estándar obliga a usar una funcionalidad específica de AWS, y entender el porqué evita horas de depuración. TL;DR: Alias vs CNAME en Route 53 Característica CNAME Alias (Route 53) Funciona en apex de zona ( example.com ) ❌ No permitido por RFC ✅ Sí Funciona en subdominios ( www.example.com ) ✅ Sí ✅ Sí Coste de consultas DNS Se cobra por query Sin coste adicional para destinos AWS Responde con IPs del destino No (devuelve el nombre) Sí (resolución directa) He...