Después de bastantes revisiones de cuentas de AWS, lo llamativo no es la variedad de los problemas. Es lo repetitivos que son. Las mismas siete cosas, una y otra vez, en empresas de tamaños y sectores completamente distintos.
Ninguna es difícil de arreglar. Todas siguen ahí porque nadie las tenía asignadas.
1. Claves de acceso que llevan años vivas
Es el hallazgo más frecuente con diferencia. Claves de IAM creadas para un despliegue puntual en 2023, que nunca se rotaron y que siguen teniendo permisos amplios.
Por qué importa: las claves acaban en repositorios, en portátiles de gente que ya no trabaja aquí, en archivos .env de entornos locales, en historiales de terminal. Cada mes que pasa es otro mes de superficie de exposición.
Cómo se arregla: genera el informe de credenciales, borra lo que no se usa, rota lo que sí, y sustituye claves por roles siempre que se pueda.
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
2. El puerto 22 abierto al mundo
Un grupo de seguridad con SSH abierto a 0.0.0.0/0. Casi siempre lo abrió alguien “un momento para depurar” hace año y medio.
Por qué importa: hay bots escaneando ese puerto de forma continua. No es una amenaza teórica; es tráfico que ya estás recibiendo.
Cómo se arregla: Session Manager de SSM elimina la necesidad de exponer SSH. Si necesitas SSH de verdad, restríngelo a IPs concretas.
3. CloudTrail solo en una región
Está activado en eu-west-1 porque es donde vive todo. Pero una cuenta de AWS tiene todas las regiones activas siempre.
Por qué importa: un atacante que consiga credenciales va a operar en ap-southeast-2, no en tu región de producción, precisamente porque ahí nadie mira. Sin CloudTrail multirregión no queda rastro.
Cómo se arregla: un trail multirregión, con los logs en un bucket que las cuentas operativas no puedan borrar.
4. Copias de seguridad que nunca se han restaurado
Hay snapshots. Hay política de retención. No hay ni una sola prueba de restauración.
Por qué importa: una copia sin verificar no es una copia. Es una suposición. Y el día que la necesites vas a descubrir que faltaba una tabla, o que el cifrado usa una clave que ya no existe.
Cómo se arregla: restaura una copia en un entorno aislado. Una vez. Anota cuánto tardas. Ese número es tu tiempo real de recuperación, y probablemente no es el que le has dicho a tu cliente.
5. Recursos huérfanos facturando en silencio
Volúmenes EBS sin adjuntar, IPs elásticas ociosas, NAT Gateways en subredes vacías, balanceadores sin destinos.
Por qué importa: dinero, directamente. En cuentas medianas esto suele ser entre un 10 % y un 20 % de la factura. Un NAT Gateway olvidado son unos 35 €/mes más el tráfico, indefinidamente.
Cómo se arregla: listar y borrar. Es el trabajo con mejor retorno por hora de toda la lista, y riesgo prácticamente cero.
6. Alertas que no llegan a nadie
Hay alarmas de CloudWatch configuradas. Publican en un tema de SNS. El tema no tiene suscriptores, o los tiene hacia un correo que nadie lee desde que esa persona cambió de puesto.
Por qué importa: es peor que no tener alertas, porque genera una falsa sensación de cobertura. Todo el mundo cree que alguien se enteraría.
Cómo se arregla: manda las alertas a un canal de Slack o Teams donde haya gente de verdad. Y prueba una: dispárala a propósito y comprueba que llega.
7. Sin alerta de facturación
No hay ninguna alarma sobre el gasto.
Por qué importa: un pico de coste es frecuentemente el primer síntoma visible de que algo va mal, sea un compromiso de credenciales para minar criptomonedas, un bucle infinito en una Lambda o una consulta que se ha vuelto salvaje. Si no lo ves hasta que llega la factura, has perdido tres semanas.
Cómo se arregla: una alarma de facturación en us-east-1, que es donde vive esa métrica, con un umbral por encima de tu gasto normal.
Lo que tienen en común
Ninguno de estos siete problemas es difícil. Ninguno requiere un proyecto, ni una herramienta cara, ni rearquitecturar nada. La mayoría se resuelven en una tarde de trabajo.
Siguen ahí porque no son responsabilidad de nadie. El equipo de desarrollo está entregando funcionalidades. No hay equipo de plataforma. Y la infraestructura funciona, así que nadie la mira.
Eso es exactamente el hueco que cubre una revisión externa: no aporta conocimiento que tu equipo no tenga, aporta el hecho de que alguien se siente a mirarlo.
Preguntas frecuentes
¿Estos fallos aparecen también en empresas grandes? Sí. En empresas grandes suele haber más control en producción y bastante menos en las cuentas de desarrollo y de proyectos antiguos, que es donde acaban acumulándose.
¿Cuánto se tarda en arreglar los siete? Entre uno y tres días de trabajo para una cuenta de tamaño medio, y la mayor parte del tiempo se va en el punto 4, probar la restauración.
¿Puedo comprobarlo yo mismo? Sí, y deberías. El checklist completo de 30 puntos tiene los comandos.
Trabaja conmigo: auditoría completa de AWS a precio cerrado.
Sigue leyendo: cómo reducir la factura de AWS.