AWS Well-Architected: los seis pilares y cómo revisar un workload real

Toda revisión de arquitectura acaba llegando al mismo punto muerto: dos ingenieros no se ponen de acuerdo, ambos tienen argumentos plausibles y la decisión la toma quien es más sénior o más insistente. El Well-Architected Framework existe para sustituir eso por algo reproducible. Es un conjunto de preguntas, agrupadas en seis pilares, que un equipo responde sobre un workload concreto, junto con los principios de diseño y las sugerencias de mejora que hay detrás de cada pregunta. El resultado no es una puntuación, sino una lista de riesgos que el equipo ha aceptado conscientemente o se ha comprometido a eliminar.

Esta guía da por hecho que ya conoces los servicios tratados en los servicios principales de AWS. Recorre los seis pilares, muestra qué cambia cada uno en un despliegue real, se detiene en los puntos donde los pilares tiran en direcciones opuestas —que es donde el framework demuestra su valor— y termina con un procedimiento para hacer tu propia revisión.

Qué es el framework y qué no es

El framework es un banco de preguntas más un método de facilitación. Cada pilar contiene unas diez preguntas del tipo «¿Cómo haces…?», cada una con un conjunto de respuestas de buenas prácticas, y cada buena práctica que no puedes acreditar se convierte en un elemento de riesgo clasificado como alto, medio o ninguno. AWS lo publica como documentación, lo integra en la Well-Architected Tool, gratuita en la consola, y forma a partners para facilitar revisiones.

Lo que no es: una certificación, un estándar de cumplimiento ni una receta. En ningún sitio dice «usa Amazon Aurora». Dice que debes entender tus objetivos de recuperación, que debes probar la recuperación y que tu almacén de datos debe cumplirlos. Tampoco es un ejercicio puntual. Un workload supera una revisión, entrega seis meses de funcionalidades y ya es otro workload; el framework está pensado para aplicarse repetidamente en hitos clave: antes del lanzamiento, tras un rediseño importante o después de un incidente grave.

La unidad de revisión importa más de lo que esperan los principiantes. Un workload es un conjunto de componentes que, juntos, aportan valor de negocio: una API de pagos con su base de datos y su cola, no «nuestra cuenta de AWS» ni «una función Lambda». Revisar una cuenta entera produce respuestas tan generales que no se deriva ninguna acción.

Los seis pilares

El framework nació con cinco pilares; la sostenibilidad se añadió en 2021 y hoy está al mismo nivel que los demás.

Excelencia operativa

Este pilar trata las operaciones como un producto con su propio backlog. Sus principios de diseño empujan hacia cambios pequeños y reversibles, operaciones definidas como código y aprendizaje a partir de cada fallo. En la práctica impulsa decisiones como estas: los despliegues pasan por un pipeline y no por la consola, los runbooks viven en el control de versiones junto al servicio que describen, cada servicio emite logs estructurados y métricas de negocio en lugar de solo CPU, y las alarmas saltan por síntomas que notan los usuarios en lugar de por umbrales internos. La pregunta de la revisión que descoloca a la mayoría de los equipos es «¿cómo sabes que tu workload está sano?»: responder «CloudWatch está en verde» no equivale a saber que el checkout funciona.

Una prueba concreta útil: ¿puede un ingeniero recién llegado desplegar en producción un cambio de una línea, sin ayuda, en su segundo día, y revertirlo en menos de cinco minutos? Si no, las respuestas de excelencia operativa son pura aspiración. Estas disciplinas se solapan en gran medida con los pipelines de entrega continua.

Seguridad

El pilar de seguridad se organiza en torno a la identidad, la detección, la protección de la infraestructura, la protección de datos y la respuesta a incidentes. Su principio más estructural es usar credenciales de corta duración en todas partes: los workloads asumen roles de IAM en lugar de llevar access keys, las personas se federan a través de un proveedor de identidad en lugar de tener usuarios de IAM, y los secretos salen de un gestor de secretos administrado con rotación. El cifrado en reposo y en tránsito se espera por defecto, no se justifica caso por caso, porque en AWS activar ambos es prácticamente gratis.

El pilar también pregunta cómo investigarías. Eso implica CloudTrail activado en todas las regiones y entregado a una cuenta en la que nadie más pueda escribir, VPC flow logs disponibles cuando hagan falta y un procedimiento escrito que vaya de «ha saltado una alerta» a «lo hemos contenido». Los equipos que describen con detalle sus controles preventivos y se quedan callados cuando se les pregunta por la detección tienen un riesgo alto, lo admitan o no.

