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

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

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

Если вы создаете соединение IPSEC между вашей корпоративной локальной сетью и вашим VPC, используйте CIDR, который отличается от того, который используется в вашей корпоративной локальной сети. Это предотвратит дублирование маршрутизации и создаст различие идентичности для справки.

Для очень больших сетей используйте как минимум разные 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)

Не выделяйте слишком много. Если вы используете загрузку Elastic Load Balancers, помните, что они также будут использовать доступные IP-адреса в ваших подсетях. Это особенно верно, если вы используете ElasticBeanstalk.

Некоторые вещи, которые я рассмотрел в последний раз, когда я создал новый VPC:

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

Похоже, Amazon не рекомендует какой-либо конкретный размер сети для вашего VPC (см. Руководство администратора сети VPC и обратите внимание на использование / 16), но в целом есть две причины, чтобы рассмотреть влияние 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