SW BBANG E

Cuando intentas montar el mismo volumen EBS en cinco instancias EC2 simultáneamente y te preguntas por qué solo una instancia puede escribir, estás enfrentando una de las confusiones más comunes en arquitecturas AWS: la diferencia fundamental entre almacenamiento de bloque y almacenamiento de archivos compartido. La respuesta corta es que EBS no fue diseñado para esto, y EFS sí. TL;DR: EBS vs EFS para Compartir Archivos entre Instancias EC2 Característica EBS (Elastic Block Store) EFS (Elastic File System) Acceso simultáneo multi-instancia Limitado (solo con io1/io2 Multi-Attach, misma AZ) Sí, nativo — múltiples instancias, múltiples AZs Protocolo Bloque (como un disco local) NFS v4.1/4.0 Caso de uso principal Base de datos, sistema operativo, disco raíz Contenido compartido, logs centralizados, home directories ...

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

Eliminaste un archivo en S3 y lo necesitas de vuelta — si tenías el versionado habilitado en el bucket, el objeto no desapareció realmente: S3 insertó un marcador de eliminación ( delete marker ) encima de las versiones anteriores. Este artículo explica cómo localizar esa versión anterior y restaurarla sin pérdida de datos. TL;DR: Recuperación Rápida de Archivos Eliminados en S3 Situación ¿Recuperable? Acción Versionado habilitado, eliminación simple ✅ Sí Eliminar el delete marker Versionado habilitado, eliminación de versión específica ⚠️ Solo si hay versiones anteriores Copiar o restaurar versión previa Versionado suspendido al momento de la eliminación ⚠️ Depende del estado Verificar si existe versión con ID explícito Versionado nunca habilitado ❌ No Sin recuperación nativa posible Cómo Funciona el Versionado de S3 y los Delete Markers Cuando el versionado está activo en un bucket, S3 nunca sobr...

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