Fiabilidad

La fiabilidad parte de objetivos medibles. Sin un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) declarados, «el sistema debe ser altamente disponible» no es falsable. Después, el pilar pregunta por los fundamentos (¿estás cerca de una cuota de servicio que no podrás ampliar en mitad de un incidente?), la gestión del cambio (¿un despliegue provoca una caída?) y la gestión de fallos (¿pruebas la recuperación o solo los backups?).

Los principios de diseño son los de siempre —recuperarse automáticamente, probar los procedimientos de recuperación, escalar horizontalmente, dejar de adivinar la capacidad, gestionar el cambio mediante automatización— y el framework es inusualmente directo al afirmar que un backup que nunca has restaurado no es un backup. Los detalles prácticos están en alta disponibilidad y recuperación ante desastres.

Eficiencia del rendimiento

Este pilar trata de selección y medición: elegir el enfoque adecuado de cómputo, almacenamiento, base de datos y red, y reevaluarlo a medida que aparecen nuevas opciones. Es el pilar con más probabilidades de sacar a la luz una decisión tomada hace tres años y nunca revisada: una base de datos relacional usada como cola, una flota de instancias de propósito general ejecutando una carga limitada por memoria, un object store consultado fila a fila.

Sus prácticas son democratizar la tecnología avanzada (usar el servicio administrado en lugar de operar el tuyo), desplegar globalmente en minutos cuando la latencia importa, usar serverless para eliminar la capacidad ociosa, experimentar a menudo y tener en cuenta la mechanical sympathy: ajustar la tecnología a cómo se accede realmente a los datos. Lo que se espera como evidencia son benchmarks y pruebas de carga, no intuiciones.

Optimización de costes

La optimización de costes pregunta si el gasto del workload se entiende, se atribuye y es proporcionado. Sus prácticas son la gestión financiera como responsabilidad compartida, una arquitectura consciente del coste, ajustar la oferta a la demanda, medir la eficiencia en términos de negocio (coste por pedido, no coste por instancia) y revisar los compromisos de compra. Un workload que no sabe responder a «¿cuánto nos cuesta un cliente al mes?» tiene un hallazgo inmediato. La disciplina completa se trata en gestión de costes en la nube.

Sostenibilidad

El pilar más reciente pregunta por el impacto ambiental de los recursos que consumes, y es más accionable de lo que parece, porque la mayoría de sus consejos también reducen costes. Entre sus prácticas están ubicar los workloads en regiones con menor intensidad de carbono cuando la latencia y la soberanía lo permitan, maximizar la utilización para necesitar menos máquinas físicas, adoptar generaciones de instancias más nuevas y eficientes y servicios administrados, reducir el volumen y la vida útil de los datos almacenados, y reducir el trabajo que hacen los clientes: payloads más pequeños, mejor caché, menos peticiones de polling.

Donde la sostenibilidad se aparta de verdad del coste es en cosas como guardar menos copias de los datos entre regiones o aceptar una latencia algo mayor para ejecutar en una región más limpia. Son compromisos reales, y el pilar existe para que se discutan.

Dónde chocan los pilares

El framework reconoce con honestidad que no puedes maximizarlo todo, y lo interesante de una revisión es poner nombre a los compromisos.

• Fiabilidad frente a coste. Un warm standby en una segunda región duplica aproximadamente el gasto de infraestructura de un sistema que está inactivo la mayor parte del tiempo. La pregunta no es «¿podemos permitírnoslo?», sino «¿cuánto vale una hora de caída?».
• Seguridad frente a excelencia operativa. El acceso break-glass, la aprobación estricta de cambios y el aislamiento de red ralentizan la entrega. La solución suele ser la automatización —policy as code, recogida automática de evidencias— en lugar de elegir un bando.
• Rendimiento frente a coste y sostenibilidad. La capacidad aprovisionada da una latencia predecible; escalar a cero ahorra dinero y energía, pero introduce cold starts. Los workloads serverless suelen aceptar una penalización en el p99 a cambio.
• Excelencia operativa frente a fiabilidad. Desplegar con frecuencia reduce el tamaño de cada cambio, pero aumenta el número de eventos de cambio, que son la principal causa de incidentes. La entrega progresiva —canaries, feature flags, rollback automático— es la forma de tener ambas cosas.

