надо выгрузку из локального .env замутить и все будет классно)

Это была шутка про разорение ) Нам хватает ssm и там, где можно использовать тф берем его. Если приходится использовать cf, то удобнее secret manager

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

Таки задача Secrets сервиса — хранить секреты и он с ней справляется хорошо. А реализация event-driven схемы работы (чтобы по изменению в одном сервисе, происходило что-то в другом-других) — это уже на вкус-цвет-воплощение каждого, кому такое нужно.

Вообще, конечно, это правильный подход/желание и Амазон даёт инструменты  — CloudWatch events, Lambda, Event Bridge etc. Когда кто-то что-то где-то повторяет слишком часто — делает из такой связки готовый сервис и продаёт.

можно вообще локальный json искать, если есть - загружать, если нет- пропускать

Чето молчат все... Как типично траблшутить что-то что создается очень долго? как узнать на чем тупняк?

попробовать сделать то же через awscli

у меня уже было, что само апи aws тупило

так, это будет нелегко) там модуль коммюнити

пытаюсь запустить aws elasticsearch от cloudposse

а. по ctcl-c ошибку вывалило

ок, уже лучше

попробуй еще TF_LOG=DEBUG

понял. ну тут вопрос был в том, что когд остановил апплай он ошибки вывалил

и это хорошо)

TF_LOG обычно помогает но там надо быть на чеку и поймать нужный вывод

а чо его ловить

делаешь параллелизм в 1 и оно последовательное всё становится

часто бывают ошибки от параллелизма👍
амазон api не любит "насилия" даже если источник их же адресное пространство

сниппет для дебага.
там хорошо видно на каких api тупняк

TF_LOG=TRACE
TF_LOG_PATH=$HOME/.terraform-debug