AEWS 12주차 - Amazon VPC Lattice for Amazon EKS(VPC Lattice)

본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다.  모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

---

kuberenetes networking 변화 과정

 

 

1) 단일 클러스터

가시다님 스터디중

 

 

단일 클러스터 환경에서는 클러스터 내부의 DNS 인 CoreDNS 및 Ingress 리소스를 통해서 내부 서비스 간 통신 및 외부로의 통신을 모두 네이티브하게 구현합니다.

 

보통 2가지로 해당 애플리케이션을 노출합니다. 즉 단순한 내부 통신과 외부 노출 기능에 중점

1. Service

2. ingress

 

 

 

2) 멀티 클러스터

가시다님 스터디중

 

 

점점 발전하면서 VPC 간 / 클러스터 간의 애플리케이션 네트워킹에 대해서 고민하게 되었습니다.

이에 해당 서비스가 어디에 있는지 또는 어떠한 네트워킹이 구성이 되어있는지 인지하기 위해 Service Discovery가 나왔습니다.

 

 

가시다님 스터디중

 

 

Service Discovery란?

**Service Discovery(서비스 디스커버리)**는 분산 시스템에서 동적으로 변하는 서비스들의 위치(IP, 포트 등)를 자동으로 찾아주는 메커니즘입니다. 쿠버네티스에서는 Pod의 IP가 고정되지 않기 때문에, 서비스 간 통신을 위해 안정적인 이름(DNS)과 라우팅 방식이 필요합니다. 이를 위해 K8s는 Service 리소스를 통해 내부 DNS 이름을 제공하고, 서비스 이름만으로 통신이 가능하게 합니다.

 

Servicce Discovery의 패턴에는 여러가지가 있는데 하나씩 사진으로 설명을 드리겠습니다.

 

 

1) 클라이언트 사이드

가시다님 스터디중

 

* 클라이언트가 직접 서비스 레지스트리를 쿼리하여 서비스 위치를 찾는 방식(예: Netflix Eureka, Spring Cloud)

 

 

2) 서버 사이드

가시다님 스터디

 

* 로드 밸런서가 서비스 레지스트리를 쿼리하고 클라이언트 요청을 적절한 서비스로 라우팅

 

 

3) AWS의 여러 VPC간의 네트워킹

가시다님 스터디중

 

* AWS의 경우에는 VPC Peering, PrivateLink, AWS Transit Gateway 등의 다양한 옵션을 통해 각 VPC를 연결

-> 이외에도 Azure, GKS에도 비슷한 솔루션들을 제공하여 연결이 가능합니다.

 

 

왜 Service Mesh가 등장했을까?

마이크로서비스 아키텍처로 전환하면서 서비스 수가 많아지고, 각 서비스 간 통신이 복잡해졌습니다.
이 과정에서 다음과 같은 공통적인 네트워크 요구사항이 생기게 됩니다:

• 요청 실패 시 재시도 또는 타임아웃 처리
• 외부 시스템 장애 전파 방지를 위한 서킷 브레이커
• 서비스 간 인증 및 권한 부여
• 트래픽 가시성 확보 (누가 누구에게 얼마나 요청하는지)

이러한 기능을 각 서비스에 직접 구현하기에는 관리 부담이 크고, 중복 코드가 많아집니다.

그래서 등장한 것이 바로 Service Mesh입니다.

Service Mesh는 통신 로직을 서비스에서 분리해, 공통 기능을 프록시(sidecar) 형태로 제공하며,
네트워크 복잡성과 운영 부담을 줄여줍니다.

 

AWS 공식문서

 

AWS 공식문

 

 

 

 

이러한 방식의 애플리케이션 네트워킹의 한계점

Ingress, Service Discovery, Service Mesh는 Kubernetes 환경에서 주요 네트워킹 구성 방식으로 사용되어 왔지만, 다음과 같은 한계점이 존재합니다.

Ingress의 한계

