Amazon VPC Lattice로 EKS 외부 연결 구성하기

들어가며

https://aws.amazon.com/ko/blogs/security/tag/amazon-vpc-lattice/

 

 

최근 AWS에서 출시한 Amazon VPC Lattice는 서비스 간 통신을 네트워크 레벨이 아닌 애플리케이션 레벨에서 제어할 수 있는 완전관리형 서비스입니다. 기존의 복잡한 피어링, 프록시 설정, 보안 구성 없이도 VPC, 계정, 구성 환경(EKS, EC2, Lambda 등)의 제한 없이 통신 경로를 구성할 수 있다는 점에서 주목받고 있습니다.

 

https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/network/client-server-communication/

Amazon VPC Lattice Client-server Communication - Amazon EKS Blueprints for Terraform

 

위의 내용을 토대로 Amazon VPC Lattice와 AWS Gateway API Controller를 활용하여 Client VPC의 EC2에서 EKS 클러스터 내부의 Pod로 통신이 가능하도록 구성하는 과정을 실습을 진행해보겠습니다.

 

Amazon VPC Lattice

Amazon VPC Lattice 란?

 

​Amazon VPC Lattice는 AWS에서 제공하는 완전관리형 애플리케이션 네트워킹 서비스로, 다양한 서비스와 리소스를 연결하고 보호하며 모니터링하는 데 사용됩니다. 이를 통해 단일 VPC뿐만 아니라 여러 계정이나 VPC에 걸쳐 있는 애플리케이션 구성 요소들을 효율적으로 통합할 수 있습니다.

 

특히 네트워크 액세스, 트래픽 관리, 모니터링에 대한 일관된 정책을 정의하여 EC2 인스턴스, EKS 컨테이너, Lambda 서버리스 함수 등 다양한 컴퓨팅 서비스 간에 간단하고 표준화된 연결 방식을 제공합니다.

 

즉, Amazon VPC Lattice는 다양한 AWS 계정과 VPC에 분산된 애플리케이션 구성 요소들을 안전하고 일관되게 연결/보호/모니터링할 수 있도록 지원하는 완전관리형 애플리케이션 네트워킹 서비스입니다. 

 

Amazon VPC Lattice 특징

중앙 집중형 네트워크 구성

여러 VPC, EC2, 컨테이너, 서버리스 리소스를 하나의 통합 네트워크로 관리할 수 있습니다.

사이드카 프록시 불필요

Envoy 등 별도의 프록시 없이도 서비스 간 통신 및 제어가 가능합니다. (→ 완전관리형 서비스).

 

단순화된 네트워킹

복잡한 라우팅, 피어링, NAT 설정 없이 애플리케이션 간 통신을 쉽게 구성이 가능합니다.

 

보안 통합 (IAM + SigV4)

서비스 간 인증 및 권한 제어를 IAM 정책과 AWS Signature V4 방식으로 쉽게 구현이 가능합니다.

 

관측성 강화 (Observability)

CloudWatch, S3, Kinesis Data Firehose와 통합하여요청 로그 및 트래픽 패턴 모니터링이 가능합니다.

 

Amazon VPC Lattice 구성 요소

 

Amazon VPC Lattice는 Service, Service Network, Auth Policy, Service Directory의 네 가지 핵심 구성 요소로 구성되어있습니다.

 

Service

 

Amazon VPC Lattice에서 service는 독립적으로 배포 가능한 애플리케이션 단위입니다. 특히 account나 VPC내의 EC2 인스턴스, ECS/EKS/Fargate 컨테이너, Lambda 함수에서 실행되며, 각 서비스는 리스너, 규칙, target group으로 구성됩니다.

 

 

 

또한, 고유한 VPC Lattice 도메인 네임을 제공하며, 리스너를 통해 들어오는 연결을 처리하고, 특정 경로나 헤더 값에 기반한 라우팅 규칙 정의하여 EC2, ECS, Lambda 등 다양한 AWS 컴퓨팅 서비스를 target으로 설정이 가능합니다. 그리고 주기적인 상태 확인을 통해 트래픽의 안정성을 보장합니다.

 

