Administración de operaciones

Hallazgos más comunes en Well-Architected Review - 5 errores de diseño que los ingenieros pasan por alto

Explicamos los problemas de diseño señalados repetidamente en AWS Well-Architected Review, centrándonos en 5 áreas: despliegue en una sola AZ, falta de backups, logs sin utilizar, optimización de costos abandonada y permisos excesivos en Security Groups.

約 7 分で読めます

Qué es Well-Architected Review

AWS Well-Architected Review es un programa en el que un arquitecto de soluciones de AWS o un partner certificado revisa las cargas de trabajo del cliente desde la perspectiva de 6 pilares (excelencia operativa, seguridad, fiabilidad, eficiencia de rendimiento, optimización de costos y sostenibilidad). También se puede realizar una revisión de autoservicio usando Well-Architected Tool. La revisión avanza en formato de preguntas, y a partir de las respuestas se identifican problemas de alto riesgo y riesgo medio. A partir de la experiencia de los arquitectos de soluciones de AWS realizando miles de revisiones, existen patrones en los problemas señalados repetidamente. A continuación presentamos los 5 hallazgos más frecuentes. No son problemas técnicamente avanzados, sino errores básicos de diseño que se podrían evitar si se conocieran.

Hallazgo 1: Despliegue en una sola AZ - El problema de fiabilidad más común

Los casos donde las cargas de trabajo de producción están desplegadas en una sola AZ son el problema más frecuentemente señalado en Well-Architected Review. Patrones como instancias EC2 que solo existen en una AZ, RDS en configuración de una sola AZ, o ELB asociado solo a subredes de una AZ. Con despliegue en una sola AZ, si esa AZ sufre una falla, el servicio se detiene completamente. Las fallas de AZ en AWS ocurren varias veces al año y no son eventos raros. La corrección es relativamente sencilla: especificar subredes de múltiples AZs en el Auto Scaling Group, cambiar RDS a despliegue multi-AZ y asociar subredes de múltiples AZs al ELB. El incremento de costo del despliegue multi-AZ es aproximadamente el doble en el caso de RDS, pero es una inversión razonable comparada con las pérdidas por interrupción del servicio. Los entornos de desarrollo y pruebas pueden ser de una sola AZ, pero los entornos de producción deben ser siempre multi-AZ.

Hallazgo 2: Falta de backups - Riesgo de pérdida de datos

La falta de backups es el segundo hallazgo más común: snapshots de volúmenes EBS no tomados, backups automáticos de RDS deshabilitados, Point-in-Time Recovery (PITR) de DynamoDB deshabilitado. También hay casos donde se descuida el backup confiando en la durabilidad de 11 nueves de S3. Sin embargo, la durabilidad de S3 es contra la pérdida física de datos y no protege contra eliminación accidental o maliciosa. Si el versionado de S3 no está habilitado, los objetos eliminados no se pueden recuperar. Con AWS Backup se pueden gestionar centralizadamente los backups de EC2, EBS, RDS, DynamoDB, EFS y S3. Se definen políticas de backup, se toman backups automáticamente según el programa y se eliminan automáticamente los backups antiguos según el período de retención. Además de tomar backups, las pruebas periódicas de restauración son importantes. Aunque existan backups, si no se han establecido procedimientos de restauración, no se podrá recuperar durante una falla.

Hallazgo 3: Permiso 0.0.0.0/0 en Security Groups

Los casos donde las reglas de entrada de Security Groups permiten acceso desde 0.0.0.0/0 (todas las direcciones IP) son el hallazgo más común en el pilar de seguridad. Especialmente los casos donde SSH (puerto 22) o RDP (puerto 3389) están abiertos a 0.0.0.0/0 son de alto riesgo. Los bots en Internet escanean constantemente los puertos 22 y 3389 abiertos y ejecutan automáticamente ataques de fuerza bruta. La solución es limitar el origen de acceso SSH/RDP a direcciones IP específicas, o usar Systems Manager Session Manager para eliminar completamente SSH/RDP. Session Manager permite acceder a instancias con autenticación IAM sin necesidad de abrir puertos en el Security Group. Para servidores web, abrir HTTP (80) y HTTPS (443) a 0.0.0.0/0 es legítimo, pero se recomienda un diseño donde se coloquen detrás de un ALB y el Security Group de las instancias EC2 solo permita acceso desde el Security Group del ALB.