• HTTP/HTTPS 중심의 L7 트래픽 처리에 최적화되어 있어, gRPC, TCP, UDP 같은 비 L7 프로토콜에 대한 라우팅 지원이 제한적입니다.
• 고급 기능(인증, 속도 제한, 트래픽 분할 등)을 사용하려면 벤더별 사용자 정의 어노테이션을 설정해야 하며, 이는 표준화와 이식성에 제약을 줍니다.
  (예: AWS ALB Ingress Controller, NGINX, HAProxy 등 각각 별도 설정 필요)

Service Mesh의 한계

• 주로 **동-서 트래픽(서비스 간 내부 통신)**에 초점을 맞추어 설계되었기 때문에,
  **북-남 트래픽(외부와의 통신)**에 대한 처리가 제한적입니다.
  • 예: Amazon EKS 환경에서는 외부 접근을 위해 VPC Peering, Transit Gateway 등의 설정이 필요
  • 교차 계정 구성 시 IAM 권한 설정 및 라우팅 정책 관리가 복잡
• 대부분의 구현체가 사이드카 프록시 배포를 요구하며, 멀티 클러스터, 멀티 VPC, 하이브리드 클라우드 환경에서는
  수많은 프록시의 운영 및 네트워크 복잡도 증가라는 부담이 따릅니다.

 

 

---

Gateway API

 

 

Gateway API의 등장

이러한 Kubernetes 네트워킹의 한계를 극복하기 위해 SIG-NETWORK 커뮤니티에서는 Gateway API를 고안하였습니다.
Gateway API는 기존 Ingress와 Service Mesh가 가진 기능적, 구조적 제약을 보완하면서도 역할 분리, 표준화, 확장성을 강조한 설계를 목표로 합니다.

Gateway API의 주요 설계 목표

• 역할 기반 설계
  인프라 관리자, 클러스터 운영자, 애플리케이션 개발자 등 각 역할의 책임과 권한을 명확히 분리하여 보다 유연하고 안정적인 네트워크 구성을 가능하게 합니다.
• 범용성과 유연성
  HTTP, HTTPS는 물론이고 gRPC, TCP, TLS 등 다양한 프로토콜을 기본적으로 지원하며, CRD(Custom Resource Definition) 기반으로 유연한 확장이 가능합니다.
• 표준화된 API
  기존 Ingress처럼 Kubernetes 네이티브 방식으로 동작하면서도, 더 구조적이고 선언적인 API 설계를 기반으로 이식성과 호환성을 고려했습니다.
• 확장성 높은 구조
  멀티 클러스터, 멀티 네임스페이스, VPC 간 통합 환경까지 고려한 설계로, 다양한 규모와 형태의 클라우드 네트워크 아키텍처에 대응할 수 있습니다.

 

 

 

Gateway API의 주요 구성요소

Gateway API는 역할 기반 설계를 중심으로, 인프라 운영자와 애플리케이션 개발자의 책임을 분리하기 위해 계층적 구조를 따릅니다.
아래는 Gateway API를 구성하는 핵심 리소스들입니다.

GatewayClass

• 여러 Gateway 리소스의 공통 구성 템플릿 역할을 합니다.
• 해당 GatewayClass를 구현하는 컨트롤러(예: AWS Lattice Controller, Istio 등) 가 이를 기반으로 게이트웨이를 프로비저닝합니다.
• Gateway 리소스는 반드시 특정 GatewayClass를 참조해야 하며, 이를 통해 어떤 인프라 제공자(controller) 가 해당 게이트웨이를 관리할지를 명시합니다.

🔗 GatewayClass 공식 문서

---

Gateway

• 외부 트래픽을 수신하는 진입점(entry point) 을 정의합니다.
• 클러스터 외부에서 들어오는 트래픽을 수용하고, 내부 서비스로 전달하기 위해 Route 리소스와 연결됩니다.
• 여러 리스너(Listener)를 정의할 수 있으며, 포트, 프로토콜(HTTP, HTTPS, gRPC 등), 인증 방식 등을 지정할 수 있습니다.

