Qual è il CIDR consigliato durante la creazione di VPC su AWS?

Ho creato VPC AWS e mi chiedo se esiste un valore CIDR raccomandato durante la creazione di VPC. Quali sono i fattori che devo considerare quando scelgo un CIDR e il valore CIDR influenza le prestazioni della rete?

Consiglierei le seguenti considerazioni:

Se si crea una connessione IPSEC tra la LAN aziendale e il VPC, utilizzare un CIDR diverso da quello sulla LAN aziendale. Ciò impedirà sovrapposizioni di routing e creerà una distinzione di identità come riferimento.

Per reti molto grandi, utilizzare almeno diverse maschere a 16 bit in diverse regioni, ad es

eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16

Per reti più piccole, utilizzare una maschera a 24 bit in diverse regioni, ad es

eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24

Valuta la possibilità di fare una distinzione tra sottoreti private e pubbliche, ad es

private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)

Non assegnare eccessivamente lo spazio degli indirizzi alle sottoreti, ad es

eu-west-1 10.0.1.0/26
eu-west-1 10.0.1.64/26
eu-west-1 10.0.1.128/26
eu-west-1 10.0.1.192/26

(62 hosts per subnet)

Non sottoallocare neanche. Se si utilizza un carico di bilanciatori di carico elastici, tenere presente che consumeranno anche gli indirizzi IP disponibili nelle sottoreti. Ciò è particolarmente vero se si utilizza ElasticBeanstalk.

Alcune cose che ho considerato l'ultima volta che ho creato un nuovo VPC:

1. Accertarsi che gli intervalli IP di regioni diverse non si sovrappongano. Non dovresti avere un 172.31.0.0/16in us-west eu-ireland, per esempio. Renderà la VPN tra queste due aree un problema che richiede il doppio NAT per risolvere. No grazie.
2. Assicurati che l'intervallo IP sia sufficientemente ampio da contenere tutte le istanze che ritieni necessarie x.x.x.x/24possano contenere 254 indirizzi diversi. Probabilmente ci sono centinaia di calcolatori CIDR là fuori per aiutarti a capirlo.
3. Creo molte sottoreti diverse in un singolo VPC, piuttosto che creare più VPC. Le sottoreti possono parlare tra loro - io posso avere sottoreti private o pubbliche per mantenere alcune istanze protette da Internet aperto. Utilizzare un'istanza NAT in modo che la sottorete privata possa comunicare con la sottorete pubblica. Utilizzare i gruppi di sicurezza per isolare i gruppi di istanze l'uno dall'altro.

Amazon non sembra raccomandare una particolare dimensione di rete per il tuo VPC (vedi la guida dell'amministratore di rete VPC e nota l'uso di / 16s), ma in generale ci sono due motivi per considerare gli effetti sulle prestazioni del CIDR:

1. Routing . Un prefisso più piccolo (rete più grande) viene spesso utilizzato per l'aggregazione del percorso e può effettivamente migliorare le prestazioni.
2. Traffico broadcast e multicast, che è più rilevante per la tua situazione e può comportare una riduzione delle prestazioni su prefissi più piccoli. È possibile mitigare gli effetti di questo traffico immettendo ulteriormente il VPC come mostrato nella guida per l'amministratore della rete.

Considera il numero iniziale di nodi nel tuo VPC e la crescita prevista per la durata prevista del progetto e dovresti avere un buon punto di partenza per la dimensione del prefisso. Ricorda che non c'è nulla di male a partire da un piccolo prefisso come / 16 perché puoi sempre creare sottoreti.

Un'altra considerazione è se sarà necessario utilizzare AWS ClassicLink per consentire l'accesso al VPC dalle istanze EC2 al di fuori del VPC. Dalla documentazione di AWS:

VPC con route in conflitto con l'intervallo di indirizzi IP privati ​​EC2-Classic di 10/8 non possono essere abilitati per ClassicLink. Ciò non include VPC con intervalli di indirizzi IP 10.0.0.0/16 e 10.1.0.0/16 che hanno già percorsi locali nelle loro tabelle di instradamento. Per ulteriori informazioni, consultare Routing per ClassicLink.

da http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-routing