Соединение нескольких VPC с одним и тем же блоком CIDR к общему VPC
В облаке 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 для ведения журналов и запустить отдельные серверы для ведения журналов на каждом из них, но с точки зрения затрат это на самом деле меня не привлекает.
1 ответ
Во-первых, я должен упомянуть: вы сделали очень серьезную ошибку, дублируя подсети в ваших VPC. Даже если существует вероятность того, что вам понадобится маршрутизировать трафик между ними, адресное пространство RFC1918 достаточно велико, чтобы вы могли предоставить каждому VPC уникальную подсеть. Я консультируюсь с рядом компаний по темам AWS и веду электронную таблицу "список основных подсетей" для записи используемых подсетей, когда я выделяю VPC для клиентов, чтобы убедиться, что у меня нет перекрывающихся подсетей.
Очевидный ответ на ваш вопрос заключается в изменении нумерации ваших перекрывающихся VPC. Это будет болезненно, но это правильный ответ на эту проблему, и она решит эту проблему для вас раз и навсегда.
Если это не вариант, я могу подумать о нескольких других вариантах:
- Используйте SQS для своих журналов - отправляйте журналы из VPC вашего приложения в очередь SQS, отмечая идентификатором источника для каждого из VPC вашего приложения, а затем извлекайте журналы из SQS из вашего VPC регистрации. В дополнение к решению указанной проблемы это создает очень высокодоступный буфер между вашими производителями журналов и потребителями журналов. Это защищает вас от потери журналов, если ваша инфраструктура работает с перебоями или если вам нужно удалить ее для технического обслуживания.
- Предоставьте доступ к конечной точке ведения журнала через общедоступный IP-адрес (ELB, EIP и т. Д.), Защитите его так, чтобы только общедоступные IP-адреса ваших серверов приложений могли получить к нему доступ, и чтобы они отправляли свои журналы таким способом. Трафик будет оставаться в сети AWS, и пока он зашифрован и аутентифицирован, это не является проблемой безопасности. Вы будете платить больше за пропускную способность.