# Pianificazione della topologia di rete
I carichi di lavoro sono spesso presenti in più ambienti. Questi includono più ambienti cloud (sia accessibili pubblicamente sia privati) e, possibilmente, l'infrastruttura del data center esistente. I piani devono includere considerazioni di rete, ad esempio connettività intrasistema e intersistema, gestione di indirizzi IP e privati e risoluzione dei nomi di dominio.
Quando si progettano sistemi che utilizzano reti basate su indirizzi IP, è necessario pianificare la topologia di rete e l'indirizzamento in anticipo rispetto a possibili guasti, nonché consentire la crescita futura e l'integrazione con altri sistemi e le relative reti.
Amazon Virtual Private Cloud (Amazon VPC) consente di effettuare il provisioning di una sezione isolata e privata dell'AWS Cloud, dove è possibile avviare risorse AWS in una rete virtuale.
**Topics**
+ [REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premises](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 Verifica che l’allocazione delle sottoreti IP consenta l’espansione e la disponibilità](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Utilizzo di una connettività di rete a disponibilità elevata per gli endpoint pubblici del carico di lavoro
La creazione di connettività di rete a disponibilità elevata agli endpoint pubblici dei carichi di lavoro può ridurre i tempi di inattività dovuti a perdita di connettività e migliorare la disponibilità e il contratto sul livello di servizio del tuo carico di lavoro. Per ottenere questo risultato, usa un servizio DNS a disponibilità elevata, reti di distribuzione di contenuti (CDN), API Gateway, bilanciamento del carico o proxy inversi.
**Risultato desiderato:** la pianificazione, la realizzazione e la messa in funzione di una connettività di rete altamente disponibile per i tuoi endpoint pubblici è fondamentale. Se il carico di lavoro diventa irraggiungibile a causa della perdita di connettività, il sistema apparirà ai clienti come non funzionante, anche se il carico di lavoro è in esecuzione e disponibile. Combinando connettività di rete a disponibilità elevata e resiliente per gli endpoint pubblici del carico di lavoro, a un’architettura resiliente per il carico di lavoro stesso, puoi offrire ai clienti la disponibilità e il livello di servizio migliori possibili.
AWS Global Accelerator, Amazon CloudFront, Gateway Amazon API, funzione URL AWS Lambda, API AWS AppSync ed Elastic Load Balancing (ELB) forniscono tutti endpoint pubblici a elevata disponibilità. Amazon Route 53 fornisce un servizio DNS ad alta disponibilità per la risoluzione dei nomi di dominio, così da verificare la possibilità di risolvere gli indirizzi degli endpoint pubblici.
Puoi anche valutare applicazioni software Marketplace AWS per il bilanciamento del carico e l’esecuzione di proxy.
**Anti-pattern comuni:**
+ Progettazione di un carico di lavoro a disponibilità elevata senza pianificare connettività DNS e di rete per la disponibilità elevata.
+ Uso di indirizzi Internet pubblici su singoli container o istanze e gestione della connettività tramite DNS.
+ Uso di indirizzi IP anziché nomi di dominio per l’individuazione dei servizi.
+ Mancata esecuzione di test su scenari con perdita di connettività agli endpoint pubblici.
+ Mancata analisi delle esigenze di throughput della rete e dei modelli di distribuzione.
+ Nessuna attività di test e pianificazione per scenari di possibile interruzione della connettività di rete Internet agli endpoint pubblici del carico di lavoro.
+ Distribuzione di contenuti (pagine Web, asset statici o file multimediali) in un’area geografica di grandi dimensioni senza l’uso di una rete di distribuzione di contenuti.
+ Nessuna pianificazione per la prevenzione di attacchi DDoS (Distributed Denial of Service). Gli attacchi DDoS rischiano di arrestare il traffico legittimo e ridurre la disponibilità per gli utenti.
**Vantaggi dell’adozione di questa best practice:** la progettazione pensata per una connettività di rete a elevata disponibilità e resilienza garantisce l’accessibilità e la disponibilità del carico di lavoro agli utenti.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Alla base della creazione di connettività di rete a disponibilità elevata agli endpoint pubblici vi è l’instradamento del traffico. Per verificare che il traffico possa raggiungere gli endpoint, il servizio DNS deve essere in grado di risolvere i nomi di dominio negli indirizzi IP corrispondenti. Utilizza un [sistema dei nomi di dominio (DNS)](https://aws.amazon.com/route53/what-is-dns/) altamente scalabile e disponibile, come Amazon Route 53, per gestire i record DNS del dominio. Puoi usare anche i controlli dell’integrità forniti da Amazon Route 53. I controlli dell’integrità verificano che l’applicazione sia raggiungibile, disponibile e funzionale e possono essere configurati in modo da simulare il comportamento degli utenti, come la richiesta di una pagina Web o un URL specifico. In caso di errore, Amazon Route 53 risponde alle richieste di risoluzione DNS e indirizza il traffico solo agli endpoint integri. Puoi anche valutare se usare le funzionalità di instradamento basato sulla latenza e GeoDNS offerte da Amazon Route 53.
Per verificare l'elevata disponibilità effettiva del carico di lavoro, utilizza Elastic Load Balancing (ELB). Amazon Route 53 consente di indirizzare il traffico verso ELB, che lo distribuisce alle istanze di calcolo di destinazione. Puoi anche usare Gateway Amazon API insieme a AWS Lambda per una soluzione serverless. I clienti possono anche eseguire carichi di lavoro in più Regioni AWS. Grazie a un [pattern attivo/attivo multisito](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/), il carico di lavoro può servire il traffico proveniente da più regioni. Con un pattern attivo/passivo multisito, il carico di lavoro serve il traffico proveniente dalla regione attiva, mentre nella regione secondaria avviene la replica dei dati, che diventano attivi in caso di guasto nella regione primaria. I controlli dell’integrità di Route 53 consentono dunque di controllare il failover DNS da qualsiasi endpoint in una regione primaria a un endpoint in una regione secondaria, verificando la raggiungibilità e la disponibilità del carico di lavoro per gli utenti.
Amazon CloudFront offre una semplice API per la distribuzione di contenuti con bassa latenza e velocità di trasferimento dati elevate gestendo le richieste tramite una rete di posizioni edge in tutto il mondo. Le reti di distribuzione di contenuti (CDN) operano per i clienti, distribuendo i contenuti situati o memorizzati nella cache in una posizione vicina all’utente. In questo modo si migliora anche la disponibilità dell’applicazione poiché il carico dei contenuti viene spostato dai server alle [posizioni edge](https://aws.amazon.com/products/networking/edge-networking/) di CloudFront. Le posizioni edge e le cache edge regionali includono copie memorizzate nella cache del contenuto vicino agli utenti, per il recupero rapido e una raggiungibilità e una disponibilità maggiori del carico di lavoro.
Per i carichi di lavoro con utenti distribuiti in più aree geografiche, AWS Global Accelerator contribuisce a migliorare la disponibilità e le prestazioni delle applicazioni. AWS Global Accelerator fornisce indirizzi IP statici anycast che operano come punto di ingresso statico alle applicazioni ospitate in una o più Regioni AWS. In questo modo, il traffico può entrare nella rete globale AWS il più vicino possibile agli utenti, migliorando così la raggiungibilità e la disponibilità del carico di lavoro. AWS Global Accelerator monitora anche l’integrità degli endpoint dell’applicazione usando controlli dell’integrità TCP, HTTP e HTTPS. Eventuali variazioni dell’integrità o della configurazione degli endpoint permettono il reindirizzamento del traffico degli utenti a endpoint integri che offrono le prestazioni e la disponibilità migliori agli utenti. Inoltre, AWS Global Accelerator presenta una progettazione di isolamento degli errori che usa due indirizzi IPv4 statici gestiti da zone di rete indipendenti, migliorando la disponibilità delle applicazioni.
Per proteggere i clienti dagli attacchi DDoS, AWS offre AWS Shield Standard. Shield Standard si attiva in automatico e protegge dagli attacchi comuni all'infrastruttura (livello 3 e 4) come i flood SYN/UDP e gli attacchi di riflessione in modo da supportare l'elevata disponibilità delle applicazioni su AWS. Per altre soluzioni di protezione da attacchi più sofisticati e di maggiore entità (come i flood UDP) e di tipo state-exhaustion (come i flood TCP SYN) e per proteggere le applicazioni in esecuzione su Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator e Route 53, puoi prendere in considerazione l'uso di AWS Shield Advanced. Per la protezione da attacchi a livello di applicazione come i flood HTTP POST o GET, usa AWS WAF. AWS WAF può usare indirizzi IP, intestazioni HTTP, corpo HTTP, stringhe URI, iniezione SQL e condizioni di scripting cross-site per determinare se una richiesta debba essere bloccata o consentita.
**Passaggi dell’implementazione**
1. Configura DNS a elevata disponibilità: Amazon Route 53 è un servizio Web di [sistema dei nomi di dominio (DNS)](https://aws.amazon.com/route53/what-is-dns/) altamente scalabile e disponibile. Route 53 collega le richieste degli utenti alle applicazioni Internet eseguite su AWS oppure on-premises. Per ulteriori informazioni, consulta [configuring Amazon Route 53 as your DNS service](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html).
1. Configura controlli dell’integrità: quando usi Route 53, verifica che solo le destinazioni integre siano risolvibili. Inizia con la [creazione dei controlli dell’integrità di Route 53 e la configurazione del failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html). Nel configurare controlli dell’integrità, è importante tenere conto degli aspetti seguenti:
1. [ Modo in cui Amazon Route 53 determina se un controllo dell’integrità ha esito positivo ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)
1. [ Creazione, aggiornamento ed eliminazione di controlli dell’integrità ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)
1. [ Monitoraggio dello stato dei controlli dell’integrità e ricezione di notifiche ](https://docs.aws.amazon.com/)
1. [ Best practice per Amazon Route 53 DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)
1. [ Connessione del servizio DNS agli endpoint. ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)
1. In caso di utilizzo di Elastic Load Balancing come target per il tuo traffico, crea un [record di alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) mediante Amazon Route 53 che punti all'endpoint regionale del tuo sistema bilanciatore del carico. Durante la creazione del record di alias, imposta l'opzione Valutazione dello stato target su Sì.
1. In caso di utilizzo di API Gateway, per i carichi di lavoro serverless o le API private, usa [Route 53 per indirizzare il traffico verso l’API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Opta per una rete di distribuzione di contenuti (CDN).
1. Per la distribuzione di contenuti mediante posizioni edge più vicine all’utente, esamina [il modo in cui CloudFront distribuisce i contenuti](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html).
1. Inizia partendo con una [distribuzione CloudFront semplice](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html). CloudFront sa quindi determinare dove vuoi distribuire i contenuti e come monitorare e gestire la distribuzione di contenuti. Nel configurare la distribuzione di CloudFront, è importante tenere conto degli aspetti seguenti:
1. [ Come funziona la memorizzazione nella cache con le posizioni edge di CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)
1. [ Aumento della percentuale di richieste eseguite direttamente dalle cache CloudFront (percentuale di riscontri nella cache) ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)
1. [ Utilizzo dello scudo di origine Amazon CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)
1. [ Ottimizzazione dell’elevata disponibilità con il failover di origine CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)
1. Configura la protezione a livello di applicazione: AWS WAF semplifica la protezione da exploit Web e bot comuni che possono compromettere la disponibilità e la sicurezza o consumare risorse eccessive. Per una conoscenza più approfondita, scopri [come funziona AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) e quando sarà tutto pronto per implementare le protezioni dai flood HTTP POST e GET a livello dell’applicazione, consulta [Getting started with AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html). Puoi anche utilizzare AWS WAF con CloudFront. Consulta la documentazione [su come funziona AWS WAF con le funzionalità di Amazon CloudFront](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html).
1. Configura protezione aggiuntiva da attacchi DDoS: per impostazione predefinita, tutti i clienti AWS ricevono protezione gratuita dagli attacchi DDoS comuni e più frequenti a livello di rete e di trasporto che prendono di mira il sito Web o l'applicazione con AWS Shield Standard. Per una protezione aggiuntiva delle applicazioni con accesso a Internet in esecuzione su Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator e Amazon Route 53, puoi prendere in considerazione [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) ed esaminare gli [esempi di architetture resilienti agli attacchi DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html). Per proteggere carico di lavoro ed endpoint pubblici dagli attacchi DDoS, consulta [Getting started with AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html).
## Risorse
**Best practice correlate:**
+ [REL10-BP01 Implementazione del carico di lavoro in diversi luoghi](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo (control-plane) durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md)
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l’infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Cosa è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [What is Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [What is Amazon Route 53?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Cos'è l'Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [ Network Connectivity capability - Establishing Your Cloud Foundations ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)
+ [ What is Amazon API Gateway? ](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [ What are AWS WAF, AWS Shield, and AWS Firewall Manager? ](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)
+ [ What is Amazon Application Recovery Controller? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [ Configure custom health checks for DNS failover ](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)
**Video correlati:**
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications ](https://www.youtube.com/watch?v=mwUV5skJJ0s)
+ [AWS re:Invent 2022 - Dive deep on AWS networking infrastructure ](https://www.youtube.com/watch?v=HJNR_dX8g8c)
+ [AWS re:Invent 2022 - Dive deep on networking infrastructure ](https://www.youtube.com/watch?v=u-qamiNgH7Q)
**Esempi correlati:**
+ [ Disaster Recovery with Amazon Application Recovery Controller (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/)
+ [AWS Global Accelerator Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
# REL02-BP02 Esecuzione del provisioning di connettività ridondante tra reti private nel cloud e negli ambienti on-premises
Implementa la ridondanza delle connessioni tra reti private nel cloud e negli ambienti on-premises per ottenere la resilienza della connettività. A tal fine, puoi implementare due o più collegamenti e percorsi di traffico, preservando la connettività in caso di errori di rete.
**Anti-pattern comuni:**
+ Dipendi da una sola connessione di rete, che crea un singolo punto di errore.
+ Utilizzi un solo tunnel VPN o più tunnel che terminano nella stessa zona di disponibilità.
+ Ti affidi a un solo ISP per la connettività VPN, suscettibile di guasto totale in caso di interruzione dell’ISP.
+ Non implementi i protocolli di instradamento dinamico come BGP, fondamentali per reindirizzare il traffico durante le interruzioni di rete.
+ Ignori i limiti di larghezza di banda dei tunnel VPN e sopravvaluti le capacità di backup.
**Vantaggi dell’adozione di questa best practice:** implementando una connettività ridondante tra il tuo ambiente cloud e l’ambiente aziendale oppure on-premises, puoi garantire l’affidabilità delle comunicazioni dei servizi dipendenti tra due ambienti.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Quando si utilizza AWS Direct Connect per connettere la rete on-premises ad AWS, è possibile ottenere la massima resilienza di rete (SLA del 99,99%) impiegando connessioni separate che terminano su dispositivi diversi in più di una posizione on-premises e in più di una posizione AWS Direct Connect. Questa topologia offre resilienza ai guasti dei dispositivi, ai problemi di connettività e alle interruzioni complete della posizione. In alternativa, puoi ottenere un’elevata resilienza (SLA del 99,9%) utilizzando due singole connessioni a più posizioni, con ciascuna posizione on-premises connessa a una singola posizione Direct Connect. Questo approccio offre protezione dalle interruzioni della connettività causate da interruzioni della fibra o guasti dei dispositivi e aiuta a mitigare le interruzioni complete della posizione. Il kit di strumenti di resilienza di Direct Connect può aiutarti a progettare la tua topologia AWS Direct Connect.
Puoi anche prendere in considerazione l’utilizzo di AWS Site-to-Site VPN che termina su AWS Transit Gateway come soluzione conveniente di backup sulla connessione primaria AWS Direct Connect. Questa configurazione abilita l’instradamento equal-cost multi-path (ECMP) su più tunnel VPN, consentendo un throughput fino a 50 Gbps, anche se ogni tunnel VPN è limitato a 1,25 Gbps. È importante notare, tuttavia, che AWS Direct Connect è ancora la scelta più efficace per ridurre al minimo le interruzioni di rete e garantire una connettività stabile.
Quando utilizzi le VPN su Internet per connettere l’ambiente cloud al tuo data center on-premises, configura due tunnel VPN come parte di un’unica connessione VPN sito-sito. Ogni tunnel deve terminare in una zona di disponibilità diversa per garantire l’alta disponibilità e utilizzare hardware ridondante per prevenire gli errori dei dispositivi on-premises. Inoltre, prendi in considerazione l’uso di più connessioni Internet di vari provider di servizi Internet (ISP) per la tua posizione on-premises per evitare l’interruzione completa della connettività VPN dovuta al guasto di un singolo ISP. La scelta di ISP con instradamento e infrastrutture diversi, in particolare quelli con percorsi fisici separati verso gli endpoint AWS, offre un’elevata disponibilità della connettività.
Oltre alla ridondanza fisica con più connessioni AWS Direct Connect e più tunnel VPN, o una combinazione di entrambi, è fondamentale anche l’implementazione dell’instradamento dinamico del Border Gateway Protocol (BGP). Il BGP dinamico fornisce il reinstradamento automatico del traffico da un percorso all’altro in base alle condizioni della rete in tempo reale e alle policy configurate. Questo comportamento dinamico è particolarmente utile per mantenere la disponibilità della rete e la continuità del servizio in caso di errori di collegamento o rete. Seleziona rapidamente percorsi alternativi, migliorando la resilienza e l’affidabilità della rete.
### Passaggi dell’implementazione
+ Acquisisci la connettività ad alta disponibilità tra AWS e l’ambiente on-premises.
+ Utilizza più connessioni AWS Direct Connect o tunnel VPN tra reti private implementate separatamente.
+ Utilizza più posizioni Direct Connect per ottenere un’elevata disponibilità.
+ Se utilizzi più Regioni AWS, garantisci la ridondanza in almeno due di esse.
+ Utilizza AWS Transit Gateway, quando possibile, per terminare la [connessione VPN](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpn-attachments.html).
+ Valuta le appliance di Marketplace AWS per terminare le VPN o [estendere la tua SD-WAN su AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway-sd-wan.html). Se utilizzi appliance di Marketplace AWS, distribuisci le istanze ridondanti per la disponibilità elevata in diverse zone di disponibilità.
+ Fornisci una connessione ridondante all’ambiente on-premises.
+ Per soddisfare le esigenze di disponibilità, possono essere necessarie connessioni ridondanti a più Regioni AWS.
+ Usa l’[Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) per iniziare.
## Risorse
**Documenti correlati:**
+ [AWS Direct Connect Resiliency Recommendations](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Using Redundant Site-to-Site VPN Connections to Provide Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Routing policies and BGP communities](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html)
+ [Active/Active and Active/Passive Configurations in AWS Direct Connect](https://docs.aws.amazon.com/architecture-diagrams/latest/active-active-and-active-passive-configurations-in-aws-direct-connect/active-active-and-active-passive-configurations-in-aws-direct-connect.html)
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l’infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud Connectivity Options Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ Realizzazione di un’infrastruttura di reti multi-VPC sicura e scalabile
+ [Using redundant Site-to-Site VPN connections to provide failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Using the Direct Connect Resiliency Toolkit to get started](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [What Is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [What is a transit gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Cos’è AWS Site-to-Site VPN?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Working with Direct Connect gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC ](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 Verifica che l’allocazione delle sottoreti IP consenta l’espansione e la disponibilità
Gli intervalli di indirizzi IP di Amazon VPC devono essere abbastanza grandi da soddisfare i requisiti del carico di lavoro, tra cui la fattorizzazione nella futura espansione e l’allocazione di indirizzi IP alle sottoreti nelle zone di disponibilità. Ciò comprende bilanciatori del carico, istanze EC2 e applicazioni basate su container.
Quando si pianifica la topologia di rete, il primo passo è definire lo spazio stesso degli indirizzi IP. Gli intervalli di indirizzi IP privati (secondo le linee guida RFC 1918) dovrebbero essere allocati per ogni VPC. Nell’ambito di questo processo, soddisfa i seguenti requisiti:
+ Lascia spazio per indirizzi IP per più di un VPC per regione.
+ All’interno di un VPC, lascia spazio per più sottoreti affinché coprano più zone di disponibilità.
+ Prendi in considerazione di lasciare spazio per un blocco CIDR inutilizzato all’interno di un VPC per un’espansione futura.
+ Assicurati che sia disponibile spazio per gli indirizzi IP, al fine di soddisfare le esigenze di qualsiasi parco istanze EC2 transitorio che puoi utilizzare, ad esempio parchi istanze spot per il machine learning, cluster Amazon EMR o cluster Amazon Redshift. Una considerazione analoga andrebbe fatta per i cluster Kubernetes, come Amazon Elastic Kubernetes Service (Amazon EKS), poiché per impostazione predefinita a ciascun pod Kubernetes viene assegnato un indirizzo instradabile dal blocco CIDR VPC.
+ Tieni presente che i primi quattro indirizzi IP e l’ultimo indirizzo IP in ogni blocco CIDR della sottorete sono riservati e non disponibili per l’uso.
+ Tieni presente che il blocco CIDR VPC iniziale allocato al VPC non può essere modificato o eliminato, ma puoi aggiungere ulteriori blocchi CIDR non sovrapposti al VPC. I CIDR IPv4 della sottorete non possono essere modificati, mentre ciò è possibile con i CIDR IPv6.
+ Il blocco CIDR VPC più grande possibile è /16 e il più piccolo è /28.
+ Prendi in considerazione altre reti connesse (VPC, on-premises o altri provider cloud) e assicurati che lo spazio degli indirizzi IP non si sovrapponga. Per ulteriori informazioni, consulta [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html)
**Risultato desiderato:** una sottorete IP scalabile può aiutarti a far fronte alla crescita futura e a evitare inutili sprechi.
**Anti-pattern comuni:**
+ Mancata presa in considerazione della crescita futura, con conseguenti blocchi CIDR troppo piccoli e che richiedono una riconfigurazione, il che comporta tempi di inattività.
+ Stima erronea del numero di indirizzi IP utilizzabili da un bilanciatore del carico elastico.
+ Distribuzione di numerosi bilanciatori del carico a traffico elevato nelle stesse sottoreti.
+ Utilizzo di meccanismi di dimensionamento automatico senza monitorare il consumo di indirizzi IP.
+ Definizione di intervalli CIDR eccessivamente ampi ben oltre le aspettative di crescita futura, il che può portare a difficoltà di peering con altre reti con intervalli di indirizzi sovrapposti.
**Vantaggi dell’adozione di questa best practice:** in questo modo puoi consentire la crescita dei carichi di lavoro e continuare a fornire disponibilità nell’aumentare verticalmente.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Pianifica la tua rete in base a crescita, compliance normativa e integrazione con altre reti. Senza una pianificazione adeguata, la crescita può essere sottovalutata, la compliance normativa può cambiare e l’implementazione di acquisizioni o di connessioni a reti private può rivelarsi difficile.
+ Seleziona gli Account AWS e le regioni pertinenti in base ai tuoi requisiti di servizio, di latenza, normativi e di disaster recovery (DR).
+ Identifica le esigenze delle implementazioni di VPC regionali.
+ Identifica le dimensioni dei VPC.
+ Stabilisci se intendi implementare connettività multi-VPC.
+ [What Is a Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Connettività multi-VPC a singola regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Stabilisci se hai bisogno della segregazione delle reti a causa di requisiti normativi.
+ Crea VPC con blocchi CIDR di dimensioni adeguate per soddisfare le tue esigenze attuali e future.
+ Se non hai definito proiezioni di crescita, potresti preferire blocchi CIDR più grandi per ridurre il potenziale di riconfigurazione futura
+ Prendi in considerazione l’utilizzo di un [indirizzo IPv6](https://aws.amazon.com/vpc/ipv6/) per le sottoreti nell’ambito di VPC dual-stack. Un indirizzo IPv6 è adatto per l’uso in sottoreti private contenenti parchi istanze o contenitori temporanei che altrimenti richiederebbero un numero elevato di indirizzi IPv4.
## Risorse
**Best practice Well-Architected correlate:**
+ [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html)
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l’infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud Connectivity Options Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Connettività multi-VPC a singola regione](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [What Is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [IPv6 su AWS](https://aws.amazon.com/vpc/ipv6)
+ [IPv6 on reference architectures](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/IPv6-reference-architectures-for-AWS-and-hybrid-networks-ra.pdf)
+ [Amazon Elastic Kubernetes Service launches IPv6 support](https://aws.amazon.com/blogs/containers/amazon-eks-launches-ipv6-support/)
+ [ Consigli per il tuo VPC - Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-backend-instances.html#set-up-ec2)
+ [ Sottoreti delle Zone di disponibilità - Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#availability-zones)
+ [ Zone di disponibilità - Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#availability-zones)
**Video correlati:**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
+ [AWS re:Invent 2023: AWS Ready for what’s next? Designing networks for growth and flexibility (NET310)](https://www.youtube.com/watch?v=FkWOhTZSfdA)
# REL02-BP04 Preferire topologie hub-and-spoke rispetto a mesh da-molti-a-molti
Quando connetti più reti private, come cloud privati virtuali (VPC) e reti on-premises, è opportuno scegliere una topologia hub-and-spoke rispetto a una mesh. A differenza delle topologie mesh, in cui ogni rete si connette direttamente alle altre e aumenta la complessità e il sovraccarico di gestione, l’architettura hub-and-spoke centralizza le connessioni tramite un unico hub. Questa centralizzazione semplifica la struttura della rete e ne migliora il funzionamento, la scalabilità e il controllo.
AWS Transit Gateway è un servizio gestito, scalabile e a disponibilità elevata progettato per la creazione di reti hub-and-spoke su AWS. Funge da hub centrale della rete che fornisce la segmentazione, il routing centralizzato e la connessione semplificata agli ambienti cloud e on-premises. La figura seguente illustra come è possibile utilizzare AWS Transit Gateway per creare la topologia hub-and-spoke.
![\[AWS Transit Gateway connecting various services like VPCs, Direct Connect, and third-party appliances.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/hub-and-spoke.png)
**Risultato desiderato:** hai connesso i cloud privati virtuali (VPC) e le reti on-premises tramite un hub centrale. Configuri le connessioni in peering tramite l’hub, che funge da router cloud a scalabilità elevata. L’instradamento è semplificato perché non è necessario lavorare con complesse relazioni di peering. Il traffico tra le reti è crittografato ed è possibile isolare le reti.
**Anti-pattern comuni:**
+ Crei regole di peering di rete complesse.
+ Fornisci instradamenti tra reti che non devono comunicare tra loro (ad esempio, carichi di lavoro separati che non hanno interdipendenze).
+ La governance dell’istanza dell’hub è inefficace.
**Vantaggi dell’adozione di questa best practice:** con l’aumento del numero di reti connesse, la gestione e l’espansione della connettività mesh diventa sempre più impegnativa. Un’architettura mesh introduce ulteriori sfide, come componenti aggiuntivi dell’infrastruttura, requisiti di configurazione e considerazioni sull’implementazione. La mesh introduce inoltre costi operativi aggiuntivi per gestire e monitorare i componenti del piano dati e del piano di controllo (control-plane). Devi pensare a come fornire disponibilità elevata dell’architettura mesh, monitorare l’integrità e le prestazioni della mesh e gestire gli aggiornamenti dei componenti della mesh.
Un modello hub-and-spoke, invece, stabilisce un instradamento centralizzato del traffico su più reti. Consente un approccio più semplice alla gestione e al monitoraggio dei componenti del piano dati e del piano di controllo (control-plane).
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Crea un account dei Servizi di rete se non esiste. Posiziona l’hub nell’account dei Servizi di rete dell’organizzazione. Questo approccio consente ai tecnici della rete di gestire centralmente l’hub.
L’hub del modello hub-and-spoke funge da router virtuale per il traffico che scorre tra i cloud privati virtuali (VPC) e le reti on-premises. Questo approccio riduce la complessità della rete e facilita la risoluzione dei problemi di rete.
Considera la progettazione della rete, inclusi VPC, AWS Direct Connect e connessioni VPN da sito a sito che desideri interconnettere.
Considera l’utilizzo di una sottorete separata per ciascun collegamento VPC del gateway di transito. Per ogni sottorete, utilizza un piccolo CIDR (ad esempio /28), in modo da avere più spazio di indirizzi per le risorse di elaborazione. Inoltre, crea una lista di controllo degli accessi alla rete e associala a tutte le sottoreti collegate all’hub. Mantieni aperta la lista di controllo degli accessi di rete in entrata e in uscita.
Progetta e implementa le tabelle di routing in modo che gli instradamenti siano forniti solo tra le reti che devono comunicare. Ometti gli instradamenti tra reti che non devono comunicare tra loro (ad esempio, tra carichi di lavoro separati che non hanno interdipendenze).
### Passaggi dell’implementazione
1. Pianifica la rete. Determina le reti che desideri connettere e verifica che non condividano intervalli CIDR sovrapposti.
1. Crea un AWS Transit Gateway e collega i VPC.
1. Se necessario, crea connessioni VPN o gateway Direct Connect e associali a Transit Gateway.
1. Definisci come viene instradato il traffico tra i VPC connessi e altre connessioni tramite la configurazione delle tabelle di routing di Transit Gateway.
1. Usa Amazon CloudWatch per monitorare e modificare come necessario le configurazioni per l’ottimizzazione delle prestazioni e dei costi.
## Risorse
**Best practice correlate:**
+ [REL02-BP03 Verifica che l’allocazione delle sottoreti IP consenta l’espansione e la disponibilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_non_overlap_ip.html)
**Documenti correlati:**
+ [What Is a Transit Gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Transit gateway design best practices](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)
+ [Realizzazione di un’infrastruttura di reti AWS Multi-VPC sicura e scalabile](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)
+ [Building a global network using AWS Transit Gateway Inter-Region peering](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/)
+ [Opzioni di connettività di Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l’infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
**Video correlati:**
+ [AWS re:Invent 2023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
+ [AWS re:Invent 2023 - Advanced VPC designs and new capabilities](https://www.youtube.com/watch?v=cRdDCkbE4es)
**Workshop correlati:**
+ [Workshop su AWS Transit Gateway](https://catalog.workshops.aws/trasitgw/en-US)
# REL02-BP05 Applicazione di intervalli di indirizzi IP privati non sovrapposti in tutti gli spazi con indirizzi privati a cui sono connessi
Gli intervalli di indirizzi IP di ogni VPC non devono sovrapporsi quando sono collegati in peering o connessi tramite Transit Gateway o VPN. Evita i conflitti di indirizzi IP tra VPC e ambienti on-premises o altri provider di servizi cloud utilizzati. Bisogna inoltre disporre di una soluzione per allocare gli intervalli di indirizzi IP privati quando necessario. Un sistema di gestione indirizzi IP (IPAM) può aiutarti ad automatizzare l'allocazione.
**Risultato desiderato:**
+ Nessun conflitto di intervalli di indirizzi IP tra VPC, ambienti on-premises o altri provider di servizi cloud.
+ La corretta gestione degli indirizzi IP consente di scalare più facilmente l'infrastruttura di rete per supportare la crescita e i cambiamenti dei requisiti di rete.
**Anti-pattern comuni:**
+ Utilizzo nel VPC dello stesso intervallo di indirizzi IP usato on-premises, nella rete aziendale o in altro provider di servizi cloud.
+ Mancato monitoraggio degli intervalli IP dei VPC utilizzati per distribuire i carichi di lavoro.
+ Ricorso a processi manuali di gestione degli indirizzi IP, come i fogli di calcolo.
+ Utilizzo di blocchi CIDR sovradimensionati o sottodimensionati, con conseguente spreco di indirizzi IP o spazio di indirizzi insufficiente per il carico di lavoro.
**Vantaggi dell'adozione di questa best practice:** la pianificazione attiva della rete garantisce di non avere più occorrenze dello stesso indirizzo IP nelle reti interconnesse. In questo modo si evitano problemi di instradamento in parti del carico di lavoro che utilizzano le diverse applicazioni.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Utilizza un sistema IPAM, come [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html), per il monitoraggio e la gestione dell'utilizzo di CIDR. Su Marketplace AWS sono disponibili anche diversi IPAM. Valuta il tuo utilizzo potenziale su AWS, aggiungi intervalli CIDR ai VPC esistenti e crea i VPC per consentire la crescita pianificata dell'utilizzo.
### Passaggi dell'implementazione
+ Misura il consumo attuale del CIDR, ad esempio VPC e sottoreti.
+ Utilizza le operazioni delle API di servizi per raccogliere il consumo attuale di CIDR.
+ Sfrutta [Amazon VPC IP Address Manager per individuare le risorse](https://docs.aws.amazon.com/vpc/latest/ipam/res-disc-work-with-view.html).
+ Misura l'utilizzo attuale delle sottoreti.
+ Utilizza le operazioni delle API di servizio per [raccogliere le sottoreti](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) per VPC in ogni regione.
+ Sfrutta [Amazon VPC IP Address Manager per individuare le risorse](https://docs.aws.amazon.com/vpc/latest/ipam/res-disc-work-with-view.html).
+ Registra l'uso attuale.
+ Verifica se hai creato intervalli di indirizzi IP sovrapposti.
+ Calcola la capacità inutilizzata.
+ Individua gli intervalli di indirizzi IP sovrapposti. Puoi effettuare la migrazione verso una nuova gamma di indirizzi o prendere in considerazione l'utilizzo di tecniche come [gateway NAT privato](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/private-nat-gateway.html) o [AWS PrivateLink](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/aws-privatelink.html) se devi connettere gli intervalli sovrapposti.
## Risorse
**Best practice correlate:**
+ [ Protezione delle reti ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-networks.html)
**Documenti correlati:**
+ [Partner APN: partner per la pianificazione della rete](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Marketplace AWS per l'infrastruttura di rete](https://aws.amazon.com/marketplace/b/2649366011)
+ [Amazon Virtual Private Cloud Connectivity Options Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [ Connecting Networks with Overlapping IP Ranges ](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/)
+ [What Is Amazon VPC?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [What is IPAM?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Video correlati:**
+ [AWS re:Invent 2023 - Advanced VPC designs and new capabilities ](https://www.youtube.com/watch?v=cRdDCkbE4es)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [AWS re:Invent 2023 - Ready for what's next? Designing networks for growth and flexibility ](https://www.youtube.com/watch?v=FkWOhTZSfdA)
+ [AWS re:Invent 2021 - \$1New Launch\$1 Manage your IP addresses at scale on AWS](https://www.youtube.com/watch?v=xtLJgJfhPLg)