LiteLLM 生产级部署：基于 AWS ECS/EKS 的 AI Gateway 架构

摘要：本文介绍如何在 AWS 上以生产级标准部署 LiteLLM AI Gateway，涵盖 ECS Fargate 和 EKS 两种方案，并结合 LiteLLM 的 Control Plane / Data Plane 分离架构实现多区域高可用部署。

1. 为什么需要 LiteLLM AI Gateway

随着企业大规模采用大语言模型（LLM），团队面临以下挑战：

• 多模型管理：同时使用 Amazon Bedrock (Claude)、OpenAI、Google Gemini、Azure OpenAI 等多个 Provider
• 成本控制：需要按团队/用户设置预算和速率限制
• 统一接口：开发者希望用 OpenAI 兼容 API 调用所有模型
• 安全合规：API Key 管理、审计日志、访问控制
• 可观测性：Token 用量追踪、延迟监控、费用分析

LiteLLM 作为开源 AI Gateway，提供统一的 OpenAI 兼容 API 代理 200+ LLM 模型，内置 Key 管理、预算控制、缓存、负载均衡等企业级功能。

2. 整体架构

两种部署方案均采用以下核心设计原则：

• 高可用：多 AZ 部署，自动故障转移
• 弹性扩缩：根据负载自动扩缩容
• 安全纵深：WAF → TLS → 内网隔离 → IAM 最小权限
• 完整可观测性：CloudWatch + S3 审计日志 + Dashboard

3. 方案一：ECS Fargate 部署（CloudFormation 一键部署）

📦 部署代码：https://github.com/zhangzhenhuajack/aws-builder/tree/main/litellm/litellm-ecs-cloudformation

3.1 架构概览

3.2 核心组件

3.3 CloudFormation 模板结构

部署采用分层 CloudFormation 栈，按依赖顺序部署：

3.4 一键部署

chmod +x deploy.sh

# 部署全部组件
./deploy.sh deploy-all

# 或分步部署
./deploy.sh deploy-vpc
./deploy.sh deploy-s3
./deploy.sh deploy-db
./deploy.sh deploy-bedrock
./deploy.sh upload-config    # 上传 litellm_config.yaml 到 S3
./deploy.sh deploy-ecs
./deploy.sh deploy-cloudfront

3.5 安全特性

3.6 验证测试

# 健康检查
curl https://<cloudfront-domain>/health/liveliness

# 获取 Master Key
MASTER_KEY=$(aws secretsmanager get-secret-value \
  --secret-id litellm/litellm/master-key \
  --query SecretString --output text | jq -r .LITELLM_MASTER_KEY)

# 调用 Bedrock Claude
curl -s https://<cloudfront-domain>/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MASTER_KEY" \
  -d '{
    "model": "bedrock-claude-opus-4-6-v1",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

3.7 ECS 方案特点

优势： - ✅ CloudFormation 一键部署，运维简单 - ✅ 无需管理 Kubernetes 集群 - ✅ Fargate Serverless，无需管理节点 - ✅ CloudFront VPC Origin 内网回源，零公网暴露 - ✅ 自动扩缩（CPU 70% / Memory 80%） - ✅ VPC Endpoint 确保 Bedrock 调用不出 VPC

适用场景： - 团队无 Kubernetes 经验 - 希望最小化运维负担 - 单区域部署为主 - 快速上线

4. 方案二：EKS 部署（Kubernetes 原生）

📦 部署代码：https://github.com/kk137/litellm-eks-public

4.1 架构概览

4.2 核心组件

4.3 Kubernetes 资源清单

litellm-eks/
├── eksctl-cluster.yaml          # EKS 集群定义
├── iam-policy.json              # IRSA IAM 权限策略
├── 00-namespace.yaml            # Namespace
├── 01-serviceaccount.yaml       # ServiceAccount (IRSA)
├── 02-secretstore.yaml          # ESO SecretStore
├── 03-externalsecret.yaml       # ESO ExternalSecret (12 个密钥)
├── 04-configmap.yaml            # LiteLLM 配置（模型、路由、缓存）
├── 05-deployment.yaml           # Deployment (3 副本, 反亲和, 探针)
├── 06-service.yaml              # ClusterIP Service
├── 07-ingress.yaml              # ALB Ingress (HTTPS, WAF, CIDR 限制)
├── 08-hpa.yaml                  # HPA (CPU 65% / Memory 75%, 3-20 副本)
├── 09-pdb.yaml                  # PDB (最少 2 可用)
├── 10-networkpolicy.yaml        # NetworkPolicy (零信任)
└── 11-karpenter-nodepool.yaml   # Karpenter NodePool + EC2NodeClass

4.4 关键部署步骤

# 1. 创建 EKS 集群
eksctl create cluster -f eksctl-cluster.yaml

# 2. 安装 Karpenter + 创建节点池
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "1.3.0" --namespace kube-system \
  --set "settings.clusterName=$CLUSTER_NAME" \
  --set "settings.clusterEndpoint=$CLUSTER_ENDPOINT" ...
kubectl apply -f 11-karpenter-nodepool.yaml

# 3. 创建 ElastiCache Redis + Aurora PostgreSQL (AWS CLI)

# 4. 写入 Secrets Manager
aws secretsmanager create-secret --name litellm/master-key --secret-string "$MASTER_KEY"
aws secretsmanager create-secret --name litellm/database-url --secret-string "$DATABASE_URL"

# 5. 安装 Helm 组件
helm install aws-load-balancer-controller eks/aws-load-balancer-controller ...
helm install external-secrets external-secrets/external-secrets ...

# 6. 部署 K8s 资源
kubectl apply -f 00-namespace.yaml
kubectl apply -f 01-serviceaccount.yaml
# ... 依次 apply 所有 YAML

# 7. 配置 Route53 DNS → ALB
# 8. 验证
curl -sk https://$DOMAIN/health/readiness

4.5 支持的模型

EKS 方案支持多 Provider 混合部署：

4.6 SSO 集成（Cognito OIDC）

管理界面通过 AWS Cognito SSO 认证：

4.7 EKS 方案特点

优势： - ✅ Kubernetes 原生，生态丰富 - ✅ Karpenter 智能扩缩，Spot 实例降低 60%+ 成本 - ✅ Graviton (ARM) 节点，性价比更高 - ✅ NetworkPolicy 零信任网络 - ✅ External Secrets Operator 自动同步密钥 - ✅ SSO 集成（Cognito OIDC） - ✅ 多 Provider 支持（Bedrock + Gemini + OpenAI + Azure） - ✅ PodDisruptionBudget 保证滚动更新零停机

适用场景： - 团队有 Kubernetes 经验 - 需要精细化的资源调度和网络策略 - 多 LLM Provider 混合使用 - 需要 SSO 集成 - 追求极致成本优化（Spot + Graviton）

5. 安全最佳实践

两种方案均遵循以下安全原则：

5.1 网络安全对比

5.2 密钥管理

5.3 IAM 最小权限

• ECS Task Role：仅允许 Bedrock InvokeModel、S3 读写、DynamoDB CRUD
• EKS IRSA：通过 OIDC 联邦，Pod 级别的 IAM 角色绑定

5.4 数据加密

6. 可观测性与审计

6.1 日志架构

API Request
    ├──▶ CloudWatch Logs        — 应用运行日志（30 天保留）
    ├──▶ S3                     — 完整 request/response JSON（Intelligent-Tiering）
    ├──▶ Aurora PostgreSQL      — 费用追踪、用量统计、审计日志
    └──▶ LiteLLM UI Dashboard  — 可视化监控

6.2 S3 审计日志

每次 API 调用生成 JSON 文件，包含： - 完整的用户输入（prompt）和模型输出（completion） - 使用的模型、调用费用、Token 用量 - 调用者 Key 别名、请求来源 IP - 延迟指标（startTime / endTime / response_time）

6.3 LiteLLM Dashboard

通过 /ui 访问管理界面： - Request Logs：每次调用的 request/response 详情 - Usage：按用户/Key/模型的用量统计 - Spend：费用追踪和预算管理 - Models：模型配置和健康状态

7. 方案对比

两种方案采用不同的技术栈，适配不同的团队技术背景：

两种方案本质上是容器编排平台的选择差异，核心能力（高可用、弹性扩缩、安全合规、可观测性）完全一致，团队可根据现有技术栈自由选择。

8. 成本优势：Serverless 按需付费

两种方案均大量采用 AWS Serverless 组件，核心优势是按需付费、无需预置容量：

关键设计原则： - 🔄 弹性伸缩：所有组件随业务负载自动扩缩，高峰期自动扩容，低谷期自动缩容 - 💰 零浪费：不使用时不产生费用（或仅产生极低的基础费用） - 📈 线性增长：成本与实际 LLM 调用量线性相关，无阶梯式跳变

9. 进阶：Control Plane / Data Plane 分离的多区域架构

✨ 此功能需要 LiteLLM Enterprise License。

当业务扩展到多区域时，可以采用 LiteLLM 的 Control Plane / Data Plane 分离架构，将管理面和数据面解耦，实现全球多区域部署。

9.1 架构设计

                    ┌─────────────────────────────────────────────────────┐
                    │              Admin Instance (Control Plane)          │
                    │              admin.company.com                       │
                    │              - Key 管理、用户管理                     │
                    │              - 配置变更、监控 Dashboard               │
                    │              DISABLE_LLM_API_ENDPOINTS=true          │
                    └──────────────────────┬──────────────────────────────┘
                                           │
                              共享 Aurora Global Database
                                           │
              ┌────────────────────────────┼────────────────────────────┐
              │                            │                            │
    ┌─────────▼─────────┐      ┌──────────▼──────────┐     ┌──────────▼──────────┐
    │  US Worker (ECS)  │      │  EU Worker (EKS)    │     │  APAC Worker (ECS)  │
    │  us.company.com   │      │  eu.company.com     │     │  apac.company.com   │
    │  DISABLE_ADMIN=true│      │  DISABLE_ADMIN=true │     │  DISABLE_ADMIN=true │
    │  → Bedrock us-east│      │  → Bedrock eu-west  │     │  → Bedrock ap-north │
    └───────────────────┘      └─────────────────────┘     └─────────────────────┘

9.2 核心理念

所有实例共享同一个数据库，Admin 实例创建的 Key/用户/配置自动对所有 Worker 生效。

9.3 配置方式

Admin Instance（管理面）：

DISABLE_LLM_API_ENDPOINTS=true      # 禁用 LLM API，仅保留管理端点
DATABASE_URL=postgresql://user:pass@global-db:5432/litellm
LITELLM_MASTER_KEY=your-master-key

Worker Instance（数据面）：

DISABLE_ADMIN_UI=true               # 禁用管理 UI
DISABLE_ADMIN_ENDPOINTS=true        # 禁用管理 API
DATABASE_URL=postgresql://user:pass@global-db:5432/litellm
LITELLM_MASTER_KEY=your-master-key

9.4 架构优势

1. 降低管理开销：仅一个实例需要管理能力
2. 区域性能优化：用户就近访问 Worker 节点，低延迟
3. 集中控制：所有管理操作通过单一界面完成
4. 安全隔离：Worker 节点禁用管理端点，减少攻击面
5. 灵活混合：不同区域可自由选择 ECS 或 EKS 部署

9.5 客户端使用

from openai import OpenAI

# 美国用户 → US Worker
client_us = OpenAI(base_url="https://us.company.com/v1", api_key="sk-xxx")

# 欧洲用户 → EU Worker
client_eu = OpenAI(base_url="https://eu.company.com/v1", api_key="sk-xxx")

# 管理操作 → Admin Instance
import requests
requests.post("https://admin.company.com/key/generate",
              headers={"Authorization": "Bearer sk-master"},
              json={"duration": "30d"})

9.6 Worker 端点说明

Worker 实例禁用管理端点后，仅保留以下 API： - /chat/completions — LLM 请求 - /v1/* — OpenAI 兼容 API - /bedrock/* — Bedrock 透传 API - /vertex_ai/* — Vertex AI 透传 API - /health — 健康检查 - /metrics — Prometheus 指标

10. 总结

LiteLLM 作为生产级 AI Gateway，在 AWS 上有两种成熟的部署路径：

1. ECS Fargate（部署代码）：适合追求简单运维的团队，CloudFormation 一键部署，Serverless 免管理节点
2. EKS（部署代码）：适合需要精细控制的团队，Kubernetes 原生生态，Karpenter + Spot 优化成本

两种方案均支持： - ✅ 高可用（多 AZ 部署） - ✅ 弹性扩缩（Auto Scaling / HPA + Karpenter） - ✅ 安全合规（WAF + TLS + VPC Endpoint + IAM 最小权限） - ✅ 完整可观测性（CloudWatch + S3 审计 + Dashboard）

对于多区域场景，可进一步采用 LiteLLM Enterprise 的 Control Plane / Data Plane 分离架构，在保持集中管理的同时为各区域用户提供低延迟的 LLM 访问体验，且各区域可自由选择 ECS 或 EKS 作为部署方式。

参考资源

• LiteLLM 官方文档 - Control Plane & Data Plane
• LiteLLM GitHub
• ECS 部署代码
• EKS 部署代码
• AWS ECS Fargate 文档
• Amazon EKS 文档
• Karpenter 文档