Сообщить об ошибкеКороткий ответ
При десятках сетей hub-and-spoke почти всегда управляемее, чем peering-mesh, за счёт линейного роста подключений и единой точки применения политик, но это не универсальная истина — выбор зависит от требуемой изоляции между командами, допустимой дополнительной задержки через хаб и готовности инвестировать в эксплуатацию дополнительного централизованного компонента.
Как это работает подробнее
hub-and-spoke концентрирует межсетевую маршрутизацию и, опционально, инспекцию трафика в одном месте, через которое логически проходит трафик между spoke-сетями, что даёт единую точку применения политик безопасности; peering-mesh оставляет маршрутизацию и политики распределёнными по каждой паре сетей, что проще для малого числа сетей, но быстро усложняет аудит на масштабе.
Пример кода
example.txt
Peering mesh, 15 VPC: потенциально до 105 отдельных peering-соединений,
политики безопасности настраиваются и проверяются в каждой паре отдельно
Hub-and-spoke, 15 VPC:
15 подключений к Transit Gateway/hub VNet
Централизованный inspection firewall в hub проверяет весь межсетевой трафик
Route table на hub явно определяет, какие spoke видят друг другаЧто использовать на практике
- Рекомендация. решение принимают с учётом трёх факторов — сколько сетей нужно связать и как быстро растёт их число, нужна ли централизованная инспекция трафика между командами по требованиям безопасности, и насколько критична дополнительная задержка и единая точка отказа хаба для самых чувствительных к задержке нагрузок (для которых иногда оставляют прямой peering в обход хаба как исключение).
- Проверка. при добавлении шестнадцатой сети в hub-and-spoke модели требуется одно новое подключение и обновление таблицы маршрутизации на хабе, а аудит межсетевых политик безопасности проводится в одном месте, а не в N отдельных конфигурациях.
- Компромисс. hub-and-spoke даёт управляемость, централизованную безопасность и линейный рост сложности, но добавляет стоимость прохождения трафика через хаб, потенциальную дополнительную задержку и новую критичную точку, которую нужно масштабировать и резервировать; peering-mesh проще и требует меньше начальных инвестиций, но плохо масштабируется и усложняет единообразный аудит политик по мере роста — выбор должен опираться на реальный масштаб, требования к инспекции трафика и бюджет, а не на предположение, что одна топология всегда лучше другой.
Подводные камни
- Риск. вводить hub-and-spoke «потому что так лучше для масштаба», не оценив, оправдывает ли реальное число сетей дополнительную сложность и стоимость трафика через хаб
- Риск. размещать инспекционный firewall в хабе без расчёта его пропускной способности, создавая узкое место при росте трафика
- Риск. не предусматривать исключения для пар сетей с жёсткими требованиями к задержке.