Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Connettività di rete per un'architettura multi-account
## Connessione VPCs
Molte aziende utilizzano il peering VPC in Amazon Virtual Private Cloud (Amazon VPC) per collegare sviluppo e produzione. VPCs Utilizzando una connessione peering VPC, puoi instradare il traffico tra due VPCs utilizzando l'indirizzamento IP privato. Il connesso VPCs può essere in diversi Account AWS e in diversi. Regioni AWS Per ulteriori informazioni, consulta la sezione [Che cos'è il peering VPC?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) (documentazione di Amazon VPC). Man mano che le aziende crescono e il numero di aziende VPCs aumenta, mantenere connessioni peering tra tutte VPCs può diventare un onere di manutenzione. Potresti anche incorrere nei limiti previsti dal numero massimo di connessioni peering VPC per VPC. Per ulteriori informazioni, consulta la sezione [Quota di connessione peering VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) (documentazione di Amazon VPC).
Se disponi di più ambienti di sviluppo, test e gestione temporanea che ospitano dati non di produzione su più ambienti Account AWS, potresti voler fornire la connettività di rete tra tutti questi ambienti VPCs ma impedire l'accesso agli ambienti di produzione. È possibile utilizzarlo [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)per connettere più account VPCs . È possibile separare le tabelle di routing per evitare che lo sviluppo VPCs comunichi con la produzione VPCs attraverso il gateway di transito, che funge da router centralizzato. Per ulteriori informazioni, consulta la sezione [Router centralizzato](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html) (documentazione Transit Gateway).
Transit Gateway supporta anche il peering con altri gateway di transito, inclusi quelli in diversi Account AWS o Regioni AWS. Poiché Transit Gateway è un servizio completamente gestito e ad alta disponibilità, è necessario fornire un solo gateway di transito per ogni regione.
Per ulteriori informazioni e architetture di rete dettagliate, vedere Creazione di [un'infrastruttura di AWS rete multi-VPC scalabile e sicura](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) (Whitepaper).AWS
## Connessione di applicazioni
Se è necessario stabilire una comunicazione tra applicazioni diverse nello stesso ambiente (ad esempio Account AWS in produzione), è possibile utilizzare una delle seguenti opzioni:
+ [Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) o [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) può offrire connettività a livello di rete se desideri aprire un ampio accesso a più indirizzi IP e porte.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) crea endpoint in una sottorete privata del VPC e questi endpoint vengono registrati come voci DNS in [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html). Utilizzando il DNS, le applicazioni possono risolvere gli endpoint e connettersi ai servizi registrati, senza richiedere gateway NAT o gateway Internet nel VPC.
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) associa servizi, come le applicazioni, su più account VPCs e li raccoglie in una rete di servizi. I client VPCs associati alla rete di servizi possono inviare richieste a tutti gli altri servizi associati alla rete di servizi, indipendentemente dal fatto che si trovino nello stesso account. VPC Lattice si integra con AWS Resource Access Manager (AWS RAM) in modo da poter condividere risorse con altri account o tramite. AWS Organizations Puoi associare un VPC a una sola rete di servizi. Questa soluzione non richiede l'uso del peering VPC o AWS Transit Gateway per comunicare tra account.
## Best practice per la connettività di rete
+ Creane uno Account AWS da utilizzare per la rete centralizzata. Assegna un nome a questo account **network-prod** e utilizzalo per AWS Transit Gateway Amazon [VPC IP](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) Address Manager (IPAM). Aggiungi questo account all'unità organizzativa **Infrastructure\$1Prod**.
+ Usa [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) per condividere il gateway di transito, le reti di servizi VPC Lattice e i pool IPAM con il resto dell'organizzazione. Ciò consente a chiunque Account AWS all'interno dell'organizzazione di interagire con questi servizi.
+ Utilizzando i pool IPAM per gestire IPv4 e IPv6 indirizzare centralmente le allocazioni, è possibile consentire agli utenti finali di eseguire autonomamente l'approvvigionamento utilizzando. VPCs [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) Ciò consente di dimensionare in modo appropriato VPCs e prevenire la sovrapposizione degli spazi di indirizzi IP.
+ Utilizza un approccio centralizzato in uscita per il traffico diretto a Internet e utilizza un approccio di ingresso decentralizzato per il traffico proveniente dal tuo ambiente da Internet. Per ulteriori informazioni, consultare [Uscita centralizzata](centralized-egress.md) e [Ingresso decentralizzato](decentralized-ingress.md).
# Uscita centralizzata
L'*uscita centralizzata* è il principio dell'utilizzo di un unico punto di ingresso comune per tutto il traffico di rete destinato a Internet. È possibile impostare l'ispezione in questo punto di ingresso e consentire il traffico solo verso domini specifici o solo attraverso porte o protocolli specifici. La centralizzazione delle uscite può inoltre aiutarvi a ridurre i costi eliminando la necessità di implementare gateway NAT in ciascuno di voi VPCs per raggiungere Internet. Ciò è vantaggioso dal punto di vista della sicurezza perché limita l'esposizione a risorse dannose accessibili dall'esterno, come l'infrastruttura di comando e controllo (C&C) del malware. [Per ulteriori informazioni e opzioni di architettura per l'uscita centralizzata, consulta la sezione Uscita centralizzata verso Internet (white paper).](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html)AWS
Puoi utilizzare [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html), che è un firewall di rete stateful e gestito e un servizio di rilevamento e prevenzione delle intrusioni, che funge da punto di ispezione centrale per il traffico in uscita. È necessario configurare questo firewall in un VPC dedicato per il traffico in uscita. Firewall di rete supporta regole stateful che puoi utilizzare per limitare l'accesso a Internet a domini specifici. Per ulteriori informazioni, consulta la sezione [Domain List](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering) (documentazione Firewall di rete).
Puoi anche utilizzare [Firewall DNS Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) per limitare il traffico in uscita verso nomi di dominio specifici, principalmente per impedire l'esfiltrazione non autorizzata dei dati. Nelle regole di Firewall DNS, puoi applicare [elenchi di domini](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (documentazione Route 53), che consentono o negano l'accesso a domini specifici. È possibile utilizzare elenchi di domini AWS gestiti, che contengono nomi di dominio associati ad attività dannose o altre potenziali minacce, oppure creare elenchi di domini personalizzati. Crei gruppi di regole del firewall DNS e poi li applichi ai tuoi VPCs. Le richieste DNS in uscita vengono instradate attraverso un Resolver nel VPC per la risoluzione dei nomi di dominio e Firewall DNS filtra le richieste in base ai gruppi di regole applicati al VPC. Le richieste DNS ricorsive che vanno al Resolver non fluiscono attraverso il gateway di transito e il percorso di Firewall di rete. Route 53 Resolver e Firewall DNS devono essere considerati un percorso di uscita separato dal VPC.
L'immagine seguente mostra un'architettura di esempio per l'uscita centralizzata. Prima che inizi la comunicazione di rete, le richieste DNS vengono inviate al Route 53 Resolver, dove il firewall DNS consente o nega la risoluzione dell'indirizzo IP utilizzato per la comunicazione. Il traffico destinato a Internet viene indirizzato a un gateway di transito in un account di rete centralizzato. Il gateway di transito inoltra il traffico a Firewall di rete per l'ispezione. Se la policy del firewall consente il traffico in uscita, il traffico viene indirizzato attraverso un gateway NAT, attraverso un gateway Internet e verso Internet. Puoi utilizzarlo AWS Firewall Manager per gestire centralmente i gruppi di regole del firewall DNS e le politiche del Network Firewall nell'infrastruttura multi-account.
![\[Instradamento del traffico da altri account attraverso l'account di rete e verso Internet.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## Best practice per proteggere il traffico in uscita
+ Inizia in [modalità di sola registrazione](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (documentazione Route 53). Passa alla modalità di blocco dopo aver verificato che il traffico legittimo non è interessato.
+ Blocca il traffico DNS diretto a Internet utilizzando [AWS Firewall Manager le politiche per gli elenchi di controllo degli accessi alla rete](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) o utilizzando. AWS Network Firewall Tutte le query DNS devono essere instradate attraverso un Route 53 Resolver, dove puoi monitorarle con Amazon GuardDuty (se abilitato) e filtrarle con [Route 53 Resolver DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) Firewall (se abilitato). Per ulteriori informazioni, consulta [Risoluzione delle query DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) tra e la rete (documentazione di Route 53). VPCs
+ Utilizza gli [Elenchi di domini gestiti da AWS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html)(documentazione Route 53) in Firewall DNS e Firewall di rete.
+ Valuta la possibilità di bloccare i domini di primo livello inutilizzati e ad alto rischio, come .info, .top, .xyz o alcuni domini con codice paese.
+ Valuta la possibilità di bloccare le porte non utilizzate e ad alto rischio, come le porte 1389, 4444, 3333, 445, 135, 139 o 53.
+ Come punto di partenza, puoi utilizzare un elenco di negazioni che include le regole gestite. AWS È quindi possibile passare il tempo all'implementazione di un modello di elenco di autorizzazioni. *Ad esempio, invece di includere solo un elenco ristretto di nomi di dominio completi nell'elenco consentito, inizia utilizzando alcuni caratteri jolly, come \$1.example.com.* Puoi anche consentire solo i domini di primo livello che ti aspetti e bloccare tutti gli altri. Poi, col tempo, restringi anche quelli.
+ Usa [i profili Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (documentazione Route 53) per applicare le configurazioni Route 53 relative al DNS su molte VPCs e diverse configurazioni. Account AWS
+ Definisci un processo per la gestione delle eccezioni a queste best practice.
# Ingresso decentralizzato
*Ingresso decentralizzato* è un principio per definire, a livello di singolo account, in che modo il traffico proveniente da Internet raggiunge i carichi di lavoro di quell'account. Nelle architetture multi-account, uno dei vantaggi dell'ingresso decentralizzato è che ogni account può utilizzare il servizio o la risorsa di ingresso più appropriati per i propri carichi di lavoro, come Application Load Balancer, Gateway Amazon API o Network Load Balancer.
Sebbene l'accesso decentralizzato implichi la necessità di gestire ogni account singolarmente, è possibile amministrare e mantenere centralmente le configurazioni tramite [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html). Firewall Manager supporta protezioni come [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) e [Gruppi di sicurezza Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). Puoi associarti AWS WAF a un Application Load Balancer CloudFront, Amazon, API Gateway o. AWS AppSync Se utilizzi un VPC di uscita e un gateway di transito, come descritto in [Uscita centralizzata](centralized-egress.md), ogni VPC spostato contiene sottoreti pubbliche e private. Tuttavia, non è necessario implementare gateway NAT poiché il traffico viene indirizzato attraverso il VPC di uscita nell'account di rete.
L'immagine seguente mostra un esempio di un individuo Account AWS che dispone di un singolo VPC contenente un carico di lavoro accessibile da Internet. Il traffico proveniente da Internet accede al VPC tramite un gateway Internet e raggiunge i servizi di bilanciamento del carico e di sicurezza ospitati in una sottorete pubblica. (Una *sottorete pubblica* contiene una route predefinita a un gateway Internet). Implementa i sistemi di bilanciamento del carico nelle sottoreti pubbliche e allega gli elenchi di controllo degli AWS WAF accessi (ACLs) per proteggerti dal traffico dannoso, come lo scripting tra siti. Implementa carichi di lavoro che ospitano le applicazioni in *sottoreti private*, che non hanno accesso diretto da e verso Internet.
![\[Traffico proveniente da Internet che accede a un VPC tramite un gateway Internet e sistemi di AWS WAF bilanciamento del carico.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
Se VPCs nella tua organizzazione ne hai molti, potresti voler condividere qualcosa in comune Servizi AWS creando endpoint VPC di interfaccia o zone private ospitate in un ambiente dedicato e condiviso. Account AWS Per ulteriori informazioni, consulta [Accedere a un endpoint VPC Servizio AWS con interfaccia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink documentazione) e [Lavorare con zone ospitate private](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (documentazione Route 53).
L'immagine seguente mostra un esempio di un ambiente Account AWS che ospita risorse che possono essere condivise all'interno dell'organizzazione. Gli endpoint VPC possono essere condivisi tra più account creandoli in un VPC dedicato. Quando crei un endpoint VPC, puoi facoltativamente far gestire ad AWS le voci DNS per l'endpoint. Per condividere un endpoint, deseleziona questa opzione e crea le voci DNS in una zona ospitata privata (PHZ) separata di Route 53. È quindi possibile associare il PHZ a tutti i componenti dell' VPCs organizzazione per la risoluzione DNS centralizzata degli endpoint VPC. È inoltre necessario assicurarsi che le tabelle delle rotte del gateway di transito includano le rotte tra il VPC condiviso e l'altro. VPCs Per ulteriori informazioni, consulta [Accesso centralizzato agli endpoint VPC di interfaccia (Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints))AWS .
![\[Un account condiviso che ospita endpoint di servizio e risorse da condividere con gli account di altri membri.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
Un ambiente condiviso Account AWS è anche un buon posto per ospitare AWS Service Catalog portafogli. Un *portfolio* è una raccolta di servizi IT che si desidera rendere disponibili per l'implementazione e il portafoglio contiene informazioni di configurazione per tali servizi. AWSÈ possibile creare i portafogli nell'account condiviso, condividerli con l'organizzazione, quindi ogni account membro importa il portafoglio nella propria istanza regionale del Service Catalog. Per ulteriori informazioni, consulta la sezione [Condivisione con AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) (documentazione Service Catalog).
Allo stesso modo, con Amazon VPC Lattice, puoi utilizzare l'account condiviso per gestire centralmente il tuo ambiente e i modelli di servizio come entità e quindi configurare connessioni di account con gli account dei membri dell'organizzazione. Per ulteriori informazioni, consulta [Condividi le tue entità VPC Lattice (](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html)documentazione VPC Lattice).