Le 1er septembre 2026, Amazon Web Services a discrètement changé une règle du jeu vieille de neuf ans. Depuis son lancement en 2017, Amazon GuardDuty ne détectait que ce qu’AWS avait programmé pour lui : un catalogue fermé de scénarios de menace, mis à jour au rythme de l’éditeur. Ce verrou vient de sauter. Les équipes de sécurité peuvent désormais écrire leurs propres règles de détection, les tester en mode « dry run » puis les déployer sur l’ensemble d’une organisation AWS en un clic. Six semaines plus tôt, le 14 juillet 2026, GuardDuty avait déjà étendu sa surveillance aux charges de travail d’intelligence artificielle sur Amazon Bedrock et SageMaker. Deux annonces techniques, un même mouvement de fond : AWS muscle sa détection de menaces cloud au moment précis où NIS2, DORA et le Cyber Resilience Act imposent aux entreprises européennes des obligations de surveillance et de notification inédites. Pour les quelque 15 000 organisations françaises désormais concernées par NIS2, la question n’est plus de savoir si elles doivent surveiller leur cloud, mais avec quel outil et à quel prix.
AWS ouvre GuardDuty aux règles de détection sur mesure
Jusqu’ici, un administrateur de sécurité cloud qui voulait repérer un comportement précis, propre à son secteur ou à son architecture, devait attendre qu’AWS l’ajoute lui-même au catalogue de GuardDuty, ou construire une détection maison via Amazon EventBridge et Lambda, en dehors du service. Avec l’ouverture des règles de détection personnalisées, ce contournement devient inutile. Chaque règle repose sur l’évaluation de champs présents dans les événements de gestion CloudTrail, comme le nom de l’appel d’API, l’identité de l’appelant ou la région d’origine. Une équipe de sécurité peut par exemple créer une règle qui déclenche une alerte dès qu’un appel AssumeRole provient d’une plage d’adresses IP hors de l’Union européenne, ou qu’une modification de politique IAM survient en dehors des horaires ouvrés.
Le point technique le plus structurant tient à l’échelle de déploiement. Une règle personnalisée peut être associée compte par compte, mais aussi propagée à l’échelle d’une organisation entière par le compte administrateur délégué. Pour un groupe qui gère plusieurs dizaines de comptes AWS répartis entre filiales, environnements de test et environnements de production, cela supprime un travail de duplication manuelle qui, jusqu’alors, générait des angles morts dès qu’un compte régional passait sous le radar d’un déploiement standard.
Le mode dry run, un garde-fou contre les fausses alertes
Toute règle personnalisée démarre en mode DRY_RUN. Dans cet état, GuardDuty évalue la règle et journalise les correspondances sans générer d’alerte visible pour les équipes d’astreinte. L’objectif est simple : éviter qu’une règle mal calibrée noie les analystes sous des centaines de faux positifs dès sa mise en production. AWS a également ajouté une date d’expiration configurable, pensée pour les règles temporaires liées à un incident en cours d’investigation ou à un test de migration. Une fois la fenêtre de test jugée concluante, la règle passe en mode LIVE et commence à produire des résultats exploitables dans la console GuardDuty ou via l’API.
Cette logique de test avant déploiement n’est pas une nouveauté absolue dans l’univers de la détection de menaces cloud, des solutions tierces comme Wiz ou Sysdig proposent des mécanismes comparables depuis plusieurs années. Mais son intégration native dans GuardDuty réduit la dépendance à des couches de sécurité supplémentaires pour les organisations qui n’ont pas les moyens, ou la volonté, de multiplier les fournisseurs.
GuardDuty AI Protection : la détection s’attaque aux dérapages de l’IA générative
La seconde brique, disponible en disponibilité générale depuis le 14 juillet 2026, cible un problème né avec l’explosion des usages d’IA générative en entreprise : la fraude par consommation de ressources, ou « cost harvesting ». Un attaquant qui met la main sur des identifiants valides peut aujourd’hui déclencher des milliers d’invocations sur Amazon Bedrock ou SageMaker, générant une facture de calcul GPU qui grimpe en quelques heures avant que quiconque ne s’en aperçoive. GuardDuty AI Protection analyse à la fois les événements de gestion et les événements de données issus des services d’IA d’AWS pour repérer des schémas d’invocation anormaux, une consommation de jetons hors norme, ou une tentative d’injection de prompt détectée en coordination avec Amazon Bedrock Guardrails.
Un détail mérite d’être signalé aux équipes techniques françaises qui exploitent déjà GuardDuty : l’activation n’est pas automatique pour les comptes plus anciens. Tout compte ayant activé GuardDuty avant le 14 juillet 2026 doit explicitement activer la fonctionnalité AI Protection, sans quoi les workloads Bedrock et SageMaker restent hors du périmètre de surveillance malgré la mise à jour du service. C’est un piège classique des extensions de service cloud à opt-in, et une source fréquente de faux sentiment de sécurité.
Une troisième pièce discrète : la détection des fichiers sensibles modifiés
Toujours en juillet 2026, AWS a ajouté à GuardDuty une détection ciblant la modification de fichiers sensibles, pensée pour repérer les tentatives de manipulation de journaux, de certificats ou de fichiers de configuration critiques sur des ressources de calcul compromises. Cette fonctionnalité complète directement l’Extended Threat Detection introduite fin 2024, qui corrèle automatiquement plusieurs signaux faibles pour reconstituer une séquence d’attaque complète, de la compromission initiale d’un identifiant jusqu’à l’exfiltration de données, sans surcoût pour les clients déjà abonnés au service de base.
Pris ensemble, ces trois chantiers dessinent une même trajectoire : AWS déplace GuardDuty d’un rôle d’alerteur statique vers celui d’un moteur de corrélation comportementale, capable de raisonner sur des séquences d’événements plutôt que sur des signatures isolées. C’est aussi la direction prise par ses deux principaux rivaux.
AWS GuardDuty face à Microsoft Defender for Cloud et Google Security Command Center
Sur le papier, la comparaison tourne vite à l’avantage de Microsoft. Defender for Cloud a construit sa proposition de valeur sur la couverture multi-cloud, avec une supervision qui s’étend nativement à Azure, AWS et Google Cloud depuis la même console, un atout décisif pour les grands comptes industriels français qui, selon plusieurs cabinets de conseil interrogés dans la presse spécialisée, opèrent presque systématiquement plus d’un fournisseur cloud. GuardDuty, à l’inverse, reste strictement cantonné au périmètre AWS. Un groupe qui exploite à la fois AWS pour son infrastructure applicative et Azure pour sa suite bureautique devra continuer à jongler entre deux consoles de sécurité, ou investir dans une couche de gestion de la posture cloud tierce pour unifier la vue.
Sur le terrain purement technique, GuardDuty conserve un avantage de profondeur sur son propre territoire. La surveillance runtime des clusters EKS s’appuie sur eBPF pour observer en direct les processus et les flux réseau à l’intérieur des conteneurs, une granularité que Google Security Command Center n’égale pas encore sur ses propres clusters GKE selon les analyses comparatives publiées par des cabinets spécialisés en sécurité cloud native. Security Command Center, de son côté, mise sur son intégration étroite avec l’écosystème de gestion des risques de Google Cloud, mais peine à convaincre en dehors de ce périmètre.
Tableau comparatif : trois approches de la détection cloud en 2026
| Plateforme | Éditeur | Périmètre cloud | Protection des workloads IA | Modèle tarifaire | Nouveauté 2026 |
|---|---|---|---|---|---|
| Amazon GuardDuty | AWS | AWS uniquement | Oui, via AI Protection (Bedrock, SageMaker) depuis le 14 juillet | Facturation à l’usage : volume d’événements et de données scannées | Règles de détection personnalisées, dry run et déploiement organisationnel |
| Microsoft Defender for Cloud | Microsoft | Azure, AWS et Google Cloud (multi-cloud natif) | Oui, via l’extension Defender aux services d’IA | Abonnement par ressource cloud protégée | Renforcement de la couverture multi-cloud et des recommandations de conformité |
| Google Security Command Center | Google Cloud, avec intégrations multi-cloud limitées | Oui, via les modules de protection des workloads IA | Niveaux Standard, Premium et Enterprise | Extension de la détection comportementale aux workloads IA sur GKE et Vertex AI |
Ce tableau illustre une réalité que les responsables de la sécurité cloud connaissent bien : il n’existe pas de solution universellement supérieure, seulement un arbitrage entre profondeur sur un cloud unique et largeur sur plusieurs environnements. AWS GuardDuty gagne en pertinence pour les organisations mono-cloud fortement engagées chez Amazon, ce qui reste le cas d’une large partie des jeunes entreprises technologiques françaises et des filiales de groupes internationaux hébergées historiquement sur AWS.
Pourquoi ce calendrier n’est pas un hasard : la pression réglementaire européenne
Ces annonces techniques tombent dans un contexte réglementaire particulièrement chargé pour les entreprises opérant en France et dans l’Union européenne. La directive NIS2 élargit le périmètre des entités soumises à une obligation de cybersécurité renforcée, faisant passer le nombre d’organisations concernées d’environ 500 à près de 15 000 en France, entre entités essentielles et entités importantes. Le règlement DORA, en vigueur depuis le 17 janvier 2025 pour le secteur financier et ses prestataires informatiques, impose une notification initiale sous quatre heures après la classification d’un incident majeur, puis un rapport complet sous 24 heures. Le Cyber Resilience Act ajoute une couche supplémentaire pour les fabricants de produits numériques commercialisés dans l’Union, avec l’obligation de signaler toute vulnérabilité activement exploitée dans un délai comparable.
Concrètement, une entreprise qui ne peut pas démontrer qu’elle surveille activement ses environnements cloud, avec des règles adaptées à son propre modèle de menace et non un simple catalogue générique fourni par défaut, s’expose à un risque de non-conformité qui dépasse largement le seul incident de sécurité. Les sanctions prévues par NIS2 atteignent 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles, et 7 millions d’euros ou 1,4 % pour les entités importantes. Le Cyber Resilience Act prévoit de son côté une amende pouvant grimper jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial en cas de manquement grave, notamment l’absence de signature numérique des mises à jour logicielles.
Tableau : le calendrier réglementaire qui pousse les entreprises à muscler leur détection
| Texte européen | Statut en 2026 | Entités concernées en France | Délai de notification | Sanction maximale |
|---|---|---|---|---|
| DORA | En vigueur depuis le 17 janvier 2025 | Secteur financier et prestataires TIC critiques | 4 heures puis rapport sous 24 heures | Jusqu’à 2 % du chiffre d’affaires mondial pour les prestataires critiques |
| NIS2 | Transposition française en cours, procédure engagée devant la CJUE | Environ 15 000 entités essentielles et importantes | Alerte sous 24 heures, rapport sous 72 heures | 10 M€ ou 2 % du CA mondial (entités essentielles), 7 M€ ou 1,4 % (entités importantes) |
| Cyber Resilience Act | Obligations progressives entre 2026 et 2027 | Fabricants de produits numériques vendus dans l’UE | Signalement sous 24 heures des vulnérabilités activement exploitées | Jusqu’à 15 M€ ou 2,5 % du CA mondial |
La France illustre bien la difficulté du calendrier : la transposition de NIS2 accuse un retard suffisant pour que la Commission européenne ait saisi la Cour de justice de l’Union européenne, alors même que les entreprises concernées doivent déjà anticiper des obligations de détection et de notification qui, elles, ne dépendent pas du calendrier législatif national mais de la réalité opérationnelle des attaques.
Un exemple simplifié d’une règle de détection personnalisée
Pour donner une idée concrète de ce que ce changement permet, voici une illustration conceptuelle simplifiée du type de logique qu’une équipe de sécurité peut désormais exprimer directement dans GuardDuty, sans passer par une architecture de détection externe :
Règle : Alerte-AssumeRole-HorsUE
Condition : eventName = "AssumeRole"
ET sourceIPAddress.geolocation NOT IN ["FR","DE","BE","NL","IT","ES"]
ET heure_evenement NOT IN plage_horaire_ouvree
Sévérité : Élevée
Mode initial : DRY_RUN (7 jours)
Action après validation : passage en LIVE, notification SNS vers l'équipe SOCCe type de règle, propre à la géographie d’activité d’une entreprise et à ses horaires de travail réels, était jusqu’ici impossible à exprimer nativement dans GuardDuty. Il fallait soit l’ignorer, soit la reconstruire en dehors du service via une combinaison d’EventBridge, de Lambda et d’un système d’alerte maison, ce qui alourdit la maintenance et complique les audits de conformité NIS2 ou DORA, où la traçabilité de la chaîne de détection compte autant que la détection elle-même.
Le marché de la détection cloud native pèse déjà plusieurs dizaines de milliards
Ces mouvements produits s’inscrivent dans un marché en forte expansion. Les plateformes de protection des applications cloud natives, la catégorie CNAPP qui regroupe GuardDuty, Defender for Cloud, Security Command Center mais aussi des acteurs spécialisés comme Wiz, Palo Alto Networks ou CrowdStrike, représentaient environ 16,8 milliards de dollars de dépenses en 2026 selon les estimations de Grand View Research, avec une trajectoire de croissance qui pourrait porter ce marché au-delà de 38 milliards de dollars d’ici 2030. Cette croissance traduit un basculement structurel : la sécurité cloud n’est plus un module optionnel ajouté après coup, mais une ligne budgétaire évaluée au même titre que le calcul ou le stockage.
Ce basculement rencontre une contrainte bien connue des équipes FinOps françaises : le gaspillage cloud. Les instances surdimensionnées et le calcul inactif représentent encore une part significative des dépenses cloud non maîtrisées en 2026, un problème qui touche directement les nouvelles fonctionnalités de détection basées sur l’IA, elles-mêmes facturées au volume d’événements ou de données analysées. Une entreprise qui active sans discernement l’ensemble des modules de scan de GuardDuty sur un périmètre trop large s’expose au même type de dérive budgétaire que celle déjà observée sur le calcul brut.
De la liste noire de 2017 à la corrélation comportementale de 2026 : une décennie de mutation
Pour mesurer l’ampleur du chemin parcouru, il faut revenir à l’origine du service. Amazon GuardDuty a été lancé en 2017 comme un outil de détection reposant sur des listes de renseignement sur les menaces et des règles statiques fournies par AWS, sans possibilité de personnalisation par le client. Le service a progressivement gagné en profondeur avec l’ajout de la protection contre les logiciels malveillants pour les volumes EBS, puis pour les buckets S3, avec une baisse de tarif de 85 % sur le scan de données S3 entrée en vigueur le 1er février 2025, faisant passer le prix de 0,60 à 0,09 dollar par gigaoctet scanné dans la région US East (Virginie du Nord).
L’introduction de l’Extended Threat Detection fin 2024 a marqué un premier tournant vers la corrélation automatique de signaux, capable de relier une compromission d’identifiant à une exfiltration de données sans intervention humaine pour établir le lien. Les annonces de juillet et septembre 2026 referment cette décennie de transformation en ajoutant les deux pièces qui manquaient encore : la personnalisation par le client et la couverture des workloads d’intelligence artificielle générative, devenue en trois ans une surface d’attaque à part entière plutôt qu’une curiosité de laboratoire.
Le risque bien réel de la facture surprise
La tarification de GuardDuty reste un point de friction régulièrement signalé par les praticiens de la sécurité cloud. Le service facture séparément l’analyse des journaux CloudTrail, des journaux de flux VPC, des requêtes DNS, ainsi que le scan de malware sur les volumes EBS ou les objets S3, chaque brique ajoutant sa propre ligne de facturation. Des cas documentés dans la presse spécialisée en sécurité cloud font état de factures mensuelles grimpant de 15 à plusieurs centaines de dollars après l’activation en cascade de plusieurs modules sur un compte de taille modeste, sans que l’équipe technique n’ait anticipé l’effet cumulatif. AWS propose des garde-fous : des notifications de dépassement de seuil configurables et un ciblage par étiquette des instances EC2 à scanner, mais ces options restent à la charge de configuration du client et ne sont pas activées par défaut.
Pour les nouvelles règles de détection personnalisées et pour AI Protection, la même vigilance budgétaire s’impose. Une règle personnalisée trop permissive, appliquée à l’échelle d’une organisation de plusieurs dizaines de comptes, peut générer un volume d’événements évalués très supérieur à ce qu’anticipait l’équipe qui l’a écrite, avec un effet direct sur la facture d’analyse.
Ce que cela change concrètement pour les entreprises françaises et européennes
Pour une PME ou un grand compte industriel français hébergé principalement sur AWS, la disponibilité de règles personnalisées réduit un argument récurrent en faveur de solutions tierces de sécurité cloud, souvent facturées en supplément et justifiées jusqu’ici par l’incapacité de GuardDuty à s’adapter à des scénarios de menace spécifiques à un secteur d’activité. Un établissement financier soumis à DORA peut désormais écrire une règle qui détecte un schéma d’accès inhabituel propre à son système de paiement, sans dépendre d’un fournisseur tiers pour combler ce vide fonctionnel.
Cela ne résout pas pour autant la question de la souveraineté des données de sécurité elles-mêmes. Les journaux CloudTrail et les résultats de détection GuardDuty restent traités par des infrastructures relevant du droit américain, un point de friction que la France et plusieurs de ses partenaires européens cherchent à contourner via le développement d’offres de cloud souverain chez OVHcloud, Scaleway ou STACKIT. Rien n’indique à ce stade qu’un équivalent de GuardDuty avec règles personnalisées existe chez ces acteurs européens, ce qui crée un angle mort pour les organisations qui doivent concilier exigence de souveraineté et maturité de détection.
Les limites qui persistent malgré ces annonces
GuardDuty reste, par construction, un outil mono-cloud. Aucune des annonces de 2026 ne change ce positionnement fondamental, et les groupes qui opèrent un environnement réellement hybride entre AWS, Azure et Google Cloud continueront d’avoir besoin d’une couche de supervision transverse, qu’il s’agisse de Defender for Cloud, d’un outil CNAPP tiers, ou d’une combinaison des deux. De plus, la personnalisation des règles suppose une compétence interne en syntaxe CloudTrail et en modélisation de la menace que toutes les équipes de sécurité ne possèdent pas encore, un facteur qui pourrait ralentir l’adoption réelle de la fonctionnalité en dehors des organisations disposant déjà d’un centre opérationnel de sécurité mature.
Cinq prévisions pour la suite de l’année 2026 et 2027
- Microsoft devrait généraliser une détection comportementale par IA sur l’ensemble des ressources couvertes par Defender for Cloud d’ici la fin de l’année 2026, pour ne pas laisser AWS seul sur ce terrain face aux workloads génératifs.
- Le marché CNAPP devrait franchir un nouveau palier de croissance en 2027 si la trajectoire observée par Grand View Research se confirme, porté par la multiplication des workloads d’IA à surveiller.
- Les auditeurs NIS2 et DORA vont progressivement exiger la preuve documentée de règles de détection adaptées au contexte de l’entreprise, et non plus la seule activation par défaut d’un outil générique.
- Les dépenses liées au scan et à la détection basée sur l’IA vont devenir un poste FinOps surveillé à part entière, au même titre que le calcul et le stockage, avec ses propres tableaux de bord de dépassement.
- Des fournisseurs de cloud souverain européens comme OVHcloud ou Scaleway pourraient chercher à combler leur retard en matière de détection native, un argument différenciant potentiel face aux hyperscalers américains sur les marchés publics sensibles.
Foire aux questions
Qu’est-ce qu’Amazon GuardDuty exactement ?
Amazon GuardDuty est le service de détection de menaces managé d’AWS, lancé en 2017. Il analyse en continu les journaux CloudTrail, les flux réseau VPC et les requêtes DNS pour repérer une activité potentiellement malveillante sur un compte AWS, sans nécessiter d’agent installé sur les serveurs.
Que change concrètement l’arrivée des règles de détection personnalisées ?
Depuis le 1er septembre 2026, une équipe de sécurité peut écrire ses propres règles de détection en évaluant des champs des événements CloudTrail, les tester en mode dry run sans générer d’alerte, puis les déployer à l’échelle de toute une organisation AWS. Auparavant, seul le catalogue défini par AWS était disponible.
Qu’est-ce que GuardDuty AI Protection ?
C’est une extension de GuardDuty, en disponibilité générale depuis le 14 juillet 2026, qui surveille les workloads d’intelligence artificielle sur Amazon Bedrock et SageMaker. Elle détecte les invocations de modèles anormales, les attaques par consommation excessive de ressources GPU et les tentatives d’injection de prompt.
GuardDuty fonctionne-t-il sur Azure ou Google Cloud ?
Non. GuardDuty reste un service exclusivement dédié aux comptes AWS. Les organisations multi-cloud doivent se tourner vers Microsoft Defender for Cloud, qui couvre nativement Azure, AWS et Google Cloud, ou vers une plateforme CNAPP tierce pour obtenir une vue unifiée.
Ces annonces ont-elles un lien avec NIS2 ou DORA ?
Aucun lien officiel n’a été établi par AWS, mais le calendrier coïncide avec la montée en puissance des obligations européennes de détection et de notification d’incidents. DORA impose une notification sous 4 heures depuis janvier 2025, et NIS2 doit s’appliquer à environ 15 000 entités en France, deux contraintes qui rendent une détection personnalisable particulièrement utile pour documenter la conformité.
La nouvelle fonctionnalité coûte-t-elle plus cher ?
Les règles de détection personnalisées ne créent pas de ligne de facturation distincte, mais le volume d’événements évalués peut augmenter les coûts d’analyse existants si les règles sont appliquées trop largement. AI Protection est incluse dans l’abonnement GuardDuty de base, mais les comptes activés avant le 14 juillet 2026 doivent l’activer manuellement.
Quelles alternatives existent pour les entreprises qui veulent rester sur un cloud souverain européen ?
OVHcloud, Scaleway et STACKIT développent leurs propres offres de sécurité cloud dans le cadre de leur stratégie de cloud souverain, mais aucun de ces acteurs ne propose à ce jour un équivalent direct des règles de détection personnalisées ou de la protection des workloads d’IA telle que la propose GuardDuty.
Comment une entreprise doit-elle prioriser l’adoption de ces nouvelles fonctionnalités ?
La démarche recommandée par les praticiens consiste à commencer par activer AI Protection sur les comptes exploitant Bedrock ou SageMaker, puis à tester une ou deux règles personnalisées ciblées en mode dry run avant tout déploiement organisationnel, afin de mesurer l’impact sur le volume d’alertes et sur la facturation avant une généralisation.
