Organizacja korzysta z AWS Organizations z ośmioma kontami członkowskimi i przewiduje maksymalnie 20 kont. Firma uruchamia wszystkie obciążenia w AWS i ma nową politykę bezpieczeństwa wymagającą: • Żadne konto nie uruchamia obciążeń w VPC w ramach tego konta. • Wszystkie obciążenia muszą być uruchamiane w podsieciach centralnie zarządzanego VPC dostępnego dla wszystkich kont. • Żadne konto nie może modyfikować zasobów aplikacji innego konta w ramach współdzielonego VPC. • Centralnie zarządzane VPC musi znajdować się w istniejącym koncie o nazwie Account-A w organizacji. Szablon CloudFormation w Account-A tworzy VPC i wiele podsieci oraz eksportuje identyfikatory podsieci jako wyjścia stosu. Które rozwiązanie uzupełnia konfigurację, aby spełnić te wymagania?

Prawidłowa odpowiedź to użycie AWS Resource Access Manager (AWS RAM) do udostępnienia podsieci VPC w Account-A kontom członkowskim. AWS RAM umożliwia współdzielenie zasobów AWS, takich jak podsieci VPC, z innymi kontami AWS w ramach organizacji lub z określonymi kontami. To rozwiązanie spełnia wszystkie wymagania: centralne zarządzanie VPC w Account-A, uruchamianie obciążeń w podsieciach zarządzanych centralnie oraz uniemożliwienie modyfikacji zasobów aplikacji przez inne konta, ponieważ konta członkowskie jedynie korzystają z udostępnionych podsieci, a nie zarządzają samym VPC. Pozostałe opcje są nieprawidłowe: Użycie Fn::ImportValue w każdym koncie członkowskim do pobierania identyfikatorów podsieci nie zapewnia mechanizmu uruchamiania obciążeń w tych podsieciach z innych kont, ani nie spełnia wymogu współdzielenia. Transit Gateway służy do łączenia wielu VPC i sieci lokalnych, a nie do udostępniania podsieci z jednego VPC innym kontom w celu uruchamiania tam obciążeń. Peering VPC łączy dwa VPC, ale nie pozwala na uruchamianie obciążeń w podsieciach jednego VPC z drugiego konta w sposób zgodny z wymaganiami, które mówią o współdzieleniu podsieci, a nie tylko o komunikacji.