Service network

 

Service Network는 VPC Lattice의 핵심 구성 요소로, 여러 service를 논리적으로 그룹화하고 이들 간의 통신을 관리합니다. 특히, 하나 이상의 VPC를 Service Network에 연결하여 해당 네트워크 내의 서비스 간 통신을 가능하게 합니다.

 

또한, 여러 VPC와 service를 단일 네트워크로 통합하고, 계정 / 리전 간 서비스 연결 지원하며, 중앙 집중식 액세스 제어 및 모니터링 제공합니다. 그리고 VPC 연결을 통한 Service Network 내 서비스에 대한 접근을 관리합니다.

 

Auth Policy

 

Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 이를 통해 특정 IAM 보안 주체나 역할이 서비스에 접근할 수 있는지 여부를 세밀하게 제어할 수 있습니다.

 

특히, IAM 기반의 세분화된 접근 제거가 가능하며 서비스 레벨 또는 서비스 네트워크 레벨에서 적용이 가능합니다. 또한, HTTP 메소드, 경로, 헤더 등을 기준으로 조건부 액세스 규칙을 설정하여 AWS 리소스 간의 안전한 통신을 보장합니다.

 

Service Directory

 

Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 대시보드입니다. 이를 통해 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원합니다.

 

특히, 사용 가능한 모든 service에 대해 중앙 집중식 대시보드를 제공하여 이를 통해 service 메타데이터 및 설명을 확인할 수 있으며, 검색 및 필터링 기능을 통해 접근 가능한 서비스에 대한 가시성을 제공합니다.

 

Amazon VPC Lattice 작동 방식

 

 

1. Service Network 생성

서비스 네트워크의 소유자가 네트워크를 생성합니다.

 

2. Service 생성

각각의 Service 소유자가 Service를 만들고, 리스너와 라우팅 규칙을 정의합니다.

 

3. 라우팅 정의

Target Group을 구성하여 어느 인스턴스로 요청을 전달할지 지정합니다.

 

4. Service를 Service Network에 연결

연결된 Service는 서로 탐색 가능해지고, 클라이언트의 요청을 수신할 수 있습니다.

 

5. Resource Gateway 생성

특정 리소스(예: DB)에 대한 접근을 허용하기 위해 게이트웨이를 설정합니다.

 

6. Resource configuration 생성

리소스를 Service Network에 나타내는 resource configuration을 생성하고, 게이트웨이를 지정합니다.

 

7. Resource configuration을 Service Network에 연결

이로 인해 다른 Service 및 클라이언트가 해당 리소스를 탐색하고 통신할 수 있게 됩니다.

 

8. VPC를 Service Network에 연결

연결된 VPC 내의 리소스는 클라이언트 역할을 하며, 다른 Service에 요청이 가능합니다.

이때, VPC 연결은 2가지 방법 중 선택이 가능합니다.

- 직접 VPC를 서비스 네트워크에 연결합니다.
- VPC 엔드포인트(Service Network 타입) 사용합니다.

 

Amazon EKS환경에서 VPC Lattice 사용하기

AWS Gateway API Controller

AWS Gateway API Controller는 오픈소스 프로젝트이며, Amazon의 완전한 지원을 받고있습니다.

 

AWS Gateway API Controller는 Kubernetes Gateway API에서 정의된 사용자 지정 리소스(CRD)를 확장하여, Kubernetes API를 통해 Amazon VPC Lattice 리소스를 생성할 수 있도록 해줍니다.

 

 

 

AWS Gateway API Controller를 통해 Gateway와 Route와 같은 Gateway API 리소스의 생성을 감지하고, 이에 따라 적절한 VPC Lattice 오브젝트를 자동으로 프로비저닝합니다.

 

이를 통해 사용자는 커스텀 코드를 작성하거나 sidecar proxy를 관리할 필요 없이 Kubernetes API를 사용하여 VPC Lattice Service, VPC Lattice Service Network 및 Target Group을 구성할 수 있습니다.

 

Amazon EKS에서 VPC Lattice로 Gateway API를 사용하기 위한 요구사항

Kubernetes Version >= 1.28 

공식 문서에서 v1.28부터 기존 Ingress가 Frozen 상태로 전환되었으며, Gateway API를 통해 구현하는 것을 권장합니다.

 

 

AWS Gateway API Controller 설치

Amazon VPC Lattice 리소스와 Kubernetes API 객체 간 매핑을 처리하는 Controller가 배포되어야 합니다.

 

설치는 아래의 문서를 참고하시면 됩니다.

https://www.gateway-api-controller.eks.aws.dev/dev/guides/deploy/

Controller Installation - AWS Gateway API Controller

 

 

[실습] Simple Client to Server communication

실습 환경 구성

시나리오

 

이 실습에서는 2개의 VPC가 존재하며, 모든 리소스는 Terraform으로 구성됩니다. 

 

첫번째 VPC는 Client VPC로 EC2내에 Client 애플리케이션이 배포되며, 두번째 VPC에는 Amazon EKS Cluster가 배포되어 있고 해당 Cluster에 Server 애플리케이션이 배포되어 있습니다. 두 애플리케이션은 Amazon VPC Lattice를 통해 연결되고, Amazon Route53과 External DNS를 통해 노출된 Service에 대해 DNS를 구성합니다.

 

Terraform 코드 준비

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
cd terraform-aws-eks-blueprints/patterns/vpc-lattice/client-server-communication

 

terraform-aws-eks-blueprints 레포지토리를 clone한 후 /patterns/vpc-lattice/client-server-communication 디렉토리로 이동합니다.

 

# terraform-aws-eks-blueprints/patterns/vpc-lattice/client-server-communication/main.tf
...

locals {
  name   = basename(path.cwd)
  region = "ap-northeast-2" # 이 부분을 수정

  cluster_vpc_cidr = "10.0.0.0/16"
  client_vpc_cidr  = "10.1.0.0/16"
  azs              = slice(data.aws_availability_zones.available.names, 0, 3)

  tags = {
    Blueprint  = local.name
    GithubRepo = "github.com/aws-ia/terraform-aws-eks-blueprints"
  }
}

 

그 후 main.tf 파일에서 locals 리소스에 있는 region을 ap-northeast-2로 수정합니다.

 

terraform init

terraform init

 

 

Terraform 모듈 프로비저닝

대략 10분정도 소요됩니다.

terraform apply -target="module.client_vpc" -auto-approve
terraform apply -target="module.cluster_vpc" -auto-approve
terraform apply -target=aws_route53_zone.primary -auto-approve

terraform apply -target="module.client_sg" -auto-approve
terraform apply -target="module.endpoint_sg" -auto-approve

terraform apply -target="module.client" -auto-approve
terraform apply -target="module.vpc_endpoints" -auto-approve

terraform apply -target="module.eks" -auto-approve
terraform apply -target="module.addons" -auto-approve

 

terraform apply하기 전에 종속성을 갖는 모듈들을 먼저 적용시켜줍니다.

 

terraform apply

대략 3~5분정도 소요됩니다.

terraform apply -auto-approve

 

모듈들을 프로비저닝한 후 나머지 리소스들도 배포합니다.

 

 

kubeconfig 설정

aws eks update-kubeconfig --name client-server-communication --alias client-server-communication --region ap-northeast-2

 

생성된 cluster로 kubeconfig를 변경합니다.

 

 

kubernetes 리소스 확인

kubectl get po -A

 

 

get 명령어로 전체 namespace에 띄어져있는 pod를 조회했을 때, 위와 같이 보이시면 배포가 성공적으로 된 것입니다.

 

프로비저닝 된 인프라 확인

VPC

 

10.0.0.0/16의 CIDR이 할당된 Client-VPC와 10.1.0.0/16의 CIDR가 할당된 Cluster VPC가 배포된 것을 확인하실 수 있습니다.

 

Subnet

Client-VPC의 서브넷은 private subnet 3개로 구성되어 있으며, Cluster-VPC의 서브넷은 public subnet 3개, private subnet 3개로 구성되어 있습니다.

 

 

