Inżynier DevOps buduje wieloetapowy AWS CodePipeline, który wymaga ręcznego zatwierdzenia między etapami testowania a wdrożenia. Zespół programistów używa niestandardowego narzędzia czatu, które akceptuje webhooki i wymaga powiadomień o statusie potoku i prośbach o zatwierdzenie w czasie zbliżonym do rzeczywistego. Jak inżynier powinien skonfigurować powiadomienia, aby zmiany stanu potoku i prośby o zatwierdzenie były publikowane w narzędziu czatu?

Poprawna odpowiedź to utworzenie reguły Amazon EventBridge, która pasuje do zdarzeń CodePipeline Pipeline Execution State Change, publikuje je w temacie SNS, a następnie subskrybuje funkcję Lambda (która publikuje na adresie URL webhooka czatu) do tego tematu SNS. EventBridge jest idealnym rozwiązaniem do przechwytywania zdarzeń z usług AWS, takich jak CodePipeline, i kierowania ich do różnych celów. Użycie SNS jako pośrednika umożliwia elastyczne skalowanie i rozdzielenie logiki, a Lambda jest doskonała do niestandardowego przetwarzania i wysyłania danych do webhooka czatu. Pozostałe opcje są mniej efektywne lub nieprawidłowe: Subskrypcja CloudWatch Logs jest mniej odpowiednia, ponieważ CloudWatch Logs służy głównie do agregacji i monitorowania logów, a nie jako główny router zdarzeń systemowych. Funkcja Lambda wyzwalana przez CloudTrail jest nieefektywna, ponieważ CloudTrail rejestruje wywołania API, a nie zdarzenia zmiany stanu potoku w czasie rzeczywistym. Przetwarzanie wszystkich zdarzeń CloudTrail byłoby kosztowne i skomplikowane. Modyfikowanie każdego potoku w celu bezpośredniego wysyłania zdarzeń do webhooka czatu jest niezalecane, ponieważ zwiększa to złożoność potoku, utrudnia zarządzanie i nie jest zgodne z najlepszymi praktykami oddzielania logiki powiadomień od logiki potoku.