Per informazioni
CONTATTACI!
Sono le tre di notte. Il telefono vibra, una notifica CloudWatch ti dice che qualcosa non va. Apri la console, guardi i log, salti su un'altra tab per le metriche, poi su una terza per i deployment recenti. Quaranta minuti dopo hai una teoria sul root cause. Un'ora dopo, forse, hai una soluzione.
Questa scena non sta sparendo perche' i sistemi diventano meno complessi — stanno diventando piu' complessi. Sta sparendo perche' c'e' qualcosa che la sta gestendo al posto tuo, mentre dormi. AWS ha rilasciato strumenti che automatizzano non solo la risposta agli incidenti, ma anche l'analisi preventiva delle architetture. E il risultato piu' importante non e' tecnico: e' che il mestiere del cloud engineer sta cambiando forma.
Per anni, una parte significativa del lavoro di chi gestisce infrastrutture cloud ha avuto una natura fondamentalmente reattiva. Qualcosa si rompe, tu lo aggiusti. Un allarme scatta, tu lo indaghi. Questa modalita' operativa ha un nome informale nel settore: firefighting. Ed e', a suo modo, una trappola.
Il problema non e' che i team DevOps e SRE siano poco preparati — e' che la quantita' di dati da correlare in un'indagine moderna e' semplicemente troppo grande per essere gestita velocemente da un essere umano. Un'applicazione contemporanea puo' coinvolgere decine di microservizi, centinaia di funzioni AWS Lambda, database distribuiti, code di messaggi, CDN e API di terze parti. Quando uno di questi pezzi inizia a comportarsi male, tracciare il filo che porta dal sintomo alla causa richiede di guardare metriche su Amazon CloudWatch, log su Splunk o Amazon CloudWatch Logs, trace su AWS X-Ray, deployment recenti su GitHub — tutto in parallelo, tutto in tempo reale, tutto mentre il business sta perdendo soldi o i clienti stanno ricevendo errori.
Il risultato medio? Un MTTR — mean time to resolution — che si misura in ore, non in minuti. Un team sotto pressione che lavora su intuizioni ed esperienza invece che su dati certi. E un accumulo di incidenti simili che si ripetono perche' il ciclo di feedback tra "cosa è andato storto" e "come evitarlo" è troppo lungo e faticoso per chiudersi davvero.
AWS ha reso generalmente disponibile AWS DevOps Agent a marzo 2026, e il modo migliore per descriverlo non e' come uno strumento, ma come un collega specializzato in incident response che lavora ventiquattro ore su ventiquattro, sette giorni su sette, senza mai sentirsi stanco di correlare log.
Il funzionamento di base e' questo: quando un allarme scatta — che arrivi da Amazon CloudWatch, da PagerDuty, da Dynatrace o da ServiceNow — l'agente avvia un'indagine autonoma. Costruisce una mappa topologica dell'applicazione, genera ipotesi sul root cause, interroga Amazon CloudWatch per le metriche, accede ai log su Amazon CloudWatch Logs o su piattaforme esterne come Splunk tramite MCP, recupera la storia dei deployment da GitHub e correla le trace da AWS X-Ray. Per chi preferisce un'integrazione personalizzata, e' possibile anche triggerlare l'agente via webhook — ad esempio tramite una funzione AWS Lambda che riceve eventi da Amazon EventBridge — ma non e' il percorso obbligato. L'agente non aspetta istruzioni: inizia a lavorare non appena riceve il segnale.
I numeri aggregati dai clienti in preview parlano da soli: 75% di riduzione del MTTR medio, 80% di investigazioni piu' veloci, 94% di accuratezza nell'identificazione della causa radice. In alcuni casi un incidente in produzione e' stato rilevato, diagnosticato e il root cause identificato in quattro minuti, senza intervento umano.
L'output non e' solo un'ipotesi: e' un root cause con evidenze specifiche — quali metriche hanno mostrato quale anomalia, in quale timestamp, correlata con quale deployment — accompagnato da un mitigation plan strutturato con rollback procedures. I risultati vengono inviati direttamente nel canale Slack del team o nel ticket Jira, senza che nessuno debba aprire una console. Per chi usa Kiro come IDE agentico, l'agente genera anche un "agent-ready spec" che Kiro puo' leggere per implementare il fix nel codice, chiudendo il ciclo dall'incidente alla correzione senza uscire dall'ecosistema AWS.
Le integrazioni supportate spaziano dall'ecosistema nativo AWS a strumenti di terze parti: Amazon CloudWatch, AWS X-Ray, Datadog, Dynatrace, New Relic, Splunk, Grafana, GitHub, GitLab e Azure DevOps. Il team non deve cambiare stack per iniziare.
Se la capacita' di investigare gli incidenti in autonomia e' il valore piu' immediato di DevOps Agent, quella forse piu' interessante nel lungo periodo e' la prevenzione. L'agente non si limita a risolvere i problemi quando si presentano: analizza i pattern degli incidenti passati per raccomandare azioni che impediscano i prossimi.
Ogni settimana, senza input da parte del team, DevOps Agent produce un report di prevenzione che identifica opportunita' di miglioramento in quattro aree specifiche: copertura dell'observability (cosa non si stava monitorando quando e' emerso il problema), ottimizzazione dell'infrastruttura (risorse sovradimensionate o sottodimensionate che creano fragilita'), pipeline di deployment (pattern che correlano rilasci con instabilita') e resilienza applicativa (single point of failure, retry logic assente, circuit breaker mancanti).
Questo e' possibile perche' l'agente costruisce e aggiorna continuamente un modello dell'applicazione — non solo una lista di risorse, ma una mappa delle relazioni tra di esse. Sa che la funzione AWS Lambda A dipende da Amazon DynamoDB B, che il servizio C e' un consumatore della coda D, che il cluster E ha una scaling policy configurata in un certo modo. Questa topologia e' il contesto che rende le sue analisi piu' accurate di una semplice correlazione statistica.
Ci sono due categorie di Skills che guidano il comportamento dell'agente. Le prime sono quelle definite dal team: runbook in formato Markdown che codificano le procedure specifiche dell'organizzazione. Se la tua azienda ha un processo standard per investigare timeout di database, puoi scriverlo una volta sola come Skill — l'agente lo seguira'. Le seconde sono le Learned skills: l'agente costruisce automaticamente nuove skill analizzando le investigation passate. Se in tre mesi si ripresenta lo stesso pattern di Amazon DynamoDB throttling, dalla quarta volta l'agente salta le ipotesi esplorative e va diretto al punto. Il sistema migliora mentre lavora.
Non sei piu' il pilota della macchina da corsa — stai diventando chi costruisce la macchina, definisce le regole di gara e stabilisce i limiti di sicurezza che il pilota autonomo non puo' superare. Il lavoro e' piu' ad alto livello, ma e' anche piu' strategico e piu' influente.
Questa trasformazione non e' una sostituzione. Il lavoro che piu' chiaramente si sposta verso gli agenti e' quello ripetitivo e ad alta fatica cognitiva: correlare dati durante un incidente alle tre di notte, eseguire la stessa review architetturale ogni trimestre, seguire runbook standard su problemi gia' visti. Il lavoro che rimane irrimediabilmente umano e' quello che richiede giudizio contestuale: navigare ambiguita' regolatori, valutare trade-off di business che non stanno nei log, decidere quanto rischio accettare in un rilascio, comunicare con il management durante una crisi.
Le competenze che emergeranno come centrali nel profilo del cloud engineer nel prossimo ciclo non sono quelle operative tradizionali — configurare allarmi, leggere log, scrivere runbook — ma quelle legate all'orchestrazione di sistemi intelligenti: come costruire Agent Spaces che danno all'agente il contesto giusto, come scrivere Skills che codificano le procedure aziendali, come progettare architetture che siano non solo corrette oggi ma diagnosticabili in autonomia domani. E, soprattutto, come interpretare cio' che gli agenti raccomandano e decidere quando fidarsi di loro e quando no.
La storia suggerisce che questa transizione non e' nuova. Quando il cloud ha automatizzato il provisioning dell'hardware, non ha eliminato i sysadmin: li ha trasformati in cloud engineer. Chi ha fatto il salto ha guadagnato in influenza, in impatto, in responsabilita'. Il pattern si sta ripetendo.
DevOps Agent non e' un annuncio in preview: e' generalmente disponibile da marzo 2026 e include un trial gratuito di due mesi — venti ore di investigazioni, quindici di evaluations e venti di on-demand SRE tasks. La tecnologia è già lì.
DevOps Agent funziona in pay-as-you-go per qualsiasi account AWS, senza bisogno di un piano di supporto specifico. Se pero' hai gia' un piano AWS Support, i costi si riducono in modo significativo: i clienti con Business Support+ ricevono crediti mensili pari al 30% della spesa di support del mese precedente, quelli con Enterprise Support al 75%, e con Unified Operations al 100%. I crediti si applicano automaticamente all'uso del servizio e scadono a fine mese — un dettaglio che vale la pena verificare prima di pianificare l'adozione.
Il lavoro del cloud engineer non sta scomparendo — sta cambiando forma. Gli agenti gestiscono la correlazione dei log, l'analisi del root cause, la risposta agli incidenti. Il tempo che si libera è quello che si può dedicare a capire i sistemi in profondità, a prevenire invece di reagire, a costruire architetture che reggano nel tempo. Non è una trasformazione che succede da sola: richiede di scegliere consapevolmente come usare questi strumenti.