Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected Tool

Explica la revisión de arquitectura de cargas de trabajo con AWS Well-Architected Tool. Presenta la evaluación basada en los 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizadas.

Unos 9 min de lecturaÚltima actualización: 2026-10-31

Well-Architected Framework y la herramienta de revisión

AWS Well-Architected Framework es un marco que sistematiza las prácticas recomendadas de arquitectura en la nube en 6 pilares (excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes y sostenibilidad). Well-Architected Tool es una herramienta administrada que evalúa las cargas de trabajo según este marco e identifica los puntos de mejora de la arquitectura mediante revisiones en formato de preguntas. Para cada pilar se ofrecen varias preguntas y, a partir de las respuestas, se identifican automáticamente los elementos de mejora de riesgo alto (HRI: High Risk Issue) y de riesgo medio (MRI: Medium Risk Issue).

Evaluación de cargas de trabajo y plan de mejora

El uso de Well-Architected Tool comienza con la definición de la carga de trabajo. Usted especifica el nombre de la carga de trabajo, la descripción, las cuentas de AWS de destino y la región, y selecciona las lentes que se aplicarán (la lente AWS Well-Architected Framework, la lente Serverless, la lente SaaS, etc.). Al responder las preguntas de cada pilar, el grado de cumplimiento de las prácticas recomendadas se muestra en un panel. En el plan de mejora (Improvement Plan), la lista de HRI y MRI se muestra por orden de prioridad, y para cada elemento se ofrecen recomendaciones de mejora concretas y enlaces a la documentación de referencia. Con la función de hitos puede guardar instantáneas de los resultados de la evaluación, volver a evaluar después de aplicar las mejoras y comparar el progreso. El patrón operativo recomendado es realizar revisiones trimestrales y seguir la evolución de las mejoras con los hitos.

Lentes personalizadas e integración con Organizations

Las lentes personalizadas son una función para definir como elementos de evaluación las prácticas recomendadas propias de la organización o los requisitos específicos de un sector. La lente se define en formato JSON, y puede configurar pilares, preguntas, prácticas recomendadas y planes de mejora propios. Por ejemplo, puede crear lentes personalizadas que evalúen el cumplimiento de los requisitos normativos del sector financiero, de las políticas de seguridad internas o de patrones de arquitectura concretos. Gracias a la integración con Organizations, puede compartir las lentes personalizadas con todas las cuentas de la organización y realizar revisiones con criterios de evaluación unificados. El uso de Well-Architected Tool en sí no tiene coste adicional, pero ser gratuito no es lo mismo que ser ilimitado. Según las cuotas de servicio oficiales (a fecha de agosto de 2026), las lentes personalizadas están limitadas a 15 por cuenta y región, una misma lente puede compartirse con hasta 300 destinatarios y una carga de trabajo puede asociarse con hasta 20 lentes. Todos son valores fijos que no admiten solicitud de aumento. En los diseños que distribuyen lentes a toda la organización, se acota su uso partiendo de estos límites. Mientras que Trusted Advisor realiza comprobaciones automáticas a nivel de recursos (configuración pública de S3, EC2 sin usar, etc.), Well-Architected Tool realiza revisiones interactivas a nivel de arquitectura (¿es adecuada la estrategia de DR?, ¿es suficiente el sistema de supervisión?), por lo que ambas se complementan.

Precios de Well-Architected Tool

El uso de Well-Architected Tool no tiene coste adicional, y la realización de revisiones o el guardado de hitos no se cobran por sí mismos. Solo se paga por los recursos de AWS que son objeto de la evaluación. Tampoco hay coste adicional al compartir lentes personalizadas con toda la organización mediante la integración con Organizations. Sin embargo, que el precio sea gratuito no es lo mismo que no haya límite en el número que se puede crear. Según las cuotas de servicio oficiales (a fecha de agosto de 2026), los límites son 1,000 cargas de trabajo por cuenta y región, 100 hitos por carga de trabajo y 500 plantillas de revisión por cuenta y región, y ninguno admite solicitud de aumento. En operaciones que concentran cientos de cargas de trabajo en una sola cuenta, o que crean una carga de trabajo nueva en cada revisión, es seguro tener presentes estos límites y decidir de antemano las convenciones de nombres y la separación de cuentas. Se recomienda convertir en hábito las revisiones periódicas trimestrales y aprovecharlas para la mejora continua de la arquitectura.

