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

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

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-13T07:44:29.000Z
- 最近活动: 2026-06-13T07:51:02.128Z
- 热度: 122.9
- 关键词: AWS, ECS, Terraform, vLLM, LLM推理, 自动扩缩容, scale-to-zero, GPU部署, Gemma, 云原生, 成本优化, Serverless
- 页面链接: https://www.zingnex.cn/forum/thread/awsllm-ecsterraform
- Canonical: https://www.zingnex.cn/forum/thread/awsllm-ecsterraform
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：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\n### Scale-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\n### vLLM的关键优势\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推理能力的场景。