судя по тому, что на этот самый террагрант очень часто ссылаются, видимо, нужно таки изучать

это простой враппер для terraform.
Все что надо будет изучить - как написать terragrunt.hcl

когда выполняешь terragrunt apply - все эти apply/state/plan/init - передаются терраформу

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

смотрел давече бестпрактисис от самого хашикорпа у них в репо, так смутило что последний коммит там 4г назад, думал, млжет что посвежее завезли

best practice формируется из практик использования и накопившейся статистики best решений.
так как терраформ развивается - практики иногда слегка меняются.

Решать организацию кода нужно под свой проект(ы) и инструменты.
стандартный подход - организовывать модули в инфраструктурные модули и дальше к этим модулям обращаться используя свою обвязку, передавая tfvars и параметризуя такие моменты как путь до стейта, динамическое получение переменных и какие-то другие моменты

Коллеги верно пишут ниже. Бестпрактис это хорошо, но еще и на цену надо смотреть. Может у тебя там кубер и будет целесообразно стейджи собрать в один кластер. И развести по стейтам разные компоненты. А может у тебя вместо кубера серверлесс и все можно один к одному собрать.

хорошо, а можно тогда такой вопросик: логически разные куски инфраструктуры, используемые всеми стейджами - например, vpc/subnets/s3 и им подобные должны быть доступны только через data для стейджей?

я вероятно плохо мысль сформулировал

Да, не совсем понятно. Data как data resource нужно использовать в редких случаях, когда ресурс не управляется - просто берется о нем информация каждый раз.
Data remote state приходится использовать чаще - чтобы обратиться к другому как ты называешь “стейджу” - и из его стейта вытащить нужные ID (output).
.
в террагрант можно использовать dependency output - террагрант идет в соседнюю папку например с vpc делает там output и забирает оттуда нужный тебе ID (из стейта)
То есть представим vpc и ec2 - для создания ec2 нужен id подсети - вот чтобы его получить - ты должен взять это из стейта. Это немного лучше чем каждый раз делать data на тот же vpc (под капотом describe vpc api call vs s3 get)

спасибо @VictorOps

Коллеги, здравствуйте!  Помогите, пожалуйста. Как без костылей и кучи файлов решить этот кейс ? https://stackoverflow.com/questions/61451870/terraform-lifecycle-prevent-destroy К сожалению вариантов множество, но какой правильный не ясно, а очевидный не  работает.

Коллеги а как добавить несколько портов в один security rule?
security_rule {
   name                       = "SSH"
   priority                   = 1001
   direction                  = "Inbound"
   access                     = "Allow"
   protocol                   = "Tcp"
   source_port_range          = "*"
   destination_port_range     = "22"
   source_address_prefix      = "*"
   destination_address_prefix = "*"
 }
}
Через запятую?

уже обсуждали.
Не хочешь удаления - выносишь в отдельную сущность (стейт-модуль)
Закрываешь доступ и даешь только доступ на чтение этого стейта.

То есть вся суть lifecycle просто в том, что бы terraform ругался на этот флаг и все?

lifecycle и prevent destroy работает не совсем так как хотелось бы и иногда мешает.

это печально

спасибо!

что за ресурс?