Firma wymaga, aby każda instancja EC2 była uruchamiana z AMI wyprodukowanego przez zespół bezpieczeństwa. Co miesiąc zespół bezpieczeństwa wysyła zatwierdzone AMI do deweloperów, którzy następnie kopiują je do szablonów CloudFormation. Inżynier DevOps chce zautomatyzować dystrybucję zatwierdzonych identyfikatorów AMI do deweloperów w najbardziej skalowalny sposób. Które podejście jest najlepsze?

Prawidłowa odpowiedź to użycie EC2 Image Builder do tworzenia AMI i przechowywanie identyfikatorów AMI jako parametrów w AWS Systems Manager Parameter Store. EC2 Image Builder to usługa zaprojektowana do automatyzacji tworzenia, zarządzania i wdrażania bezpiecznych obrazów serwerów, co idealnie pasuje do wymagań zespołu bezpieczeństwa. Parameter Store umożliwia centralne zarządzanie danymi konfiguracyjnymi, takimi jak identyfikatory AMI, a CloudFormation może bezpośrednio odwoływać się do tych parametrów, zapewniając skalowalne i zautomatyzowane rozwiązanie. Pozostałe opcje są mniej optymalne: Użycie zaszyfrowanego obiektu S3 ze stack Outputs wymagałoby skomplikowanej logiki odczytu i zarządzania uprawnieniami, a także nie jest standardowym sposobem dystrybucji identyfikatorów AMI. CodePipeline mógłby budować AMI, ale przechowywanie identyfikatorów AMI w obiekcie S3 jako wynik potoku i odwoływanie się do niego za pomocą referencji między stosami jest mniej bezpośrednie niż Parameter Store. Opcja z SNS i Lambda do aktualizacji stosów CloudFormation jest zbyt złożona i reaktywna. Wymagałaby dodatkowej logiki do zarządzania aktualizacjami stosów deweloperów, co zwiększa złożoność i ryzyko błędów.