クラスター間通信用の AWS Elasticache セキュリティグループ

クラスター間通信用の AWS Elasticache セキュリティグループ

これをテストするためのセットアップは実際にはありませんが、1 つ以上のノードを持つ elasticache redis クラスターを作成する場合、クラスター自体を壊さずに非常に安全であるためには、セキュリティ グループはどのようにする必要がありますか?

ポート 6379 で自分自身と Kubernetes ノードからの受信を許可し、自分自身と Kubernetes へのすべての送信を許可するセキュリティ グループを作成したとします。

たとえば次のようになります:

resource "aws_security_group" "tools_elasticache_default" {
  name        = "tools-elasticache-default"
  description = "Allow traffic from tools cluster to elasticache instance"
  vpc_id      = module.tools_cluster.vpc_id

  ingress {
    description = "Incomming redis traffic"
    from_port   = 6379
    to_port     = 6379
    protocol    = "tcp"
    self        = "true"
    security_groups = [for x in module.tools_cluster.node_security_groups : x.id ]
  }

  egress {
    description = "Outgoing redis traffic"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    self        = "true"
    security_groups = [for x in module.tools_cluster.node_security_groups : x.id ]
  }

  tags = merge(var.tags, {
    "shared" = "true"
  })
}

これは、内部的にはec2であり、セキュリティグループはインスタンスごとにあるため、Elasticacheクラスターを壊してしまうのでしょうか?上記のようにRedisクラスターの通信ポートを明示的に指定していないため、ここ?

私の理解では、1 つの Redis ノードがポート 3333 で別のノードに送信できるが、他のクラスター参加者にそのノードに対するイングレス ルールがないため、その要求がドロップされるため、クラスターは壊れているはずです。

それとも、AWS は暗黙的にこれらのルールを管理し、クラスター間通信用のポートが常に許可されるようにしているのでしょうか?

ご協力いただければ幸いです。ありがとうございます!

答え1

それとも、AWS は暗黙的にこれらのルールを管理し、クラスター内通信用のポートが常に許可されるようにしているのでしょうか?

はい。

関連情報