AWS 상의 멀티 프로바이더 생성형 AI 게이트웨이를 위한 가이드

• 프로젝트 개요 (Project Overview)
• 아키텍처 (Architecture)
• 이 가이드에 사용된 AWS 서비스 (AWS Services in this Guidance)
• 배포 옵션 (Distribution Options)
• 비용 (Cost)
• 보안 (Security)
• 배포 방법 (How to Deploy)
• 오픈 소스 라이브러리 (Open Source Library)
• 고지 사항 (Notices)

이 프로젝트는 AWS 상의 Amazon Elastic Container Service (ECS) 및 Elastic Kubernetes Service (EKS) 플랫폼에 LiteLLM을 간단하게 배포할 수 있는 Terraform 구성을 제공합니다. 대부분의 사용자가 LiteLLM을 빠르게 시작할 수 있도록 기본 설정이 미리 구성되어 있는 것을 목표로 합니다.

또한 LiteLLM 상단에 추가적인 기능들을 제공합니다. 예를 들어, 기본 OpenAI 인터페이스 대신 AWS Bedrock 인터페이스를 제공하며, AWS Bedrock Managed Prompts, 채팅 기록 (Chat History), 그리고 Okta OAuth 2.0 JWT 토큰 인증 (JWT Token Auth) 지원 등을 포함합니다.

LiteLLM이 생소하시다면, LiteLLM은 모든 LLM 프로바이더에 접근할 수 있는 일관된 인터페이스를 제공하므로 다양한 모델을 테스트하기 위해 코드를 수정할 필요가 없습니다. 또한 사용자, 팀, API 키 수준에서 회사 전체의 LLM 사용량을 중앙에서 관리하고 추적할 수 있게 해줍니다. 예산 및 속도 제한 (Rate limits)을 설정할 수 있고, 특정 모델에 대한 접근을 제한하며, 여러 프로바이더에 걸쳐 재시도/폴백 라우팅 (Retry/fallback routing) 로직을 설정할 수 있습니다. 프롬프트 캐싱 (Prompt caching)과 같은 비용 절감 조치도 제공합니다. 모든 LLM 프로바이더에 대해 AWS Bedrock Guardrails를 지원하는 것과 같은 보안 기능도 제공합니다. 마지막으로, 관리자가 사용자 및 팀을 구성할 수 있고, 사용자가 자신의 API 키를 생성하여 채팅 인터페이스에서 다양한 LLM을 테스트해 볼 수 있는 UI를 제공합니다.

• 테넌트(Tenants) 및 클라이언트 애플리케이션은 Amazon Route 53 URL 엔드포인트 또는 Amazon CloudFront 배포를 통해 LiteLLM 게이트웨이 프록시 API에 액세스하며, 이는 AWS Web Application Firewall (WAF)를 사용하여 일반적인 웹 취약점 공격 및 봇으로부터 보호됩니다.
• AWS WAF는 요청을 Application Load Balancer (ALB)로 전달하여, 들어오는 애플리케이션 트래픽을 생성형 AI 게이트웨이 컨테이너가 실행 중인 Amazon Elastic Container Service (ECS) 태스크 또는 Amazon Elastic Kubernetes Service (EKS) 포드(pod)로 자동 분산합니다. TLS/SSL 암호화는 AWS Certificate Manager (ACM)에서 발급한 인증서를 사용하여 트래픽을 보호합니다.
• API/미들웨어 및 LiteLLM 애플리케이션을 위한 컨테이너 이미지는 가이드 배포 중에 빌드되어 Amazon Elastic Container Registry (ECR)로 푸시됩니다. 이 이미지들은 AWS Fargate 기반의 Amazon ECS 또는 해당 애플리케이션을 각각 ECS 태스크나 EKS 포드에서 컨테이너로 실행하는 Amazon EKS 클러스터에 배포하는 데 사용됩니다. LiteLLM은 LLM 제공업체와의 구성 및 상호작용을 위한 통합 애플리케이션 인터페이스를 제공합니다. API/미들웨어는 Amazon Bedrock과 네이티브하게 통합되어 LiteLLM 오픈 소스 프로젝트에서 지원하지 않는 기능을 활성화합니다.
• Amazon Bedrock 및 Amazon Nova에 호스팅된 모델은 통합 API를 통해 AI 게이트웨이를 강화하고 클라이언트에 대한 추가 제어 기능을 제공하기 위해 모델 액세스, 가드레일(guardrails), 프롬프트 캐싱(prompt caching) 및 라우팅(routing)을 제공합니다. 모델 액세스는 Amazon SageMaker AI에 배포된 모델에 대해서도 가능합니다. 필요한 Amazon Bedrock 모델에 대한 액세스는 적절히 구성되어야 합니다.
• 외부 모델 제공업체(OpenAI, Anthropic 또는 Vertex AI 등)는 LiteLLM의 통합 애플리케이션 인터페이스를 통해 추가적인 모델 액세스를 활성화할 수 있도록 LiteLLM 관리 UI(Admin UI)를 사용하여 구성됩니다. LiteLLM API를 사용하여 제3자 제공업체의 기존 구성을 게이트웨이에 통합할 수 있습니다.
• LiteLLM은 Amazon ElastiCache (Redis OSS), Amazon Relational Database Service (RDS) 및 AWS Secrets Manager 서비스와 통합됩니다.