Registra estos puntos como decisiones explícitas. Un architecture decision record de una página que diga «aceptamos un RTO de cuatro horas porque un warm standby cuesta más que la pérdida estimada» vale más que una suposición no escrita de que el sistema es multirregión.

Cómo revisar un workload real

1. Define el workload y su contexto

   Anota los componentes, el responsable de negocio, el nivel de criticidad, las regiones utilizadas y el RTO y RPO actuales. Todo lo que quede fuera de ese perímetro queda fuera del alcance de esta revisión.

2. Crea el workload en la Well-Architected Tool

   La herramienta guarda el workload, las respuestas y la lista de riesgos, y te permite repetir la revisión más adelante sobre la misma línea base. Los milestones congelan un momento concreto para que puedas demostrar el progreso.

3. Responde a las preguntas en grupo, sin maquillar la realidad

   Trabaja un pilar cada vez. Para cada buena práctica, las respuestas honestas son «sí, y aquí es donde está implementado» o «no». «En parte» significa no. Guarda el enlace a la evidencia —el pipeline, el dashboard, la policy—, porque eso es lo que hace que la respuesta sea auditable más adelante.

4. Convierte los riesgos en un backlog

   Cada riesgo alto o medio se convierte en un ticket con un responsable y un hito objetivo. Agrúpalos: cinco hallazgos suelen compartir una misma causa raíz, como la ausencia de infraestructura como código.

5. Programa la siguiente revisión

   Entre seis y doce meses después, o inmediatamente tras un rediseño importante o un incidente de severidad 1.

La herramienta se puede automatizar con scripts, algo importante si revisas decenas de workloads. Así se crea un workload desde la CLI:

aws wellarchitected create-workload \
  --workload-name "payments-api-prod" \
  --description "Card authorisation API and its data stores" \
  --environment PRODUCTION \
  --aws-regions eu-west-1 eu-central-1 \
  --lenses wellarchitected serverless \
  --review-owner "[email protected]"

aws wellarchitected list-lens-review-improvements \
  --workload-id "$WORKLOAD_ID" --lens-alias wellarchitected \
  --query 'ImprovementSummaries[?RiskFacingRisk!=`NONE`].[PillarId,QuestionTitle,Risk]' \
  --output table

Un patrón que merece la pena adoptar: acompañar la revisión de un poco de evidencia automatizada. Las reglas de AWS Config, los estándares de Security Hub y las comprobaciones de Trusted Advisor pueden responder mecánicamente a una parte de las preguntas —¿está activado el cifrado?, ¿están configurados los backups?, ¿hay buckets públicos?— y dejar el tiempo del taller para las preguntas que requieren criterio.

Errores comunes

Revisar la arquitectura que pretendías construir. Las respuestas deben describir producción tal como está hoy, incluido el paso manual que todo el mundo olvida y la instancia que alguien lanzó a mano. Saca la evidencia de la cuenta, no del diagrama.

Tratar el número de riesgos como una puntuación que hay que minimizar. Los equipos aprenden rápido qué respuestas hacen bajar la cifra. Si nadie registra nunca un riesgo alto, la revisión se ha convertido en teatro.

Saltarse los pilares que parecen trabajo de otros. Los desarrolladores se saltan el coste, los equipos de plataforma se saltan el rendimiento y todos se saltan la sostenibilidad. Son justo los pilares en los que una pregunta desde fuera encuentra algo.

Hacer la revisión y no programar nunca el seguimiento. El valor del framework está en la diferencia entre revisiones. Una única revisión que produce un documento que nadie vuelve a abrir es una tarde muy cara.

Puntos clave

• El Well-Architected Framework es un conjunto estructurado de preguntas que se aplica a un workload cada vez y produce una lista de riesgos aceptados o corregidos, no una puntuación.
• Los seis pilares son excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes y sostenibilidad; cada uno impulsa decisiones concretas y comprobables.
• La verdadera aportación del framework es sacar los compromisos a la luz: fiabilidad frente a coste, seguridad frente a velocidad de entrega, latencia frente a eficiencia.
• Una revisión necesita a las personas que construyen, operan y financian el workload, evidencias de la cuenta en producción y un facilitador externo que mantenga honestas las respuestas.
• Los hallazgos solo importan si se convierten en elementos del backlog con responsable y una revisión de seguimiento programada; las lenses amplían las preguntas base para serverless, SaaS, analítica o tus propios estándares.