AWS Well-Architected Agent: la revisión de arquitectura ahora la hace un agente (preview)

Hacer una revisión Well-Architected como corresponde siempre costó lo mismo: una o varias jornadas con el equipo respondiendo un cuestionario largo, alguien juntando evidencia de cinco consolas distintas y, al final, un informe que envejece en semanas. Trusted Advisor ayudaba con chequeos puntuales, pero no sabía qué aplicación era crítica ni qué le importaba a tu negocio este trimestre.

El 1 de octubre de 2026 AWS lanzó en preview pública AWS Well-Architected Agent, un servicio con IA que analiza tus cuentas de forma continua y devuelve recomendaciones de costos, seguridad, resiliencia y rendimiento priorizadas según objetivos que vos declarás. Además de decirte qué está mal, te da el arreglo: pasos en consola, comandos de CLI o el cambio en tu código de infraestructura (IaC). AWS lo presenta como la evolución de Trusted Advisor y de la Well-Architected Tool, y lo entrega a través de AWS Support.

En este artículo vemos qué hace, cómo se configura con roles de solo lectura en varias cuentas, cómo pedirle una revisión de un repo de Terraform de EKS antes de desplegar, qué se sabe (y qué no) de precios, y qué conviene mirar antes de darle acceso a toda la organización.

TL;DR

• Preview pública desde el 1/10/2026. El servicio corre en us-east-1, us-east-2 y us-west-2, pero puede analizar recursos de cualquier región comercial, incluida São Paulo.
• Se configura con un perfil: hasta 100 cuentas, sus regiones, los pilares que te interesan y un objetivo por pilar. Las primeras recomendaciones llegan dentro de las 24 horas.
• Lee configuración de más de 65 servicios, métricas de uso y topología de aplicaciones con roles de solo lectura (rol de ejecución + rol de acceso por cuenta).
• Recomendaciones en tres niveles: recurso, aplicación y arquitectura, con prioridad, esfuerzo, impacto estimado (incluso en dólares) y trade-offs con otros pilares.
• Revisión de IaC antes de desplegar: subís un .zip con Terraform, CloudFormation o CDK y elegís lente y pilares.
• Remediación por consola, IaC actualizado, CLI, SDK, runbooks de Systems Manager y MCP. En lo que mostró AWS, el agente no aplica cambios por su cuenta.
• Requiere un plan de AWS Support. AWS no publicó precio durante la preview.

Por qué ahora

AWS venía resolviendo el problema por partes. Trusted Advisor tiene chequeos automáticos, pero son reglas fijas sobre recursos sueltos: te avisa que un volumen EBS está sin usar, no que tu pipeline de eventos no tiene alarmas en sus colas de mensajes fallidos (DLQ). La Well-Architected Tool tiene el marco completo y las lentes, pero depende de que un equipo se siente a responder preguntas. Compute Optimizer y Cost Optimization Hub ven costos y dimensionamiento, Security Hub ve seguridad, y cada uno tiene su consola.

El resultado en la práctica es conocido: las revisiones se hacen una vez por año (si se hacen), los hallazgos de cada herramienta compiten por atención sin un criterio común, y nadie conecta "este rol tiene permisos de administrador" con "y es el que usa el pipeline que despliega producción".

La apuesta del agente es juntar esas señales, cruzarlas con contexto de negocio (qué aplicaciones existen, qué tan críticas son, qué objetivos tenés) y devolver una lista corta y ordenada, con el arreglo ya escrito. Es la misma línea que AWS viene siguiendo con AWS DevOps Agent para incidentes: agentes que hacen el trabajo de análisis y dejan la decisión del lado del equipo.

Qué es y qué no es

Qué es. Un servicio de AWS Support, con su panel dentro de la consola de Well-Architected, que analiza de forma continua las cuentas y regiones de un perfil y genera recomendaciones priorizadas. También hace revisiones de arquitectura bajo demanda sobre código de IaC, antes de que exista infraestructura.

Qué no es.

• No reemplaza a la Well-Architected Tool. AWS aclara que podés seguir usando la herramienta para evaluaciones manuales. El agente la complementa.
• No es un auditor de cumplimiento. No certifica PCI ni SOC 2. Recomienda mejoras según el marco Well-Architected.
• No toca tus recursos por su cuenta, al menos en lo que mostró AWS: los roles son de lectura y la remediación la ejecutás vos (o tu pipeline).
• No es infalible. Cada recomendación aclara que fue generada con IA y que puede tener errores o información incompleta. Evaluarla sigue siendo tu responsabilidad.
• No cubre todo el marco en la preview. La consola ofrece cuatro pilares (costos, seguridad, resiliencia y rendimiento). La API ya lista OPERATIONAL_EXCELLENCE como valor posible, pero en la preview no aparece en la consola. En revisiones de IaC, por ahora la lente disponible es la del Well-Architected Framework.

