AWS Well-Architected Agent automatiza las revisiones de nube, pero mantiene a los humanos al mando
AWS lanzó AWS Well-Architected Agent en versión preliminar pública el 1 de octubre, llevando revisiones automatizadas de arquitectura a más de 65 servicios de AWS. El agente examina la infraestructura, el uso y la topología de las aplicaciones, y luego recomienda cambios relacionados con costes, seguridad, rendimiento y resiliencia. El conflicto es inmediato: AWS busca que un agente de IA sustituya las auditorías manuales, pero los clientes siguen siendo responsables de validar cada corrección generada.
El servicio va más allá de producir otra lista de advertencias aisladas. Conecta configuraciones de recursos con objetivos empresariales, agrupa hallazgos relacionados y genera orientación para la implementación. Algunas recomendaciones incluyen archivos revisados de infraestructura como código, instrucciones de línea de comandos o runbooks de automatización predefinidos.
Esto acerca las revisiones de arquitectura de AWS al flujo de trabajo diario de ingeniería. Sin embargo, AWS Well-Architected Agent no opera de forma independiente la infraestructura de un cliente. AWS advierte explícitamente que sus recomendaciones de IA generativa pueden contener errores o información incompleta.
Por tanto, la verdadera competencia no enfrenta a AWS con otro proveedor de nube. Enfrenta la automatización contextual con el juicio experto humano. AWS puede acelerar el descubrimiento y empaquetar correcciones propuestas, pero los equipos de plataforma aún deben determinar si esas correcciones se ajustan a sus aplicaciones, obligaciones de cumplimiento y modelos de fallo.
AWS Well-Architected Agent sustituye la lista de verificación estática
AWS ha transformado su marco de arquitectura de un cuestionario en un sistema de recomendaciones consciente del entorno.
El anuncio de la versión preliminar de AWS describe el servicio como una capa impulsada por IA sobre la infraestructura real de los clientes. Lee configuraciones de recursos, métricas de utilización y relaciones entre aplicaciones, en lugar de depender únicamente de las respuestas proporcionadas durante una revisión.
Los clientes comienzan creando un perfil de agente. Ese perfil identifica las cuentas de AWS, aplicaciones, regiones, recursos y áreas de optimización que el agente puede examinar. Los administradores también pueden describir objetivos empresariales que deben influir en cómo se clasifican los hallazgos.
Un equipo que prepara un servicio importante de atención al cliente para crecer podría priorizar la resiliencia por encima de una reducción inmediata de costes. Otra organización podría destacar los controles de seguridad o el gasto operativo. El agente utiliza esas prioridades declaradas para ordenar las recomendaciones según el impacto esperado y el esfuerzo de implementación.
Esto importa porque las recomendaciones tradicionales de nube suelen aparecer como alertas desconectadas. Un servicio podría señalar una instancia de cómputo sobredimensionada, mientras que otro identifica una falta de redundancia. Ninguno de los hallazgos explica necesariamente qué acción importa más para el papel empresarial de la aplicación.
AWS Well-Architected Agent intenta conectar esas señales. AWS afirma que analiza las prácticas recomendadas en más de 65 servicios y produce recomendaciones en tres niveles.
Los hallazgos a nivel de recurso se centran en recursos individuales de nube. Los hallazgos a nivel de aplicación combinan recursos relacionados dentro de una carga de trabajo identificada. Los hallazgos a nivel de arquitectura examinan patrones de diseño más amplios y pueden incluir cambios en infraestructura como código, o IaC.
IaC representa la infraestructura mediante archivos de configuración con control de versiones, en lugar de cambios manuales en la consola. La versión preliminar puede revisar proyectos escritos con Terraform, AWS CloudFormation o AWS Cloud Development Kit.
Esa revisión previa al despliegue proporciona al agente un segundo modo de operación. Puede inspeccionar recursos desplegados mediante acceso de solo lectura, o analizar IaC cargada antes de que esos recursos lleguen a producción.
Las recomendaciones pueden incluir instrucciones de consola, comandos de AWS Command Line Interface o plantillas de IaC actualizadas. Algunos hallazgos establecidos también pueden utilizar runbooks de AWS Systems Manager, que automatizan procedimientos operativos definidos.
AWS afirma que las recomendaciones deberían aparecer en las 24 horas posteriores a la creación de un perfil de agente. Después, el servicio las actualiza periódicamente, creando un ciclo de revisión continuo en lugar de un taller de arquitectura único.
Esto representa un cambio significativo respecto a la actual AWS Well-Architected Tool. Ese producto respalda revisiones estructuradas de cargas de trabajo mediante preguntas, lentes, hitos y planes de mejora. En cambio, el nuevo agente obtiene hallazgos directamente de evidencias de infraestructura y del contexto de aplicación proporcionado.
AWS denomina al servicio la evolución de próxima generación tanto de Trusted Advisor como de Well-Architected Tool. Esa descripción presenta el producto como una consolidación, no simplemente como otro asistente añadido a la consola de AWS.
Sin embargo, el servicio actualmente evalúa cuatro áreas: optimización de costes, seguridad, rendimiento y resiliencia. El Well-Architected Framework más amplio también aborda la excelencia operativa y la sostenibilidad. Los clientes no deberían considerar la versión preliminar como un sustituto completo de todas las revisiones del marco.
La versión preliminar pública está disponible a través de endpoints de servicio en US East en Northern Virginia, US East en Ohio y US West en Oregon. Los clientes pueden incorporar cargas de trabajo que se ejecutan en otras regiones comerciales de AWS.
El acceso también requiere un plan de AWS Support. Esos límites hacen del lanzamiento inicial una prueba controlada de si el contexto automatizado produce mejores decisiones que los flujos tradicionales de recomendaciones.
Por qué el contexto es el producto, no la interfaz de chat
La principal ventaja del agente es su intento de clasificar concesiones, no su capacidad de generar consejos en lenguaje natural.
Los entornos de nube ya producen grandes volúmenes de recomendaciones. AWS Trusted Advisor evalúa las cuentas en busca de problemas establecidos, mientras que los servicios de seguridad y supervisión generan sus propios hallazgos. Los equipos de ingeniería suelen tener dificultades con la priorización, más que con la detección.
Una advertencia puede ser técnicamente correcta y aun así resultar poco útil desde el punto de vista operativo. Por ejemplo, una base de datos podría beneficiarse de redundancia adicional, pero ese cambio puede aumentar el gasto y la complejidad del despliegue. Una aplicación interna más pequeña podría aceptar ese riesgo.
AWS Well-Architected Agent intenta distinguir estas situaciones mediante el contexto de la aplicación y los objetivos declarados. Puede asociar varios recursos con una aplicación, examinar su topología y explicar las concesiones detrás de una recomendación.
AWS ofrece el ejemplo de añadir conmutación por error Multi-Availability Zone a una base de datos crítica. La recomendación puede describir el beneficio de resiliencia y, al mismo tiempo, mostrar las consecuencias relacionadas con costes y rendimiento.
Ese análisis entre pilares es importante. Las decisiones de arquitectura rara vez mejoran todos los resultados a la vez. Una redundancia más sólida puede aumentar el coste, una seguridad más estricta puede añadir fricción operativa y un ahorro agresivo puede reducir la capacidad de reserva.
Las listas de verificación genéricas tienen dificultades con estos conflictos porque evalúan los controles de forma independiente. El nuevo agente promete razonar entre ellos y ordenar el trabajo según las prioridades declaradas por el cliente.
El producto también genera paquetes de implementación en lugar de detenerse en un hallazgo. Un paquete puede contener IaC actualizada, instrucciones de CLI o una guía de consola adaptada a los recursos identificados.
Esto reduce parte de la brecha entre el asesoramiento arquitectónico y el trabajo de ingeniería. Los equipos a menudo entienden que un diseño necesita mejoras, pero no tienen tiempo para traducir una recomendación amplia en código revisado.
El agente puede acelerar esa traducción. Puede identificar recursos afectados, proponer cambios específicos y exponer recomendaciones mediante una API. Después, los equipos pueden conectar esos resultados con flujos de trabajo de desarrollo y operaciones.
Sin embargo, el razonamiento en lenguaje natural no vuelve autoritativa la salida. Los objetivos empresariales introducidos en un perfil son representaciones simplificadas de restricciones reales. No pueden capturar automáticamente todos los contratos, clasificaciones de datos, dependencias u obligaciones de recuperación.
La topología de las aplicaciones también depende de los metadatos de AWS disponibles. Las etiquetas, las relaciones entre recursos y los límites de cuentas pueden proporcionar una estructura útil, pero muchas organizaciones mantienen contexto crítico en otros lugares.
Un servicio de pagos podría depender de un procesador externo, un proceso interno de aprobación y un acuerdo de recuperación que la telemetría de AWS no puede observar. Una recomendación basada únicamente en recursos visibles pasaría por alto esas relaciones.
Por tanto, la calidad del resultado depende de tres entradas: telemetría de infraestructura precisa, contexto útil de la aplicación y objetivos claramente establecidos. La debilidad en cualquiera de estas entradas puede producir consejos que parecen precisos, aunque sigan siendo incompletos.
Por eso AWS presenta el agente como inteligencia consciente del contexto, en lugar de un arquitecto plenamente autónomo. El sistema empaqueta evidencias y acciones propuestas, pero el cliente debe aportar el significado organizativo.
El mecanismo también crea un reto de retroalimentación. Los equipos tendrán que distinguir las recomendaciones útiles de las sugerencias técnicamente válidas que no se ajustan a su carga de trabajo.
Los controles de supresión y finalización pueden reducir el ruido repetido. Aun así, el valor de la versión preliminar dependerá de si las recomendaciones siguen siendo relevantes después de que los equipos procesen los hallazgos más sencillos.
La automatización de arquitectura en la nube presiona a los equipos de plataforma
AWS Well-Architected Agent comprime el trabajo de revisión, pero no elimina la necesidad de ingenieros de plataforma con experiencia.
Las revisiones de arquitectura tradicionalmente requieren que los ingenieros recopilen diagramas, inspeccionen configuraciones, entrevisten a los propietarios de servicios y comparen las cargas de trabajo con prácticas documentadas. El proceso puede requerir una coordinación considerable, especialmente entre varias cuentas.
AWS está automatizando la capa de recopilación de evidencias. El agente puede analizar metadatos de recursos, patrones de uso y componentes conectados sin esperar a que los equipos reúnan un paquete de revisión.
Esto ejerce una presión inmediata sobre los procesos de revisión dirigidos por consultoría y programados internamente. Resulta más difícil justificar una evaluación trimestral cuando un servicio automatizado puede actualizar los hallazgos durante todo el año.
Los equipos de plataforma también afrontan un cambio de responsabilidad. Su función pasa de descubrir manualmente cada problema a gobernar recomendaciones, validar paquetes de implementación y mantener políticas reutilizables.
El trabajo no desaparece. Se desplaza hacia la revisión, la gestión de excepciones y la titularidad del riesgo.
Un cambio generado en Terraform todavía necesita revisión de código. Los ingenieros deben inspeccionar los riesgos de sustitución de recursos, las consecuencias de la gestión del estado, el comportamiento del proveedor y las dependencias que el agente no modeló.
Un comando de CLI propuesto también exige escrutinio. Los comandos que parecen limitados pueden afectar a la disponibilidad si se aplican a recursos de producción o se ejecutan en la cuenta equivocada.
Aquí es donde la diferencia entre consejo y autoridad se vuelve crítica. AWS Well-Architected Agent puede recomendar un cambio, pero su recomendación no transfiere la responsabilidad fuera del cliente.
AWS mantiene su modelo establecido de responsabilidad compartida. AWS protege la infraestructura que presta sus servicios de nube, mientras que los clientes siguen siendo responsables de las configuraciones, cargas de trabajo, identidades y datos bajo su control.
El agente podría reducir la experiencia necesaria para encontrar problemas de diseño conocidos. No puede decidir la tolerancia al riesgo de una organización ni aprobar un cambio que afecte a sistemas regulados.
Los equipos más pequeños podrían beneficiarse más del análisis comprimido. A menudo carecen de arquitectos de nube dedicados, pero aun así operan cargas de trabajo cuya complejidad supera una lista de verificación básica.
Un agente que conecta hallazgos sobre recursos y genera orientación para la implementación puede ofrecer a esos equipos un punto de partida más sólido. También puede hacer más enfocadas las conversaciones con asesores externos.
Las grandes empresas se enfrentan a una oportunidad diferente. Pueden usar el acceso mediante API para canalizar recomendaciones hacia sistemas de ingeniería establecidos, donde ya existen reglas de propiedad, pruebas y aprobación.
Para esas organizaciones, el servicio se convierte en otra señal del plano de control. Su utilidad depende de la integración con los procesos de gestión de tickets, despliegue, excepciones y cumplimiento.
El lanzamiento también eleva las expectativas sobre las plataformas cloud internas. Los desarrolladores esperarán cada vez más que la orientación de arquitectura aparezca junto a su código y recursos, y no dentro de una revisión anual independiente.
Eso puede mejorar la velocidad de retroalimentación. También puede inundar a los equipos con trabajo generado si las recomendaciones carecen de precisión o no reflejan los estándares locales.
Por ello, los ingenieros con experiencia se convierten en la capa de calibración. Deciden qué hallazgos se convierten en políticas, cuáles requieren una revisión específica de la aplicación y cuáles deben permanecer suprimidos.
Cuanto mejor sea el agente en el análisis rutinario, más atención humana podrá dirigirse hacia modos de fallo inusuales. Entre ellos se encuentran las dependencias entre sistemas, las restricciones organizativas y los riesgos que no cuentan con señales estandarizadas de AWS.
Esto no elimina el trabajo de arquitectura. Redistribuye ese trabajo en torno a evidencia generada por máquinas.
AWS se enfrenta a Azure Advisor y Google Cloud Recommender
AWS entra en un mercado consolidado de recomendaciones cloud, pero compite mediante contexto a nivel de aplicación y remediación generada.
Microsoft y Google ya proporcionan orientación automatizada en sus respectivas plataformas cloud. Sus productos demuestran que los clientes esperan recomendaciones de optimización como parte del plano de control cloud.
Azure Advisor analiza las configuraciones de recursos y la telemetría de uso. Agrupa recomendaciones relacionadas con coste, rendimiento, fiabilidad, seguridad y excelencia operativa.
Microsoft también proporciona evaluaciones Well-Architected mediante Azure Advisor. Esas evaluaciones utilizan preguntas seleccionadas para identificar brechas en las cargas de trabajo a través de los cinco pilares del marco de Azure.
Google Cloud Recommender genera sugerencias mediante el uso de recursos, datos de configuración, aprendizaje automático y heurísticas. Sus recomendaciones pueden incluir efectos sobre coste, rendimiento, seguridad, capacidad de gestión y sostenibilidad.
Ambos rivales exponen recomendaciones mediante API y consolas cloud. También admiten flujos operativos para revisar, descartar o aplicar hallazgos específicos.
AWS no está introduciendo la idea de asesoramiento cloud automatizado. Su diferenciación es la afirmación de que un solo agente puede combinar métricas, configuración, topología de la aplicación y objetivos empresariales declarados.
La estructura de tres niveles también amplía la unidad de análisis. Los recomendadores de recursos suelen comenzar con un producto o una configuración. AWS afirma que su agente puede consolidar hallazgos en los niveles de aplicación y arquitectura.
Esta distinción importa cuando varios recursos aceptables de forma individual conforman un sistema global débil. Una arquitectura puede fallar aunque cada componente cumpla sus reglas locales de configuración.
Los cambios de IaC generados aportan otro ángulo competitivo. En lugar de indicar a un cliente que mejore la redundancia o ajuste un diseño, el servicio puede proponer código que represente el cambio.
Aun así, el agente solo funciona en entornos AWS. Puede incorporar cargas de trabajo de regiones comerciales de AWS, pero su documentación no describe el análisis de infraestructura de Azure, Google Cloud o local.
Ese límite crea una debilidad estructural para las organizaciones multicloud. Sus aplicaciones más importantes suelen abarcar proveedores de identidad, servicios de datos, plataformas de software y varios proveedores cloud.
Una topología exclusiva de AWS puede mostrar cómo se conectan los recursos de AWS. No puede modelar por completo un servicio cuya ruta de recuperación depende de sistemas ajenos a AWS.
La misma limitación afecta al contexto empresarial. AWS comprende en profundidad las configuraciones de sus propios servicios, pero la optimización específica de un proveedor puede favorecer de forma natural productos específicos de ese proveedor.
Una recomendación podría ser correcta dentro del espacio de diseño de AWS y, al mismo tiempo, pasar por alto una elección arquitectónica más sencilla fuera de él. Eso no hace que la recomendación sea engañosa, pero limita el conjunto de respuestas disponibles.
Azure y Google afrontan el mismo incentivo dentro de sus plataformas. Todos los proveedores cloud se benefician cuando los sistemas de recomendación se convierten en la capa de arquitectura de confianza del cliente.
Eso hace que el bloqueo cloud sea más intelectual que técnico. Los clientes no solo adoptan servicios. Comienzan a codificar prioridades operativas, asignaciones de aplicaciones, historial de remediaciones y hábitos de revisión en el plano de control del proveedor.
Las organizaciones deberían conservar sus propios estándares de arquitectura junto a estos servicios. Las recomendaciones de los proveedores pueden aportar evidencia y ayuda para la implementación, mientras que las políticas internas preservan la visión multiplataforma.
La prueba competitiva no será el número de hallazgos generados. Será si AWS Well-Architected Agent produce de forma consistente recomendaciones que los ingenieros aceptan y despliegan.
El acceso de solo lectura limita el riesgo, pero las correcciones generadas aún necesitan revisión
AWS diseñó la vista previa con acceso restringido, pero las propias recomendaciones siguen siendo una fuente de riesgo operativo.
El agente utiliza roles de Identity and Access Management gestionados por el cliente. IAM controla qué identidades y servicios de AWS pueden acceder a recursos y acciones específicos.
Según el modelo de acceso de AWS, los clientes crean un rol de ejecución para el perfil del agente. Ese rol puede asumir roles de acceso de solo lectura en cuentas de destino seleccionadas.
Este diseño permite el análisis en un entorno con varias cuentas, a la vez que mantiene la propiedad de los roles en manos del cliente. Las organizaciones pueden personalizar permisos, revocar la confianza o finalizar el acceso cuando sea necesario.
AWS recomienda operar los perfiles desde una cuenta dedicada sin cargas de trabajo de producción. También aconseja a los clientes supervisar la actividad del agente mediante AWS CloudTrail.
El servicio examina la telemetría de recursos, los patrones de uso y los datos de configuración. La documentación de AWS indica que no lee el contenido de servicios de almacenamiento, como los objetos de Amazon S3 o los registros de bases de datos.
Sus permisos administrados emplean acciones de solo lectura para el descubrimiento y el análisis. El agente no puede crear, modificar ni eliminar recursos de clientes mediante esos permisos de análisis.
Estos límites reducen el radio de impacto de un error durante el análisis. No eliminan la sensibilidad de los metadatos recopilados.
La topología de aplicaciones, los nombres de recursos, las estructuras de cuentas, las configuraciones y los patrones de uso pueden revelar detalles significativos sobre una organización. Los equipos de seguridad deben decidir qué cuentas debe inspeccionar el agente.
El despliegue entre cuentas también aumenta la importancia de una configuración correcta de IAM. El rol de ejecución de un perfil se convierte en una vía a través de la cual el servicio puede examinar varios entornos.
AWS utiliza encadenamiento de roles y un identificador externo vinculado al perfil para reducir el riesgo de intermediario confundido. Un intermediario confundido se produce cuando se manipula un servicio de confianza para que use su acceso en favor de una parte no prevista.
Los clientes aún deben verificar las políticas de confianza, los permisos, el registro y el alcance de las cuentas. El acceso de solo lectura es más seguro que el acceso de escritura, pero una visibilidad excesiva puede seguir siendo un problema de gobernanza.
La mayor incertidumbre se refiere a las recomendaciones generadas. AWS afirma en sus directrices de seguridad que el agente no ejecuta automáticamente remediaciones generadas por IA.
Los clientes reciben acciones guiadas para su revisión, prueba e implementación. Siguen siendo responsables de decidir si esas acciones son adecuadas.
Existe una distinción limitada para los hallazgos establecidos de Trusted Advisor. El agente puede activar runbooks predefinidos de Systems Manager con el consentimiento del cliente. Esos runbooks son deterministas, en lugar de código de remediación generado recientemente.
Esta separación tiene sentido. La IaC y los comandos generados siguen siendo propuestas, mientras que la automatización predefinida sigue rutas operativas probadas.
Incluso una propuesta plausible puede ser incorrecta en su contexto. Podría cambiar un recurso gestionado por otro equipo, entrar en conflicto con un módulo externo o debilitar un margen de rendimiento cuidadosamente diseñado.
Una corrección también podría optimizar el pilar visible y, al mismo tiempo, generar una consecuencia no modelada. Un cambio de resiliencia puede alterar el comportamiento de red, mientras que una recomendación de costes puede reducir la capacidad disponible durante picos de tráfico.
AWS reconoce abiertamente que la salida de la IA generativa puede contener errores o información incompleta. Esa advertencia debería configurar todo el modelo de adopción.
Los equipos deberían encaminar los cambios generados a través de los mismos controles utilizados para el código de infraestructura escrito por personas. Esos controles incluyen revisión por pares, pruebas automatizadas, comprobaciones de políticas, despliegue por fases y planificación de reversión.
La precisión de las recomendaciones es solo una medida. Las empresas también necesitan evidencia sobre falsos positivos, riesgos no detectados y consistencia entre revisiones repetidas.
El anuncio de la vista previa no proporciona parámetros de precisión independientes. Tampoco cuantifica con qué frecuencia los clientes aceptan, modifican, suprimen o revierten sus recomendaciones.
Hasta que surjan esos resultados, AWS Well-Architected Agent debe tratarse como un sistema de asesoramiento con resultados excepcionalmente accionables. No es una certificación automatizada de que un entorno sea seguro o resiliente.
Tres señales determinarán si la vista previa importa
La adopción dependerá de la calidad de las recomendaciones, la integración con los flujos de trabajo y la evidencia de que las revisiones automatizadas mejoran resultados reales en producción.
La primera señal es el comportamiento de aceptación. AWS no ha publicado datos de la vista previa que muestren con qué frecuencia los clientes implementan recomendaciones sin una revisión sustancial.
Una aceptación elevada sugeriría que el agente comprende suficiente contexto como para reducir el trabajo de ingeniería. La supresión frecuente o las reescrituras importantes indicarían que la especificidad generada supera la comprensión real.
La medida más útil diferenciaría entre recomendaciones de recursos, aplicaciones y arquitectura. Los hallazgos simples sobre recursos son más fáciles de automatizar que los cambios que afectan a toda una carga de trabajo.
La segunda señal es una integración más profunda con los flujos de trabajo de ingeniería. AWS ya expone recomendaciones mediante API y admite conexiones con herramientas de programación a través de interfaces de desarrollador de AWS.
Los clientes deberían observar si el agente obtiene integraciones más sólidas con repositorios de código, canalizaciones de despliegue, gestores de incidencias y motores de políticas. Esas conexiones determinan si los hallazgos se convierten en trabajo gobernado o siguen siendo otra fuente de información en la consola.
La integración debe preservar los límites de aprobación. El hito importante no es la ejecución autónoma, sino el movimiento trazable desde la recomendación hasta el cambio revisado.
Los equipos necesitan saber quién aceptó un hallazgo, qué código cambió, qué pruebas se ejecutaron y si se produjo el resultado esperado. Sin esa cadena, la remediación generada puede crear más ambigüedad operativa.
La tercera señal es la respuesta competitiva. Microsoft y Google ya ofrecen sistemas de recomendación maduros, pero AWS está elevando las expectativas en torno al contexto de aplicación y las correcciones a nivel de arquitectura.
Si los rivales amplían sus productos hacia análisis conscientes de objetivos e IaC generada, AWS habrá validado un cambio más amplio en la gestión cloud. Si, en cambio, hacen hincapié en recomendaciones deterministas, el mercado podría dividirse entre enfoques generativos y basados en reglas.
Los clientes también deberían observar si AWS amplía la cobertura más allá de los cuatro pilares de la vista previa. La excelencia operativa y la sostenibilidad siguen siendo partes importantes del Well-Architected Framework más amplio.
Regiones adicionales, límites de servicio más claros y métodos de evaluación documentados reforzarían la propuesta de valor del producto. También ayudaría contar con evidencia de que la calidad de las recomendaciones se mantiene en entornos complejos con múltiples cuentas.
El AWS Well-Architected Agent ya es más que una interfaz conversacional sobre documentación. Lee los entornos de los clientes, prioriza los hallazgos y propone rutas de implementación.
La cuestión aún sin resolver es si ese contexto basta para tomar decisiones de arquitectura con consecuencias en producción. AWS ha incorporado salvaguardas en torno al acceso y la ejecución, pero los clientes deben crear sus propias salvaguardas en torno a la confianza.
Para los desarrolladores y líderes de plataformas, el primer paso adecuado es una evaluación acotada. Elijan una carga de trabajo bien conocida, restrinjan el alcance del perfil y comparen sus hallazgos con una revisión humana existente.
Hagan seguimiento de qué recomendaciones se aceptan, revisan, descartan o rechazan. Después, examinen si los cambios aplicados generan el resultado esperado en costes, seguridad, rendimiento o resiliencia.
Esa evidencia importará más que la cantidad de hallazgos mostrados. Si el AWS Well-Architected Agent ahorra tiempo de expertos de forma consistente sin aumentar el riesgo de los cambios, las revisiones de arquitectura pasarán a ser continuas. Si genera soluciones pulidas pero incompletas, el criterio humano seguirá siendo la parte más importante del sistema.
