Terraform으로 EKS 배포하기 2. AWS VPC 셋업 추가 작업

2024.04.18 - [개발/인프라] - Terraform AWS VPC 셋업하기 - 1 의 후속편

 

이전 포스팅에서 Terraform VPC 모듈을 이용해 구축하는 방법을 정리했었다.

 

어떻게보면 당연한 이야기지만 VPC 모듈 외의 요소들도 실 서비스에서 많이 사용된다.

 

진짜 다양한 리소스들이 있지만 내가 써본 것들 위주로 정리해볼 예정이다.

 

AWS 엔드포인트(AWS EndPoint)

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 사용할 필요 없이 Virtual Private Cloud(VPC)와 지원되는 서비스 간에 연결할 수 있습니다. 따라서 VPC는 퍼블릭 인터넷에 노출되지 않습니다.

 

어떻게보면 구축하면 효과는 확실하지만 모르고 넘어갈 만한 VPC 구성요소 중 하나이다.

 

VPC 엔드포인트에는 세가지 유형이 존재한다.

 

1. 인터페이스 엔드포인트

2. 게이트웨이 로드 밸런서 엔드포인트

3. 게이트웨이 엔드포인트

 

인터페이스 엔드포인트와, 게이트웨이 로드 밸런서 엔드포인트는 실제로 사용해보진 않았다.

 

AWS에서는 해당 서비스를 아래와 같이 표현했다.

인터페이스 엔드포인트와 게이트웨어 로드 밸런서 엔드포인트는 AWS PrivateLink에 의해 구동하며 ENI(탄력적 네트워크 인터페이스)를 서비스로 가는 트래픽의 진입점으로 사용합니다. 인터페이스 엔드포인트는 일반적으로 이러한 서비스에 연결된 퍼블릭 및 프라이빗 DNS 이름을 사용하여 액세스하며 게이트웨이 엔드포인트와 게이트웨이 로드 밸런서 엔드포인트는 서비스로 향하는 트래픽에 대한 라우팅 테이블의 경로에 대한 대상으로 사용됩니다.

 

음.. 정확히 모르겠으나 외부 인터넷 망을 사용하지 않고도, VPC 엔드포인트 서비스로 구축된 앱에 접근할 수 있도록 처리해주는 것 같다.

 

내가 사용해본 것은 게이트웨이 엔드포인트이다.

 

게이트웨이 엔드포인트는 S3나 DynamoDB와 같은 AWS 서비스 간의 연결을 외부에 노출시키지 않고 프라이빗하게 연결할 수 있게 지원해준다.

서비스가 DynamoDB, S3 등 다양한 AWS 서비스를 사용하고 있다면, 상대적으로 비싼 NAT Gateway를 사용하지 않아도 되기 때문에 반드시 설정해야한다.(같은 VPC 내에서 사용된다면 추가 요금이 발생하지 않는다)

 

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/gateway-endpoints.html

 

공식 문서에 박혀 있는 추가요금이 없다!

 

다음은 Terraform 코드인데, 리소스는 aws_vpc_endpoint이고 service_name에 유의해서 작성해야 한다.

resource "aws_vpc_endpoint" "s3_endpoint" {
  vpc_id          = module.vpc.vpc_id
  route_table_ids = module.vpc.private_route_table_ids
  service_name    = "com.amazonaws.ap-northeast-2.s3"
  tags = {
    Name = "s3-gateway-endpoint"
  }
}

resource "aws_vpc_endpoint" "dynamo_endpoint" {
  vpc_id          = module.vpc.vpc_id
  route_table_ids = module.vpc.private_route_table_ids
  service_name    = "com.amazonaws.ap-northeast-2.dynamodb"
  tags = {
    Name = "s3-dynamodb-endpoint"
  }
}

 

모듈도 있지만, 이번엔 따로 사용하진 않았다.

https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest/submodules/vpc-endpoints

 

마지막으로 비슷한 이름의 엔드포인트 서비스는 전혀 다른 리소스다.

VPC에서 자체 애플리케이션을 생성하고 이를 AWS PrivateLink 지원 서비스(엔드포인트 서비스라고 함)로 구성할 수 있습니다.

 

읽어보면 좋을만한 자료 : AWS VPC S3 endpoint gateway vs interface 차이

 

데이터 베이스 서브넷 그룹(DB Subnet Group)

DB 서브넷 그룹은 데이터베이스에 대해 지정되는 Virtual Private Cloud(VPC)의 서브넷을 정의합니다. DB 서브넷 그룹은 AWS 리전의 두 개 이상의 가용 영역에 서브넷이 있습니다. DB 서브넷 그룹의 서브넷은 네트워크 ACL 및 라우팅 테이블의 구성에 따라 퍼블릭이거나 프라이빗입니다. 보안을 위해 DB 서브넷 그룹의 서브넷은 일반적으로 프라이빗입니다. 데이터베이스 생성 중에 컴퓨팅 리소스와의 연결을 설정하는 경우 RDS는 프라이빗 서브넷이 있는 DB 서브넷 그룹을 생성하며 이 설정은 변경할 수 없습니다.

 

RDS나 Elastic Cache를 생성해본 사람이라면 서브넷 그룹을 한번쯤 봤을 것이다.

 

위 내용을 정리하면 DB나 캐시 같은 자원이 여러 가용 영역에 분산될 수 있도록 하여, 고가용성과 장애 허용성을 제공한다.

 

AWS Console에서 생성할 때는 각각의 DB를 생성할 때 서브넷 그룹을 지정해주어야 하지만 이름이 Subnet이니까 그냥 VPC Terraform에서 정의했다.

 

공개로 접근해야할 DB가 있어서 public subnet group도 하나 만들어줬다.

resource "aws_db_subnet_group" "rds_private" {
  name        = "rds-private"
  description = "rds subnet group - private"
  subnet_ids  = module.vpc.database_subnets
}

resource "aws_db_subnet_group" "rds_public" {
  name        = "rds-public"
  description = "rds subnet group - public"
  subnet_ids  = module.vpc.public_subnets
}

resource "aws_elasticache_subnet_group" "elasticache_private" {
  name        = "elasticache_private"
  description = "elasticache subnet group - private"
  subnet_ids  = module.vpc.database_subnets
}

 

다음은 서브넷 그룹을 Terraform으로 구성하지 않았을 때 서브넷 그룹을 만드는 위치이다.

RDS의 서브넷 그룹

 

ElasticCache의 Subnet 그룹

 

관리형 접두사 목록(aws_ec2_managed_prefix_list)

관리형 접두사 목록은 하나 이상의 CIDR 블록 세트입니다. 접두사 목록을 사용하면 보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지 관리할 수 있습니다. 자주 사용하는 IP 주소에서 접두사 목록을 만들고, 이를 개별적으로 참조하지 않고 보안 그룹 규칙 및 경로의 집합으로 참조할 수 있습니다. 

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/managed-prefix-lists.html

 

관리형 접두사 목록이란 이름이 조금 생소하지만, IP 주소 범위를 효율적으로 관리해서 네트워크 관련 설정을 쉽게 적용할 수 있게 하려는 목적이다.

 

대표적으로 라우팅 테이블, 보안 그룹의 IP 관리에 주로 사용된다.

 

내가 사용할 예시에서는 보안 그룹에 특정 사용자들을 지정하는데 사용한다.

resource "aws_ec2_managed_prefix_list" "office_members" {
  name = "office-members"
  address_family = "IPv4"
  max_entries = 4

  entry {
    description = "office_employee"
    cidr = "..."
  }
  
  entry {
    description = "office_security"
    cidr = "..."
  }
}

 

보안 그룹(Security Group)

말 그대로 보안 그룹이다. 아래는 모듈 예시 코드를 그대로 가져왔다.

https://registry.terraform.io/modules/terraform-aws-modules/security-group/aws/latest

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"
    },
  ]
}

 

다음은 ssh 연결을 위한 sg이다. ingress 규칙으로 관리형 접두사 목록이 추가되었다.

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

  name        = "ssh-sg"
  description = "Allow for members"
  vpc_id      = module.vpc.vpc_id

  ingress_prefix_list_ids = [aws_ec2_managed_prefix_list.ps_members.id]
  tags                    = "ssh_sg"

  number_of_computed_ingress_with_source_security_group_id = 1
  computed_ingress_with_source_security_group_id = [
    {
      rule                     = "ssh-tcp"
      description              = "Allow ssh"
      source_security_group_id = ...
    }
  ]
}

 

마치며

정리하고보니 정식으로 VPC에서 분류가 된 부분들이 아니라

 

그냥 우리 서비스에 필요한 부분들을 대충 정리해놓은 걸 정리한게 되버렸다.

 

그래도 필요한 부분들이 있으면 잘 가져다 쓰면 좋을 것 같다.