Le re:Invent 2025 a marqué un tournant côté AWS passant de l’IA générative vers une IA agentique, avec des agents autonomes capables de collaborer avec les membres de l’équipe. Bedrock agentcore en est l’exemple.
Dans cette vision, AWS introduit une nouvelle famille de Frontier Agents qui couvrent l’ensemble du cycle de vie logiciel :
AWS Devops Agent est un agent IA autonome qui cartographie votre infrastructure, consomme vos signaux d’observabilité et automatise une bonne partie du run. Il peut être déclenché par une alerte (CloudWatch, Datadog, Dynatrace, New Relic, Grafana, Splunk, etc.), par un ticket ou par une simple interaction chat. Il enquête sur l’incident, propose des actions de remédiation, et peut dialoguer avec l’équipe de run via Slack, ServiceNow ou PagerDuty pour partager ses analyses et plans d’actions.
Pour s’intégrer à des systèmes externes, il s’appuie sur des serveurs MCP (Model Context Protocol), ce qui permet de brancher des outils maison ou des plateformes SaaS. Ses appels aux services AWS restent encadrés par des politiques IAM, ce qui délimite précisément son périmètre d’action (lecture seule, remédiations automatisées, etc.) et facilite l’audit.
AWS présente le DevOps Agent comme un SRE d’astreinte virtuel, toujours disponible, qui enquête sur les incidents et propose des plans de remédiation comme le ferait un SRE.
Il apprend la topologie de vos applications (services, bases, files de messages, dépendances externes) en croisant les métadonnées AWS, les métriques, logs et traces, il puise aussi les informations issues des pipelines CI/CD et de dépôts Git.
Lorsqu’une alerte arrive l’agent démarre automatiquement une investigation, corrèle les signaux, remonte une ou plusieurs causes probables et propose un plan d’action détaillé (rollback, ajustement de capacité, modification de configuration, etc.).
Tout au long de l’incident, il documente sa démarche (hypothèses, métriques consultées, traces, changements de code associés) ce qui remplace en partie les traditionnels tickets d’incident et simplifie le post‑mortem.
En entrée, l’agent se connecte :
Cette vision full‑stack lui permet de ne pas se limiter à ”il y a plus d’erreurs 500”, mais de remonter jusqu’au commit ou au changement d’infra qui a déclenché le problème.
En sortie, le DevOps Agent peut :
Pour une équipe de run, cela ressemble beaucoup à un collègue qui prend le relais sur l’investigation, poste ses hypothèses dans le channel d’incident, et propose un plan d’action que l’on peut ensuite valider ou laisser exécuter automatiquement.
La vraie différence avec agent branché à CloudWatch, c’est l’intégration via Model Context Protocol (MCP).
MCP permet d’exposer des outils externes (API internes, plateformes SaaS, bases de documentation, CMDB maison, etc.) que l’agent peut appeler.
Plutôt que d’écrire une intégration spécifique pour chaque outil, vous exposez côté MCP un ensemble de fonctions (par exemple : récupérer la topologie réseau d’un datacenter on‑prem, interroger des logs applicatifs historiques, lire une CMDB) et le DevOps Agent les découvre et les orchestre comme n’importe quel autre outil.
C’est ce qui lui permet, par exemple, d'investiguer des incidents sur des workloads on‑premises en utilisant vos propres outils de supervision exposés via MCP. d’enrichir une investigation avec des données issues de systèmes hors AWS (CMDB, inventaire de clusters Kubernetes, observabilité maison, etc.).
Au-delà de la gestion des infrastructures hors AWS avec le devops agent via du mcp il est également possible de construire en interne un DevOps Agent sur mesure. En effet AWS met à disposition des serveurs MCP pour plusieurs services en preview. Ils couvrent notamment la documentation, l’observabilité, les bases de données, les files de messages et plusieurs briques IA. Dans un environnement largement AWS, on peut donc orchestrer un agent DevOps avec le LLM de son choix, le déclencher sur des alertes CloudWatch ou d’outils d’observabilité externe. Ainsi on conserve une logique proche de celle d’un Frontier Agent, tout en maîtrisant son modèle de coût et son déploiement.
La liste des serveurs mcp disponibles sur aws : https://awslabs.github.io/mcp/
Donner à un agent IA le droit d’agir sur votre prod pose évidemment des questions de sécurité et de gouvernance.
Le périmètre d’action du DevOps Agent est défini par :
Vous pouvez ainsi, par exemple, commencer avec un espace en lecture seule sur un environnement de staging, ou limiter l’agent à l’investigation (pas de remédiation automatisée) en prod. Toute l’activité passe par les logs et CloudTrail, ce qui facilite le suivi.
Côté facturation, le mode de calcul change un peu nos réflexes d’ingénieur cloud.
Le DevOps Agent est facturé au temps d’agent, en secondes, correspondant au temps passé à mener des investigations, des analyses préventives ou des tâches SRE à la demande, indépendamment du mode de déclenchement (alerte, ticket, chat, tâche planifiée).
Il ne sera pas ici question de token comme on peut le retrouver sur des modèles classiques de LLM.
Il n’y a pas de coût d’ownership : tant que l’agent ne travaille pas vous ne payez rien.
Un gros incident analysé en profondeur peut coûter quelques centaines ou milliers de secondes d’agent, mais en échange d’un temps de rétablissement du service réduit et de moins de personnes mobilisées ainsi qu’un CA sauvegardé.
Des tâches de revue préventive (analyse régulière des incidents passés, recommandations d’amélioration) peuvent être planifiées mais doivent être pensées comme n’importe quel batch coûteux côté cloud.
Pour une équipe FinOps / run, il va falloir intégrer ce nouveau type de coût dans les modèles de coût total de possession du run : comparer le coût d’un agent à la réduction du temps d’astreinte, aux gains de productivité et aux incidents prévenus.
Même si cet article est centré sur le DevOps Agent, il vaut la peine de situer brièvement l’AWS Security Agent dans le tableau.
Ce Frontier Agent applique une logique similaire, mais orientée sécurité : il industrialise les revues de conception, les revues de code, les scans d’infra et les tests d’intrusion continus, en s’intégrant très tôt dans le cycle de développement.
On peut, par exemple, lui confier l’analyse d’un nouveau projet dès la phase d’architecture, puis la revue automatique des MR sensibles et campagnes régulières de pentest as code sur des environnements de pré‑production ou même de production sous contrôle.
La combinaison Kiro + DevOps Agent + Security Agent dessine la vision d’AWS de gestion du run avec une architecture agentique : une chaîne complète où des agents spécialisés collaborent sur tout le cycle de vie, de la spec, l’implémentation à l’exploitation en passant par la sécurité.
Le Frontier Agent DevOps ne remplace pas la compétence SRE, mais change la répartition du travail : L’agent prend en charge une partie de l’investigation, de la corrélation de signaux et de la documentation d’incident.
Les humains peuvent ainsi se recentrer sur la définition des bonnes guardrails (IAM, périmètres, skills), sur l’architecture et sur les décisions à fort impact.
Le run devient plus ”as code” : les compétences SRE se cristallisent sous forme de skills, de playbooks et d’intégrations MCP réutilisables par les Frontier Agents.
Kiro est sorti en GA en novembre 2025 et Frontier Agent Devops le 31 Mars 2026. Il est, à la date de cet article (2 juin 2026) disponible dans 6 régions AWS uniquement. AWS Security Agent est également passé en GA le 31 mars et est déployé dans les mêmes régions que Frontier Agent.