В облаке AWS моей компании у нас есть 4 VPC, по одному для каждой из наших основных сред API (dev, test, stage, prod). Чтобы сделать эти среды как можно более похожими друг на друга, для всех них установлен блок CIDR 10.0.0.0/16.
Теперь у нас возникла потребность в создании внутренней службы, совместно используемой этими средами. В качестве аргумента предположим, что эта новая служба хранит данные журналов из всех этих сред. Эта служба существует в собственном VPC с блоком CIDR 10.1.1.0/24.
Сначала я думал, что смогу просто добавить пиринговые соединения из всех VPC среды в VPC, ведущий журнал. Однако я столкнулся с препятствием, когда начал настраивать таблицы маршрутов. Я сделал таблицу маршрутов из Dev -> Logging, которая направляет весь трафик с пунктом назначения 10.1.1.0/24. Но я все еще не могу подключиться к моему серверу журналов изнутри dev. Кажется, мне нужно добавить таблицу маршрутов для Logging -> Dev, которая направляет весь трафик с пунктом назначения 10.0.0.0/16. Это позволяет мне подключаться к серверу журналов с сервера разработки, но теперь я не могу подключиться ни к одной из моих других сред к VPC журналирования.
Сервер регистрации никогда не должен инициировать соединение с моими серверами API, ему нужно только получать соединения и отвечать на них. Итак, моей следующей мыслью было то, что я мог бы использовать шлюз NAT на каждом из VPC среды, а затем направить их в VPC, ведущий журнал. К сожалению, кажется, что шлюзы NAT подключены напрямую к Интернету, и я не хочу, чтобы мой VPC для ведения журналов был подключен к Интернету.
Я чувствую, что должен быть способ заставить эту работу работать, но я не могу его придумать. На данный момент я чувствую, что мой единственный вариант - создать 4 VPC для ведения журналов и запустить отдельные серверы журналов в каждом из них, но с точки зрения затрат это мне не очень нравится.
Во-первых, я должен упомянуть: вы допустили очень серьезную ошибку, дублируя подсети в своих VPC. Даже если вероятность того, что вам потребуется маршрутизировать трафик между ними, практически равна нулю, адресное пространство RFC1918 достаточно велико, чтобы вы могли предоставить каждому VPC уникальную подсеть. Я консультируюсь с рядом компаний по темам, связанным с AWS, и веду электронную таблицу «главного списка подсетей» для записи используемых подсетей при выделении VPC для клиентов, чтобы убедиться, что у меня нет перекрывающихся подсетей.
Очевидный ответ на ваш вопрос - изменить нумерацию перекрывающихся VPC. Это будет болезненно, но это правильный ответ на эту проблему, и он решит ее для вас раз и навсегда.
Если это не вариант, я могу придумать еще пару вариантов: