CloudWatch centralise les logs multi-comptes sans pipeline maison
Le 16 octobre 2026, la centralisation des logs CloudWatch s’est étendue aux deux régions GovCloud et à 13 régions commerciales, portant à quinze le nombre de régions couvertes. Pour les organisations déjà pilotées par AWS Organizations, c’est le signal qu’il faut comparer le pipeline de logs maison à une fonctionnalité native facturée 0,05 $ par gigaoctet au-delà de la première copie.
16 octobre 2026. AWS étend la centralisation des logs CloudWatch aux deux régions GovCloud (US) et à 13 régions commerciales supplémentaires. Mars 2026. La fonctionnalité avait fait son entrée avec la copie multi-comptes et multi-régions pilotée par règles. 16 octobre 2026, toujours. La première copie reste gratuite ; les copies suivantes sont facturées 0,05 $/Go. Pourquoi c’est important : centraliser les logs n’est plus un projet d’ingénierie, c’est une règle de configuration — et le coût devient assez prévisible pour être discuté en réunion de FinOps.
Ce que fait la centralisation
La centralisation CloudWatch copie les journaux de plusieurs comptes et de plusieurs régions vers un compte de destination unique. Elle s’appuie sur AWS Organizations pour agréger les logs sans pipeline custom : plus besoin de maintenir une chaîne Kinesis, une Lambda de shipper et un bucket intermédiaire qui accumulent les points de défaillance. La donnée est acheminée par le service lui-même.
Le périmètre se règle par règles de centralisation, que l’on peut scoper à l’organisation entière, à une unité organisationnelle précise ou à des comptes choisis. C’est le bon niveau de granularité : une équipe sécurité peut capter tous les journaux, tandis qu’une business unit garde les siens cloisonnés. Le contexte d’origine est préservé via des champs système enrichis — on sait d’où vient chaque événement une fois qu’il atterrit dans le compte central, ce que ne garantit pas un shipper maison qui écrase les métadonnées au passage.
La fonctionnalité élimine aussi le problème du « qui a accès à quoi ». Au lieu de dupliquer des rôles IAM dans chaque compte pour lire les logs, l’équipe d’exploitation lit depuis le compte central. La surface d’accès se réduit à un point, et l’audit devient univoque.
Le coût : une première copie gratuite, puis 0,05 $/Go
Le tarif est la partie la plus lisible de l’annonce, et c’est rare. AWS facture 0,05 $/Go pour chaque copie supplémentaire au-delà de la première copie gratuite. Autrement dit : si vos logs restent dans leur compte d’origine et que vous n’en faites qu’une copie centrale, la centralisation ne vous coûte rien en volume. Ce n’est qu’en multipliant les copies — une pour la sécurité, une pour le FinOps, une pour la conformité — que la facture apparaît.
Ce modèle change la décision d’architecture. Historiquement, centraliser les logs signifiait payer doublement : une fois pour l’ingestion (le pipeline), une fois pour le stockage (le compte central). Ici, l’ingestion est native et la première destination est offerte. Le coût marginal de 0,05 $/Go est à mettre en face des journaux VPC Flow Logs ou des CloudTrail d’une grande organisation, qui peuvent peser des téraoctets par mois : la question n’est plus « combien coûte le pipeline », mais « combien de copies voulons-nous réellement ».
Ce que cela remplace
Jusqu’ici, la centralisation multi-comptes se construisait à la main. On posait un abonnement PutSubscriptionFilter sur chaque groupe de logs, une Lambda ou un agent Firehose pour pousser vers un bucket S3, puis un consommateur pour rejouer le tout vers le SIEM. Chaque maillon ajoute un coût de maintenance, un risque de perte et une question de chiffrement en transit. La centralisation CloudWatch replie ces trois étages en une règle déclarée.
La création d’une règle via l’AWS CLI tient en une commande :
aws logs put-centralization-rule \
--rule-name all-accounts \
--scope organization \
--destination-arn arn:aws:logs:eu-west-1:111122223333:destination:centralLa règle s’applique à l’organisation entière, et les journaux convergent vers le compte de destination sans qu’aucune Lambda ne tourne. Ce qui était un projet d’équipe devient une ligne dans un pipeline IaC, versionnée et revue comme le reste de l’infrastructure.
Le calcul de coût se fait en deux minutes. Une organisation qui centralise CloudTrail et VPC Flow Logs à hauteur de 10 To/mois ne paie rien pour sa première copie. Si elle en ajoute une seconde — une copie sécurité séparée de la copie FinOps — la facture passe à 500 $/mois (10 To × 0,05 $/Go). Le chiffre est assez faible pour être absorbé, assez concret pour être budgété : c’est la prévisibilité qui manquait aux pipelines maison, où le vrai coût se cachait dans les heures d’ingénierie.
L’expansion du 16 octobre
L’annonce du 16 octobre étend la fonctionnalité à 13 régions commerciales et aux deux régions GovCloud. Les nouvelles régions commerciales couvrent Le Cap, Hong Kong, Hyderabad, Jakarta, Malaisie, Melbourne, Calgary, Milan, Espagne, Zurich, Tel Aviv, Bahreïn et les Émirats arabes unis. Pour les clients GovCloud, l’arrivée signifie que les charges soumises à des exigences de résidence des données peuvent enfin centraliser leurs journaux dans la partition gouvernementale, séparément de la partition commerciale — un détail de conformité qui bloque souvent les déploiements fédéraux.
Cette géographie n’est pas anodine : les régions Asie-Pacifique et Moyen-Orient ajoutées sont précisément celles où les organisations multi-comptes déploient des charges régionales et devaient jusqu’ici rapatrier leurs logs vers une région lointaine, avec la latence et les contraintes de localisation que cela suppose. La centralisation locale lève ce frein.
Ce que la centralisation ne règle pas
Bornons la portée, parce que la tentation est de la croire plus large qu’elle n’est. La centralisation CloudWatch est mono-cloud : elle agrège les logs AWS, pas ceux de GCP, d’Azure ni de vos serveurs on-premise. Une stratégie multi-cloud devra toujours reposer sur un SIEM ou un collecteur tiers en aval. Elle ne fait pas non plus de détection ni de corrélation : elle déplace et copie des journaux, elle ne les interprète pas. L’alerte sur une séquence d’événements anormale reste le travail de l’outil qui consomme le compte central.
La rétention reste à votre charge. Les journaux centralisés obéissent aux politiques de cycle de vie du groupe de logs de destination : sans règle d’expiration, le compte central accumule du volume — et donc de la facture — sans limite. Enfin, le chiffrement en transit est géré par le service, mais l’accès au compte de destination demeure votre responsabilité : un rôle IAM trop large qui lit le compte central revient à donner les clés du coffre de logs à toute l’organisation. Centraliser les logs ne centralise pas, par magie, leur gouvernance.
Verdict
Si votre organisation tourne déjà sous AWS Organizations et que vous maintenez un pipeline de logs maison, faites le calcul : le coût de votre shipper — développement, maintenance, pannes — contre une première copie gratuite et 0,05 $/Go ensuite. Pour la plupart des parcs, la fonctionnalité native gagne. Si vous avez besoin de plusieurs copies — sécurité, conformité, revente interne — budgétez explicitement chaque copie supplémentaire plutôt que de dupliquer par réflexe. Si vous agrégez déjà vers un SIEM ou OpenSearch, la centralisation ne le remplace pas : elle devient la couche de collecte qui alimente ces outils, en supprimant la plomberie intermédiaire. La centralisation CloudWatch ne fait pas le travail d’un SIEM ; elle fait le travail que vos ingénieurs n’auraient jamais dû avoir à faire eux-mêmes.