Есть ли способ отслеживать изменения, которые мы вносим в систему AWS?
Например, изменения в настройках подсети, от использования nat до iwg - они отображают сообщение, а затем исчезают.
Есть ли способ заставить AWS создать журнал, чтобы можно было отслеживать, какие изменения были внесены, что и когда?
Самое близкое, что у нас есть сейчас, - это события ElasticBeanstalk, но даже это говорит только о том, что сделал AWS, а не о том, какие настройки были изменены, чтобы вызвать события.
Ответы:
AWS имеет сервис CloudTrail, который отслеживает большинство вызовов API, выполненных в вашем аккаунте. Затем сохраняет их в файлах в указанном вами контейнере S3.
https://aws.amazon.com/cloudtrail/
Используя CloudTrail, вы можете увидеть, кто или какой сервис вызвал, какое изменение - во многих случаях, в том числе и то, какие аргументы были использованы.
К сожалению, на данный момент он не поддерживает ВСЕ услуги.
Есть несколько сервисов AWS, которые могут помочь с этим, и это действительно зависит от ваших конкретных потребностей, которые подойдут вам лучше всего. Различные функции (и расходы) применяются к каждому.
CloudTrail уже упоминался, но первым вариантом, который мне приходит в голову, учитывая ваш вопрос (и он упоминается в комментарии к ответу @ Evgeny ), является AWS Config Service . Он хранит «снимки» вашей конфигурации AWS в определенные моменты времени (в сегменте S3), но также помогает отправлять любые изменения в тему SNS. Затем вы можете иметь дело с этим, как вам нравится. Например, на низком трафике у меня они идут прямо в Slack; на учетной записи с высоким трафиком я отслеживаю NumberOfMessagesPublishedметрику в этой теме SNS, чтобы заметить, если будет сделано большее количество изменений, чем обычно.
AWS Config также предлагает услугу «правил»; они немного дороже, чем я ожидал, но в зависимости от ваших потребностей они могут быть полезны. Просто не активируйте их все сразу, как я делал, когда играл вокруг ... плата за каждый месяц действует сразу. ;) (Но вы можете использовать Config без правил - это то, чем я сейчас занимаюсь).
Есть также Trusted Advisor , который не выполняет точно то, что вы просили, но может быть полезен для выполнения определенных проверок на предмет того, как инженеры конфигурируют вашу инфраструктуру, например, не оставили ли кто-нибудь открытые корзины S3. Это наиболее полезно с Планом поддержки бизнес-уровня или выше, так как в противном случае многие из его проверок блокируются.
Кроме того, существуют сторонние инструменты, такие как CloudCheckr , в которых объединены аспекты AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector и GuardDuty. Полезно, если вы хотите углубиться, но сэкономить время, настраивая все самостоятельно.
В качестве альтернативы, вы можете управлять своей инфраструктурой, используя такие инструменты, как Terraform или CloudFormation , и поручить, чтобы через них были сделаны все изменения. Затем вы можете передать свои файлы конфигурации / шаблоны в систему управления версиями и даже протестировать их на действующей инфраструктуре в CI и завершить сборку, если кто-то внес неотслеживаемые изменения. Таким образом, ваша история коммитов становится вашим журналом аудита - но для этого нужно, чтобы ваши инженеры были дисциплинированы!