Un architetto di soluzioni sta progettando una VPC con più sottoreti per ospitare istanze EC2 e istanze di database Amazon RDS. La VPC ha sei sottoreti distribuite su due zone di disponibilità: in ogni AZ c'è una sottorete pubblica, una sottorete privata e una sottorete dedicata ai database. Solo le istanze EC2 nelle sottoreti private dovrebbero essere in grado di accedere ai database RDS. Quale soluzione impone questo requisito?

La soluzione corretta è creare un gruppo di sicurezza che consenta il traffico in entrata dal gruppo di sicurezza assegnato alle istanze nelle sottoreti private e collegarlo alle istanze DB. I gruppi di sicurezza agiscono come firewall virtuali a livello di istanza, controllando il traffico in entrata e in uscita. Specificando il gruppo di sicurezza delle istanze private come origine consentita, si garantisce che solo le istanze EC2 in tali sottoreti possano connettersi al database. Le altre opzioni sono errate perché: Creare una nuova tabella di routing che escluda il percorso verso i blocchi CIDR delle sottoreti pubbliche e associarla alle sottoreti del database non è sufficiente. Le tabelle di routing controllano solo il routing del traffico, non le autorizzazioni a livello di istanza. Creare un gruppo di sicurezza che neghi il traffico in entrata dal gruppo di sicurezza assegnato alle istanze nelle sottoreti pubbliche non è l'approccio più efficace. È meglio consentire esplicitamente ciò che è permesso piuttosto che negare ciò che non lo è, per una maggiore sicurezza e chiarezza. Creare connessioni di peering tra le sottoreti pubbliche, private e del database è inutile in questo scenario. Il peering VPC è utilizzato per connettere VPC diverse, non sottoreti all'interno della stessa VPC.