Comment suivre les modifications apportées aux paramètres AWS?

Existe-t-il un moyen de suivre les modifications que nous apportons au système AWS?

Par exemple, les modifications apportées à un paramètre de sous-réseau, de l'utilisation de nat à iwg - celles-ci affichent un message, puis disparaissent.

Existe-t-il un moyen pour qu'AWS crée un journal afin que l'on puisse suivre les modifications apportées à quoi et quand?

La chose la plus proche que nous avons maintenant est les événements ElasticBeanstalk - mais même cela ne vous dit que ce qu'AWS a fait, pas quels paramètres ont été modifiés pour provoquer les événements.

AWS dispose du service CloudTrail qui suit la plupart des appels d'API effectués dans votre compte. Les stocke ensuite dans des fichiers dans votre compartiment S3 spécifié.

https://aws.amazon.com/cloudtrail/

À l'aide de CloudTrail, vous pouvez voir qui, ou quel service, a appelé quel changement - dans de nombreux cas, y compris également les arguments qui ont été utilisés.

Malheureusement, il ne prend pas en charge TOUS les services pour le moment.

Il existe plusieurs services AWS qui peuvent vous aider, et cela dépend vraiment de vos besoins exacts qui vous conviennent le mieux. Différentes fonctionnalités (et coûts) s'appliquent à chacun.

CloudTrail a été mentionné, mais la première option qui me vient à l'esprit compte tenu de votre question (et elle est mentionnée dans un commentaire sur la réponse de @ Evgeny ) est le service de configuration AWS . Il stocke des «instantanés» de votre configuration AWS à des moments précis (dans un compartiment S3), mais envoie également les modifications apportées à une rubrique SNS. Vous pouvez ensuite les gérer comme bon vous semble. Par exemple, sur un compte à faible trafic, je les ai directement dans Slack; sur un compte à fort trafic, je suis en train de suivre la NumberOfMessagesPublishedmétrique sur ce sujet SNS pour remarquer si un plus grand nombre de modifications sont apportées que d'habitude.

AWS Config propose également un service de «règles»; ceux-ci sont un peu plus chers que ce à quoi je m'attendrais, mais en fonction de vos besoins, ils pourraient être utiles. Ne les activez pas tous en même temps comme je le faisais quand je jouais ... la charge du mois pour chaque règle s'applique immédiatement. ;) (Mais vous pouvez utiliser Config sans utiliser les règles - c'est ce que je fais en ce moment).

Il existe également Trusted Advisor , qui ne fait pas exactement ce que vous avez demandé, mais qui peut être pratique pour effectuer certaines vérifications par rapport à la façon dont les ingénieurs configurent votre infrastructure, par exemple si quelqu'un a laissé les compartiments S3 ouverts. Il est plus utile avec un plan d'assistance de niveau professionnel ou supérieur, car bon nombre de ses contrôles sont bloqués sinon.

Ensuite, il existe des outils tiers comme CloudCheckr , qui combinent des aspects d'AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector et GuardDuty. Utile si vous voulez entrer vraiment en profondeur mais gagner du temps en configurant tout vous-même.

Alternativement, vous pouvez gérer votre infrastructure à l'aide d'un outil tel que Terraform ou CloudFormation , et exiger que toutes les modifications soient apportées par le biais de ceux-ci. Vous pouvez ensuite valider vos fichiers / modèles de configuration pour le contrôle de code source, et même les tester par rapport à l'infrastructure en direct dans CI et échouer la génération si quelqu'un a apporté des modifications non suivies. De cette façon, votre historique de validation devient votre journal d'audit - mais cela nécessite que vos ingénieurs soient disciplinés!