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

Я тут одно применение вижу, sg_rules описывать в его вызове

Все

Только в итоге по факту оно особо не нужно, кода меньше не станет

А создавать sg к которым привязана гора правил - не особо хороший подход

Нужно делать их по назначению

Потому что к инстансам ты можешь либо привязать sg,  либо не привязать

И если правил дохрена - рано или поздно у тебя будут либо инстансы где разрешено слишком много

Либо расплодятся sg, где эти правила дублируются

@antonbabenko расскажи пожалуйста основной смысл модуля terraform-aws-modules/security-group. И какие у него могут быть преимущества перед простым декларированием ресурсов( этих самых сек групп) Если не затруднит, конечно.

собственно даже его же пример

module "vote_service_sg" {
  source = "terraform-aws-modules/security-group/aws"

  name        = "user-service"
  description = "Security group for user-service with custom ports open within VPC, and PostgreSQL publicly open"
  vpc_id      = "vpc-12345678"

  ingress_cidr_blocks      = ["10.10.0.0/16"]
  ingress_rules            = ["https-443-tcp"]
  ingress_with_cidr_blocks = [
    {
      from_port   = 8080
      to_port     = 8090
      protocol    = "tcp"
      description = "User-service ports"
      cidr_blocks = "10.10.0.0/16"
    },
    {
      rule        = "postgresql-tcp"
      cidr_blocks = "0.0.0.0/0"
    },
  ]
}

Вешаешь правила постгри и веба в одном месте, замечательно

Ну тут не поспоришь

Было масса преимуществ в 0.11, щаз уже поменьше. Основное это спрятать сложные условия, тк раньше не было возможности писать null. Еще кое что, но я сплю 🛏

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

Спасибо. Может если будет время и желание завтра расскажешь. Лично мне интересно. Другие я думаю тоже не особо против будут

Ну и потеряли смысл модуля, если в нем все sg

модуль - реюзаемая сущность

Библиотека так сказать

А тут просто все частные случаи в него перенесены