В моей предыдущей работе мне сказали, что при создании VPC мы всегда должны пытаться заполнить его CIDR как можно лучше в его подсетях. Итак, / 16 VPC с тремя общедоступными тремя частными подсетями,
Я привык настраивать как:
Общедоступные подсети как / 20 (в данном случае / 20 x 3) = 12 тыс. IP-адресов.
Частные подсети как / 18 (в данном случае / 18 x 3) = ~ 49,5 тыс. IP-адресов
Это позволит выделить 61,5 тыс. IP-адресов.
Однако в моей текущей работе мы все используем / 16 в VPC и шесть подсетей в / 20, что оставляет 1/3 IP-адресов для распределения. В предыдущей работе пиринг VPC был необходим, поскольку большинство проектов подключались к основному VPC, где была платформа электронной коммерции, в текущей работе это не так, и нам действительно не о чем беспокоиться Коллизия IP-адресов, поэтому это никого не беспокоит и т. Д.
У меня возникает вопрос: должны ли мы создавать / 16 VPC для этого (я честно считаю, что ответ на этот вопрос всегда должен быть отрицательным), и должны ли мы оставлять большие куски IP-адресов нераспределенными, или мы должны пытаться всегда заполнять наш VPC как как можно лучше?
Мой аргумент в пользу этого всегда был отрицательным для обоих, потому что это не лучшая практика, но, кажется, всегда приводит к безмолвному спору, поскольку противоположное не увеличивает затраты.
С IPv6 решена задача определения размера подмножеств, все - / 64s.
VPC получает / 56, скажем, это 2001:db8:9876:5400::/56. Из этого, возможно:
a АЗ получает 2001:db8:9876:540a::/64b АЗ получает 2001:db8:9876:540b::/64И так далее. Эти / 64 имеют миллиарды адресов, а у вас их 256. Хотите подсеть по любой причине? Другой / 64. Уникален в глобальном масштабе, поэтому конфликтов адресов нет.
Маршрутизируйте и применяйте политику безопасности как обычно.
Ваш вопрос относится к планированию адресов v4 с ограничениями по максимальному использованию и поддержанию уникальной адресации. v6 делает этот правильный размер устаревшим. Количество хостов значения не имеет.
Конечно, после, возможно, значительного проекта его нужно включить.
Выделение подсетей, связанных с безопасностью, - лишь одно из ограничений адресных планов. Но планы адресов v4 могут стать сложными при добавлении множества подсетей. Этой сложности нет в v6, «общедоступный» против «частного» - это все / 64. Тем не менее, см. Ответ Тима о том, что безопасность - это не только подсети.
Я не считаю это лучшей практикой, но вот мое мнение
Подсети и группы безопасности
Вот кое-что, с чем некоторые не согласятся - особенно старые специалисты по безопасности или, может быть, люди, у которых есть другие варианты использования, чем я. Я думаю, что многоуровневые подсети не всегда необходимы, и что группы безопасности следует использовать вместо подсетей, если вам не нужна функция, которую могут предоставить только подсети, например маршрутизация на основе подсети, серверы, защищенные от проникновения, NAT. Необходимы общедоступные и частные подсети, но я не думаю, что «одна подсеть на уровень приложения» обязательно является лучшим подходом. Сервисы, которые не являются общедоступными, иногда могут обойтись одной подсетью на каждую зону доступности. В некоторых случаях подсети могут обеспечить «глубокую защиту», которая может снизить риск неправильной настройки групп безопасности.
В AWS все подсети в VPC могут маршрутизировать друг друга, и вы не можете это изменить, но вы можете использовать NACL и группы безопасности для ограничения обмена данными. Однако вам может потребоваться, например, набор ресурсов, которые не могут получить доступ к Интернету или локально, или наоборот. Вы можете сделать это с помощью групп безопасности, но не все будут им доверять. Подсети там уместны.
NACL я обычно использую для изоляции сред - например, чтобы производственные ресурсы не могли взаимодействовать с тестовыми ресурсами - обычно в разных учетных записях, но транзитный шлюз обеспечивает связь.
Когда вы применяете этот подход, у вас есть небольшое количество более крупных подсетей - может быть, только одна подсеть на каждую зону доступности, может быть, две подсети на зону доступности, чтобы ограничить доступ в Интернет таким способом, который может принять группа безопасности.