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

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

1. 背景与选型

1.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 管理、预算控制、缓存、负载均衡等企业级功能。

1.2 为什么部署在 AWS 上

• 原生 Bedrock 集成：通过 IAM Role 和 VPC Endpoint (PrivateLink) 直接调用 Bedrock 模型，无需管理 API Key，流量不出 VPC
• 安全合规体系成熟：IAM 最小权限、Security Group、WAF、KMS 加密、CloudTrail 审计，满足企业级合规要求
• Serverless 组件丰富：Aurora Serverless、ElastiCache Serverless、Fargate、DynamoDB On-Demand 等按需付费组件，避免资源浪费
• 全球基础设施：多区域部署 + CloudFront 全球加速，支持就近访问和数据驻留要求
• IaC 生态完善：CloudFormation / CDK TypeScript / eksctl 一键部署，基础设施即代码，可重复、可审计

1.3 为什么选择容器化部署（ECS/EKS）而不是 EC2 直接部署

总结：LiteLLM 本身以 Docker 镜像发布，容器化部署是其推荐方式。ECS Fargate 提供最低运维负担，EKS 提供最大灵活性和成本优化空间（Spot + Graviton），两者均远优于 EC2 裸机部署。

2. 整体架构

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

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

3. 方案一：ECS Fargate 部署

ECS Fargate 方案提供两种 IaC 部署方式，架构完全一致，团队可根据技术偏好选择：

3-A. CloudFormation 一键部署

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

⚠️ 具体模板文件、部署命令等请以 GitHub 仓库 README 为准，以下仅介绍架构设计和核心理念。

架构概览

核心组件

CloudFormation 模板结构

部署采用分层 CloudFormation 栈，按依赖顺序部署（VPC → S3 → Database → Bedrock IAM → ECS → CloudFront），每层职责单一，支持独立更新。具体模板文件列表请参考 GitHub 仓库。

一键部署

通过仓库提供的 deploy.sh 脚本一键部署全部组件，或按需分步部署各层。详细命令请参考 GitHub 仓库 README。

安全特性

验证测试

部署完成后，通过以下方式验证：

1. 健康检查：curl https://<cloudfront-domain>/health/liveliness
2. 获取 Master Key：从 Secrets Manager 获取自动生成的密钥
3. 调用测试：使用 OpenAI 兼容 API 格式调用 Bedrock 模型

具体命令和参数请参考 GitHub 仓库 README。

CloudFormation 方案特点

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

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

3-B. CDK TypeScript 部署

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

⚠️ 具体部署步骤、参数配置、Stack 名称等请以 GitHub 仓库 README 为准，以下仅介绍架构设计和核心理念。

架构概览

与 CloudFormation 方案架构一致（ECS Fargate + Internal ALB + CloudFront + WAF），但使用 AWS CDK TypeScript 编写，具备更好的类型安全、可测试性和代码复用能力。

分层 Stack 设计

CDK 方案将基础设施拆分为 6 个独立 Stack，按依赖顺序自动部署：

VpcStack → S3Stack → DatabaseStack → BedrockStack → EcsStack → CloudFrontStack

每个 Stack 职责单一（网络、存储、数据库、IAM、计算、CDN），通过 TypeScript 接口传递跨栈依赖，支持独立更新和回滚。

核心特性

• 参数化部署：所有关键配置（副本数、CPU/内存、Aurora ACU、WAF 速率限制等）通过 CDK Context 参数化，命令行 -c key=value 即可切换环境
• 单元测试：CDK Assertions 验证生成的 CloudFormation 模板，部署前发现配置错误
• 变更预览：npx cdk diff 对比本地代码与已部署资源的差异
• 一键部署/销毁：npx cdk deploy --all / npx cdk destroy --all

CDK 方案特点

优势： - ✅ TypeScript 类型安全，IDE 自动补全 - ✅ CDK Assertions 单元测试，部署前验证基础设施 - ✅ 参数通过 -c 命令行覆盖，灵活切换环境 - ✅ 跨栈依赖自动解析，无需手动管理输出/导入 - ✅ 与 CloudFormation 方案架构一致，可互相迁移 - ✅ npx cdk diff 部署前预览变更

适用场景： - 团队偏好编程式 IaC（TypeScript/Python） - 需要单元测试基础设施代码 - 多环境（dev/staging/prod）通过参数切换 - 希望利用 CDK Construct 生态复用组件

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

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

⚠️ 具体 YAML 清单、Helm 版本、部署步骤等请以 GitHub 仓库 README 为准，以下仅介绍架构设计和核心理念。

4.1 架构概览

4.2 核心组件

4.3 Kubernetes 资源清单

部署包含完整的 Kubernetes 资源定义，覆盖：

• 集群定义：eksctl 集群配置 + IRSA IAM 策略
• 密钥管理：ESO SecretStore + ExternalSecret
• 应用部署：Deployment（多副本、反亲和、探针）+ ConfigMap
• 网络入口：Service + ALB Ingress（HTTPS、WAF、CIDR 限制）
• 弹性扩缩：HPA + Karpenter NodePool
• 高可用保障：PodDisruptionBudget + NetworkPolicy（零信任）

具体文件列表请参考 GitHub 仓库。

4.4 关键部署步骤

部署流程概览：

1. 创建 EKS 集群：通过 eksctl 创建多 AZ 集群 + 系统节点组
2. 安装 Karpenter：Helm 安装 + 创建 NodePool（Spot + Graviton）
3. 创建数据层：Aurora PostgreSQL + ElastiCache Redis
4. 写入密钥：Master Key、Database URL 等写入 Secrets Manager
5. 安装 Helm 组件：AWS Load Balancer Controller + External Secrets Operator
6. 部署 K8s 资源：按序 apply 所有 YAML
7. 配置 DNS：Route53 指向 ALB
8. 验证：健康检查 + API 调用测试

详细步骤和命令请参考 GitHub 仓库 README。

4.5 支持的模型

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

具体支持的模型列表请参考 GitHub 仓库中的 ConfigMap 配置。

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. 方案对比

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

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

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（部署代码）：YAML 模板一键部署，适合熟悉 CloudFormation 的运维团队
2. ECS Fargate — CDK TypeScript（部署代码）：编程式 IaC，适合偏好 TypeScript、需要单元测试基础设施的开发团队
3. EKS（部署代码）：Kubernetes 原生生态，适合需要精细控制、Spot + Graviton 成本优化的团队

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

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

参考资源

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