Cómo funciona

El perfil

Todo arranca en un perfil (agent profile) que creás en la cuenta que va a hospedar el servicio. Ahí definís:

• Cuentas y regiones a monitorear. Hasta 100 cuentas por perfil, listadas por ID, y las regiones de cada una. Pueden ser regiones fuera de EE.UU.
• Pilares y objetivos. Para cada pilar escribís un objetivo de negocio, por ejemplo "reducir gasto innecesario en todas mis cuentas" o "que las cargas toleren fallas y se recuperen solas". El agente usa esos objetivos para ordenar las recomendaciones.
• Rol de ejecución y nombre del rol de acceso que va a existir en cada cuenta.
• Protección contra borrado del perfil, activada por defecto en la consola.

Contexto de aplicación

Opcionalmente podés agregar contexto de aplicación: qué aplicaciones hay, en qué cuentas y regiones viven, qué servicios usan y qué tags las identifican. Con eso el agente puede agrupar hallazgos por aplicación y no solo por recurso. Es la diferencia entre "15 colas sin alarma" y "el pipeline de procesamiento de eventos no tiene observabilidad de fallas en ninguna de sus tres regiones".

Permisos: roles encadenados

El modelo de acceso usa encadenamiento de roles (role chaining):

1. Un rol de ejecución en la cuenta del perfil, que confía en el servicio wellarchitected.amazonaws.com y tiene permiso para asumir los roles de acceso.
2. Un rol de acceso en cada cuenta monitoreada, con la política administrada WellArchitectedAgentResourceScanning (solo lectura), que confía en el rol de ejecución.
3. Un external ID (el ARN del perfil) para evitar el problema del "confused deputy", donde un servicio podría ser usado para acceder a recursos de otro cliente.

La incorporación es opcional por cuenta: una cuenta sin rol de acceso simplemente no se analiza.

Recomendaciones: recurso, aplicación y arquitectura

Las recomendaciones vienen en tres tipos:

Cada una trae prioridad (HIGH, MEDIUM, LOW), esfuerzo (SMALL, MEDIUM, LARGE), impacto, una estimación de retorno, la cantidad de recursos afectados, beneficios para otros pilares y trade-offs. Ese último campo es el que más me gustó: un buen arquitecto siempre te dice qué perdés al aplicar un cambio, y acá está explícito.

El detalle de una recomendación muestra la explicación (insights), las señales que la dispararon, el impacto estimado, los recursos afectados con su ARN, cuenta y región, y recomendaciones relacionadas. En el ejemplo de AWS, poner dos alarmas por DLQ bajaría el tiempo de detección de 48 minutos a unos 2.

Remediación: del hallazgo al cambio

Al tocar Start remediation elegís cómo arreglarlo: desde la consola, con el template de IaC actualizado o con la AWS CLI. En la API, los tipos de remediación incluyen además SDK, MCP y uno llamado AUTO_REMEDIATION. El anuncio también menciona runbooks de Systems Manager para cambios de configuración y la posibilidad de consumir todo desde tus herramientas de IA para programar vía el AWS MCP Server.

En el ejemplo de AWS, la opción de IaC devuelve una función de CDK lista para pegar en tu stack, dividida en fases (agregar el código y después desplegar y verificar), y podés descargar el procedimiento completo.

Revisión de arquitectura sobre IaC

La otra mitad del servicio es la revisión bajo demanda. Subís a S3 un .zip con tu proyecto de IaC (Terraform, CloudFormation o CDK), elegís la lente y los pilares, y el agente revisa el código antes de que haya infraestructura. Los archivos binarios y multimedia del .zip se excluyen.

Classmethod lo probó apenas salió: la revisión tardó unos 30 minutos y, entre otras cosas, marcó una función Lambda con MemorySize: 256 fijo y sin alarmas ni automatización para ajustarla. Nada que un buen revisor humano no vea, pero sin agendar a nadie.

Manos a la obra

Vamos a dejar andando un perfil sobre dos cuentas (una de plataforma con EKS y otra de producción), a pedir una revisión de un repo de Terraform de EKS y a consultar recomendaciones desde la CLI. Antes de empezar: necesitás un plan de AWS Support activo, una versión reciente de la AWS CLI (los comandos *-agent-* de wellarchitected son nuevos) y trabajar en una de las regiones del servicio. Uso us-east-1.

1. Rol de ejecución en la cuenta del perfil

cat > exec-trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "wellarchitected.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role --path /service-role/ \
  --role-name WAAgentExecutionRole \
  --assume-role-policy-document file://exec-trust.json

