L'azienda desidera centralizzare la gestione degli endpoint VPC di interfaccia e delle zone Route 53 in un account di servizi condivisi, utilizzando un modello hub-and-spoke di Transit Gateway tra gli account. Il team dei servizi di rete deve gestire centralmente tutte le zone Route 53 e gli endpoint di interfaccia, e fornire accesso privato a AWS KMS senza che il traffico passi su internet pubblico. Cosa dovrebbe implementare l'ingegnere per raggiungere questo obiettivo?

La soluzione corretta centralizza la gestione creando un endpoint di interfaccia KMS nell'account dei servizi condivisi. Disabilitare il DNS privato è cruciale perché l'endpoint sarà accessibile da più VPC spoke. Creando una zona ospitata privata centralizzata nell'account dei servizi condivisi con un record alias che punta all'endpoint KMS e associandola a tutti i VPC spoke, si garantisce che il traffico KMS rimanga privato e non attraversi internet pubblico, come richiesto. Le opzioni errate falliscono perché: La seconda opzione suggerisce di creare zone ospitate private in ogni account spoke, il che va contro l'obiettivo di centralizzazione. La terza opzione crea endpoint KMS in ogni account spoke, aumentando la complessità e non centralizzando la gestione. La quarta opzione crea endpoint KMS in ogni account spoke e poi tenta di centralizzare i record alias, ma la creazione distribuita degli endpoint è inefficiente e non conforme al requisito di gestione centralizzata degli endpoint.