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 VPC progetti multi-account per sottoreti non destinate al carico di lavoro
Creato da Adam Spicer () AWS
Archivio di codice: pattern secondario non instradabile CIDRs | Ambiente: produzione | Tecnologie: infrastruttura DevOps; Gestione e governance; Reti |
AWSservizi: AWS Transit Gateway; AmazonVPC; Elastic Load Balancing () ELB |
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 che per gli endpoint Gateway Load Balancer (per supportare AWSNetwork Firewall o appliance di terze parti). Queste sottoreti vengono utilizzate per contenere interfacce di rete elastiche per questi servizi. Se si utilizzano sia AWS Transit Gateway che un Gateway Load Balancer, vengono create due sottoreti in ciascuna zona di disponibilità per. VPC A causa del modo in cui VPCs sono progettate, queste sottoreti aggiuntive non possono essere più piccole di una maschera /28 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 Classless Inter-Domain Routing (CIDR) secondario e non routabile per queste sottoreti dedicate per preservare lo spazio IP instradabile.
Prerequisiti e limitazioni
Prerequisiti
Architettura
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 ‒ collegata con routing in ingresso a un dispositivo TGW VPC
Il diagramma seguente rappresenta un'architettura di riferimento per A VPC che si estende su due zone di disponibilità. In ingresso, VPC utilizza uno schema di routing in ingresso
Questo modello utilizza un CIDR intervallo non instradabile per la sottorete e la sottorete degli TGW allegati. GWLBe Nella tabella di TGW routing, questa route non instradabile CIDR è configurata con una route blackhole (statica) utilizzando una serie di rotte più specifiche. Se le rotte dovessero essere propagate alla tabella di TGW routing, si applicherebbero queste rotte blackhole più specifiche.
In questo esempio, il routable /23 CIDR è suddiviso e completamente allocato a sottoreti instradabili.
Architettura 2 — -allegata TGW VPC
Il diagramma seguente rappresenta un'altra architettura di riferimento per A VPC che si estende su due zone di disponibilità. Un TGW allegato supporta il traffico in uscita (in uscita) dalle sottoreti private verso una subnet separata. VPC Utilizza un CIDR intervallo non instradabile solo per la sottorete degli allegati. TGW Nella tabella di TGW routing, questo percorso non instradabile CIDR è configurato con una route blackhole utilizzando una serie di rotte più specifiche. Se le rotte dovessero essere propagate alla tabella di TGW routing, si applicherebbero queste rotte a buco nero più specifiche.
In questo esempio, il routable /23 CIDR è suddiviso e completamente allocato a sottoreti instradabili.
Strumenti
AWSservizi e risorse
Amazon Virtual Private Cloud (AmazonVPC) ti aiuta a lanciare AWS risorse 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 sistemi VPC secondari CIDRs vengono utilizzati per preservare lo spazio IP instradabile durante il carico di lavoro. CIDRs
L'Internet Gateway Ingress Routing
(associazioni edge) può essere utilizzato insieme agli endpoint Gateway Load Balancer per sottoreti dedicate non instradabili. AWSTransit Gateway è un hub centrale che collega VPCs reti locali. 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: 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.
AWSNetwork Firewall è un firewall di rete a stato gestito e un servizio di rilevamento e prevenzione delle intrusioni per il cloudVPCs. AWS In questo modello, gli endpoint di un firewall possono essere utilizzati in una sottorete dedicata non routabile.
Archivio di codice
Un runbook e dei AWS CloudFormation modelli per questo pattern sono disponibili nel repository GitHub Non-Routable
Best practice
AWSTransit Gateway
Utilizza una sottorete separata per ogni VPC allegato del gateway di transito.
Alloca una sottorete /28 dall'CIDRintervallo secondario non instradabile 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 non instradabile come buco nero. CIDR
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'CIDRintervallo secondario non instradabile per le sottoreti degli endpoint Gateway Load Balancer.
Epiche
| Attività | Descrizione | Competenze richieste |
|---|---|---|
Determina l'intervallo non instradabile. CIDR | Determina un CIDR intervallo 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 CIDR intervallo verrà utilizzato come secondario per. CIDR VPC Non deve essere instradabile dall'CIDRintervallo VPC primario o dalla rete più grande. | Architetto del cloud |
Determina gli CIDR intervalli di routing perVPCs. | Determina una serie di CIDR intervalli instradabili che verranno utilizzati per il tuo. VPCs Questo CIDR intervallo verrà utilizzato come principale CIDR per il tuoVPCs. | Architetto del cloud |
CreaVPCs. | Crea i tuoi VPCs e collegali al gateway di transito. Ciascuno VPC deve avere un CIDR intervallo primario instradabile e un CIDR intervallo secondario non instradabile, in base agli intervalli determinati nei due passaggi precedenti. | Architetto del cloud |
| Attività | Descrizione | 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 routabili. CIDRs Queste sono configurate per garantire che il traffico proveniente dal secondario VPC CIDR rimanga non instradabile e non si riveli nella rete più ampia. Questi percorsi devono essere più specifici di quelli non routabili impostati come CIDR secondari su. CIDR VPC Ad esempio, se il percorso secondario non instradabile CIDR è 100.64.0.0/26, le rotte blackhole 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
Informazioni aggiuntive
L'CIDRintervallo secondario 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 NAT gateway privato per utilizzare una sottorete non routabile per ospitare le distribuzioni dei container. Per ulteriori informazioni, consulta il post del blog Come risolvere l'esaurimento dell'IP privato con Private Solution