🔗 Gateway 공식 문서

---

Routes

• 수신한 트래픽을 어떤 서비스로 보낼지 정의하는 규칙 세트입니다.
• 라우팅 규칙은 URI, 헤더, 호스트 이름 등을 기준으로 정할 수 있으며, 서비스 디스커버리의 핵심 역할을 합니다.
• 다양한 트래픽 유형을 지원하는 여러 Route 리소스가 존재합니다:

Route 타입설명

HTTPRoute	일반적인 HTTP(S) 라우팅
GRPCRoute	gRPC 호출 라우팅
TLSRoute	SNI 기반 TLS 라우팅
TCPRoute	L4 레벨의 TCP 라우팅
UDPRoute	L4 레벨의 UDP 라우팅

각 Route는 특정 Gateway에 바인딩되며, 실제 트래픽 전달 경로를 구성합니다.

 

가시다님 스터디중

 

 

이 계층적 구조를 통해 인프라 관리자는 GatewayClass와 Gateway를 관리하며 전체 인프라의 일관성을 유지하고, 애플리케이션 개발자는 다양한 Route를 통해 자신의 애플리케이션에 대한 세부 라우팅 규칙을 독립적으로 정의할 수 있습니다.

AWS는 이러한 계층적 구조를 Amazon VPC Lattice와 통합하여 제공함으로써, 클라우드 네이티브 환경에서의 네트워킹 요구사항을 효과적으로 충족시킵니다.

 

 

 

---

Amazon VPC Lattice

 

가시다님 스터디중

 

 

Amazon VPC Lattice는 애플리케이션의 서비스 및 리소스를 연결, 보호 및 모니터링하는 데 사용하는 완전관리형 애플리케이션 네트워킹 서비스입니다. VPC Lattice는 단일 Virtual Private Cloud(VPC)와 함께 사용하거나 계정 하나 이상의 여러 VPC에서 사용할 수 있습니다.

 

최신 애플리케이션은 일반적으로 HTTP API, 데이터베이스, DNS 및 IP 기반 엔드포인트 등 다양한 리소스를 기반으로 구성되며, 이러한 구성 요소들은 흔히 마이크로서비스라고 불리는 작은 모듈 단위로 나뉘어 동작합니다.
이러한 애플리케이션의 모듈화와 현대화는 여러 가지 이점을 제공하지만, 동시에 마이크로서비스 간의 네트워킹에 있어 복잡성과 문제가 발생할 수 있습니다.

예를 들어, 마이크로서비스가 서로 다른 VPC나 AWS 계정, 혹은 서로 다른 팀에 의해 관리되는 경우, 이들 간의 연결을 안전하고 효율적으로 구성하는 것이 점점 더 어려워질 수 있습니다.

 

이에 VPC Lattice는 매우 좋은 선택지가 될 수 있습니다.

 

 

Amazon VPC Lattice 주요 구성 요소

가시다님 스터디중

 

 

 

1) Service

 

Service는 특정 작업이나 기능을 수행하는 독립적으로 배포가능한 소프트웨어 단위입니다. 이는 어떤 Amazon Virtual Private Cloud(VPC)나 계정에도 존재할 수 있으며, 다양한 유형의 컴퓨팅 환경(가상머신, 컨테이너, 서버리스 함수)에서 실행할 수 있습니다. 서비스 구성은 다음과 같은 요소로 이루어집니다.