Amazon ElastiCache는 애플리케이션 설정의 멀티 테넌트 (multi-tenant) 분산 및 프롬프트 캐싱 (prompt caching)을 가능하게 합니다. Amazon RDS는 LiteLLM에서 제공하는 가상 API 키 및 기타 구성 설정의 영속성 (persistence)을 지원합니다. Secrets Manager는 외부 모델 제공업체의 자격 증명 및 기타 민감한 설정을 안전하게 저장합니다.

• LiteLLM 및 API/미들웨어 스토어 애플리케이션은 문제 해결 및 액세스 분석을 위해 전용 Amazon S3 스토리지 버킷으로 로그를 전송합니다.

버전 1.1.0부터 이 솔루션은 다양한 보안 및 액세스 요구 사항을 충족하기 위해 유연한 배포 시나리오를 지원합니다. 특정 요구 사항에 따라 LiteLLM 게이트웨이에 액세스하는 방식을 맞춤 설정할 수 있습니다.

USE_CLOUDFRONT="true"
USE_ROUTE53="false"
PUBLIC_LOAD_BALANCER="true"

이 시나리오를 선택하는 이유:

• CloudFront의 에지 로케이션 (edge locations)을 통한 저지연 액세스로 글로벌 성능 확보
• AWS Shield Standard DDoS 보호를 통한 보안 강화
• CloudFront의 기본 인증서를 사용한 간소화된 HTTPS 관리
• 글로벌 사용자 기반을 가진 공개용 AI 서비스에 최적의 옵션

보안:

• CloudFront IP 필터링을 통해 ALB 액세스를 CloudFront 트래픽으로만 제한
• CloudFront 레벨에서 WAF 적용 가능 (글로벌 WAF 필요)
• CloudFront의 기본 인증서를 사용하여 더 간단한 인증서 관리

액세스 URL: https://d1234abcdef.cloudfront.net

USE_CLOUDFRONT="true"
USE_ROUTE53="true"
PUBLIC_LOAD_BALANCER="true"
...

이 시나리오를 선택하는 이유:

• 커스텀 도메인을 통한 브랜드 일관성 유지
• 전문적인 외관 및 SEO(검색 엔진 최적화) 이점
• 시나리오 1과 동일한 글로벌 성능 및 보안

추가 요구 사항:

• 도메인을 위한 Route53 호스팅 영역 (hosted zone)
• 도메인을 위한 ACM 인증서 (CloudFront를 위해 us-east-1에 있어야 함)

액세스 URL: https://genai.example.com

USE_CLOUDFRONT="false"
USE_ROUTE53="true"
PUBLIC_LOAD_BALANCER="true"
...

이 시나리오를 선택하는 이유:

• 단일 리전 배포 시 더 낮은 지연 시간 (Lower latency)
• CloudFront 없는 단순화된 아키텍처
• Regional WAF (지역 WAF)를 ALB에 직접 적용 가능
• CloudFront 배포 제거를 통한 비용 절감

보안 고려 사항 (Security considerations):

• CloudFront 계층이 없으므로 ALB가 인터넷에 직접 노출됨
• WAF 보호가 특히 중요해짐
• ALB 보안 그룹 (Security group)이 모든 IP (0.0.0.0/0)로부터의 트래픽을 허용함

액세스 URL (Access URL): https://genai.example.com

(ALB를 직접 가리킴)

USE_CLOUDFRONT="false"
USE_ROUTE53="true"
PUBLIC_LOAD_BALANCER="false"
...

이 시나리오를 선택하는 이유:

• 내부 기업용 애플리케이션을 위한 최대 보안
• 퍼블릭 인터넷으로부터의 완전한 격리
• 민감하거나 독점적인 데이터를 처리하는 데 적합

액세스 방법 (Access methods):

• VPC로의 VPN 연결
• AWS Direct Connect
• 기업 네트워크와의 VPC 피어링 (VPC peering)
• Transit Gateway

보안 고려 사항 (Security considerations):

• 퍼블릭 인터넷 접속 불가능
• ALB 보안 그룹 (Security group)이 프라이빗 서브넷 CIDR로부터의 트래픽만 허용함
• 액세스를 위해 VPC에 대한 네트워크 연결이 필요함