Cómo entender los 6 pilares

Well-Architected Framework organiza en 6 pilares los puntos de vista para evaluar un buen diseño. La excelencia operativa plantea si se pueden mejorar las operaciones de forma continua. La seguridad plantea si los datos y los sistemas están protegidos. La fiabilidad plantea si es posible recuperarse de los fallos y responder a la demanda. La eficiencia del rendimiento plantea si se utilizan los recursos de forma eficiente. La optimización de costes plantea si se evitan los gastos innecesarios. La sostenibilidad plantea si se tiene en cuenta el impacto ambiental. Al revisar las cargas de trabajo desde múltiples ángulos siguiendo estos pilares, es posible realizar una evaluación del diseño equilibrada que no se inclina hacia un punto de vista concreto.

Convertir las revisiones en un hábito

Una revisión de arquitectura no termina después de hacerla una sola vez. Como los sistemas cambian continuamente, es importante revisarlos con regularidad. Si realiza revisiones en momentos clave, como antes de añadir funciones importantes o cambiar la configuración, o cada trimestre, podrá detectar pronto las desviaciones del diseño y los nuevos riesgos. También es eficaz incorporarlas como punto de control antes de cada lanzamiento a producción. Al convertir las revisiones en una parte habitual del proceso de desarrollo, puede abordar los problemas antes de que se acumulen y sea demasiado tarde. Contar con un mecanismo de inspección continua es la clave para mantener la salud de los sistemas a largo plazo.

Priorización de las mejoras

Aunque una revisión detecte muchos problemas, no es realista abordarlos todos a la vez. Los elementos detectados se clasifican según su nivel de riesgo y se abordan primero los más graves. Well-Architected Tool identifica los elementos de riesgo alto y ayuda a elaborar el plan de mejora. Las prioridades se fijan de modo que los riesgos graves relacionados con la seguridad o la fiabilidad se abordan cuanto antes y las mejoras de menor impacto se llevan a cabo de forma planificada. Se hace un seguimiento del progreso y se confirma que los riesgos disminuyen de forma constante. Concentrar los recursos limitados en las mejoras importantes conduce a una mejora eficaz de la arquitectura.

Arraigar una cultura de mejora del diseño

El verdadero valor de Well-Architected no reside en usar la herramienta en sí, sino en arraigar en la organización una cultura de mejora continua del diseño. Contar con el marco común de los 6 pilares facilita el debate sobre el diseño entre equipos y unifica los criterios de evaluación. Si se comparte lo aprendido en las revisiones, mejora la capacidad de diseño de toda la organización. Si se evalúan varias cargas de trabajo de forma transversal, se hacen visibles las debilidades comunes y los patrones de mejora. No dejar las revisiones en un trámite formal, sino aprovecharlas como oportunidades de aprendizaje y mejora, es lo que cultiva una cultura de diseño sólida.

Resumen - Pautas de uso de Well-Architected Tool

AWS Well-Architected Tool es una herramienta que evalúa sistemáticamente la arquitectura de las cargas de trabajo según los 6 pilares. Sus principales puntos fuertes son las revisiones en formato de preguntas, la identificación automática de HRI/MRI, la elaboración de planes de mejora y la evaluación propia de la organización mediante lentes personalizadas. Se puede usar de forma gratuita, y se recomienda realizar revisiones trimestrales de las cargas de trabajo en producción. También se puede utilizar para las revisiones previas al lanzamiento de nuevas cargas de trabajo.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

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.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 a partir de los informes de incidentes de AWS (COE) - Principios de diseño transformados por los grandes incidentes del pasadoA partir de los Correction of Errors (COE) y los informes de incidentes publicados por AWS, explica las causas raíz de grandes incidentes del pasado, como el incidente de S3, el incidente de DNS en us-east-1 y el incidente 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.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.