Réponses:
Je recommanderais les considérations suivantes:
Si vous créez une connexion IPSEC entre votre réseau local d'entreprise et votre VPC, utilisez un CIDR différent de celui de votre réseau local. Cela évitera les chevauchements de routage et créera une distinction d'identité pour référence.
Pour les très grands réseaux, utilisez au moins différents masques 16 bits dans différentes régions, par exemple
eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16
Pour les réseaux plus petits, utilisez un masque 24 bits dans différentes régions, par exemple
eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24
Envisagez de faire la distinction entre les sous-réseaux privés et publics, par exemple
private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)
Ne sur-allouez pas l'espace d'adressage aux sous-réseaux, par exemple
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)
Ne sous-allouez pas non plus. Si vous utilisez une charge d’Elastic Load Balancers, n’oubliez pas qu’ils utiliseront également les adresses IP disponibles sur vos sous-réseaux. Ceci est particulièrement vrai si vous utilisez ElasticBeanstalk.
Certaines choses que j'ai prises en compte la dernière fois que j'ai créé un nouveau VPC:
172.31.0.0/16
dans us-west
eu-ireland
, par exemple. Cela fera du VPN entre ces deux régions un problème nécessitant une double NAT. Non merci.x.x.x.x/24
pour 254 adresses différentes. Il existe probablement des centaines de calculatrices CIDR pour vous aider à comprendre cela.Amazon ne semble pas recommander de taille de réseau particulière pour votre VPC (voir le guide de l'administrateur de réseau VPC et notez l'utilisation de / 16), mais en général, il existe deux raisons de considérer les effets de CIDR sur les performances:
Prenez en compte le nombre initial de nœuds dans votre VPC et la croissance prévue pour la durée de vie prévue du projet. Vous devriez avoir un bon point de départ pour la taille du préfixe. N'oubliez pas qu'il n'est pas nocif de commencer par un petit préfixe tel que / 16 car vous pouvez toujours créer des sous-réseaux.
Une autre considération est de savoir si vous devrez utiliser AWS ClassicLink pour autoriser l'accès au VPC à partir d'instances EC2 en dehors du VPC. De la documentation AWS:
Les VPC dont les itinéraires sont en conflit avec la plage d'adresses IP privées EC2-Classic 10/8 ne peuvent pas être activés pour ClassicLink. Cela n'inclut pas les VPC avec les plages d'adresses IP 10.0.0.0/16 et 10.1.0.0/16 qui ont déjà des itinéraires locaux dans leurs tables de routage. Pour plus d'informations, voir Routage pour ClassicLink.
à partir de http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-routing