액세스 URL (Access URL): https://genai.example.internal

(VPC 또는 연결된 네트워크 내에서만 해석됨)

파라미터 (Parameter)	기본값 (Default)	설명 (Description)
USE_CLOUDFRONT	true	글로벌 전송을 위한 CloudFront 배포 활성화
USE_ROUTE53	false	커스텀 도메인 지원을 위한 Route53 활성화
PUBLIC_LOAD_BALANCER	true	퍼블릭 서브넷에 ALB 배포
CLOUDFRONT_PRICE_CLASS	PriceClass_100	CloudFront 가격 클래스 (100/200/All)
HOSTED_ZONE_NAME	""	커스텀 도메인을 위한 Route53 호스팅 영역 (Hosted zone) 이름
RECORD_NAME	""	Route53에 생성할 레코드 (서브도메인)
CERTIFICATE_ARN	""	커스텀 도메인을 위한 ACM 인증서의 ARN

각 배포 시나리오는 서로 다른 보안 특성을 제공합니다:

• CloudFront와 퍼블릭 ALB 조합 (기본값 (Default)):

  • ALB가 퍼블릭 서브넷 (Public Subnet)에 위치하지만, 커스텀 헤더 인증 (Custom Header Authentication)으로 보호됩니다.
  • 적절한 CloudFront 비밀 헤더 (Secret Header)를 포함한 트래픽만 허용됩니다 (헬스 체크 (Health Check) 경로 제외).
  • CloudFront는 AWS Shield Standard DDoS 보호를 통해 추가적인 보안 계층을 제공합니다.
  • 퍼블릭 서비스에 대해 접근성과 보안 사이의 최적의 균형을 제공합니다.

• ALB 직접 액세스 (CloudFront 미사용):

  • 인터넷에서 ALB에 직접 접근할 수 있습니다.
  • 이 배포 방식에서는 WAF (Web Application Firewall) 보호가 필수적입니다.
  • 가능하다면 IP 기반 제한 (IP-based Restrictions)을 고려하십시오.

• 프라이빗 VPC 배포 (Private VPC Deployment):

  • 가장 높은 보안 수준을 제공하며, 인터넷에 직접 노출되지 않습니다.
  • 액세스를 위해 VPN 또는 Direct Connect가 필요합니다.
  • 민감한 워크로드 (Workload) 또는 내부 서비스를 위해 고려하십시오.

모든 시나리오는 다음과 같은 보안 모범 사례 (Security Best Practices)를 유지합니다:

• TLS 1.2 이상을 사용하는 모든 통신에 대한 HTTPS 적용
• 최소 권한 원칙 (Principle of Least Privilege)을 적용한 보안 그룹 (Security Groups)
• 일반적인 공격에 대한 WAF 보호
• 적절한 권한을 가진 IAM 역할 (IAM Roles)

CloudFront를 사용할 때는 다음과 같은 커스텀 보안 메커니즘이 구현됩니다:

• CloudFront는 ALB로 전송되는 모든 요청에 비밀 헤더 (X-CloudFront-Secret)를 추가합니다.
• ALB는 액세스를 허용하기 전에 이 헤더를 검증하는 리스너 규칙 (Listener Rules)을 가집니다.
• CloudFront 오리진 헬스 체크 (Origin Health Checks)를 허용하기 위해 헬스 체크 경로는 특별히 제외됩니다.
• 이 비밀 값은 배포 간에 안정적으로 유지됩니다 (명시적으로 변경하지 않는 한 변경되지 않음).

이를 통해 누군가 ALB의 도메인 이름을 알아내더라도 ALB에 대한 직접적인 액세스를 방어하는 강력한 방어 체계를 제공합니다. 비밀 값은 생성 후 Terraform 출력 (Outputs)에서 단 한 번만 표시되며, 민감한 정보 (Sensitive)로 표시됩니다.

AWS 서비스	역할 (Role)	설명
Amazon Bedrock	핵심 서비스 (Core Service)	여러 파운데이션 모델 (Foundational Models)에 대한 단일 API 액세스를 관리합니다
Amazon SageMaker AI	핵심 서비스 (Core Service)	Amazon SageMaker AI에 배포된 모든 파운데이션 모델 (Foundational Model)에 대한 액세스를 관리합니다
...

참고 (NOTE) 가이드에 따른 배포 시, Amazon ECS 또는 EKS 컨테이너 오케스트레이션 플랫폼 (Container Orchestration Platform) 중 하나를 사용할 수 있으며, 두 가지를 동시에 사용할 수는 없습니다.

