Entradas

Mostrando las entradas etiquetadas como CloudWatch

Instancias T3 Burstables en AWS: Créditos de CPU y Por Qué Tu Servidor Se Ralentiza

Estás monitoreando una instancia EC2 T3 en producción y todo va bien — hasta que de repente la CPU cae a un rendimiento mínimo sin ninguna razón aparente en los logs de aplicación. No hay errores, no hay picos de memoria, pero las peticiones empiezan a acumularse. Si esto te suena familiar, el problema casi siempre está en el sistema de créditos de CPU que define cómo funcionan las instancias burstables T3. TL;DR: Créditos de CPU en Instancias T3 Concepto Descripción Crédito de CPU Unidad que permite usar el 100% de un vCPU durante 1 minuto Tasa de acumulación Varía por tipo de instancia; se acumula cuando el uso está por debajo del baseline Baseline Porcentaje de CPU garantizado sin consumir créditos (ej. 20% para t3.small) Modo Standard Al agotar créditos, la CPU cae al baseline — comportamiento por defecto en T3 ...

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

SES Sandbox Mode: Por qué solo puedes enviarte emails a ti mismo y cómo salir de él

Acabas de integrar Amazon SES en tu aplicación, las pruebas internas funcionan perfectamente, pero en el momento en que intentas enviar un email de bienvenida a un cliente real, el mensaje rebota o simplemente no llega. El diagnóstico es casi siempre el mismo: tu cuenta SES está en Sandbox mode y nadie te avisó de que necesitas solicitar acceso a producción antes de poder enviar emails a direcciones no verificadas. TL;DR — Resumen rápido del Sandbox de SES Aspecto Sandbox (por defecto) Producción (tras aprobación) Destinatarios permitidos Solo direcciones o dominios verificados en SES Cualquier dirección de email válida Límite de envío diario 200 emails/día Según el límite aprobado en tu solicitud Tasa de envío máxima 1 email/segundo Según el límite aprobado Remitentes permitidos Solo identidades verificadas (email o dominio) Solo identidades verificadas (igual) Cómo salir Solicitud de acceso a prod...

Alertas por Email con SNS: Por qué No Recibes los Mensajes y Cómo Solucionarlo

Configuraste un tema SNS, añadiste tu dirección de correo como suscriptor, y publicaste un mensaje de prueba — pero tu bandeja de entrada sigue vacía. Antes de revisar políticas de acceso o configuraciones de red, la causa más frecuente es la más simple: el enlace de confirmación de suscripción nunca fue cliqueado. SNS no entrega ningún mensaje a una suscripción de email que permanezca en estado PendingConfirmation . TL;DR: Diagnóstico Rápido de Alertas SNS por Email Síntoma Causa más probable Acción inmediata No llega ningún email tras publicar Suscripción sin confirmar Verificar estado con aws sns list-subscriptions-by-topic El email de confirmación no llegó Filtro de spam o dirección incorrecta Revisar spam; re-suscribir con dirección correcta Suscripción confirmada pero sin mensajes Política de acceso al tema restrictiva Revisar política del tema con aws sns get-topic-attributes Mensajes publicados pe...

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...