AWS - NAT между несколькими VPC
В AWS у меня несколько VPC. В каждом VPC у меня есть экземпляр EC2, на котором запущен сервер. На данный момент у каждого EC2 есть эластичный IP-адрес, потому что мои серверы выделены для IoT, а нашим подключенным объектам нужен выделенный IP-адрес, они не могут использовать DNS. И, конечно же, каждый VPC предназначен для разных клиентов.
Вот очень простая схема архитектуры:
Конечно, у меня также есть вся выделенная сеть для доступа к серверу, то есть группы безопасности, интернет-шлюз и т. Д. Но всегда одна для выделенного VPC.
Но в AWS существует ограничение в 5 эластичных IP-адресов на регион. Из-за этого мне нужно найти решение, чтобы не использовать эластичный IP-адрес для каждого экземпляра.
Какое решение для этого я могу использовать на AWS? Самый простой способ - создать NAT, используя один единственный EIP и перенаправляя на правильный сервер, используя порт. Что-то такое:
Но проблема в том, что я использую другой VPC.
Как это сделать между разными VPC?
(Я упоминаю NAT, потому что это решение, которое я знаю за пределами "мира aws", но могут быть и другие решения, такие как NAT Gateway, NAT Instance, Transit Gateway, Internet Gateway и т. Д. Я немного потерялся)
Спасибо
Один VPC на одного клиента не сможет долго масштабироваться, если вы добьетесь успеха. Это мягкий лимит (т.е. он может быть увеличен) в 5 VPC на регион для каждой учетной записи, я не знаю, насколько AWS повысит его.
Существует мягкий предел в 5 эластичных IP-адресов для каждой учетной записи. Я предполагаю, что AWS захочет поднять этот вопрос, но IPv4 - пугающий ресурс, поэтому я сомневаюсь, что они дадут вам их огромное количество. Конечно, каждый экземпляр получает общедоступный IP-адрес, но он меняется, если вы останавливаете / запускаете экземпляр.
NAT предназначен для исходящего, а не входящего трафика. Не думаю, что это тебе поможет. Если вы можете использовать один IP-адрес с каждым клиентом на указанном порту, проксируемый через центральную учетную запись, это будет эффективно и будет масштабироваться. Однако у вас могут возникнуть проблемы с брандмауэрами, и это означает, что вы можете платить за трафик дважды - один раз на прокси, а затем один раз на VPC / учетную запись, которая его обслуживает.
Транзитный шлюз
Транзитный шлюз обеспечивает подключение практически к любому количеству AWS VPC в одной или нескольких учетных записях. Это проще, чем пиринг VPC, поскольку это архитектура концентратора и луча, а не точка-точка.
Если вы не хотите, чтобы ваши учетные записи передавались друг другу, а только к центральной учетной записи, вы можете установить брандмауэры для изоляции учетной записи. Я использую для этого NACL, резервируя группы безопасности для многоуровневого хранения (веб, приложения, базы данных и т. Д.). Я в основном автоматизировал создание NACL с помощью CloudFormation для моего текущего проекта - мы развертываем практически все в виде кода.
Плата за транзитный шлюз за подключение VPC. По памяти это немного дороже, чем пиринг VPC, но пиринг VPC может взимать плату как за отправленные, так и за полученные данные, что сделало бы его похожим. Я не рассматривал это подробно, потому что предприятия не особо заботятся о стоимости полосы пропускания в разумных пределах.
Транзитный шлюз не может выполнить ваше требование использовать один эластичный IP-адрес для доставки в несколько VPC. Вероятно, это должно быть сделано чем-то вроде Nginx, запущенного в экземпляре, хотя, возможно, вы можете посмотреть на ALB / NLB для этого. На данный момент у меня нет времени полностью рассмотреть ваши требования и создать решение.
Хорошо Решение
IPv6 имеет очень большое количество адресов. Если ваши клиенты могут поддерживать IPv6, это решение будет масштабироваться. Вам не нужны эластичные IP-адреса для IPv6, вы выделяете диапазон IPv6 для своего VPC, а его диапазон - ваш без NAT.
Вы все равно столкнетесь с ограничением количества VPC на учетную запись с этой опцией.
Лучшее решение
Архитектуру с несколькими учетными записями с одной учетной записью на каждого клиента было бы легче масштабировать и избежать ограничений. Используйте AWS Control Tower для управления учетными записями. Transit Gateway может организовать сеть между учетными записями за вас, но будьте осторожны с затратами.
Мультиаккаунтом управлять не особо сложно. Вы создаете организацию AWS, и в нее входит ваша платежная информация - кредитная карта или вы можете выставлять ежемесячные счета с помощью AWS. Вы можете создавать новые учетные записи либо в AWS Organizations (хорошо), либо, если вы используете Control Tower, у нее есть фабрика учетных записей. Преимущество Control Tower заключается в том, что она предлагает вам все виды передовой безопасности. Этот недостаток заключается в том, что для создания новой учетной записи AWS требуется час, поскольку для каждой новой учетной записи необходимо развернуть все элементы управления.
Лучшее решение
Я бы посоветовал лучше всего написать приложение для обслуживания нескольких клиентов через одну учетную запись / VPC / IP, если ваши клиенты могут это сделать. Используйте какую-либо службу аутентификации / авторизации, чтобы гарантировать, что запросы связаны с правильным клиентом.
Ты можешь использовать Пиринг VPC между VPC с NLB во внешнем VPC и другими VPC.
Пиринговое соединение VPC - это сетевое соединение между двумя VPC, которое позволяет маршрутизировать трафик между ними с помощью частных адресов IPv4 или IPv6. Экземпляры в любом VPC могут взаимодействовать друг с другом, как если бы они находились в одной сети. Вы можете создать пиринговое соединение VPC между своими собственными VPC или с VPC в другой учетной записи AWS. VPC могут находиться в разных регионах (также называемых межрегиональным пиринговым соединением VPC).