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

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

Acabas de lanzar una instancia EC2 y necesitas que Nginx esté instalado y corriendo sin conectarte manualmente por SSH — ese es exactamente el problema que resuelve EC2 User Data . En producción, configurar servidores manualmente es un error que escala muy mal: la automatización del arranque es la diferencia entre infraestructura reproducible y caos operacional. TL;DR: Instalar Nginx Automáticamente con EC2 User Data Punto clave Detalle ¿Qué es User Data? Script que EC2 ejecuta una sola vez en el primer arranque, como root ¿Dónde se configura? Consola AWS → 'Advanced Details' al lanzar la instancia, o vía CLI con --user-data ¿Cuándo se ejecuta? Solo en el primer boot (por defecto). Requiere configuración adicional para re-ejecución ¿Quién lo ejecuta? El agente cloud-init , como usuario root ¿Dónde ver los logs? /var/log/cloud-init-output.log en la instancia Límite de tamaño 16 KB para U...

Una instancia EC2 desaparece en producción y nadie admite haberla terminado. Antes de escalar el incidente o revisar manualmente cada cuenta IAM, CloudTrail ya registró exactamente quién ejecutó TerminateInstances , desde qué IP y con qué credenciales. El problema no es que la información no exista — es saber dónde buscarla y cómo interpretarla correctamente. TL;DR — Resumen Rápido Paso Acción Resultado esperado 1 Abrir CloudTrail Event History en la consola Vista de eventos de los últimos 90 días 2 Filtrar por nombre de evento: TerminateInstances Lista de eventos de terminación 3 Filtrar por ID de recurso o rango de tiempo Evento específico de la instancia eliminada 4 Inspeccionar el campo userIdentity del evento Usuario IAM, rol asumido, o cuenta raíz responsable 5 Verificar sourceIPAddress y userAgent Contexto adicional del origen de la acción Cómo Funciona CloudTrail Event History CloudT...