Un'azienda ha centinaia di VPC che accedono a endpoint pubblici per Amazon S3 e AWS Systems Manager tramite NAT gateway. Tutto il traffico verso S3 e Systems Manager passa attraverso questi NAT gateway. L'ingegnere di rete deve centralizzare l'accesso a questi servizi e rimuovere la necessità di utilizzare endpoint pubblici, con il minimo overhead operativo. Quale soluzione raggiunge questo obiettivo?

La soluzione corretta centralizza l'accesso a S3 e Systems Manager tramite endpoint VPC di interfaccia in un VPC di servizi condivisi. Disattivare il DNS privato sugli endpoint VPC impedisce che i nomi DNS pubblici vengano risolti direttamente in indirizzi IP privati all'interno del VPC dell'endpoint. Invece, si utilizza Route 53 Private Hosted Zones con record alias che puntano agli endpoint VPC di interfaccia. Questo permette ai VPC client di risolvere i nomi di servizio AWS (es. s3.region.amazonaws.com) agli indirizzi IP privati degli endpoint nel VPC di servizi condivisi, garantendo che il traffico rimanga privato e non passi attraverso i NAT gateway pubblici. Le opzioni errate: La prima opzione propone NAT gateway privati, che non sono un servizio AWS standard e non risolvono il problema di accedere a S3 e Systems Manager privatamente senza endpoint VPC. La seconda opzione suggerisce regole di forwarding di Route 53, che sono più complesse da gestire su larga scala rispetto alle zone ospitate private e ai record alias per questo scenario. La quarta opzione attiva il DNS privato sugli endpoint VPC, il che farebbe sì che i nomi DNS pubblici vengano risolti agli indirizzi IP privati solo all'interno del VPC dell'endpoint, non nei VPC client. Il supporto DNS di Transit Gateway non reindirizza automaticamente le query DNS per i servizi AWS agli endpoint VPC di interfaccia in un VPC condiviso.