• 리스너 : 리스너에서는 Service가 트래픽을 받아들일 포트와 프로포콜을 정의합니다. 지원되는 프로토콜은 HTTP/1.1, HTTP/2, gRPC이며, TLS가 활성화된 Service의 경우 HTTPS도 포함됩니다.
• 규칙 : 리스너의 기본 구성 요소로, 요청을 대상 그룹의 대상들로 전달합니다. 각 규칙은 우선 순위, 하나 이상의 작업, 그리고 리스너가 클라이언트 요청을 라우팅하는 기준이 되는 하나 이상의 조건으로 구성됩니다.
• 대상 그룹 : 애플리케이션이나 서비스를 실행하는 리소스들의 집합으로, 이를 대상 이라고도 합니다. 대상은 EC2 인스턴스, IP주소, Lambda 함수, 또는 Kubernetes Pod가 될 수 있습니다.

 

2) Service Network

가시다님 스터디중

 

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

 

Service Network의 주요 특징은 다음과 같습니다.

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

 

 

3) Auth Policy

가시다님 스터디중

 

 

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

 

Auth Policy의 주요 기능은 다음과 같습니다.

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

 

 

2) Service Directory

가시다님 스터디중

 

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

 

Service Directory의 핵심 기능은 다음과 같습니다.

• 사용 가능한 모든 서비스의 중앙 집중식 카탈로그 제공
• 서비스 메타데이터 및 설명 관리
• 서비스 검색 및 필터링 기능
• 접근 가능한 서비스에 대한 가시성 제공

 

Amazon VPC Lattice의 장점

• 여러 VPC, EC2 인스턴스, 컨테이너, 서버리스로 구성한 애플리케이션의 네트워크 구성을 중앙 집중화 할 수 있습니다.
• 별도의 사이드카 프록시를 구성할 필요가 없습니다. (+ 완전 관리형 서비스)
• 복잡한 네트워크 구성을 단순화 해서 쉽게 사용할 수 있습니다.
• IAM 및 SigV4를 통해 각 애플리케이션으로의 보안 구성을 손쉽게 적용 할 수 있습니다.
• CloudWatch, S3, Kinesis Data Firehose를 통해 쉽게 로깅, 트래픽 패턴 분석 등을 수행할 수 있습니다.

 

 

사용사례

 

1)  단일 리전의 애플리케이션 간 연결

단일 AWS 리전에서 프로덕션, 개발 및 공유 서비스 애플리케이션 네트워킹을 사용하는 일반적인 엔터프라이즈 아키텍처

 

 

2) 온프레미스에서 AWS에 배포된 애플리케이션으로 접근하는 경우

서비스 네트워크 엔드포인트가 있는 하이브리드 인그레스 VPC를 사용하여 온프레미스에서 Prod, Dev 및 Shared 서비스의 서비스 네트워크 접근하기

 

 

3) 여러 AWS 리전에 걸친 애플리케이션 간의 연결

리전 간 액티브-패시브 서비스 접속 구성

 

 

4)  다중 계정 간 애플리케이션의 연결

다중 계정 간 네트워크 연결 구성

 

 

 

 

---

Gateway API Controller

 

AWS Gateway Controller란?

AWS Gateway Controller는 Kubernetes의 Gateway API 를 AWS 인프라에서 사용할 수 있도록 지원하는 오픈소스 컨트롤러입니다. 즉, Kubernetes 클러스터 내에서 선언적으로 Gateway 리소스를 정의하면, 해당 리소스를 기반으로 AWS Load Balancer나 VPC Lattice 같은 AWS 네트워크 인프라 리소스를 자동으로 생성하고 관리해주는 역할을 합니다.

주요 특징

• 🎯 Gateway API 준수: Kubernetes Gateway API 스펙을 따르며, 표준화된 방법으로 트래픽 라우팅을 설정할 수 있습니다.
• 🔧 AWS 네이티브 통합: Gateway 리소스를 기반으로 ALB(Application Load Balancer) 또는 Amazon VPC Lattice 리소스를 생성하여 자동으로 연동합니다.
• 🔐 IAM 기반 권한 관리: Kubernetes에서 정의한 Route, Gateway 등의 리소스에 대해 IAM 정책 기반의 서비스 접근 제어가 가능합니다.
• 🌐 멀티-프로토콜 지원: HTTP, HTTPS, gRPC와 같은 다양한 L7 프로토콜을 지원하여 복잡한 트래픽 요구사항도 충족할 수 있습니다.
• 🔄 자동화된 인프라 생성 및 업데이트: Kubernetes 리소스를 수정하면 자동으로 AWS 리소스가 업데이트되어 일관된 인프라 운영이 가능합니다.

 

 