구성된 워크로드 확인

 

Client-VPC내의 워크로드로 1개의 EC22 인스턴스가 구성되어 있고, Cluster-VPC내의 워크로드로 3개의 EC2 인스턴스(워커 노드)가 구성되어 있습니다.

 

kubectl get node

 

또한, kubectl 명령을 수행하면 EKS cluster의 워커 노드를 확인하실 수 있습니다.

 

VPC Lattice를 통한 Client to Server 통신 테스트

client 서버에 ssh 접속

 

 

client라는 이름의 EC2를 클릭한 후 상단에 [연결] 버튼을 클릭합니다.

 

 

그 후 Session Manager 탭을 클릭 후 연결합니다.

 

 

위와 같이 터미널 화면으로 넘어간다면 접속이 된 것입니다.

 

client 애플리케이션에서 cluster 애플리케이션으로 http 요청 전송

Client-VPC내에 배포되어있는 client 애플리케이션에서 Cluster-VPC에 배포되어있는 Cluster내의 server 애플리케이션으로 http 요청을 전송해보겠습니다.

 

 

위와 같이 한쪽엔 EC2 Session Manager 화면, 다른 한쪽에는 Cluster Terminal 화면을 띄어놓겠습니다.

 

kubectl logs -f deployment/server -n apps --all-containers=true --since=1m

 

Cluster Terminal에 kubectl 명령을 통해 server pod의 애플리케이션 로그를 실시간으로 모니터링합니다.

 

curl -i http://server.example.com

 

client의 터미널에서는 아래 명령을 수행하여 네트워크 통신 테스트를 수행합니다.

 

 

이때 Server Pod에 찍힌 로그를 보면 아래와 같습니다.

