Я бы порекомендовал следующие соображения:
Если вы создаете соединение IPSEC между вашей корпоративной LAN и вашим VPC, используйте CIDR, отличный от CIDR в вашей корпоративной LAN. Это предотвратит перекрытие маршрутов и создаст различие идентичности для справки.
Для очень больших сетей используйте, по крайней мере, разные 16-битные маски в разных регионах, например,
eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16
Для небольших сетей используйте 24-битные маски в разных регионах, например
eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24
Рассмотрите возможность проведения различия между частными и общедоступными подсетями, например,
private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)
Не выделяйте чрезмерное адресное пространство подсетям, например,
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)
Не выделяйте слишком много места. Если вы используете множество эластичных балансировщиков нагрузки, помните, что они также будут использовать доступные IP-адреса в ваших подсетях. Это особенно верно, если вы используете ElasticBeanstalk.
Некоторые вещи, которые я рассмотрел, когда в последний раз создавал новый VPC:
172.31.0.0/16
в us-west
eu-irireland
. Это сделает VPN между этими двумя регионами проблемой, требующей решения двойного NAT. Нет, спасибо. x.x.x.x / 24
будет поддерживать 254 разных адреса. Вероятно, существуют сотни калькуляторов CIDR, которые помогут вам в этом разобраться. Amazon, похоже, не рекомендует какой-либо конкретный размер сети для вашего VPC (см. Руководство администратора сети VPC и обратите внимание на использование / 16s), но В общем, есть две причины учитывать влияние CIDR на производительность:
Примите во внимание начальное количество узлов в вашем VPC и прогнозируемый рост в течение ожидаемого срока жизни проекта, и у вас должна быть хорошая отправная точка для размер префикса. Помните, что нет ничего плохого в том, чтобы начать с небольшого префикса, такого как / 16, потому что вы всегда можете создавать подсети.
Еще одно соображение - нужно ли использовать AWS ClassicLink, чтобы разрешить доступ к VPC из экземпляров EC2 за пределами VPC. Из документации AWS:
VPC с маршрутами, которые конфликтуют с диапазоном частных IP-адресов EC2-Classic 10/8, не могут быть включены для ClassicLink. Сюда не входят VPC с 10.0.0.0/16 и 10.1.0.0/16 диапазоны IP-адресов, для которых в таблицах маршрутов уже есть локальные маршруты. Для получения дополнительной информации см. Маршрутизация для ClassicLink.
из http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-routing
В случае, если кто-то может найти этот вопрос и будет заинтересован в настройке спецификации на основе CIDR только одного IP-адреса (например, если вы устанавливаете IP-адрес RDP, разрешенный в новом стеке AWS) , вы бы сделали это с IP-адресом, а затем /32 (что означает «один IP-адрес»), поэтому, если бы ваш адрес был 66.12.34.567, вы бы указали:
66.12.34.567/32