이 가이드를 AWS 상에 구현할 때는 전체 비용에 기여하는 다양한 요인들을 이해하는 것이 중요합니다. 이 섹션에서는 주요 비용 구성 요소와 가격에 영향을 미치는 핵심 요인들을 설명합니다.

이 솔루션을 실행하는 총 비용은 크게 두 가지 주요 구성 요소로 분류할 수 있습니다:

LLM 프로바이더 비용 (LLM Provider Costs): Amazon Bedrock, Amazon SageMaker AI, Anthropic 등과 같은 LLM 프로바이더의 서비스를 사용하는 데 발생하는 비용입니다. 각 프로바이더는 일반적으로 처리된 토큰 수, 모델 복잡도, 사용량과 같은 요인에 기반한 자체적인 가격 모델을 가지고 있습니다. -
AWS 인프라 비용 (AWS Infrastructure Costs): AWS 인프라 상에서 Gen AI Gateway 프록시 서버를 실행하는 것과 관련된 비용입니다. 여기에는 솔루션을 호스팅하고 운영하는 데 사용되는 다양한 AWS 서비스 및 리소스가 포함됩니다.

기본 설정이 시작점을 제공하기는 하지만, AWS에서 LiteLLM 기반 프록시 서버를 실행하는 실제 비용은 구체적인 구현 방식과 사용 패턴에 따라 크게 달라질 수 있습니다. 확장성(Scaling)과 비용에 영향을 미칠 수 있는 주요 요인은 다음과 같습니다:

컴퓨팅 인스턴스 (Compute Instances): 프록시로서 LiteLLM 컨테이너를 호스팅하는 데 사용되는 EC2 인스턴스의 유형과 수입니다. 인스턴스 유형 선택은 성능과 비용 모두에 영향을 미칩니다. -
EBS 스토리지 (EBS Storage): EC2 인스턴스에 연결된 EBS 볼륨의 유형과 크기는 성능과 비용 모두에 영향을 줄 수 있습니다. -
오토스케일링 설정 (Autoscaling Configuration): EKS/ECS 클러스터에 구성된 오토스케일링 정책은 수요에 따라 솔루션이 확장되는 방식에 영향을 미치며, 성능과 비용 모두에 영향을 줍니다. -
트래픽 패턴 (Traffic Patterns): 다음과 같은 요인을 포함한 LLM 요청의 형태와 분포입니다:

• 요청/응답 페이로드 크기 (Request/response payload sizes)

• 분당 토큰 수 (Tokens per minute, TPM)

• 분당 요청 수 (Requests per minute, RPM)

• 동시성 수준 (Concurrency levels)

• 모델 지연 시간 (Model latency, 다운스트림 LLM 프로바이더로부터의 지연 시간)

• AWS와 LLM 프로바이더 간의 네트워크 지연 시간 (Network latency)

• 캐싱 설정 (Caching Configuration): 효과적인 캐싱은 LLM 프로바이더로의 요청 수를 줄여 잠재적으로 비용을 낮출 수 있지만, 추가적인 리소스가 필요합니다. -
  데이터베이스 스토리지 (Database Storage): 가상 키(virtual keys), 조직(organizations), 팀(teams), 사용자(users), 예산(budgets) 및 요청당 사용량 추적을 관리하는 데 필요한 스토리지 양입니다. -
  고가용성 및 회복탄력성 (High Availability and Resiliency): 로드 밸런싱(load balancing), 라우팅(routing) 및 재시도(retries)를 위한 설정은 신뢰성과 비용 모두에 영향을 미칠 수 있습니다. -
  로깅 수준 (Logging Level): 설정된 로깅 수준은 스토리지 및 잠재적인 네트워크 송신(network egress) 비용에 영향을 미칩니다. -
  네트워킹 비용 (Networking Costs): 여기에는 데이터 전송 요금과 LLM 프로바이더로의 외부 호출을 위한 NAT 게이트웨이(NAT gateways) 운영 비용이 포함됩니다.

이것이 비용 요인의 전체 목록은 아니며, 솔루션의 전체 비용에 기여하는 주요 요인 중 일부를 강조한 것임을 유의하는 것이 중요합니다.

본 구현 가이드는 기본 설정을 제공하지만, 고객은 다음 사항에 대한 책임이 있습니다:

• 특정 사용 사례 및 요구 사항을 기반으로 솔루션을 최적의 설정으로 구성하는 것.
• AWS 인프라에서 프록시 서버(proxy server)를 실행함으로써 발생하는 비용을 모니터링하고 관리하는 것.
• 선택한 LLM 프로바이더와 관련된 비용을 관리하고 최적화하는 것.

고객은 정기적으로 AWS 서비스 사용 패턴을 검토하고, 필요에 따라 설정을 조정하며, AWS 비용 관리 도구를 활용하여 지출을 최적화해야 합니다.