Hallazgo 4: Optimización de costos abandonada - Recursos sin usar abandonados

Los casos donde recursos lanzados para desarrollo y pruebas quedan abandonados generando costos innecesarios son el hallazgo más común en el pilar de optimización de costos. Los patrones típicos son: instancias EC2 olvidadas sin detener, volúmenes EBS no adjuntos, direcciones Elastic IP sin usar (las EIP no adjuntas se cobran a 0,005 USD por hora), y NAT Gateways sin tráfico (0,045 USD/hora + cargos de procesamiento de datos). Las verificaciones de optimización de costos de AWS Trusted Advisor detectan automáticamente estos recursos desperdiciados. El informe de recursos con baja utilización de Cost Explorer también es efectivo. Otro hallazgo frecuente es no aprovechar Savings Plans o Reserved Instances. Operar cargas de trabajo estables de producción con precios bajo demanda resulta en pagar entre 30-60% más comparado con Savings Plans. Se recomienda verificar el monto de compromiso óptimo con la función de recomendación de Savings Plans de Cost Explorer.

Hallazgo 5: Deficiencias en logs y monitoreo

Las deficiencias en logs y monitoreo como CloudTrail no habilitado, CloudWatch Alarms no configuradas y logs de aplicación no estructurados son el hallazgo más común en el pilar de excelencia operativa. CloudTrail registra eventos de gestión por defecto, pero si no se configura la entrega a S3 (creación de trail), los eventos de más de 90 días se pierden. En entornos de producción, siempre se debe crear un trail y almacenar los logs a largo plazo en S3. Sin CloudWatch Alarms configuradas, la detección de fallas se retrasa. Como mínimo, se deben configurar alarmas para uso de CPU, uso de memoria (métricas personalizadas), uso de disco, tasa de errores 5xx del ELB y número de conexiones de RDS. Los logs de aplicación deben estructurarse en formato JSON y enviarse a CloudWatch Logs para poder analizarlos con consultas tipo SQL en CloudWatch Logs Insights. Los logs de texto no estructurados solo permiten búsquedas con grep durante la investigación de fallas, lo cual no es práctico en entornos a gran escala. Para aprender sistemáticamente los principios de diseño de Well-Architected, puede consultar libros especializados (Amazon).

Servicios relacionados

AWS Well-Architected ToolMarco de mejores prácticas y herramienta de revisión para evaluar y mejorar arquitecturas en la nubeAWS Trusted AdvisorServicio que proporciona recomendaciones en tiempo real para optimizar su entorno de AWS

Artículos relacionados

Revisión de cargas de trabajo con AWS Well-Architected Tool - Mejora de arquitectura basada en 6 pilaresCuantifica riesgos con revisiones de arquitectura basadas en 6 pilares, agrega mejores prácticas específicas de la organización con lentes personalizados. Realiza seguimiento del progreso de mejoras con hitos.Madurez del AWS Well-Architected Framework - Seis pilares que guían el diseño cloud de máximo nivelAnalizamos en detalle los seis pilares del AWS Well-Architected Framework, comparando su madurez con el Azure Well-Architected Framework y el GCP Architecture Framework.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.

Más sobre este tema

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalaresExplicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.

Artículos y servicios similares

Revisión de cargas de trabajo con AWS Well-Architected Tool - Mejora de arquitectura basada en 6 pilaresCuantifica riesgos con revisiones de arquitectura basadas en 6 pilares, agrega mejores prácticas específicas de la organización con lentes personalizados. Realiza seguimiento del progreso de mejoras con hitos.Madurez del AWS Well-Architected Framework - Seis pilares que guían el diseño cloud de máximo nivelAnalizamos en detalle los seis pilares del AWS Well-Architected Framework, comparando su madurez con el Azure Well-Architected Framework y el GCP Architecture Framework.El diseño de Availability Zones de AWS - La diferencia en confiabilidad que genera la separación física y el aislamiento de fallosExplicamos la filosofía de diseño de las AZ de AWS como grupos de centros de datos físicamente independientes, comparándolas con las zonas de disponibilidad de Azure y GCP, y analizamos la diferencia en madurez del aislamiento de fallos a partir de incidentes reales.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.