# AI Gateway：企业级LLM推理网关的AWS云原生实践 > 该项目提供了一个基于AWS的云原生LLM推理网关解决方案，采用Cognito M2M认证、ALB原生JWT验证、ECS Fargate容器化和CloudWatch可观测性，支持多模型提供商的统一API接入，并实现了全面的安全扫描和供应链防护。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-06T18:42:48.000Z - 最近活动: 2026-04-06T18:51:15.243Z - 热度: 154.9 - 关键词: LLM网关, AWS, 云原生, Cognito认证, ECS Fargate, 安全扫描, 供应链安全, 多模型提供商, JWT验证, 可观测性 - 页面链接: https://www.zingnex.cn/forum/thread/ai-gateway-llmaws - Canonical: https://www.zingnex.cn/forum/thread/ai-gateway-llmaws - Markdown 来源: ingested_event --- # AI Gateway：企业级LLM推理网关的AWS云原生实践 ## 项目概述：面向生产环境的LLM统一接入层 随着大语言模型在企业的广泛应用，如何统一管理多个模型提供商的API接入、保障安全性、控制成本，成为了技术团队面临的重要挑战。AI Gateway项目正是为解决这些问题而设计的企业级解决方案。它是一个轻量级的LLM推理网关，部署在AWS云平台上，基于Portkey AI Gateway OSS构建，能够统一路由来自AI代理的请求到多个模型提供商，包括Bedrock、OpenAI、Anthropic、Google和Azure OpenAI。 该项目的设计理念非常明确：为生产环境提供一个安全、可观测、成本可控的LLM接入层。它不仅支持OpenAI的Chat Completions格式和Anthropic的Messages格式，还实现了机器对机器（M2M）认证、自动扩缩容、全面的安全扫描和供应链防护，体现了云原生架构的最佳实践。 ## 架构设计：单区域双可用区的高可用部署 AI Gateway的基础设施采用单区域、双可用区的部署模式，这是AWS云原生应用的典型架构选择。整个架构包含以下核心组件： 首先是网络层，VPC配置了两个公有子网用于部署应用负载均衡器（ALB），以及两个私有子网用于运行ECS任务。通过单个NAT网关实现出站互联网访问，同时使用VPC端点连接ECR、CloudWatch Logs、Secrets Manager和S3等AWS服务，既保证了安全性，又避免了公网流量费用。 ALB作为流量入口，配置了TLS 1.3加密、WAF v2防护（包含AWS托管规则和IP速率限制），以及原生的JWT验证功能。这种设计的一个显著优势是无需使用API Gateway，从而消除了按请求计费的成本。 认证层采用Cognito用户池实现M2M认证，支持client_credentials授权类型，可以定义自定义OAuth作用域，并通过JWKS端点实现ALB的签名验证。这种架构下，认证完全在ALB层完成，无需额外的Lambda或API Gateway介入。 计算层使用ECS Fargate运行Portkey网关容器，并搭配AWS OpenTelemetry Collector作为边车容器。Fargate的无服务器特性消除了服务器管理的负担，同时支持基于CPU利用率和ALB请求数的自动扩缩容。 ## 安全体系：多层防护与供应链安全 AI Gateway的安全设计堪称全面，实现了从开发到生产的全链路安全防护。项目采用了多达十余种安全扫描工具，覆盖了静态代码分析、密钥泄露检测、基础设施即代码审计、容器镜像扫描等多个层面。 在静态应用安全测试（SAST）方面，项目使用了Semgrep、Bandit和CodeQL三种工具，分别针对不同的安全规则集进行代码分析。Semgrep覆盖了OWASP Top 10和安全审计规则，Bandit专注于Python特定的安全问题，CodeQL则提供GitHub原生的语义代码分析。 密钥泄露防护由Gitleaks负责，在预提交钩子中运行，防止敏感信息进入代码仓库。基础设施安全方面，Checkov和TFLint对Terraform配置进行扫描，检查2500多项安全策略和合规性规则。 容器安全是该项目的另一个亮点。Hadolint对Dockerfile进行最佳实践检查，Trivy则对容器镜像和文件系统进行漏洞扫描。项目还使用Syft生成CycloneDX和SPDX格式的软件物料清单（SBOM），并通过Cosign实现基于Sigstore OIDC的无密钥镜像签名。 特别值得关注的是供应链安全设计。项目明确排除了LiteLLM作为依赖，原因是评估时发现LiteLLM存在14个已知CVE，包括关键级别的RCE漏洞和活跃的SSRF攻击。这一决策在项目文档中有详细的架构决策记录（ADR），并在2026年3月LiteLLM遭遇供应链攻击后得到了验证。 ## 认证流程：零额外延迟的JWT验证 AI Gateway的认证流程设计巧妙，实现了零额外成本和零额外延迟的目标。整个流程分为五个步骤： 首先，客户端向Cognito的oauth2/token端点发起请求，使用client_credentials授权类型，提供客户端ID和密钥。Cognito验证通过后返回签名的JWT访问令牌，有效期为1小时，包含特定的作用域声明。 然后，客户端在请求ALB时在Authorization头中携带该JWT令牌。ALB使用Cognito的JWKS端点验证JWT签名，检查发行者、过期时间、生效时间等声明，以及必需的作用域。对于无效的令牌，ALB直接返回401响应，不会将请求转发到后端服务。 只有通过验证的请求才会被转发到ECS Fargate目标组，由Portkey网关处理。这种设计将认证完全卸载到ALB层，相比API Gateway方案既节省了成本，又避免了额外的网络跳转延迟。 ## 开发体验：统一的任务运行器与Git钩子 项目使用mise作为工具版本管理器，统一安装Python、Terraform、lefthook、checkov、trivy等开发工具。所有项目任务都定义在mise.toml中，通过mise run命令执行，包括安装依赖、本地开发、测试、代码检查、格式化、类型检查、安全扫描等。 Lefthook管理的Git钩子在提交前并行运行多项检查：ruff对暂存的Python文件进行代码检查和自动修复，pyright进行类型检查，gitleaks检测密钥泄露，hadolint检查Dockerfile，terraform进行格式化和验证。在推送前还会运行完整的测试套件和安全扫描。 这种设计确保了代码质量的一致性，同时通过并行执行保持了较快的反馈速度。提交信息格式也强制执行Conventional Commits规范，支持feat、fix、docs、style、refactor等多种类型。 ## 可观测性：CloudWatch与OpenTelemetry集成 AI Gateway的可观测性体系基于CloudWatch和OpenTelemetry构建。项目配置了专门的日志组用于收集网关和OTel收集器的日志，并提供了预定义的Logs Insights查询。CloudWatch仪表板展示了请求量、错误率、延迟、按提供商分类的端点统计等关键指标。 OpenTelemetry Collector作为边车容器运行，负责将链路追踪发送到X-Ray，将指标以EMF格式输出，将日志发送到CloudWatch。这种架构实现了分布式追踪、指标收集和日志管理的统一，便于运维团队监控网关的运行状态。 ## 实践价值与适用场景 AI Gateway为企业提供了一个可直接部署的LLM网关参考实现。它特别适合以下场景：需要在多个模型提供商之间灵活切换的组织、对安全合规有严格要求的企业环境、希望降低API Gateway成本的技术团队，以及需要统一管理和监控LLM流量的平台团队。 项目的架构决策记录（ADR）文档尤为珍贵，详细记录了技术选型的 rationale，包括为什么选择Portkey OSS而非LiteLLM、为什么使用python:3.13-slim而非Chainguard镜像、为什么采用ALB JWT验证而非API Gateway等。这些文档对于理解设计意图和进行类似架构设计具有重要参考价值。 ## 总结 AI Gateway代表了云原生LLM基础设施的成熟实践。它将安全、可观测性、成本控制和开发体验有机地结合在一起，为企业级LLM应用提供了一个可靠的接入层。对于正在规划或建设LLM平台的团队来说，这是一个值得深入研究和借鉴的开源项目。