У меня есть бессерверное. net ядро веб-API-лямбда-приложения, развернутое на AWS.
У меня это сидит внутри VP C, когда я получаю доступ к сервису ElasticSearch внутри того же VP C .
У меня есть два API-сервиса, которые подключаются к сервису Elasticsearch.
После периода неиспользования (4 часа, 6 часов, 18 часов - я точно не уверен, но кажется случайным ), функция перестает отвечать, и я получаю ошибку тайм-аута шлюза 504: «Не удается найти конечную точку»
Я где-то читал, что если «простаивать» слишком долго, ENI возвращается в систему AWS и что повторное включение лямбды должно запустить его.
Я не могу "разбудить" функцию, вызвав ее, так как она истекает из-за указанной выше ошибки (я также увеличил время ожидания по умолчанию) ).
Вот кикер - если я внесу какие-либо изменения в указанную c лямбда-функцию и сохраню эти изменения (сюда входит нечто такое простое, как изменение значения тайм-аута) - Мой AP Я звоню (ОБА из них, несмотря на то, что разные лямбды) снова начинают работать, как будто они «вернулись» обратно. Очевидно, изменения делают это, но почему?
Очевидно, что я не хочу тайм-аутов в производственной среде независимо от того, сколько ИЛИ как мало используется лямбда-вызов или вызов API.
Мне нужно пуленепробиваемое решение для этого. Конечно, это проблема конфигурации некоторого описания, но я просто не уверен, где искать.
Я изменил таблицы маршрутов, публичные / частные подсети, блоки CIDR, создал шлюзы inte rnet, NAT et c. для VP C. Это все работает, но эти две лямбды, которым требуется доступ VP C, продолжают как-то "засыпать".