Назад | Перейти на главную страницу

Какой CIDR рекомендуется использовать при создании VPC на AWS?

Я создавал AWS VPC, и мне интересно, есть ли рекомендованное значение CIDR при создании VPC. Какие факторы я должен учитывать при выборе CIDR и влияет ли значение CIDR на производительность сети?

Я бы рекомендовал следующие соображения:

Если вы создаете 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:

  1. Убедитесь, что диапазоны IP-адресов из разных регионов не перекрываются. У тебя не должно быть 172.31.0.0/16 в us-west eu-ireland, например. Это сделает VPN между этими двумя регионами проблемой, требующей решения двойного NAT. Нет, спасибо.
  2. Убедитесь, что диапазон IP-адресов достаточно велик, чтобы вместить все нужные вам экземпляры. x.x.x.x/24 разместит 254 разных адреса. Вероятно, существуют сотни калькуляторов CIDR, которые помогут вам в этом разобраться.
  3. Я создаю множество разных подсетей в одном VPC, а не создаю несколько VPC. Подсети могут взаимодействовать друг с другом - у меня могут быть частные или общедоступные подсети, чтобы некоторые экземпляры были защищены от открытого Интернета. Используйте экземпляр NAT, чтобы частная подсеть могла взаимодействовать с общедоступной подсетью. Используйте группы безопасности, чтобы изолировать группы экземпляров друг от друга.

Amazon, похоже, не рекомендует какой-либо конкретный размер сети для вашего VPC (см. Руководство администратора сети VPC и обратите внимание на использование / 16s), но в целом есть две причины учитывать влияние CIDR на производительность:

  1. Маршрутизация. Меньший префикс (более крупная сеть) часто используется для агрегации маршрутов и действительно может улучшить производительность.
  2. Трансляция и многоадресный трафик, который более актуален для вашей ситуации и может привести к снижению производительности на меньших префиксах. Вы можете уменьшить влияние этого трафика, разделив VPC на подсети, как показано в руководстве администратора сети.

Примите во внимание начальное количество узлов в вашем VPC и прогнозируемый рост на ожидаемый срок существования проекта, и у вас должна быть хорошая отправная точка для размера префикса. Помните, что нет ничего плохого в том, чтобы начать с небольшого префикса, например / 16, потому что вы всегда можете создавать подсети.

Еще одно соображение: нужно ли использовать AWS ClassicLink, чтобы разрешить доступ к VPC из инстансов EC2 за пределами VPC. Из документации AWS:

VPC с маршрутами, которые конфликтуют с диапазоном частных IP-адресов EC2-Classic 10/8, не могут быть включены для ClassicLink. Сюда не входят VPC с диапазонами IP-адресов 10.0.0.0/16 и 10.1.0.0/16, которые уже имеют локальные маршруты в своих таблицах маршрутов. Для получения дополнительной информации см. Маршрутизация для ClassicLink.

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