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à. # Conserva lo spazio IP instradabile nei progetti VPC multi-account per sottoreti non destinate ai carichi di lavoro *Adam Spicer, Amazon Web Services* ## Riepilogo Amazon Web Services (AWS) ha pubblicato delle best practice che consigliano l'uso di sottoreti dedicate in un cloud privato virtuale (VPC) sia per [gli allegati del gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html) che per gli [endpoint Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) (per supportare AWS [Network](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-high-level-steps.html) Firewall o appliance di terze parti). Queste sottoreti vengono utilizzate per contenere interfacce di rete elastiche per questi servizi. Se utilizzi sia AWS Transit Gateway che un Gateway Load Balancer, vengono create due sottoreti in ciascuna zona di disponibilità per il VPC. A causa del modo in cui VPCs sono progettate, queste sottoreti aggiuntive [non possono essere più piccole di una maschera /28](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-sizing) e possono consumare prezioso spazio IP instradabile che potrebbe altrimenti essere utilizzato per carichi di lavoro instradabili. Questo modello dimostra come è possibile utilizzare un intervallo CIDR (Classless Inter-Domain Routing) secondario e non routabile per queste sottoreti dedicate per preservare lo spazio IP instradabile. ## Prerequisiti e limitazioni **Prerequisiti** + [Strategia multi-VPC per spazio IP](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) instradabile + [Una gamma CIDR non instradabile per i servizi che stai utilizzando ([allegati del gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html) e endpoint Gateway Load [Balancer o](https://aws.amazon.com/blogs/apn/centralized-traffic-inspection-with-gateway-load-balancer-on-aws/) Network Firewall)](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) ## Architecture **Architettura Target** Questo modello include due architetture di riferimento: un'architettura ha sottoreti per gli allegati Transit Gateway (TGW) e un endpoint Gateway Load Balancer (GWLBe), mentre la seconda architettura ha sottoreti solo per gli allegati TGW. **Architettura 1 ‒ VPC collegato a TGW con routing di ingresso verso un dispositivo** Il diagramma seguente rappresenta un'architettura di riferimento per un VPC che si estende su due zone di disponibilità. [In ingresso, il VPC utilizza [uno schema di routing in ingresso per indirizzare il traffico destinato alla sottorete pubblica verso un'](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/)appliance per l'ispezione del firewall. bump-in-the-wire ](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) Un allegato TGW supporta l'uscita dalle sottoreti private verso un VPC separato. Questo modello utilizza un intervallo CIDR non instradabile per la sottorete e la sottorete degli allegati TGW. GWLBe Nella tabella di routing TGW, questo CIDR non routabile è configurato con una route blackhole (statica) utilizzando una serie di rotte più specifiche. Se le rotte dovessero essere propagate alla tabella di routing TGW, si applicherebbero queste rotte blackhole più specifiche. In questo esempio, il CIDR instradabile /23 è suddiviso e completamente allocato a sottoreti instradabili. ![\[VPC collegato a TGW con routing di ingresso verso un dispositivo.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/adad1c83-cdc2-4c5e-aa35-f47fc31af384.png) **Architettura 2 — VPC collegato a TGW** Il diagramma seguente rappresenta un'altra architettura di riferimento per un VPC che si estende su due zone di disponibilità. Un allegato TGW supporta il traffico in uscita (uscita) dalle sottoreti private verso un VPC separato. Utilizza un intervallo CIDR non instradabile solo per la sottorete degli allegati TGW. Nella tabella di routing TGW, questo CIDR non instradabile è configurato con una route blackhole utilizzando una serie di rotte più specifiche. Se le rotte dovessero essere propagate alla tabella di routing TGW, si applicherebbero queste rotte blackhole più specifiche. In questo esempio, il CIDR instradabile /23 è suddiviso e completamente allocato a sottoreti instradabili. ![\[VPC si estende su 2 zone di disponibilità con attacco TGW per l'uscita da sottoreti private a VPC separato.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/31a2a241-5be6-425e-93e9-5ff7ffeca3a9.png) ## Tools (Strumenti) **Servizi e risorse AWS** + [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) ti aiuta a lanciare le risorse AWS in una rete virtuale che hai definito. Questa rete virtuale è simile a una rete tradizionale che gestiresti nel tuo data center, con i vantaggi dell'utilizzo dell'infrastruttura scalabile di AWS. In questo modello, i VPC secondari CIDRs vengono utilizzati per preservare lo spazio IP instradabile nel carico di lavoro. CIDRs + L'[Internet Gateway Ingress Routing](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/) (associazioni edge) può essere utilizzato insieme agli endpoint Gateway Load Balancer per sottoreti dedicate non instradabili. + [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) è un hub centrale che collega reti locali VPCs e internazionali. In questo modello, VPCs sono collegati centralmente a un gateway di transito e gli allegati del gateway di transito si trovano in una sottorete dedicata non instradabile. + [Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html): consentono di implementare, dimensionare e gestire appliance virtuali, come firewall, sistemi di prevenzione e rilevamento delle intrusioni e sistemi di ispezione approfondita dei pacchetti. Il gateway funge da unico punto di ingresso e uscita per tutto il traffico. In questo modello, gli endpoint per un Gateway Load Balancer possono essere utilizzati in una sottorete dedicata non routabile. + [AWS Network Firewall è un firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) di rete a stato gestito e un servizio di rilevamento e prevenzione delle intrusioni VPCs nel cloud AWS. In questo modello, gli endpoint di un firewall possono essere utilizzati in una sottorete dedicata non routabile. **Archivio di codice** Un runbook e CloudFormation modelli AWS per questo pattern sono disponibili nel repository GitHub [Non-Routable Secondary CIDR](https://github.com/aws-samples/non-routable-secondary-vpc-cidr-patterns/) Patterns. Puoi utilizzare i file di esempio per configurare un laboratorio di lavoro nel tuo ambiente. ## Best practice **AWS Transit Gateway** + Utilizza una sottorete separata per ogni allegato VPC del gateway di transito. + Alloca una sottorete /28 dall'intervallo CIDR secondario non routabile per le sottoreti allegate del gateway di transito. + In ogni tabella di routing del gateway di transito, aggiungi una route statica e più specifica per l'intervallo CIDR non instradabile come buco nero. **Gateway Load Balancer e routing in ingresso** + Utilizza il routing in ingresso per indirizzare il traffico da Internet agli endpoint Gateway Load Balancer. + Utilizza una sottorete separata per ogni endpoint Gateway Load Balancer. + Alloca una sottorete /28 dall'intervallo CIDR secondario non instradabile per le sottoreti degli endpoint Gateway Load Balancer. ## Epiche ### Crea VPCs | Operazione | Description | Competenze richieste | | --- | --- | --- | | Determina l'intervallo CIDR non instradabile. | Determina un intervallo CIDR non instradabile che verrà utilizzato per la sottorete degli allegati del gateway di transito e (facoltativamente) per qualsiasi sottorete endpoint Gateway Load Balancer o Network Firewall. Questo intervallo CIDR verrà utilizzato come CIDR secondario per il VPC. **Non deve essere instradabile** dall'intervallo CIDR primario del VPC o dalla rete più ampia. | Architetto del cloud | | Determina gli intervalli CIDR instradabili per. VPCs | Determina un set di intervalli CIDR instradabili che verranno utilizzati per il tuo. VPCs Questo intervallo CIDR verrà utilizzato come CIDR principale per il tuo. VPCs | Architetto del cloud | | Crea VPCs. | Crea i tuoi VPCs e collegali al gateway di transito. Ogni VPC deve avere un intervallo CIDR primario instradabile e un intervallo CIDR secondario non instradabile, in base agli intervalli determinati nei due passaggi precedenti. | Architetto del cloud | ### Configura i percorsi blackhole del Transit Gateway | Operazione | Description | Competenze richieste | | --- | --- | --- | | Crea buchi neri più specifici e non CIDRs instradabili. | Ogni tabella di routing del gateway di transito deve disporre di una serie di percorsi blackhole creati per i percorsi non instradabili. CIDRs Questi sono configurati per garantire che il traffico proveniente dal CIDR VPC secondario rimanga non instradabile e non si disperda nella rete più grande. Questi percorsi devono essere più specifici del CIDR non routabile impostato come CIDR secondario sul VPC. Ad esempio, se il CIDR secondario non routabile è 100.64.0.0/26, le rotte dei buchi neri nella tabella di routing del gateway di transito devono essere 100.64.0.0/27 e 100.64.0.32/27. | Architetto del cloud | ## Risorse correlate + [Best practices for deploying Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) + [Architetture di ispezione distribuite con Gateway Load Balancer](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/distributed-inspection-architectures-gwlb-ra.pdf?did=wp_card&trk=wp_card) + [Giornata di immersione nella rete](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc) ‒ [Laboratorio firewall da Internet a VPC](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc) + [Transit gateway design best practices](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html) ## Informazioni aggiuntive La gamma CIDR secondaria non routabile può essere utile anche quando si lavora con implementazioni di container su larga scala che richiedono un ampio set di indirizzi IP. È possibile utilizzare questo modello con un gateway NAT privato per utilizzare una sottorete non instradabile per ospitare le distribuzioni dei contenitori. Per ulteriori informazioni, consulta il post del blog [Come risolvere l'esaurimento dell'IP privato con la soluzione NAT privata](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/).