AWS Well-Architected Agent automatizza le revisioni cloud, ma mantiene gli esseri umani responsabili
AWS ha lanciato AWS Well-Architected Agent in public preview il 1° ottobre, portando revisioni automatizzate dell'architettura a oltre 65 servizi AWS. L'agente esamina infrastruttura, utilizzo e topologia delle applicazioni, quindi raccomanda modifiche in materia di costi, sicurezza, prestazioni e resilienza. Il conflitto è immediato: AWS vuole che un agente AI sostituisca gli audit manuali, ma i clienti restano responsabili della convalida di ogni correzione generata.
Il servizio va oltre la produzione dell'ennesimo elenco di avvisi isolati. Collega le configurazioni delle risorse agli obiettivi aziendali, raggruppa le evidenze correlate e genera indicazioni per l'implementazione. Alcune raccomandazioni includono file infrastructure-as-code rivisti, istruzioni da riga di comando o runbook di automazione predefiniti.
Questo avvicina le revisioni dell'architettura AWS al flusso di lavoro ingegneristico quotidiano. Tuttavia, AWS Well-Architected Agent non gestisce in autonomia l'infrastruttura di un cliente. AWS avverte esplicitamente che le sue raccomandazioni di AI generativa possono contenere errori o informazioni incomplete.
La vera sfida non è quindi AWS contro un altro cloud provider. È l'automazione contestuale contro il giudizio umano esperto. AWS può accelerare l'individuazione dei problemi e confezionare le correzioni proposte, ma i team di piattaforma devono comunque stabilire se tali correzioni siano adatte alle loro applicazioni, agli obblighi di conformità e ai modelli di guasto.
AWS Well-Architected Agent sostituisce la checklist statica
AWS ha trasformato il proprio framework architetturale da questionario in un sistema di raccomandazioni consapevole dell'ambiente.
L'annuncio della preview di AWS descrive il servizio come un livello basato sull'AI che opera sull'infrastruttura reale dei clienti. Legge configurazioni delle risorse, metriche di utilizzo e relazioni tra applicazioni, anziché basarsi solo sulle risposte fornite durante una revisione.
I clienti iniziano creando un profilo dell'agente. Tale profilo identifica gli account AWS, le applicazioni, le regioni, le risorse e le aree di ottimizzazione che l'agente può esaminare. Gli amministratori possono anche descrivere gli obiettivi aziendali che dovrebbero influenzare la classificazione delle evidenze.
Un team che prepara un importante servizio clienti alla crescita potrebbe dare priorità alla resilienza rispetto alla riduzione immediata dei costi. Un'altra organizzazione potrebbe porre l'accento sui controlli di sicurezza o sulla spesa operativa. L'agente utilizza queste priorità dichiarate per classificare le raccomandazioni in base all'impatto atteso e allo sforzo di implementazione.
Questo è rilevante perché le raccomandazioni cloud tradizionali appaiono spesso come avvisi scollegati. Un servizio potrebbe segnalare un'istanza di calcolo sovradimensionata, mentre un altro identifica una ridondanza mancante. Nessuna delle due evidenze spiega necessariamente quale azione conti di più per il ruolo aziendale dell'applicazione.
AWS Well-Architected Agent tenta di collegare questi segnali. AWS afferma che analizza le best practice in oltre 65 servizi e produce raccomandazioni su tre livelli.
Le evidenze a livello di risorsa si concentrano sulle singole risorse cloud. Le evidenze a livello applicativo combinano risorse correlate all'interno di un workload identificato. Le evidenze a livello architetturale esaminano modelli di progettazione più ampi e possono includere modifiche all'infrastructure as code, o IaC.
IaC rappresenta l'infrastruttura attraverso file di configurazione sottoposti a controllo di versione, anziché modifiche manuali nella console. La preview può revisionare progetti scritti con Terraform, AWS CloudFormation o AWS Cloud Development Kit.
Questa revisione pre-deployment offre all'agente una seconda modalità operativa. Può ispezionare le risorse distribuite tramite accesso in sola lettura oppure analizzare l'IaC caricato prima che tali risorse raggiungano la produzione.
Le raccomandazioni possono includere istruzioni per la console, comandi AWS Command Line Interface o template IaC aggiornati. Alcune evidenze consolidate possono inoltre utilizzare runbook AWS Systems Manager, che automatizzano procedure operative definite.
AWS afferma che le raccomandazioni dovrebbero comparire entro 24 ore dalla creazione di un profilo dell'agente. Il servizio le aggiorna poi periodicamente, creando un ciclo di revisione continuo anziché un workshop architetturale una tantum.
Questo rappresenta un cambiamento significativo rispetto all'attuale AWS Well-Architected Tool. Quel prodotto supporta revisioni strutturate dei workload tramite domande, lens, milestone e piani di miglioramento. Il nuovo agente, invece, deriva le evidenze direttamente dai dati dell'infrastruttura e dal contesto applicativo fornito.
AWS definisce il servizio l'evoluzione di nuova generazione sia di Trusted Advisor sia di Well-Architected Tool. Questa descrizione inquadra il prodotto come un consolidamento, non semplicemente come un altro assistente collegato alla console AWS.
Tuttavia, il servizio valuta attualmente quattro aree: ottimizzazione dei costi, sicurezza, prestazioni e resilienza. Il Well-Architected Framework più ampio affronta anche l'eccellenza operativa e la sostenibilità. I clienti non dovrebbero trattare la preview come una sostituzione completa di ogni revisione del framework.
La public preview è disponibile tramite endpoint di servizio in US East in Northern Virginia, US East in Ohio e US West in Oregon. I clienti possono effettuare l'onboarding di workload in esecuzione in altre regioni commerciali AWS.
L'accesso richiede inoltre un piano AWS Support. Questi limiti rendono il rilascio iniziale un test controllato per verificare se il contesto automatizzato produca decisioni migliori rispetto ai tradizionali flussi di raccomandazioni.
Perché il contesto è il prodotto, non l'interfaccia chat
Il principale vantaggio dell'agente è il tentativo di classificare i compromessi, non la capacità di generare consigli in linguaggio naturale.
Gli ambienti cloud producono già grandi volumi di raccomandazioni. AWS Trusted Advisor valuta gli account alla ricerca di problematiche consolidate, mentre i servizi di sicurezza e monitoraggio generano le proprie evidenze. I team di ingegneria spesso faticano più nella definizione delle priorità che nel rilevamento.
Un avviso può essere tecnicamente corretto e al tempo stesso poco utile dal punto di vista operativo. Un database potrebbe trarre vantaggio da una ridondanza aggiuntiva, per esempio, ma quella modifica può aumentare la spesa e la complessità di deployment. Un'applicazione interna più piccola potrebbe accettare tale rischio.
AWS Well-Architected Agent cerca di distinguere queste situazioni usando il contesto applicativo e gli obiettivi dichiarati. Può associare diverse risorse a un'applicazione, esaminarne la topologia e spiegare i compromessi alla base di una raccomandazione.
AWS cita l'esempio dell'aggiunta del failover multi-Availability Zone a un database critico. La raccomandazione può descrivere il beneficio in termini di resilienza mostrando al contempo le conseguenze correlate su costi e prestazioni.
Questa analisi trasversale ai pillar è importante. Le decisioni architetturali raramente migliorano ogni risultato contemporaneamente. Una ridondanza più solida può aumentare i costi, una sicurezza più rigida può aggiungere attrito operativo e risparmi aggressivi possono ridurre la capacità di riserva.
Le checklist generiche faticano con questi conflitti perché valutano i controlli in modo indipendente. Il nuovo agente promette di ragionare su tutti questi aspetti e di classificare il lavoro in base alle priorità dichiarate dal cliente.
Il prodotto genera inoltre pacchetti di implementazione anziché fermarsi a un'evidenza. Un pacchetto può contenere IaC aggiornato, istruzioni CLI o una guida della console adattata alle risorse identificate.
Questo colma in parte il divario tra consulenza architetturale e lavoro ingegneristico. I team spesso comprendono che un progetto necessita di miglioramenti, ma non hanno il tempo di tradurre una raccomandazione ampia in codice sottoposto a revisione.
L'agente può rendere questa traduzione più rapida. Può identificare le risorse coinvolte, proporre modifiche specifiche ed esporre le raccomandazioni tramite un'API. I team possono quindi collegare tali risultati ai flussi di lavoro di sviluppo e operazioni.
Tuttavia, il ragionamento in linguaggio naturale non rende autorevole l'output. Gli obiettivi aziendali inseriti in un profilo sono rappresentazioni semplificate dei vincoli reali. Non possono acquisire automaticamente ogni contratto, classificazione dei dati, dipendenza o obbligo di ripristino.
Anche la topologia applicativa dipende dai metadati AWS disponibili. Tag, relazioni tra risorse e confini degli account possono fornire una struttura utile, ma molte organizzazioni mantengono altrove un contesto critico.
Un servizio di pagamento potrebbe dipendere da un processore di terze parti, da un processo interno di approvazione e da un accordo di ripristino che la telemetria AWS non può osservare. Una raccomandazione basata solo sulle risorse visibili non coglierebbe tali relazioni.
La qualità del risultato dipende quindi da tre input: telemetria dell'infrastruttura accurata, contesto applicativo utile e obiettivi chiaramente dichiarati. La debolezza di uno qualsiasi di questi input può produrre consigli che appaiono precisi pur rimanendo incompleti.
Ecco perché AWS presenta l'agente come intelligence consapevole del contesto anziché come un architetto pienamente autonomo. Il sistema raccoglie evidenze e azioni proposte, ma il cliente deve fornire il significato organizzativo.
Il meccanismo crea anche una sfida di feedback. I team dovranno distinguere le raccomandazioni utili dai suggerimenti tecnicamente validi che non si adattano al loro workload.
I controlli di soppressione e completamento possono ridurre il rumore ripetuto. Tuttavia, il valore della preview dipenderà dal fatto che le raccomandazioni restino pertinenti dopo che i team avranno gestito le evidenze più semplici.
L'automazione dell'architettura cloud mette sotto pressione i team di piattaforma
AWS Well-Architected Agent comprime il lavoro di revisione, ma non elimina la necessità di ingegneri di piattaforma esperti.
Le revisioni architetturali richiedono tradizionalmente agli ingegneri di raccogliere diagrammi, ispezionare configurazioni, intervistare i responsabili dei servizi e confrontare i workload con pratiche documentate. Il processo può richiedere un coordinamento considerevole, soprattutto tra più account.
AWS sta automatizzando il livello di raccolta delle evidenze. L'agente può analizzare metadati delle risorse, modelli di utilizzo e componenti connessi senza attendere che i team assemblino un pacchetto di revisione.
Questo esercita una pressione immediata sui processi di revisione guidati dalla consulenza e pianificati internamente. Una valutazione trimestrale diventa più difficile da giustificare quando un servizio automatizzato può aggiornare le evidenze durante tutto l'anno.
I team di piattaforma affrontano anche un cambiamento di responsabilità. Il loro ruolo passa dalla scoperta manuale di ogni problema alla governance delle raccomandazioni, alla convalida dei pacchetti di implementazione e al mantenimento di policy riutilizzabili.
Il lavoro non scompare. Si sposta verso revisione, gestione delle eccezioni e titolarità del rischio.
Una modifica Terraform generata richiede comunque una code review. Gli ingegneri devono ispezionare i rischi di sostituzione delle risorse, le conseguenze sulla gestione dello stato, il comportamento del provider e le dipendenze che l'agente non ha modellato.
Anche un comando CLI proposto richiede attenzione. Comandi apparentemente limitati possono incidere sulla disponibilità se applicati a risorse di produzione o eseguiti nell'account sbagliato.
Qui la differenza tra consiglio e autorità diventa cruciale. AWS Well-Architected Agent può raccomandare una modifica, ma la sua raccomandazione non trasferisce la responsabilità dal cliente.
AWS mantiene il suo consolidato modello di responsabilità condivisa. AWS protegge l'infrastruttura che eroga i propri servizi cloud, mentre i clienti restano responsabili di configurazioni, workload, identità e dati sotto il loro controllo.
L'agente potrebbe ridurre l'esperienza necessaria per individuare problemi di progettazione noti. Non può decidere la tolleranza al rischio di un'organizzazione né approvare una modifica che riguarda sistemi regolamentati.
I team più piccoli potrebbero trarre il massimo beneficio dall'analisi compressa. Spesso non dispongono di architetti cloud dedicati, ma gestiscono comunque workload la cui complessità supera una checklist di base.
Un agente che collega le evidenze sulle risorse e produce indicazioni per l'implementazione può offrire a questi team un punto di partenza più solido. Può inoltre rendere più mirate le conversazioni con i consulenti esterni.
Le grandi imprese hanno un'opportunità diversa. Possono utilizzare l'accesso API per instradare le raccomandazioni verso sistemi di ingegneria consolidati, in cui esistono già regole di responsabilità, test e approvazione.
Per queste organizzazioni, il servizio diventa un ulteriore segnale del control plane. La sua utilità dipende dall'integrazione con processi di ticketing, deployment, gestione delle eccezioni e conformità.
Il lancio alza inoltre le aspettative per le piattaforme cloud interne. Gli sviluppatori si aspetteranno sempre più spesso che le indicazioni architetturali compaiano accanto al proprio codice e alle proprie risorse, non all'interno di una revisione annuale separata.
Questo può migliorare la velocità del feedback. Può anche sommergere i team di lavoro generato se le raccomandazioni non sono precise o non riflettono gli standard locali.
Gli ingegneri esperti diventano quindi il livello di calibrazione. Decidono quali evidenze diventino policy, quali richiedano una revisione specifica per l'applicazione e quali debbano rimanere soppresse.
Migliore diventa l'agente nell'analisi di routine, più l'attenzione umana può spostarsi verso modalità di guasto insolite. Tra queste figurano dipendenze tra sistemi, vincoli organizzativi e rischi privi di segnali AWS standardizzati.
Non si tratta dell'eliminazione del lavoro architetturale. È una ridistribuzione di quel lavoro attorno a evidenze generate dalla macchina.
AWS affronta Azure Advisor e Google Cloud Recommender
AWS entra in un mercato già consolidato per le raccomandazioni cloud, ma compete attraverso il contesto a livello applicativo e la remediation generata.
Microsoft e Google forniscono già indicazioni automatizzate sulle rispettive piattaforme cloud. I loro prodotti dimostrano che i clienti si aspettano raccomandazioni di ottimizzazione come parte del control plane cloud.
Azure Advisor analizza le configurazioni delle risorse e la telemetria di utilizzo. Raggruppa le raccomandazioni per costo, prestazioni, affidabilità, sicurezza ed eccellenza operativa.
Microsoft fornisce inoltre valutazioni Well-Architected tramite Azure Advisor. Queste valutazioni usano domande curate per identificare le lacune dei carichi di lavoro nei cinque pilastri del framework Azure.
Google Cloud Recommender produce suggerimenti generati automaticamente usando utilizzo delle risorse, dati di configurazione, machine learning ed euristiche. Le sue raccomandazioni possono includere impatti su costi, prestazioni, sicurezza, gestibilità e sostenibilità.
Entrambi i concorrenti espongono le raccomandazioni tramite API e console cloud. Supportano inoltre flussi operativi per esaminare, ignorare o applicare evidenze specifiche.
AWS non sta introducendo l'idea della consulenza cloud automatizzata. Il suo elemento distintivo è l'affermazione che un unico agente possa combinare metriche, configurazione, topologia applicativa e obiettivi di business dichiarati.
La struttura a tre livelli amplia inoltre l'unità di analisi. I sistemi di raccomandazione per le risorse di solito iniziano da un singolo prodotto o configurazione. AWS afferma che il suo agente può consolidare le evidenze a livello di applicazione e architettura.
Questa distinzione conta quando diverse risorse singolarmente accettabili formano nel complesso un sistema debole. Un'architettura può fallire anche se ogni componente soddisfa le proprie regole di configurazione locali.
Le modifiche IaC generate offrono un ulteriore vantaggio competitivo. Invece di dire a un cliente di migliorare la ridondanza o modificare un progetto, il servizio può proporre codice che rappresenti la modifica.
Tuttavia, l'agente opera solo negli ambienti AWS. Può acquisire carichi di lavoro dalle regioni commerciali AWS, ma la sua documentazione non descrive l'analisi di infrastrutture Azure, Google Cloud o on-premises.
Questo confine crea una debolezza strutturale per le organizzazioni multicloud. Le loro applicazioni più importanti spesso si estendono a provider di identità, servizi dati, piattaforme software e più fornitori cloud.
Una topologia limitata ad AWS può mostrare come si collegano le risorse AWS. Non può modellare completamente un servizio il cui percorso di ripristino dipende da sistemi esterni ad AWS.
La stessa limitazione riguarda il contesto aziendale. AWS comprende a fondo le configurazioni dei propri servizi, ma l'ottimizzazione specifica per un provider può naturalmente favorire prodotti specifici di quel provider.
Una raccomandazione potrebbe essere corretta nello spazio progettuale AWS, pur trascurando una scelta architetturale più semplice al di fuori di esso. Questo non rende la raccomandazione fuorviante, ma restringe l'insieme di risposte disponibili.
Azure e Google affrontano lo stesso incentivo all'interno delle loro piattaforme. Ogni cloud provider trae vantaggio quando i sistemi di raccomandazione diventano il livello architetturale di fiducia del cliente.
Questo rende il lock-in cloud più intellettuale che tecnico. I clienti non adottano soltanto servizi. Iniziano a codificare priorità operative, mappature applicative, cronologia delle remediation e abitudini di revisione nel control plane del provider.
Le organizzazioni dovrebbero conservare i propri standard architetturali accanto a questi servizi. Le raccomandazioni dei provider possono fornire evidenze e aiuto nell'implementazione, mentre le policy interne mantengono una visione multipiattaforma.
Il test competitivo non sarà il numero di evidenze generate. Sarà capire se AWS Well-Architected Agent produrrà costantemente raccomandazioni che gli ingegneri accettano e distribuiscono.
L'accesso in sola lettura limita il rischio, ma le correzioni generate richiedono comunque revisione
AWS ha progettato l'anteprima con accesso vincolato, ma le raccomandazioni stesse restano una fonte di rischio operativo.
L'agente utilizza ruoli Identity and Access Management gestiti dal cliente. IAM controlla quali identità e servizi AWS possono accedere a risorse e azioni specifiche.
Secondo il modello di accesso AWS, i clienti creano un ruolo di esecuzione per il profilo dell'agente. Quel ruolo può assumere ruoli di accesso in sola lettura negli account di destinazione selezionati.
Questo design supporta l'analisi in un ambiente multi-account mantenendo al cliente la proprietà dei ruoli. Le organizzazioni possono personalizzare le autorizzazioni, revocare la fiducia o terminare l'accesso quando necessario.
AWS consiglia di gestire i profili da un account dedicato senza carichi di lavoro di produzione. Consiglia inoltre ai clienti di monitorare l'attività dell'agente tramite AWS CloudTrail.
Il servizio esamina telemetria delle risorse, modelli di utilizzo e dati di configurazione. La documentazione AWS afferma che non legge i contenuti di servizi di archiviazione come gli oggetti Amazon S3 o i record di database.
Le sue autorizzazioni gestite utilizzano azioni in sola lettura per l'individuazione e l'analisi. L'agente non può creare, modificare o eliminare risorse del cliente tramite tali autorizzazioni di scansione.
Questi confini riducono il raggio d'impatto di un errore durante l'analisi. Non eliminano la sensibilità dei metadati raccolti.
Topologia applicativa, nomi delle risorse, strutture degli account, configurazioni e modelli di utilizzo possono rivelare dettagli significativi su un'organizzazione. I team di sicurezza devono decidere quali account l'agente debba ispezionare.
Il deployment tra account amplia inoltre l'importanza di una corretta configurazione IAM. Il ruolo di esecuzione di un profilo diventa un percorso attraverso il quale il servizio può esaminare più ambienti.
AWS utilizza concatenazione di ruoli e un identificatore esterno associato al profilo per ridurre il rischio del confused deputy. Un confused deputy si verifica quando un servizio affidabile viene manipolato per usare il proprio accesso a vantaggio di una parte non prevista.
I clienti devono comunque verificare policy di trust, autorizzazioni, logging e ambito degli account. L'accesso in sola lettura è più sicuro dell'accesso in scrittura, ma una visibilità eccessiva può continuare a rappresentare un problema di governance.
L'incertezza maggiore riguarda le raccomandazioni generate. AWS dichiara nelle sue linee guida di sicurezza che l'agente non esegue automaticamente remediation generate dall'IA.
I clienti ricevono azioni guidate per revisione, test e implementazione. Restano responsabili di decidere se tali azioni siano adatte.
Esiste una distinzione limitata per le evidenze consolidate di Trusted Advisor. L'agente può attivare runbook Systems Manager predefiniti con il consenso del cliente. Tali runbook sono deterministici anziché codice di remediation generato ex novo.
Questa separazione è sensata. IaC e comandi generati restano proposte, mentre l'automazione predefinita segue percorsi operativi testati.
Anche una proposta plausibile può essere errata nel contesto. Potrebbe modificare una risorsa gestita da un altro team, entrare in conflitto con un modulo esterno o indebolire un margine prestazionale progettato con cura.
Una correzione potrebbe inoltre ottimizzare il pilastro visibile creando al contempo una conseguenza non modellata. Una modifica alla resilienza può alterare il comportamento della rete, mentre una raccomandazione sui costi può ridurre la capacità disponibile durante picchi di traffico.
AWS riconosce apertamente che l'output dell'IA generativa può contenere errori o informazioni incomplete. Questo avvertimento dovrebbe plasmare l'intero modello di adozione.
I team dovrebbero far passare le modifiche generate attraverso gli stessi controlli usati per il codice infrastrutturale scritto da persone. Tali controlli includono revisione tra pari, test automatizzati, controlli delle policy, deployment graduale e pianificazione del rollback.
L'accuratezza delle raccomandazioni è solo una misura. Le imprese necessitano anche di evidenze su falsi positivi, rischi mancati e coerenza tra revisioni ripetute.
L'annuncio dell'anteprima non fornisce benchmark indipendenti sull'accuratezza. Non quantifica neppure con quale frequenza i clienti accettino, modifichino, sopprimano o annullino le sue raccomandazioni.
Finché tali risultati non emergeranno, AWS Well-Architected Agent dovrebbe essere considerato un sistema consulenziale con output insolitamente azionabile. Non è una certificazione automatizzata che un ambiente sia sicuro o resiliente.
Tre segnali determineranno se l'anteprima conta
L'adozione dipenderà dalla qualità delle raccomandazioni, dall'integrazione nei flussi di lavoro e da evidenze che le revisioni automatizzate migliorino risultati reali in produzione.
Il primo segnale è il comportamento di accettazione. AWS non ha pubblicato dati dell'anteprima che mostrino con quale frequenza i clienti implementino raccomandazioni senza revisioni sostanziali.
Un'elevata accettazione suggerirebbe che l'agente comprenda abbastanza contesto da ridurre il lavoro di ingegneria. Soppressioni frequenti o riscritture importanti indicherebbero che la specificità generata supera la comprensione effettiva.
La misura più utile separerebbe le raccomandazioni per risorse, applicazioni e architetture. Le semplici evidenze sulle risorse sono più facili da automatizzare rispetto alle modifiche che interessano un intero carico di lavoro.
Il secondo segnale è un'integrazione più profonda con i flussi di lavoro di ingegneria. AWS espone già le raccomandazioni tramite API e supporta connessioni con strumenti di programmazione attraverso interfacce per sviluppatori AWS.
I clienti dovrebbero osservare se l'agente acquisirà integrazioni più solide con repository di codice, pipeline di deployment, sistemi di tracciamento delle issue e motori di policy. Queste connessioni determinano se le evidenze diventino lavoro governato o rimangano un ulteriore feed della console.
L'integrazione deve preservare i confini di approvazione. La tappa importante non è l'esecuzione autonoma, bensì il passaggio tracciabile dalla raccomandazione alla modifica revisionata.
I team devono sapere chi ha accettato un'evidenza, quale codice è cambiato, quali test sono stati eseguiti e se si è verificato l'esito previsto. Senza questa catena, la remediation generata può creare maggiore ambiguità operativa.
Il terzo segnale è la risposta competitiva. Microsoft e Google offrono già sistemi di raccomandazione maturi, ma AWS sta alzando le aspettative sul contesto applicativo e sulle correzioni a livello architetturale.
Se i concorrenti espanderanno i propri prodotti verso analisi consapevoli degli obiettivi e IaC generato, AWS avrà convalidato un cambiamento più ampio nella gestione del cloud. Se invece metteranno l'accento su raccomandazioni deterministiche, il mercato potrebbe dividersi tra approcci generativi e basati su regole.
I clienti dovrebbero inoltre osservare se AWS estenderà la copertura oltre i quattro pilastri dell'anteprima. L'eccellenza operativa e la sostenibilità restano parti importanti del più ampio Well-Architected Framework.
Ulteriori regioni, limiti di servizio più chiari e metodi di valutazione documentati rafforzerebbero la proposta del prodotto. Sarebbero utili anche prove che la qualità delle raccomandazioni si mantenga elevata in ambienti complessi con più account.
L'AWS Well-Architected Agent è già qualcosa di più di un'interfaccia conversazionale attorno alla documentazione. Legge gli ambienti dei clienti, classifica i risultati e propone percorsi di implementazione.
La questione ancora aperta è se quel contesto sia sufficiente per decisioni architetturali con conseguenze in produzione. AWS ha predisposto misure di protezione per accesso ed esecuzione, ma i clienti devono predisporre misure di protezione per la fiducia.
Per gli sviluppatori e i responsabili delle piattaforme, il primo passo corretto è una valutazione circoscritta. Scegliete un carico di lavoro ben conosciuto, limitate l'ambito del profilo e confrontate i suoi risultati con una revisione umana esistente.
Monitorate quali raccomandazioni vengono accettate, riviste, soppresse o respinte. Quindi verificate se le modifiche applicate producono il risultato atteso in termini di costi, sicurezza, prestazioni o resilienza.
Queste evidenze conteranno più del numero di risultati visualizzati. Se l'AWS Well-Architected Agent farà risparmiare costantemente tempo agli esperti senza aumentare il rischio di modifiche, le revisioni architetturali diventeranno continue. Se produrrà correzioni raffinate ma incomplete, il giudizio umano resterà la parte più importante del sistema.
