Errores comunes en AWS y cómo prevenirlos: lecciones para arquitectos cloud

Errores frecuentes en proyectos de nube AWS: seguridad (buckets públicos, IAM sobredimensionado), costos descontrolados, diseño sin alta disponibilidad, y cómo evitarlos con buenas prácticas del AWS Well-Architected Framework.

1. Error #1: Buckets S3 públicos accidentalmente

El error más famoso de AWS: dejar un bucket S3 con permisos de "lectura pública" o "listado público", exponiendo datos sensibles. Ejemplos reales: Booz Allen, Dow Jones, Apple (configuraciones internas), y miles de empresas.

• Prevención: Habilitar "Block Public Access" a nivel de cuenta por defecto. Solo deshabilitar para buckets específicos que necesiten ser públicos (ej: sitio web estático), y luego auditar.
• Detección: Usar AWS Trusted Advisor, Macie, o herramientas de terceros como ScoutSuite. Configurar alertas de CloudTrail para cambios en políticas de bucket.
• Política: Nunca usar "Authenticated Users" o "Everyone" en políticas de bucket. Usar presigned URLs para acceso temporal.

2. Error #2: Roles IAM con privilegios excesivos

Conceder permisos como "AdministratorAccess" o "s3:*" a roles que solo necesitan leer un bucket específico es una puerta abierta a la escalada de privilegios.

• Prevención: Aplicar principio de mínimo privilegio. Usar políticas administradas o personalizadas específicas. Ejemplo: en lugar de "s3:*", usar "s3:GetObject" y "s3:ListBucket" con condición de recurso.
• Herramientas: IAM Access Analyzer para identificar permisos no utilizados. AWS Organizations SCP (Service Control Policies) para limitar máximos permisos.
• Revisión: Auditoría trimestral de roles IAM. Eliminar roles no utilizados.

3. Error #3: Instancias EC2 sobredimensionadas o abandonadas

Es común lanzar una instancia "grande" (ej: m5.4xlarge) para pruebas y olvidar detenerla, o mantener instancias de desarrollo activas 24/7 cuando solo se usan 8 horas al día.

• Prevención: Usar AWS Compute Optimizer para recomendar tamaños. Implementar políticas de "instance scheduler" que apaguen instancias de desarrollo fuera de horario laboral.
• Detección: AWS Cost Explorer y Trusted Advisor reportan instancias idle o sobredimensionadas. Configurar alarmas de presupuesto (Budget Alarms).
• Acción: Usar etiquetas (tags) para distinguir producción vs desarrollo. Automatizar detención de instancias no productivas con Lambda.

4. Error #4: No usar etiquetas (tags) y luego no saber quién gasta qué

Cuando varias aplicaciones, equipos o clientes comparten la misma cuenta AWS, es imposible asignar costos sin etiquetas consistentes.

• Prevención: Definir política de tagging obligatorio al lanzar recursos: Environment (prod/dev), CostCenter, Application, Owner. Aplicar etiquetas a todos los recursos (EC2, S3, RDS, etc).
• Herramientas: AWS Cost Explorer permite agrupar por tags. Etiquetas heredadas (Resource Groups Tagging API).
• Penalización: Automatizar detección de recursos sin tags y notificar al dueño (con Lambda).

5. Error #5: Diseñar sin alta disponibilidad (una sola AZ, un solo balanceador)

Muchos proyectos usan una sola Availability Zone (AZ) para EC2, RDS, etc. Si esa AZ tiene una interrupción (ocurre cada cierto tiempo), el sistema cae completamente.

• Prevención: Para producción, mínimo 2 AZs. Usar Auto Scaling Groups y Application Load Balancer (multi-AZ). RDS debe tener multi-AZ habilitado (con standby en otra AZ).
• Costo adicional: Mínimo (~10-20% más), pero evita downtime que cuesta mucho más.
• Excepción: Workloads no críticos (desarrollo, pruebas) pueden usar una sola AZ con menor SLA.

6. Error #6: No monitorear ni alarmar nada

Configurar EC2, RDS, etc, pero no tener CloudWatch Alarms para CPU, memoria, o alarmas de facturación. Recién se dan cuenta cuando la instancia está caída hace horas o la factura se disparó.

• Prevención: Configurar alarmas básicas: CPU >80% por 15 min, StatusCheckFailed (instancia unreachable), billing > $X (budget alarm). Usar AWS Health Dashboard para eventos programados.
• Acción: Integrar con SNS para enviar notificaciones por correo, Slack o PagerDuty.
• Dashboards: Crear dashboard de CloudWatch personalizado para métricas clave.

7. Error #7: Usar la región incorrecta (o solo una región)

• Región incorrecta: Elegir región lejos de los usuarios finales aumenta latencia. Medir con AWS Latency Checker o herramientas de terceros.
• Falta de disaster recovery: Producir solo en una región. Si toda la región falla (ej: us-east-1 ha tenido incidentes), el negocio se detiene.
• Solución: Para workloads críticos, replicar datos a otra región (DynamoDB Global Tables, S3 Cross-Region Replication, RDS Cross-Region Read Replica + failover manual). Considerar Route53 failover.

8. Error #8: Ignorar los límites de servicio (service quotas)

Por defecto, cada cuenta tiene límites conservadores (ej: máximo 5 VPCs por región, 20 instancias EC2 por tipo de instancia).

• Impacto: En medio de un lanzamiento o escalamiento automático, te quedas sin capacidad y el sistema falla.
• Prevención: Solicitar aumentos de límites (quota increase) con anticipación. AWS usualmente aprueba en 1-2 días hábiles.
• Monitoreo: Usar Trusted Advisor para reportar límites cercanos a agotarse. Configurar CloudWatch para métrica "Usage" de cada servicio.

9. Error #9: No usar snapshots/backups (o no probar restauración)

• RDS: No habilitar backups automáticos (por defecto 7 días, se puede extender a 35).
• EBS: No tomar snapshots periódicos de volúmenes de datos importantes.
• Acción: Automatizar snapshots con Amazon Data Lifecycle Manager (DLM) o AWS Backup. Probar restauración de snapshots cada trimestre (lanzar instancia desde snapshot, validar datos).

10. Error #10: Usar credenciales de root para tareas diarias

La cuenta root tiene acceso total y no debe usarse excepto para tareas muy específicas (cambiar soporte, cerrar cuenta).

• Riesgo: Si las credenciales root se filtran, el atacante tiene control absoluto.
• Prevención: Crear usuario IAM con privilegios suficientes para administradores. Proteger credenciales root con MFA (dispositivo físico), guardar en lugar seguro (cofre, gestor de contraseñas de emergencia).
• Política: Nunca usar llaves de acceso (access key) de root. Rotar llaves de usuarios IAM anualmente.

11. Checklist de revisión de seguridad mensual para AWS

12. Conclusión: la nube no es segura por defecto, es segura por configuración

AWS opera bajo el modelo de responsabilidad compartida: AWS es responsable de la seguridad de la nube (hardware, red, hipervisor); el cliente es responsable de la seguridad en la nube (IAM, datos, parches, configuración).

• Automatiza buenas prácticas: Usa AWS Control Tower, Service Catalog, CloudFormation con reglas de validación.
• Capacita al equipo: Los errores humanos son la causa más común. Invierte en certificaciones AWS (Solutions Architect, Security).
• Revisa periódicamente: La nube cambia rápido; lo seguro hoy puede no serlo mañana. Programa auditorías recurrentes.

Aplicando estas lecciones, podrás aprovechar la potencia de AWS sin sufrir los dolores de cabeza comunes.