2025/04/25 07:31:51 Receiving %!(EXTRA *http.Request=&{GET / HTTP/1.1 1 1 map[Accept:[*/*] User-Agent:[curl/8.3.0] X-Amzn-Lattice-Network:[SourceVpcArn=arn:aws:ec2:ap-northeast-2:346614024082:vpc/vpc-0de344619e457716b] X-Amzn-Lattice-Target:[ServiceArn=arn:aws:vpc-lattice:ap-northeast-2:346614024082:service/svc-021837592ada55a01; ServiceNetworkArn=arn:aws:vpc-lattice:ap-northeast-2:346614024082:servicenetwork/sn-076010fa2bc527a77; TargetGroupArn=arn:aws:vpc-lattice:ap-northeast-2:346614024082:targetgroup/tg-08f3faa516088cc1a] X-Amzn-Source-Vpc:[vpc-0de344619e457716b] X-Forwarded-For:[10.1.14.54]] {} <nil> 0 [] false server.example.com map[] map[] <nil> map[] 169.254.171.196:7312 / <nil> <nil> <nil> 0xc000298780})

 

위 내용은 클라이언트(curl)가 VPC Lattice를 통해 서비스로 HTTP GET 요청을 보냈고, Lattice 서비스 네트워크/서비스/타겟그룹을 거쳐 해당 서버에 도달했으며, 서버는 이 요청을 수신했고 Go의 http.Request 정보를 그대로 출력했다는 내용입니다.

 

client의 터미널에서 아래와 같이 nslookup 명령 수행

nslookup server.example.com

 

nslookup 명령어를 통해 위에서 http 요청을 보냈던 Cluster 내의 server pod의 요청 주소를 조회해보겠습니다.

 

 

 

Amazon VPC Lattice의 네트워크 구성을 통해 server.example.com은 정상적으로 VPC Lattice 내부 경로로 해석되고 있고, Lattice가 사용하는 169.254.171.0/24 대역은 Lattice 프록시 엔드포인트로 예약된 주소인 것을 알 수 있습니다.

 

 

 

Amazon VPC Lattice 확인

 

 

Console에서 VPC 페이지에 접근하신 후 왼쪽 탭에서 [Lattice 서비스]를 클릭하신 수 배포되어있는 service를 선택합니다. 그 후 호스팅 영역과  도메인 이름, 구성을 확인합니다.

 

 

 

위와 같이 VPC Lattice Service의 세부 항목 중, 라우팅 섹션을 클릭하면 아래와 같은 리스너 규칙(Listener rules)과 함께 대상 그룹을 확인할 수 있습니다.

 

 

위의 대상 그룹을 클릭 후 등록된 대상(Registered targets)에서 IP 주소와 포트 번호를 통해 VPC Lattice Service로의 라우팅 대상이 설정되어 있는 것을 확인하실 수 있습니다.

 

kubectl get po -n apps -o wide

 

그 후 kubectl 명령어로 pod의 IP를 조회해보면 아래와 같이 매핑되어있는 IP가 조회되는 것을 확인하실 수 있습니다.

 

 

AWS Gateway API Controller의 동작 체크

VPC Lattice를 통해 EKS 클러스터 내의 server Pod로 HTTP 트래픽을 라우팅하기 위해서는, EKS 클러스터 내에 GatewayClass, Gateway, Route 리소스를 생성해야 합니다.

 

이때 AWS Gateway API Controller는 사용자가 생성한 이 Gateway API 리소스를 감지하고, 이를 기반으로 필요한 VPC Lattice의 Service, Target Group, Listener, Rule, Service Network 등의 리소스를 자동으로 구성합니다.

 

kubectl logs deployment/aws-gateway-api-controller-aws-gateway-controller-chart -n aws-application-networking-system --all-containers=true > lattice.log

 

이를 확인하기 위해 위의 명령어를 통해 AWS Gateway API Controller의 로그를 파일로 저장합니다.

 

 

파일로 저장된 로그 파일을 확인해보면 위와 같이 로그들이 쌓여있는 것을 확인할 수 있습니다. 

 

이 중 중요한 로그만 요약해보면 아래와 같습니다.

• server라는 이름의 service와 my-services라는 이름의 gateway의 생성을 감지하여, reconcile 작업을 수행
• server-apps라는 이름(HTTPRoute의 metadata.name 및 metadata.namespace를 사용)으로 구성된 Route 대상에 라우팅 하기 위해 server.example.com이라는 사용자 지정 도메인 이름을 세팅하고, VPC Lattice Service를 구성
• VPC Lattice Service에 대해 Listener rule을 생성
• HTTPRoute 매니페스트 내용에 맞춰 PathPrefix를 구성
• backendRefs에 대한 대상 그룹 생성
• 대상 그룹에는 Service를 참조하여 라우팅 대상 Pod의 IP 주소 및 Port 번호를 세팅

 

즉, AWS Gateway API Controller가 GatewayClass, Gateway, Route 리소스를 참조하여 VPC Lattice 네트워크 환경을 구성하여 정상적으로 통신이 가능한 환경을 구성했다는 것을 알 수 있습니다.

 

실습 리소스 정리

대략 10~15분정도 소요됩니다.

terraform destroy -target="module.client_vpc" -auto-approve
terraform destroy -target="module.cluster_vpc" -auto-approve
terraform destroy -target=aws_route53_zone.primary -auto-approve

terraform destroy -target="module.client_sg" -auto-approve
terraform destroy -target="module.endpoint_sg" -auto-approve

terraform destroy -target="module.client" -auto-approve
terraform destroy -target="module.vpc_endpoints" -auto-approve

terraform destroy -target="module.eks" -auto-approve
terraform destroy -target="module.addons" -auto-approve

terraform destroy -auto-approve

 

 

 

---

참고

https://docs.aws.amazon.com/ko_kr/vpc-lattice/latest/ug/what-is-vpc-lattice.html

Amazon VPC Lattic란 무엇입니까? - Amazon VPC Lattice

 

https://www.gateway-api-controller.eks.aws.dev/latest/

AWS Gateway API Controller User Guide - AWS Gateway API Controller

 

https://www.gateway-api-controller.eks.aws.dev/dev/guides/deploy/

Controller Installation - AWS Gateway API Controller

 

https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/network/client-server-communication/

Amazon VPC Lattice Client-server Communication - Amazon EKS Blueprints for Terraform