Aplikacja internetowa działa na instancjach EC2 zbudowanych z niestandardowego AMI i jest udostępniana za pomocą CloudFormation w regionie us-east-1. Firma chce wdrożyć ten sam stos w regionie us-west-1, ale tworzenie stosu w us-west-1 kończy się błędem, że identyfikator AMI nie istnieje. Deweloper musi to naprawić przy minimalnym wysiłku operacyjnym. Które rozwiązanie to osiągnie?

Poprawna odpowiedź to skopiowanie niestandardowego AMI z us-east-1 do us-west-1 i zaktualizowanie szablonu CloudFormation. AMI są specyficzne dla regionu, więc niestandardowy obraz utworzony w us-east-1 nie jest dostępny w us-west-1. Skopiowanie AMI sprawia, że jest ono dostępne w docelowym regionie, a aktualizacja szablonu CloudFormation odwołuje się do jego nowego identyfikatora, co jest minimalnym wysiłkiem operacyjnym. Modyfikowanie szablonów, aby używały AMI zarządzanego przez AWS, może wymagać znacznych zmian w aplikacji, jeśli niestandardowe AMI zawiera specyficzne konfiguracje. Odbudowanie AMI bezpośrednio w us-west-1 jest czasochłonne i duplikuje wysiłek. Ręczne wdrożenie aplikacji poza CloudFormation jest sprzeczne z zasadami infrastruktury jako kodu i zwiększa wysiłek operacyjny.