AWS上部署可扩展LLM推理服务：基于ECS与Terraform的完整云原生方案

一个完整的开源项目，展示如何在AWS上使用ECS、Terraform和vLLM部署支持自动扩缩容的GPU推理服务，实现成本优化的scale-to-zero架构

• 原作者/维护者：dinosmuc
• 来源平台：github
• 原始标题：llm-cloud-deployment
• 原始链接：https://github.com/dinosmuc/llm-cloud-deployment
• 来源发布时间/更新时间：2026-06-13T07:44:29Z

原作者与来源

• 原作者/维护者：dinosmuc
• 来源平台：github
• 原始标题：llm-cloud-deployment
• 原始链接：https://github.com/dinosmuc/llm-cloud-deployment
• 来源发布时间/更新时间：2026-06-13T07:44:29Z 原作者与来源\n\n- 原作者/维护者: dinosmuc\n- 来源平台: GitHub\n- 原始标题: llm-cloud-deployment: Scalable LLM inference service on AWS using ECS, Terraform, and HuggingFace TGI\n- 原始链接: https://github.com/dinosmuc/llm-cloud-deployment\n- 发布时间: 2025年（IU Cloud Programming课程项目）\n\n---\n\n项目概述\n\n这是一个面向生产环境的完整云原生LLM部署方案，由德国国际应用科学大学（IU）云计算课程的学生开发。项目展示了如何在AWS上构建一个具备自动扩缩容能力的GPU推理服务，核心特色是scale-to-zero架构——当没有请求时系统可以完全关闭GPU实例，仅在收到请求时自动唤醒，从而大幅降低运营成本。\n\n该项目运行Google Gemma 4 E2B IT模型，通过vLLM推理引擎提供服务，并配备了一个简洁的HTML/JS聊天界面。整个基础设施使用Terraform进行声明式管理，体现了现代DevOps最佳实践。\n\n---\n\n架构设计深度解析\n\n整体架构流程\n\n系统的请求流转遵循边缘到核心的经典云架构模式：\n\n1. 边缘层: CloudFront CDN作为入口，提供全球内容分发和DDoS防护\n2. 安全层: AWS WAFv2应用防火墙，内置通用规则集和速率限制（每IP每5分钟1000请求）\n3. 负载均衡: ALB应用负载均衡器，跨两个可用区部署\n4. 计算层: ECS-on-EC2运行g6.xlarge实例（NVIDIA L4 GPU，24GB显存）\n5. 容器编排: 双容器任务——nginx反向代理 + vLLM推理服务\n\n网络拓扑设计\n\n项目采用精心设计的VPC网络架构：\n\n- VPC CIDR: 10.0.0.0/16，为子网划分提供充足空间\n- 双可用区部署: 确保高可用性，符合AWS Well-Architected框架\n- NAT网关: 单个NAT网关部署在公有子网，处理私有子网的出站流量\n- S3 Gateway端点: 免费访问S3服务，避免NAT网关流量费用\n- 安全组策略: 最小权限原则，仅开放必要的端口和协议\n\nScale-to-Zero机制\n\n这是项目最具创新性的设计。系统通过三层协作的自动扩缩策略实现零实例待机：\n\n| 策略名称 | 类型 | 触发条件 | 效果 |\n|---------|------|---------|------|\n| scale_out_wake | 步进策略 | ALB返回503错误（无健康目标） | 0→1实例唤醒 |\n| scale_out_load | 目标追踪 | 每目标请求数>600/分钟 | 1→N实例扩容 |\n| scale_in_idle | 步进策略 | 15分钟零流量 | N→0实例缩容 |\n\n冷启动流程约需5-8分钟，包括：EC2实例启动（90秒）、容器镜像拉取（18GB vLLM镜像）、模型加载到显存、健康检查通过等阶段。前端界面会显示"Warming up..."状态，让用户了解进度。\n\n---\n\n技术栈详解\n\n核心组件选择\n\n| 层级 | 技术选型 | 版本/规格 |\n|-----|---------|----------|\n| IaC | Terraform | ≥1.10，AWS Provider ~6.45 |\n| 状态管理 | S3后端 | 原生条件写入锁定 |\n| 计算资源 | ECS-on-EC2 | g6.xlarge，NVIDIA L4 GPU |\n| 推理引擎 | vLLM | v0.20.2，OpenAI兼容API |\n| 部署模型 | Google Gemma 4 | E2B IT版本，BF16精度 |\n| 反向代理 | nginx | alpine版本，SSE流支持 |\n| 边缘加速 | CloudFront | 默认证书，OAC源访问控制 |\n| 密钥管理 | AWS SSM | SecureString参数存储 |\n| 监控告警 | CloudWatch + SNS | 6个仪表板小部件，3个告警 |\n\n为什么选择ECS-on-EC2而非ECS Fargate？\n\n项目作者明确指出，GPU工作负载需要EC2而非Fargate，原因包括：\n\n1. GPU支持: Fargate目前不支持GPU实例类型\n2. 显存需求: Gemma 4模型需要24GB显存，L4 GPU是性价比最优选择\n3. 自定义AMI: 需要NVIDIA驱动和CUDA运行时环境\n4. 成本控制: EC2 Spot实例可进一步降低成本（虽然本项目使用按需实例）\n\nvLLM的关键优势\n\nvLLM作为推理引擎提供了多项生产级特性：\n\n- PagedAttention: 高效管理KV缓存，提升吞吐量\n- 连续批处理: 动态合并请求，最大化GPU利用率\n- OpenAI兼容API: /v1/chat/completions端点，零迁移成本\n- 流式输出: Server-Sent Events (SSE)格式，实时返回生成token\n- BF16支持: 利用L4 GPU的Tensor Core加速\n\n---\n\n安全设计考量\n\n双层API密钥机制\n\n项目实现了防御纵深的安全模型：\n\n1. Public API Key: 客户端在x-api-key头中发送，由nginx验证\n2. Internal API Key: nginx注入到vLLM的Authorization: Bearer头中\n\n两个密钥都存储在SSM Parameter Store的SecureString参数中，ECS任务执行角色仅在启动时解密获取。这种设计确保即使容器被攻破，攻击者也只能访问内部密钥，无法冒充客户端。\n\n网络安全措施\n\n- WAFv2防护: AWS托管的通用规则集，自动阻止常见攻击模式\n- 速率限制: 每IP每5分钟1000请求，防止滥用\n- CloudFront OAC: 源访问控制确保S3存储桶仅可通过CloudFront访问\n- 私有子网: ECS任务运行在私有子网，无公网IP\n- 安全组最小化: 仅允许ALB到容器的80端口流量\n\n---\n\n成本优化策略\n\n成本构成分析\n\n在零实例待机状态下，系统仅产生以下费用：\n\n- NAT网关: ~$0.045/小时（约$32/月）\n- ALB: ~$0.0225/小时（约$16/月）\n- CloudFront: 仅当有请求时产生数据传输费\n- S3: 前端静态资源存储（可忽略）\n\nGPU实例（g6.xlarge）仅在实际处理请求时运行，按秒计费。\n\n成本对比估算\n\n假设一个典型的AI客服场景：\n\n| 部署模式 | 月成本估算 | 适用场景 |\n|---------|-----------|---------|\n| 常驻实例（24x7） | ~$730/月 | 高并发、低延迟要求 |\n| Scale-to-Zero | $50-200/月 | 间歇性流量、开发测试 |\n| 纯无服务器（如Bedrock） | $0.06/千token | 完全不可预测流量 |\n\n该项目的架构特别适合开发和测试环境，以及流量模式可预测的生产工作负载。\n\n---\n\n部署与使用指南\n\n前置要求\n\n- AWS账户需具备GPU配额（G/VT实例vCPU限制≥4）\n- AWS CLI已配置有效凭证\n- Docker用于本地构建镜像\n- Terraform ≥ 1.10\n\n首次部署流程\n\n1. 创建状态存储桶（一次性）：\n bash\n aws s3api create-bucket --bucket gemma-inference-tfstate-ds --region eu-central-1\n aws s3api put-bucket-versioning --bucket gemma-inference-tfstate-ds --versioning-configuration Status=Enabled\n \n\n2. 配置变量：复制并编辑terraform.tfvars，设置API密钥和告警邮箱\n\n3. 分阶段部署：\n bash\n terraform init\n terraform apply -target=module.ecr 先创建ECR仓库\n ./scripts/build_and_push.sh 构建并推送镜像\n terraform apply 部署完整基础设施\n \n\n4. 确认SNS订阅：检查邮箱并点击AWS发送的确认链接\n\n首次使用体验\n\n打开Terraform输出的frontend_url，输入public_api_key，点击Connect。首次请求将经历5-8分钟的冷启动，界面会实时显示进度。之后的消息将以每秒30-80个token的速度流式返回。\n\n---\n\n关键收获与最佳实践\n\n设计亮点\n\n1. 真正的scale-to-zero: 不仅关闭容器，而是完全终止EC2实例\n2. 智能冷启动处理: 503错误触发扩容，前端自动重试机制\n3. 成本与体验的平衡: 15分钟空闲后缩容，平衡成本和用户体验\n4. 完整的可观测性: CloudWatch仪表板、告警、日志全覆盖\n5. 生产级安全: 双层密钥、WAF防护、私有子网、最小权限\n\n适用场景\n\n- 开发/测试环境的LLM服务\n- 内部工具和低频次AI应用\n- 需要完全控制模型和数据的合规场景\n- 学习云原生LLM部署的教育用途\n\n潜在改进方向\n\n- 集成Spot实例进一步降低成本\n- 添加模型缓存层减少冷启动时间\n- 实现多模型路由和A/B测试\n- 集成AWS Bedrock作为备用模型源\n\n---\n\n结语\n\n这个项目展示了云原生LLM部署的完整范式：从基础设施即代码到自动扩缩容，从安全防护到成本优化。对于希望在AWS上自建LLM服务的团队来说，这是一个极佳的参考实现，既可以直接使用，也可以作为定制化的起点。其scale-to-zero架构特别适合预算敏感但需要GPU推理能力的场景。