Un'azienda gestisce più account AWS con AWS Organizations. Alcune applicazioni condivise sono eseguite in una VPC nell'account dei servizi condivisi. Un Transit Gateway è collegato a tale VPC. Un team di sviluppo necessita di accedere alle applicazioni dei servizi condivisi da un account di sviluppo. L'ambiente di sviluppo viene frequentemente distrutto e ricreato, e il team deve essere in grado di ricreare la propria connessione all'account dei servizi condivisi secondo necessità. Quale design soddisfa questi requisiti?

L'opzione corretta consente la condivisione centralizzata del Transit Gateway (TGW) e la gestione decentralizzata delle connessioni. Abilitare l'accettazione automatica sul TGW dei servizi condivisi e condividere il TGW tramite AWS Resource Access Manager (RAM) permette all'account di sviluppo di creare autonomamente un attachment TGW quando necessario, senza intervento manuale nell'account dei servizi condivisi. Questo soddisfa il requisito di ricreazione frequente dell'ambiente di sviluppo. Le opzioni errate presentano le seguenti problematiche: Creare un TGW separato nell'account di sviluppo e richiedere il peering TGW introduce complessità e costi aggiuntivi, oltre a richiedere l'accettazione manuale o una configurazione specifica per l'accettazione automatica del peering, non dell'attachment. L'utilizzo di un VPC Endpoint non è il meccanismo corretto per connettere VPC tramite Transit Gateway. I VPC Endpoint sono per l'accesso ai servizi AWS o ai servizi endpoint privati, non per la connettività tra VPC attraverso un TGW. L'uso di EventBridge e Lambda per l'accettazione degli attachment è un'automazione eccessiva e non necessaria, poiché RAM e l'accettazione automatica del TGW gestiscono già questo scenario in modo più semplice e nativo. AWS Network Manager non è il servizio primario per la condivisione di risorse TGW tra account; RAM lo è.