AWS VP C Lambda Networking Issue - PullRequest
       4

AWS VP C Lambda Networking Issue

1 голос
/ 25 марта 2020

Итак, у меня очень запутанная проблема, которую я не знаю, как решить. Моя настройка - API Gateway -> Lambda -> IoT Core. Я установил код, и он отлично работает из моей IDE. Я развернул его в AWS, и мое соединение в AWS истекло.

Lambda находится в одном su bnet, а su bnet имеет маршрут по умолчанию к IGW. Я выполнил тест, и функция Lambda может разрешить IP-адрес моей конечной точки IoT на опубликованный c IP (54.xxx). Но время ожидания метода connect () истекло. Моя группа безопасности для функции Lambda настроена так, чтобы разрешить все входящие / исходящие.

Что мне не хватает? Почему я не могу получить доступ к IoT Core из VP C с настроенным IGW, который, кажется, работает. Любое направление будет с благодарностью.

ОБНОВЛЕНИЕ

После игры со многими разными вещами я не могу определить, что именно я испортил с моей конфигурацией. Но после принятого ответа я получил следующую настройку, которая, кажется, работает для того, что мне нужно.

  • su bnet -1 10.14.10.0/24 (auto-assign-public = false)
    • локальный маршрут (10.14.0.0/16) и маршрут по умолчанию = nat-gateway
  • su bnet -2 10.14.20.0/24 (автоматическое назначение- public = false)
    • локальный маршрут (10.14.0.0/16) и маршрут по умолчанию = nat-gateway
  • su bnet -3 10.14.30.0/24 ( auto-assign-public = false)
    • локальный маршрут (10.14.0.0/16) и маршрут по умолчанию = nat-gateway
  • su bnet -4 10.14. 40.0 / 24 (auto-assign-public = false)
    • локальный маршрут (10.14.0.0/16) и маршрут по умолчанию = nat-gateway
  • su bnet -5 10.14.200.0/24 (auto-assign-public = true)
    • локальный маршрут (10.14.0.0/16) и маршрут по умолчанию = igw
  • nat- шлюз
    • в су bnet -5

Я не знаю, то ли это, что я имел в виду, но это то, что я был находясь в поиске. Серия подсетей, которые не являются общедоступными, но имеют соединение rnet для доступа к другим AWS службам. Таким образом, мои лямбда-ресурсы, ECS и т. Д. c могут сидеть конфиденциально и получать доступ к тому, что им нужно.

Спасибо всем за информацию.

Ответы [ 2 ]

1 голос
/ 25 марта 2020

Не следует развертывать функцию Lambda в общедоступной c su bnet (это su bnet с маршрутом по умолчанию к IGW). Это не сработает так, как вы хотите. Функция Lambda не имеет и не может иметь публичный c IP, поэтому не может маршрутизировать к inte rnet через IGW.

Если лямбда должна быть в VP C, то переместите его к частному su bnet и убедитесь, что у частного su bnet есть маршрут по умолчанию к NAT (или шлюзу NAT) в publi c su bnet. Или полностью разверните функцию Lambda вне VP C, если это возможно.

Более подробная информация по адресу:

0 голосов
/ 25 марта 2020

Когда вы говорите: «Я провел тест, и функция Lambda может разрешить IP-адрес моей конечной точки IoT в общедоступный c IP (54.xxx)». Вы имеете в виду разрешение DNS или вы проверили это с помощью фактический сетевой трафик c.

В любом случае вы можете включить VP C Flow Logs для вашего VP C и попробовать еще раз. Журнал потока определит, блокируют ли SG или NACL ваш трафик c.

Помните также, что лямбды не могут существовать в общедоступных c su bnet, они должны находиться в частных подсетях и использовать NAT GW в подсетях publi c для подключения к inte rnet.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...