Duża firma odnotowała nieoczekiwany wzrost opłat za Amazon RDS i Amazon DynamoDB. Organizacja korzysta z AWS Organizations z wieloma kontami deweloperskimi i produkcyjnymi. Nie ma narzuconej strategii tagowania na wszystkich kontach, chociaż wytyczne wymagają, aby infrastruktura była wdrażana za pomocą AWS CloudFormation i spójnych tagów. Zarząd nakazuje, aby wszystkie istniejące i przyszłe tabele DynamoDB i instancje RDS zawierały wartości cost center i project ID. Jakie podejście powinien zarekomendować architekt rozwiązań, aby spełnić te wymagania?

Prawidłowa odpowiedź rozwiązuje zarówno problem istniejących, jak i przyszłych zasobów. Tag Editor (obecnie część Resource Groups) umożliwia dodawanie tagów do istniejących zasobów w wielu kontach i regionach, co jest kluczowe dla zasobów już wdrożonych. Utworzenie tagów alokacji kosztów jest niezbędne do śledzenia wydatków. Wymuszanie tagowania dla nowych zasobów za pomocą Service Control Policies (SCP) w AWS Organizations jest skutecznym sposobem na zapewnienie zgodności w przyszłości, ponieważ SCP mogą blokować operacje API, jeśli wymagane tagi nie są obecne. Pozostałe opcje są nieprawidłowe, ponieważ: Opcja 1: Samo otagowanie istniejących zasobów nie rozwiązuje problemu przyszłych zasobów. Czekanie 24 godzin na propagację tagów alokacji kosztów jest standardem, ale nie jest to pełne rozwiązanie. Opcja 2: Reguła AWS Config powiadamia, ale nie wymusza tagowania. Rozwiązanie Lambda do automatycznego tagowania jest możliwe, ale SCP jest bardziej proaktywne i zapobiega tworzeniu nieotagowanych zasobów, zamiast je naprawiać po fakcie. Opcja 4: Modyfikowanie ról federacyjnych w celu blokowania tworzenia zasobów bez tagów jest mniej elastyczne i trudniejsze do zarządzania niż SCP, które działają na poziomie konta w całej organizacji.