AWS VPC Peering против PrivateLink для сетевого доступа к сторонней облачной базе данных

Question

AWS здесь. У меня есть простой сервер приложений, работающий на экземплярах EC2, которые находятся в группе автомасштабирования («целевой»), которая находится под управлением балансировщика нагрузки приложений (ALB). Доменное имя ALB сопоставляется CNAME в DNS с моим поддоменом dev, скажем, dev.myapp.example.com. Следовательно, я могу использовать curl, wget, PostMan и т. д. для отправки HTTP-запросов http://dev.myapp.example.comи получения ответов от него, и эти запросы балансируются по всем экземплярам EC2, которые находятся за ALB (в группе автомасштабирования).

Сервер приложений, работающий на этих экземплярах EC2, должен подключаться к сторонней базе данных как услуге. Мы будем называть эту облачную базу данных " MyCloudDB" для целей этого вопроса.

Когда я вручную подготавливаю экземпляр EC2 и развертываю там свой сервер приложений, для того, чтобы он мог взаимодействовать с MyCloudDB, мне нужно войти в MyCloudDBвеб-консоль и получить доступ к публичному IP-адресу экземпляра EC2 с подсетью /32 (честно говоря, не уверен, почему в подсети /32). Так, например, если AWS назначает публичный IP-адрес для экземпляра, скажем, 1.2.3.4, то мне нужно войти в систему MyCloudDBи добавить запись в список доступа для 1.2.3.4/32. Тогда и только тогда сервер приложений (работающий на новом экземпляре EC2) сможет подключиться к MyCloudDB.

Я пытаюсь выяснить, как сделать эту настройку списка разрешений/доступа совместимой с моим ALB и его группой автомасштабирования. Очевидно, что экземпляры EC2 в группе автомасштабирования являются эфемерными и будут запускаться и останавливаться в зависимости от моих правил автомасштабирования. Поскольку нам нужно, чтобы это было динамично/эластично, мне нужен способ сказать MyCloudDB«доверять» любым запросам, поступающим от экземпляров EC2 за моим ALB. И, очевидно, не ослаблять безопасность настолько, чтобы создавать себе головную боль.

Предлагается MyCloudDB3 типа вариантов доступа к сети:

• Список доступа IP (_то, что я использую в данный момент, исключительно)
• VPC-пиринг
  • это позволяет моему приложению подключаться к VPC с помощью MyCloudDBVPC
• Частная конечная точка
  • позволяет AWS PrivateLink подключаться кMyCloudDB
• API управления REST
  • позволяет мне управлять списком доступа IP, но через RESTful (веб-сервис) API
  • поэтому я мог бы создать хук жизненного цикла экземпляра EC2 для запуска скрипта, который добавляет IP-адрес экземпляра в MyCloudDBсписок доступа IP-адресов с помощью curlили какого-либо другого инструмента

Итак, с точки зрения автоматизации, у меня есть 3 варианта: VPC Peering, Private Endpoint (PrivateLink) или вызовы API. Я могу разобрать плюсы/минусы варианта вызова API, но я с трудом "увидеть лес сквозь деревья" по опции VPC Peering vs PrivateLink.

Аглавный вызоввот: в конечном итоге у меня будут шаблоны CloudFormation, управляющие развертыванием этого ALB в новых (эфемерных) средах. Поэтому мне нужно не только, чтобы это решение для подключения работало для экземпляров EC2, находящихся за ALB, мне нужно, чтобы оно работало с ALB, которые будут предоставлены через CloudFormation.

Учитывая мою ситуацию, контекст и потребности, каковы преимущества/недостатки VPC-пиринга по сравнению с PrivateLink?

Answer 1

Это практически то же самое, для чего был создан PrivateLink. Они фактически помещают сетевой интерфейс в ваш VPC, вы получаете к нему доступ. На их стороне он попадает на NLB, а затем попадает в их базу данных. Это минимальные привилегии, и это то, что я бы сделал.

Пиринг VPC открывает большую часть вашей сети для большей части их сети. Если ваши диапазоны IP-адресов конфликтуют, это становится сложнее. Я не вижу никаких преимуществ в этой ситуации.

Если бы список доступа IP был единственным вариантом, вам бы понадобились статические IP-адреса для вашей группы автомасштабирования. Создание шлюза NAT в каждой подсети и внесение их эластичных IP-адресов в белый список позволило бы этого добиться.