Buenas prácticas en AWS

Toda cuenta de AWS empieza limpia y, unos seis meses después, se convierte en un depósito de recursos olvidados, permisos demasiado amplios y una factura que nadie entiende. Las buenas prácticas que siguen no son teoría para un examen de certificación: son las consecuencias que aparecen cuando las ignoras.

IAM: menos privilegios, más roles

Una clave de acceso expuesta en un repositorio es, con diferencia, uno de los incidentes más comunes en AWS. Y casi siempre la clave pertenecía a un usuario con AdministratorAccess. Por eso:

• Elimina las credenciales estáticas de larga duración. EC2, ECS y Lambda asumen roles: no necesitan una access key hardcoded.
• Las personas acceden mediante SSO (IAM Identity Center), con credenciales temporales. Nada de usuarios humanos de IAM con una contraseña eterna.
• El least privilege de verdad es tedioso, pero vale la pena: empieza con el permiso mínimo y amplíalo cuando la aplicación se queje, no al revés. Access Analyzer ayuda a identificar qué está expuesto.

Si todavía tienes la clave root activa, deja de leer y ve a desactivarla ahora. Root es para emergencias, con MFA físico.

Una sola cuenta es deuda técnica: Organizations y multicuentas

Poner desarrollo, staging y producción en la misma cuenta resulta cómodo al principio y caro después: basta con ejecutar un terraform apply en el directorio equivocado para derribar producción. Una estrategia de multicuentas resuelve esto desde la raíz:

• Una cuenta por entorno (o por equipo o producto), todo bajo AWS Organizations.
• Las SCPs (Service Control Policies) bloquean acciones que ni siquiera un administrador debería poder realizar, como habilitar una región que no usas o desactivar CloudTrail.
• Facturación consolidada: una sola factura, pero con los costos aislados por cuenta. Resulta evidente quién está gastando.

Requiere más configuración el primer día, pero es la diferencia entre un radio de explosión pequeño y un incidente que afecta a todo el mundo.

El costo no debería ser una sorpresa de fin de mes

La factura de AWS no debería asustarte. Si lo hace, es porque nadie la está revisando. Tres frentes resuelven la mayoría de los casos:

• Budgets con alertas por correo electrónico o Slack en distintos umbrales (80 %, 100 % y previsión). El costo es una métrica: trátalo como tal.
• Right-sizing: esa instancia m5.2xlarge con un 8 % de CPU durante tres meses es dinero tirado a la basura. Compute Optimizer señala los casos más evidentes.
• Savings Plans / Reserved para cargas de trabajo estables. Usar On-Demand para una base predecible es pagar precio de mostrador: puedes recortar entre un 30 % y un 60 % comprometiendo lo que ya sabes que vas a utilizar.

Bonus: elimina lo que no usas. Un volumen EBS huérfano, un snapshot de 2023 o un NAT Gateway de un entorno abandonado: todo eso aparece silenciosamente en la factura.

Un servicio administrado casi siempre es mejor que EC2

Ejecutar tu propio Postgres en una instancia EC2 significa que ahora eres DBA y responsable de los parches, las copias de seguridad, el failover y de esa madrugada en la que el disco se llena. AWS lo hace mejor y con un costo menor que el tiempo de tu equipo:

• ¿Base de datos? RDS/Aurora en lugar de Postgres gestionado manualmente.
• ¿Cola, mensajería o tareas programadas? SQS, EventBridge y Lambda en lugar de un daemon en una instancia EC2 que olvidas actualizar.
• ¿Contenedores? ECS Fargate o EKS antes de administrar los nodos por tu cuenta.

EC2 no ha muerto: es la opción cuando el servicio administrado no encaja (una licencia específica, un kernel personalizado o la necesidad de un control detallado). El error es usarlo como opción predeterminada por costumbre.

Si no tiene tags, no existe

Un recurso sin tags es un huérfano: no sabes de quién es, a qué proyecto pertenece ni si puedes eliminarlo. Sin tags, cualquier informe de costos se convierte en una estimación.

• Estandariza un conjunto reducido de claves obligatorias: env, owner, project y cost-center.
• Obliga a usarlas mediante Tag Policies y SCP: un recurso sin tags no se crea.
• Activa Cost Allocation Tags para desglosar la factura por equipo o proyecto en Cost Explorer.

Implementar tags es tedioso, pero no tiene precio el día que alguien pregunta: "¿por qué la factura subió un 40 %?".

Observabilidad: CloudWatch y CloudTrail activados desde el día cero

Depurar sin logs es adivinar. En AWS, los dos pilares vienen de fábrica: solo hay que activarlos correctamente.

• CloudTrail en todas las cuentas (mediante un organization trail), registrando los eventos en un bucket central e inmutable. Es tu registro de "quién hizo qué y cuándo": la auditoría y el análisis posterior a un incidente dependen de él.
• CloudWatch para métricas, logs y alarmas. Una alarma debe activarse antes de que el usuario se queje, no después.
• Centraliza los logs y los traces en una cuenta de observabilidad separada, sin acceso de escritura desde las cuentas de las aplicaciones. Un log que el atacante puede borrar no es evidencia.

Si solo tienes estos dos servicios activados y nada más, ya estás por delante de la mayoría.

Las buenas prácticas en AWS no son burocracia de compliance: son lo que separa la cuenta que tú controlas de la cuenta que te controla a ti (y a tu tarjeta de crédito). Elige una sección de las anteriores y soluciónala esta semana. Tu próxima factura te lo agradecerá.