Czy istnieje sposób na śledzenie zmian, które wprowadzamy w systemie AWS?
Na przykład zmiany ustawień podsieci, od użycia nat do iwg - wyświetlają komunikat, a następnie znikają.
Czy istnieje sposób, aby AWS utworzył dziennik, aby można było śledzić, jakie zmiany zostały wprowadzone w co i kiedy?
Najbliższe nam teraz są zdarzenia ElasticBeanstalk - ale nawet to mówi tylko to, co zrobił AWS, a nie które ustawienia zostały zmienione, aby spowodować zdarzenia.
Odpowiedzi:
AWS ma usługę CloudTrail, która śledzi większość połączeń API wykonanych na Twoim koncie. Następnie przechowuje je w plikach w określonym segmencie S3.
https://aws.amazon.com/cloudtrail/
Korzystając z CloudTrail, możesz zobaczyć, kto lub która usługa wywołała, która zmiana - w wielu przypadkach również z uwzględnieniem użytych argumentów.
Niestety nie obsługuje obecnie WSZYSTKICH usług.
Istnieje wiele usług AWS, które mogą w tym pomóc, i to naprawdę zależy od twoich dokładnych potrzeb, które z nich najbardziej Ci odpowiadają. Każda z nich ma różne funkcje (i koszty).
Wspomniano o CloudTrail, ale pierwszą opcją, która przychodzi mi na myśl, biorąc pod uwagę twoje pytanie (i jest wspomniane w komentarzu do odpowiedzi @ Evgeny ), jest usługa konfiguracji AWS . Przechowuje „migawki” konfiguracji AWS w określonych momentach (w segmencie S3), ale pomocne jest również wysyłanie wszelkich zmian do tematu SNS. Następnie możesz sobie z nimi poradzić w dowolny sposób. Na przykład na koncie o niskim natężeniu ruchu mam je prosto do Slacka; na koncie o dużym ruchu śledzę NumberOfMessagesPublisheddane dotyczące tego tematu SNS, aby zauważyć, czy wprowadzono większą liczbę zmian niż zwykle.
AWS Config oferuje również usługę „reguł”; są nieco droższe, niż się spodziewałbym, ale w zależności od potrzeb mogą być przydatne. Po prostu nie aktywuj ich wszystkich naraz, tak jak to robiłem, kiedy bawiłem się ... opłata miesięczna za każdą regułę obowiązuje od razu. ;) (Ale możesz używać Config bez korzystania z reguł - to właśnie robię w tej chwili).
Istnieje również Trusted Advisor , który nie robi dokładnie tego, o co prosiłeś, ale może być przydatny do przeprowadzenia pewnych kontroli, w jaki sposób inżynierowie konfigurują twoją infrastrukturę, na przykład czy ktoś zostawił otwarte segmenty S3. Jest to najbardziej przydatne w przypadku planu wsparcia na poziomie biznesowym lub wyższym, ponieważ w przeciwnym razie wiele jego kontroli jest blokowanych.
Są też narzędzia innych firm, takie jak CloudCheckr , które łączą aspekty AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector i GuardDuty. Przydatne, jeśli chcesz się naprawdę głęboko zanurzyć, ale oszczędzaj czas, konfigurując wszystko sam.
Alternatywnie możesz zarządzać infrastrukturą za pomocą narzędzia takiego jak Terraform lub CloudFormation i upoważnić, że wszystkie zmiany muszą być dokonywane za ich pośrednictwem. Następnie możesz zatwierdzić swoje pliki konfiguracyjne / szablony do kontroli źródła, a nawet przetestować je pod kątem infrastruktury na żywo w CI i zawieść kompilację, jeśli ktoś dokonał nieśledzonych zmian. W ten sposób historia zatwierdzeń staje się dziennikiem kontroli - ale wymaga dyscypliny inżynierów!