Design VPC #best_practices или как разбить на подсетки VPC, какую схему выбрать для dev/stg/prod, как грамотно организовать VPC для разных целей. Рекомендуемые ссылки почитать:
- Официальная дока
- Пошаговые инструкции с примерами для консоли и AWS CLI (не совсем про дизайн, но может быть полезно)
- Базовые понятия и общие рекомендации (13 пунктов)
- Старенькая, но тоже можно глянуть
- Тоже старенькая, но весьма подробная (25 пунктов)
- Полезное обсуждение на Reddit по вопросу разбивке на CIDR-blocks
- Не про VPC, но полезные общие практики AWS Cloud Design Patterns

#vpc #design #vpc_design #cidr

Для внутренних адресов можно выбрать несколько регионов, описанных в RFC1918:

10.0.0.0    - 10.255.255.255  (10.0.0.0/8     prefix)
172.16.0.0  - 172.31.255.255  (172.16.0.0/12  prefix)
192.168.0.0 - 192.168.255.255 (192.168.0.0/16 prefix)

и RFC6598:

100.64.0.0 - 100.127.255.255 (100.64.0.0/10 prefix)

Из четырёх "удобными" являются лишь два - 10.0.0.0/8 и 192.168.0.0/16. Их подсети описываются очевидной схемой 10.х.х.х и 192.168.х.х, хорошо запоминаются и потому вероятность ошибиться минимальна, не путая локальные адреса с публичными.

Кроме того, Docker использует по умолчанию регион 172.17.0.0/16 - пересечение с ним обеспечит незабываемые ощущения при отладке. Равно как и дефолтная подсеть VPC в Амазоне это 172.31.0.0/16, что сделает проблемным возможный пиринг при использовании такого же региона.

Потому в общем случае не стоит мудрить и использовать для CIDR block подсети из 10.х.х.х (10.0.0.0/8) — много адресов и обычно они банально короче (меньше кнопок жать).

#VPC #CIDR