cat > exec-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/AccessRoleForWellArchitectedAgent"
  }]
}
EOF

aws iam put-role-policy --role-name WAAgentExecutionRole \
  --policy-name assume-access-roles \
  --policy-document file://exec-policy.json

2. Rol de acceso en cada cuenta monitoreada

En cada cuenta (acá 111122223333 es la del perfil), creá el rol con la política administrada de solo lectura. Buscá el ARN exacto de la política en vez de escribirlo a mano:

POLICY_ARN=$(aws iam list-policies --scope AWS \
  --query "Policies[?PolicyName=='WellArchitectedAgentResourceScanning'].Arn" \
  --output text)

cat > access-trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111122223333:role/service-role/WAAgentExecutionRole"
    },
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role --role-name AccessRoleForWellArchitectedAgent \
  --assume-role-policy-document file://access-trust.json
aws iam attach-role-policy --role-name AccessRoleForWellArchitectedAgent \
  --policy-arn "$POLICY_ARN"

Para varias cuentas, lo razonable es desplegar este rol con CloudFormation StackSets desde la cuenta de administración. La documentación de IAM del agente explica cómo agregar el external ID (el ARN del perfil) a la política de confianza; hacelo una vez que el perfil exista.

3. Crear el perfil

cat > aggregation.json <<'EOF'
[
  {
    "accountId": "111122223333",
    "regions": ["us-east-1", "sa-east-1"],
    "accessRoleArn": "arn:aws:iam::111122223333:role/AccessRoleForWellArchitectedAgent"
  },
  {
    "accountId": "444455556666",
    "regions": ["sa-east-1"],
    "accessRoleArn": "arn:aws:iam::444455556666:role/AccessRoleForWellArchitectedAgent"
  }
]
EOF

aws wellarchitected create-agent-profile \
  --name plataforma-eks \
  --display-name "Plataforma EKS" \
  --business-overview "Plataforma de contenedores en EKS para APIs de pagos" \
  --pillars COST_OPTIMIZATION SECURITY RESILIENCE PERFORMANCE \
  --execution-role-arn arn:aws:iam::111122223333:role/service-role/WAAgentExecutionRole \
  --aggregation-configuration file://aggregation.json \
  --deletion-protection \
  --region us-east-1

Los objetivos por pilar y el contexto de aplicación son más cómodos de cargar desde la consola. Después, get-agent-profile te dice si el perfil quedó habilitado para generar recomendaciones programadas (eligibleForScheduledGeneration) y revisiones de arquitectura (eligibleForArchitectureGeneration), y en fieldErrors aparece lo que esté mal configurado:

aws wellarchitected get-agent-profile \
  --profile-arn arn:aws:wellarchitected:us-east-1:111122223333:agent-profile/plataforma-eks \
  --region us-east-1

4. Revisión de un repo de Terraform de EKS

Empaquetá el repo sin estado, sin caché de providers y sin variables con secretos:

cd infra-eks
zip -r ../infra-eks.zip . \
  -x ".terraform/*" "*.tfstate" "*.tfstate.backup" "*.tfvars" ".git/*"
aws s3 cp ../infra-eks.zip s3://mi-bucket-revisiones/infra-eks.zip

Después, en la consola: Conduct architecture review, elegís el objeto de S3, la lente Well-Architected Framework y los pilares. Las recomendaciones de tipo arquitectura aparecen en el mismo panel que las del análisis continuo.

5. Consultar recomendaciones desde la CLI

# Recomendaciones abiertas de costos
aws wellarchitected list-agent-recommendations \
  --profile-arn arn:aws:wellarchitected:us-east-1:111122223333:agent-profile/plataforma-eks \
  --pillar COST_OPTIMIZATION --state OPEN \
  --region us-east-1

# Detalle de una recomendación, con la remediación en formato IaC
aws wellarchitected get-agent-recommendation \
  --recommendation-arn <ARN de la recomendación> \
  --remediation-type IAC \
  --region us-east-1

Cada recomendación trae el campo awsServices, así que podés filtrar las que tocan EKS o ECS y armar un reporte semanal para el equipo de plataforma, o abrir un issue por cada recomendación HIGH.

Trampas comunes

• Aplicar el arreglo por CLI en un entorno con GitOps. Si tu infraestructura vive en Terraform y tus manifiestos en Argo CD, un cambio por consola o CLI genera drift y el próximo apply o sync lo revierte. Usá la remediación de IaC y pasala por pull request.
• Subir secretos en el .zip. El agente excluye binarios, no terraform.tfvars ni archivos .env. Revisá qué empaquetás.
• Asumir que "solo lectura" significa "no ve nada sensible". El rol lee configuración de recursos. Revisá qué incluye WellArchitectedAgentResourceScanning antes de desplegarla en cuentas con datos regulados.
• Esperar resultados inmediatos. Las primeras recomendaciones pueden tardar hasta 24 horas.
• Tomar las cifras como exactas. Los ahorros en dólares y los tiempos de detección son estimaciones generadas con IA. Validalas con Cost Explorer y tus métricas.
• Olvidar la protección contra borrado. Si la activaste (es lo recomendable), hay que desactivarla antes de eliminar el perfil.

