если при такой схеме просто убрать ноды из паблика в приват, ничего же не сломается? балансеру же пофиг куда внутри VPC трафик гнать?

Не сломается, обычно ноды и есть в приватных подсетях по бестпрактисам

Но цена nat gw часто вынуждает отступить тут от бестпрактисов(

Воот. У нас один и так есть, жрет не то что бы много, но прилично.
Поэтому из двух зол(еще один нат или добавить трафика на тот что есть), я пока склоняюсь ко второму

Коллеги, прошу помощи - есть bash скрипт, который циклически  создаёт security groups в разных vpc. Если такая группа уже существует, то aws cli даёт ошибку, но код ошибки = 0. Как поймать такую ошибку башем и завершить цикл?

grep на вывод?

или вывод в переменную и ее парсить?

други, почему запросы в с3 по ключу могут быть не видны в клаудтрейле, хотя бы авторизация в иам, хотя галка стоит логировать все вызовы АПИ, но имени ключа 0 событий, хотя сам ИАМ пишет что ключ недавно ходил в с3

по хорошему бы делать проверку - describe-security-groups и по условию создавать группу или обновлять рулы.

в настройках S3 бакета включен Object level logging?

Всем привет ) Есть у меня postgres (но можно и другое), есть лямбды, есть api gateway. Лямбда принимает запрос, читает его тело, что-то делает и дальше уже по обстоятельствам решает, что куда.
Я хочу логировать действия лямбды не только в clouwatch, но и в БД (pg в моем случае). Мол, если body не верное - сделать запись в БД, если там всё ок, сделать запись в бд. Идея в том, чтоб я мог в любое время получить логи из бд, находясь на фронтенде. Как это лучше делать? Тупо писать в новую таблицу в постгресе, или что-то другое?

И тогда юзер сможет выполнить запрос и увидеть, как обстоят дела у той или иной лямбды) Что она сделала, и как всё прошло. Что было на входе, почему не пошло дальше?)

Да, плюс RDS proxy, лямбды не любят долгих коннектов.

Чем это отличается от логов?

Тем, что я не знаю, как мне доставать данные из cloudwatch. Плюс я хочу фильтровать по определенным ID, timestamp

Как и у любой бд, у cloudwatch есть апи и способы через апи доставать данные. Эти данные важны в длительной перспективе? Если да то я бы взял другую бд да. Если нет то можно обойтись cloudwatch.

На данный момент хранить их буду 1 месяц )

База для логов.. это как-то не совсем правильно. Логи штука временная (ну если вы не храните их 7 лет для комплайнсов), поэтому правильнее было бы стучать по API к cloudwatch и доставать нужные логи.
А еще есть Cloudwatch Insights, у которого тоже есть API и в котором можно фильтровать по содержимому логов.

Удваиваю.

Спасибо, ушел читать. А на вскидку, если будет требование хранить логи 7 лет, что лучше использовать в этом случае?