2016-11-08 2 views
0

Je sais que ce sujet contient beaucoup d'informations, mais je ne trouve pas de réponse à une question simple.Paramètre AWS CIRD

Je suis prêt à avoir un sous-réseau pour chaque zone de disponibilité dans ma région (3 zones). Mon VPC CIDR est 10.0.0.0/19 et je veux que chaque sous-réseau ait la même quantité d'adresses IP. Ma question est de savoir quel est le bloc CIDR que je devrais assigner à chaque sous-réseau?

+0

Je vote pour clore cette question hors-sujet parce qu'elle ne semble pas concerner la programmation dans la portée définie dans le [centre d'aide] (http://stackoverflow.com/help/on-topic). – Matt

Répondre

0

10.0.0.0/19 a 8192 adresses IP, de 10.0.0.0 par 10.0.31.255

Lors de la division un SuperNet en sous-réseaux de taille égale, vous ne pouvez diviser par deux puissances de - 2, 4 , 8, 16, etc., de sorte que ce bloc ne peut pas être divisé en 3 blocs de taille égale, mais il peut être divisé en 4.

10.0.0.0/21 has 2,048 addresses 
10.0.8.0/21 has 2,048 addresses 
10.0.16.0/21 has 2,048 addresses 
10.0.24.0/21 has 2,048 addresses 

Puisque vous seulement trois d'entre eux, vous pouvez simplement réserver un d'entre eux pour une utilisation dans une 4ème zone de disponibilité si vous y avez accès (certains comptes ont accès à plus de 3 zones de disponibilité dans au moins une région) ou à d'autres fins.

Cependant, même si vous ne le réalisez peut-être pas encore, vous avez probablement besoin d'au moins deux sous-réseaux dans chaque zone de disponibilité de chaque VPC. En règle générale, vos instances sont placées sur des sous-réseaux privés, mais les passerelles ou instances NAT et les équilibreurs de charge Elastic doivent se trouver dans des sous-réseaux publics. Voir Why do we need private subnets in VPC? pour plus de détails sur comment cela fonctionne.

Donc, vous avez probablement besoin d'au moins 6 blocs. Encore une fois, vous ne pouvez pas faire 6 blocs de taille égale, mais vous pouvez faire 8, et stocker les deux restes.

10.0.0.0/22 has 1,024 addresses 
10.0.4.0/22 has 1,024 addresses 
10.0.8.0/22 has 1,024 addresses 
10.0.12.0/22 has 1,024 addresses 
10.0.16.0/22 has 1,024 addresses 
10.0.20.0/22 has 1,024 addresses 
10.0.24.0/22 has 1,024 addresses 
10.0.28.0/22 has 1,024 addresses 

Un autre facteur important dans la VPC est que vous n'avez pas besoin de vous soucier du sous-réseau d'une machine est si elle communique avec une autre machine dans la même zone de disponibilité. Il n'y a pas de différence de performance dans une zone de disponibilité si les deux instances communicantes sont sur les mêmes sous-réseaux ou non ... il peut donc être judicieux d'utiliser des sous-réseaux encore plus petits que ceux-ci, ou des masques de sous-réseau de longueur variable. commodité.

+0

Merci @ Michael-sqlbot. Considérons que je mets IP publique pour chaque instance, alors j'ai besoin d'un seul sous-réseau pour chaque zone, n'est-ce pas? En outre, quel est l'inconvénient pour la mise en place d'IP publique pour chaque instance? – guystart

+0

Ce n'est vraiment pas une bonne pratique. Vous augmentez votre surface d'attaque potentielle de façon exponentielle et inutilement, vous gaspillez des adresses IPv4 (une ressource rare), vos machines n'auront pas d'adresses publiques * statiques *, elles sont dynamiques, sauf si vous demandez le support AWS augmentez votre allocation par défaut de 5 adresses IP publiques ("élastiques") par région, ce qui nécessite de justifier votre cas d'utilisation. Cela peut sembler plus simple maintenant, mais au fur et à mesure que vous en apprendrez plus sur AWS, vous verrez inévitablement les problèmes plus clairement et vous aurez beaucoup de travail à faire. –