Precios

AWS no publicó precio para la preview. Lo que sí está claro es la condición de acceso: el agente se entrega a través de AWS Support y requiere un plan de soporte activo.

No hay ejemplo de costo oficial. Si estás evaluando el agente, lo importante es que la preview es el momento barato de probarlo: anotá cuántas recomendaciones útiles te dio y cuánto ahorro real lograste, para tener números propios cuando AWS publique el precio.

Para mantener los costos asociados bajo control:

• Empezá con un perfil chico (una o dos cuentas no productivas) antes de abrirlo a toda la organización.
• Borrá los .zip de revisiones viejas o poné una regla de ciclo de vida en el bucket.
• Antes de aplicar una recomendación que agrega recursos (por ejemplo 30 alarmas de CloudWatch), calculá su costo mensual: las alarmas, métricas y runbooks también se pagan.

Disponibilidad y lo que conviene mirar con lupa

• ¿Está en sa-east-1? El servicio no: corre en us-east-1, us-east-2 y us-west-2. Pero puede analizar recursos de cualquier región comercial, así que tus cargas en São Paulo se pueden incorporar a un perfil alojado en EE.UU.
• Residencia de datos. Este es el punto a revisar. Si tus recursos están en sa-east-1 y el perfil en us-east-1, la configuración de recursos, las métricas de uso y el código de IaC que subís se procesan en una región de EE.UU. El anuncio no detalla dónde se guardan esos datos ni por cuánto tiempo. Si tenés requisitos regulatorios de residencia (banca, salud, sector público), consultalo con tu equipo de cumplimiento antes de incorporar esas cuentas.
• Transferencia entre regiones. Lo que lee el agente no debería generarte costos de transferencia visibles, pero el .zip de IaC sí: subilo a un bucket en la misma región del perfil.
• Preview. Puede cambiar la API, los pilares disponibles, las lentes y el modelo de precios. No construyas un proceso crítico encima todavía.
• Plan de soporte. Si tu organización usa el plan básico, esto todavía no es para vos.

¿Vale la pena?

Si ya tenés un plan de AWS Support que lo habilita, probarlo cuesta poco: dos roles, un perfil y esperar un día. Donde más valor le veo es en tres situaciones:

• Equipos de plataforma que administran muchas cuentas y no tienen tiempo de hacer revisiones Well-Architected periódicas. El agente les da una lista priorizada con algo que las herramientas sueltas no daban: contexto de aplicación y trade-offs.
• Revisión de IaC antes de producción, como un revisor más en el proceso de cambios de un repo de Terraform o CDK.
• FinOps, porque las recomendaciones de dimensionamiento cruzan configuración con métricas reales (el ejemplo de Fargate sobredimensionado al doble es el clásico que todos tenemos).

Donde lo miraría con más cuidado: cuentas con requisitos de residencia en la región, organizaciones donde todo cambio pasa por GitOps (el valor está en la remediación de IaC, no en la de CLI) y cualquier caso donde se tienda a aceptar recomendaciones sin revisarlas.

Mi lectura: lo más interesante no es que use IA, sino que cambia la unidad de trabajo. Trusted Advisor te daba chequeos; la Well-Architected Tool te daba un cuestionario. Esto te da una recomendación con contexto, impacto, trade-offs y el cambio en tu repo, ordenada por objetivos que escribiste vos. Si la calidad se sostiene en entornos reales (la preview mostró ejemplos muy prolijos y Classmethod obtuvo recomendaciones razonables pero de prioridad media o baja), va a reemplazar buena parte de las revisiones manuales anuales. Pero hay dos cosas que todavía no sabemos: cuánto va a costar y dónde quedan nuestros datos. Lo probaría ya en cuentas no productivas, con la remediación pasando siempre por pull request, y esperaría la disponibilidad general y el precio para llevarlo a toda la organización.

Recursos

• AWS News Blog: Announcing AWS Well-Architected Agent (preview)
• What's New: AWS Well-Architected Agent is now available in preview
• Guía de usuario de Well-Architected Agent
• IAM para Well-Architected Agent
• AWS CLI: create-agent-profile, get-agent-profile, list-agent-recommendations, get-agent-recommendation
• Desplegando.cloud (Marcia Villalba): Llega el AWS Well-Architected Agent
• Classmethod: prueba de la preview (en japonés)