Gateway API 구성 요소와 VPC Lattice 오브젝트 간 매핑 관계

가시다님 스터디중

 

 

 

 

 

---

Simple Client to Server communication

 

가시다님 스터디중

 

 

해당 설명

이 패턴에서는 Terraform을 활용하여 클라이언트 애플리케이션이 한 곳에서 실행되고 서버 애플리케이션이 다른 곳에서 실행되는 두 개의 별개의 VPC를 배포합니다. 서버 애플리케이션은 EKS 클러스터 내에 배포되며 두 애플리케이션 간의 연결을 설정하는 Amazon VPC Lattice를 통해 클라이언트 애플리케이션에 노출됩니다. 또한 Amazon Route53 및 External DNS Add-on을 사용하여 노출된 서비스에 대한 사용자 지정 도메인 이름을 구성하는 방법을 보여줍니다.

 

client 인스턴스에서 curl를 하여 EKS app에 대한 로그를 확인해봅니다.

 

이러한 VPC Lattice을 통한 네트워킹 로그를 확인할 수 있습니다.

 

이것이 어떻게 가능할까요? nslookup으로 확인해봅니다.

 

Amazon VPC Lattice로 구성된 엔드포인트가 조회됩니다.

 

이 엔드포인트는 aws 콘솔에서도 확인이 가능합니다.

 

 

그리고 이전 글에서 말씀드린 것과 같이 여러 구성 요소들이 있는데 routing에서 리스너를 확인할 수 있습니다.

 

 

 

 

 

 

Gateway API Controller 동작 확인

가시다님 스터디중

 

Gateway API Controller는 EKS 클러스터 내에 GatewayClass, Gateway, Route에 대한 오브젝트가 추가되면 AWS Gateway API Controller에서 이를 감지하여 조정(reconcile)합니다.

 

설명은 아래와 같습니다.

• 로그를 보면, 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 번호를 세팅합니다.

 

 

---

Multi Cluster secure communication

 

https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/network/cross-cluster-pod-communication/

 

 

해당 설명

이 패턴에서는 Amazon VPC Lattice와 IAM authorization을 사용하여 서로 다른 VPC에 있는 두 EKS 클러스터 간의 안전한 멀티 클러스터 통신 방식을 보여줍니다.

• 이 솔루션에서는 Service Discovery가 어떻게 이루어지는지를 설명하고, VPC Lattice가 겹치는 CIDR을 가진 EKS 클러스터 간 통신을 어떻게 용이하게 하는지 강조합니다.
• 이를 통해 프라이빗 NAT 게이트웨이와 Transit Gateway와 같은 네트워킹 구조가 필요하지 않도록 하는 방법을 소개합니다.
• 클러스터 간 통신을 안전하게 수행하기 위해, 인증서 관리자(ACM)에서 발행하고 AWS Private CA에서 지원하는 TLS 인증서로 보호되는 Amazon Route53 Private Hosted Zone을 사용하여 Amazon VPC Lattice를 통해 설정됩니다.
• 이를 위해 Kyverno를 사용하여 Envoy SigV4 proxy 컨테이너를 Pod에 추가하고, 여기에 PCA를 주입합니다.

 

 

https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/network/cross-cluster-pod-communication/

Cross VPC and EKS clusters secure Communication - Amazon EKS Blueprints for Terraform

 

여러 VPC 및 Cluster 사이에서도 VPC Lattice를 사용하면 더욱 효과적인 구성이 될 것 같습니다.