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.1 CloudFormation 一键部署

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

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

3.1.1 架构概览

[图1 ECS Fargate 架构图]

3.1.2 核心组件

3.1.3 CloudFormation 模板结构

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

3.1.4 一键部署

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

3.1.5 安全特性

3.1.6 验证测试

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

1. 健康检查：curl https://<cloudfront-domain>/health/liveliness

2. 获取 Master Key：从 Secrets Manager 获取自动生成的密钥

3. 调用测试：使用 OpenAI 兼容 API 格式调用 Bedrock 模型

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

3.1.7 CloudFormation 方案特点

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

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

3.2 CDK TypeScript 部署

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

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

3.2.1 架构概览

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

3.2.2 分层 Stack 设计

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

VpcStack → S3Stack → DatabaseStack → BedrockStack → EcsStack → CloudFrontStack

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

3.2.3 核心特性

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

3.2.4 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 架构概览

[图2 EKS 架构图]

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 配置方式

9.3.1 Admin Instance（管理面）

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

9.3.2 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 作为部署方式。

➡️ 下一步行动：

相关产品：

• Amazon ECS — 完全托管的容器编排服务
• Amazon EKS — 托管式 Kubernetes 服务
• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
• Amazon Fargate — 适用于容器的无服务器计算
• Amazon CDK — 基础设施即代码框架

相关文章：

• 告别堡垒机：使用 AWS EICE （EC2 Instance Connect Endpoint） 与 Chaterm 实现私有子网的安全智能运维
• （上篇）基于 AWS Bedrock AgentCore 构建企业级航空客服智能体 —— 基于AIDLC方法从需求分析到生产部署的完整实践
• 基于 AWS DevOps Agent 构建 AI 驱动的运维分析系统
• AWS IAM Identity Center 现在支持适用于 AWS 账户访问和应用程序使用的多区域复制功能

11. 参考资源

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

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者