当前位置：首页 > news >正文

使用 Terraform 模块在 AWS 上快速部署生产级 AI 智能体网关 OpenClaw

news 2026/5/14 6:44:49

1. 项目概述与核心价值

如果你正在寻找一个能快速、安全地将 OpenClaw 这个 AI 智能体网关部署到 AWS 上的“一站式”解决方案，那么infrahouse/terraform-aws-openclaw这个 Terraform 模块就是为你准备的。我最近在一个内部项目中用它来搭建一个供团队使用的 AI 助手平台，整个过程比我预想的要顺畅得多。这个模块的核心价值在于，它把一个涉及 ALB、Cognito、EC2、EFS、Secrets Manager 等多个 AWS 服务的复杂架构，封装成了一个开箱即用的、生产就绪的 Terraform 模块。你不需要从零开始编写安全组规则、配置 Cognito 用户池、或是操心 EFS 的挂载和备份策略，它都帮你做好了，并且遵循了相当不错的安全实践。

简单来说，这个模块帮你部署了一个带有 Web 界面的 OpenClaw 服务。用户通过浏览器访问一个 HTTPS 地址，首先会经过 AWS Cognito 进行身份认证（支持多因素认证），认证通过后，流量才会被转发到后端的 EC2 实例上运行的 OpenClaw 应用。OpenClaw 本身是一个 AI 智能体的“路由器”或“网关”，它支持连接多个后端的 LLM 提供商，包括 AWS Bedrock（默认，无需 API 密钥）、Anthropic Claude API、OpenAI API，以及一个本地部署的 Ollama 服务。这意味着你可以在一个界面里，根据任务需求，灵活选择使用云上的大模型（如 Claude 3.5 Sonnet）或者自己服务器上跑的轻量级模型（如 Qwen2.5），所有 API 密钥都安全地存放在 AWS Secrets Manager 中。

对于运维和开发团队而言，它的吸引力在于“基础设施即代码”带来的可重复性和可控性。通过修改几行 Terraform 配置，你就能轻松调整实例规格、预拉取不同的 Ollama 模型、添加新的 Bedrock 模型，或者扩缩容整个环境。模块内置的安全设计，如系统服务加固、网络隔离和加密存储，也让你在快速部署的同时，无需在安全合规性上做出妥协。

1.1 核心需求与适用场景解析

这个模块主要解决以下几类用户的痛点：

1. 企业内部 AI 助手平台搭建者：很多公司希望为员工提供一个统一的、安全的 AI 对话界面，用于代码辅助、文档撰写、数据分析等。直接使用公有云 AI 服务的网页界面存在账号管理、费用分摊、数据安全等问题。这个模块允许你在自己的 AWS 账户内部署，通过 Cognito 集成公司现有的身份体系（如企业邮箱），所有流量和数据都在你的 VPC 内，并且可以精细控制模型的使用权限和成本。

2. 需要混合云 AI 能力的开发者：你的应用可能既需要云上大模型的强大能力来处理复杂任务，又需要本地小模型的快速响应和零数据出境风险来处理敏感或实时性要求高的请求。OpenClaw 的多提供商支持正好满足了这种混合架构的需求。你可以用 Bedrock 的 Claude 处理创意写作，同时用本地的 Ollama 运行 CodeLlama 来快速补全代码片段。

3. 追求生产级部署的 AI 应用开发者：如果你自己从 GitHub 拉取 OpenClaw 源码部署，会面临一系列生产环境问题：如何做高可用？如何做用户认证？日志怎么收集和留存？密钥如何管理？这个模块将这些生产级需求都标准化了。它使用 Auto Scaling Group 保证实例故障时自动替换，用 EFS 保证应用数据持久化，用 CloudWatch Logs 集中管理日志并默认保留 365 天以满足审计要求。

4. 希望快速验证 AI 智能体工作流的团队：模块的“Quick Start”配置几乎可以零修改直接运行。你只需要提供一个域名和子网信息，它就能在 15-20 分钟内帮你搭起一个完整可用的环境。这比手动在 EC2 上一步步安装配置要快得多，也规范得多，非常适合 PoC（概念验证）或开发测试环境。

注意：虽然模块简化了部署，但它仍然要求使用者具备基本的 AWS 和 Terraform 知识。你需要提前准备好一个 VPC 网络（包含公网和私网子网）、一个 Route 53 托管域名，并配置好相应的 IAM 权限。这不是一个“点一下按钮就全自动完成”的魔法，而是一个为具备一定基础设施管理能力的团队设计的强力工具。

2. 架构深度解析与设计理念

理解这个模块的架构设计，能帮助你在使用和定制时做出更合理的决策。整个部署可以看作由四个逻辑层构成：访问层、认证层、应用层和数据层。

访问层由 Application Load Balancer (ALB) 构成。它对外提供 HTTPS 服务，终端用户通过它访问 OpenClaw。ALB 自动集成了 AWS Certificate Manager (ACM) 来管理 SSL/TLS 证书，你无需自己上传或更新证书。安全组规则默认允许来自0.0.0.0/0的 80/443 端口访问，因为真正的访问控制发生在下一层。如果你需要限制源 IP，可以通过allowed_cidrs变量进行配置。

认证层是整个安全架构的核心，由 AWS Cognito 实现。这是该模块与 OpenClaw 原始部署指南最大的区别之一。原始方案使用一个共享的网关令牌，存在泄露风险且难以管理用户。本模块将 ALB 配置为使用 Cognito 作为 OIDC 身份提供商。当未认证的用户访问 ALB 时，会被重定向到 Cognito 的托管 UI 进行登录。登录成功后，Cognito 会向用户浏览器颁发一个包含身份信息的 JWT 令牌，后续请求都会携带此令牌，ALB 负责验证其有效性。这种方式带来了几个关键优势：基于标准的 OIDC 协议、支持多因素认证 (MFA)、具备高级安全特性（如检测异常登录）、并且可以与企业目录（如通过 AWS SSO）进行联邦。用户账户通过 Terraform 的cognito_users变量直接创建，密码会自动生成并可以通过模块输出获取。

应用层运行在 Auto Scaling Group (ASG) 管理的 EC2 实例上。模块使用了infrahouse/website-pod/aws这个子模块来部署实例，它封装了最佳实践，如将用户数据 (user data) 分割成可管理的片段、使用cloud-init进行系统初始化。实例运行一个经过加固的 systemd 服务来启动 OpenClaw。加固措施包括ProtectSystem=strict（防止服务写入系统目录）、ProtectHome=tmpfs（将/home和/root挂载为临时内存文件系统以隔离用户数据）、以及NoNewPrivileges=true（防止进程提升权限）。Ollama 服务也以同样的原则运行在同一个实例上，但绑定在localhost:11434，仅允许 OpenClaw 进程本地访问，进一步减少了攻击面。

数据层的持久化由 Amazon EFS 实现。OpenClaw 的配置、会话数据、以及可能由技能（skills）产生的文件都存储在 EFS 上。这样做的好处是，当 ASG 因为伸缩或实例不健康而替换 EC2 实例时，新启动的实例挂载同一个 EFS，所有应用数据得以保留，用户体验无缝衔接。EFS 文件系统默认启用了备份策略，并使用了 AWS 托管或客户管理的 KMS 密钥进行静态加密。网络访问上，EFS 的安全组只允许来自后端实例所在子网的 NFS 流量，确保了存储网络的隔离性。

供应链安全是另一个值得称道的设计。模块在引导脚本中避免了常见的curl | sh或wget | bash这种以 root 权限直接执行远程脚本的不安全模式。对于 Node.js，它配置了官方的 NodeSource GPG 密钥和 APT 源来安装。对于 Ollama，它下载官方发布的二进制压缩包，校验 SHA256 哈希值，然后安装。OpenClaw 本身则是通过 npm 以非特权用户身份安装在用户家目录下。这种分步骤、可验证的安装方式，显著降低了供应链攻击的风险。

3. 模块配置与核心参数详解

要使用这个模块，你需要在自己的 Terraform 代码中声明并传入必要的参数。下面我们来拆解一个生产环境可用的配置示例，并解释每个关键参数的作用和背后的考量。

# 假设你有一个已经定义好的 VPC 模块，输出公网和私网子网 ID module "network" { source = "terraform-aws-modules/vpc/aws" version = "~> 5.0" # ... 你的 VPC 配置 ... } # 获取已有的 Route53 托管区域信息 data "aws_route53_zone" "primary" { name = "yourdomain.com" } # 部署 OpenClaw module "openclaw" { source = "registry.infrahouse.com/infrahouse/openclaw/aws" version = "0.4.0" # 务必检查并使用最新版本 # 必须提供 AWS Provider，其中 aws.dns 用于管理 Route53 记录 providers = { aws = aws # 默认 provider，用于创建大部分资源 aws.dns = aws # 用于在指定 zone_id 中创建 DNS 记录 } # --- 核心基础设施参数 --- environment = "production" # 环境标签，用于资源命名和 tagging zone_id = data.aws_route53_zone.primary.zone_id # Route53 托管区域 ID alb_subnet_ids = module.network.public_subnets # ALB 需要部署在公网子网 backend_subnet_ids = module.network.private_subnets # 后端实例建议放在私网子网 alarm_emails = ["ops-team@yourcompany.com", "ai-platform-admin@yourcompany.com"] # 告警接收邮箱 # --- 认证与用户管理 --- cognito_users = [ { email = "alice@yourcompany.com" full_name = "Alice Developer" }, { email = "bob@yourcompany.com" full_name = "Bob Analyst" }, ] # --- 实例与性能配置 --- instance_type = "t3.xlarge" # 如果你打算运行 7B 参数的本地模型，需要至少 16GB 内存 root_volume_size = 50 # 根卷大小，如果计划拉取多个 Ollama 模型，建议调大 # --- Ollama 本地模型配置 --- ollama_default_model = "llama3.1:8b" # 实例启动时自动拉取的模型，设为 null 则跳过 # ollama_version = "0.5.3" # 可指定 Ollama 版本，不指定则使用最新版 # --- 网络访问控制（可选）--- # allowed_cidrs = ["10.0.0.0/8", "192.168.1.0/24"] # 限制 ALB 访问来源 CIDR # --- 高级 Bedrock 模型注册（可选）--- extra_bedrock_models = [ { id = "us.meta.llama3-1-70b-instruct-v1:0" name = "Llama 3.1 70B Instruct" }, { id = "us.amazon.nova-pro-v1:0" name = "Amazon Nova Pro" reasoning = true # 如果模型支持推理模式，可以开启 } ] # --- 其他可选配置 --- service_name = "team-ai-gateway" # 用于资源命名的服务前缀 # key_name = "my-existing-ec2-key" # 使用现有密钥对，不指定则模块自动生成 }

关键参数解析与选型建议：

alb_subnet_ids与backend_subnet_ids：这是网络设计的关键。ALB 必须放在公有子网（有互联网网关路由）以便从互联网接收流量。而后端 EC2 实例强烈建议放在私有子网（通过 NAT 网关访问外网以下载包和模型）。这种布局将应用服务器与互联网隔离，是 AWS 推荐的安全架构。你需要确保这些子网分布在至少两个可用区 (AZ) 以实现高可用。
instance_type与ollama_default_model的匹配：这是最容易出错的点。Ollama 模型在加载时会完全驻留在内存中。t3.large（8GB 内存）是模块默认值，仅能运行 1-3B 参数的小模型（如qwen2.5:1.5b）。如果你在配置中指定了ollama_default_model = "llama3.1:8b"，但实例类型仍是t3.large，实例在拉取并尝试运行该模型时，会因内存不足而剧烈交换 (swap)，导致服务完全无响应。务必参考模块文档中的实例选型表，根据目标模型大小选择实例。如果只打算用云模型（Bedrock/OpenAI/Anthropic），可以将ollama_default_model设为null，并选择t3.medium这类更小规格的实例以节省成本。
cognito_users：模块会为列表中的每个用户创建 Cognito 账户，并生成一个随机密码。创建完成后，密码会以明文形式出现在 Terraform 状态文件和应用日志中。因此，在生产环境中，更安全的做法是：1）通过此变量创建初始管理员用户；2）登录后立即修改密码；3）后续用户通过 AWS 控制台、CLI 或 SCIM 同步等方式添加。模块也输出了cognito_user_pool_id，方便你使用aws cognito-idp admin-create-user命令以编程方式添加用户。
extra_bedrock_models：模块已经预置了一批常见的 Bedrock 模型（如 Claude 3 Haiku/Sonnet， Nova Lite/Pro）。这个变量允许你添加未在默认列表中的模型，比如新发布的模型或特定区域的模型。你需要提供模型的推理配置标识符 (Inference Profile ID)，格式如us.meta.llama3-1-70b-instruct-v1:0。你可以在 AWS 控制台的 Bedrock 模型访问页面找到这个 ID。
alarm_emails：模块会创建 CloudWatch 警报，监控 ALB 的 5xx 错误、目标响应时间、不健康主机数等关键指标。当警报触发时，会通过 SNS 邮件通知这里设置的邮箱。这是生产运维不可或缺的一环，建议至少设置一个团队邮箱。

4. 完整部署流程与实操要点

假设你已经有了一个配置好公网和私网子网的 VPC，以及一个 Route53 托管域名，下面我们一步步走完从零部署到首次登录的完整流程。

4.1 环境准备与权限配置

在运行 Terraform 之前，确保你的 AWS CLI 已配置好具有足够权限的凭证。执行 Terraform 的用户或角色需要以下关键权限：

EC2：创建实例、安全组、密钥对、启动模板、Auto Scaling 组。
IAM：创建实例角色和策略。
VPC：创建负载均衡器、目标组、监听器。
Cognito：创建用户池、应用客户端、域名。
Route53：在指定托管区域中创建和验证记录。
ACM：申请和验证证书（模块会自动处理）。
Secrets Manager：创建和管理密钥。
EFS：创建文件系统、挂载目标、备份策略。
CloudWatch：创建日志组、指标警报、SNS 主题。

一个简单的策略是临时使用具有AdministratorAccess权限的凭证进行首次部署。在生产环境中，应遵循最小权限原则，根据模块创建的精确资源类型来定制 IAM 策略。

在你的项目目录中，创建以下文件结构：

your-project/ ├── main.tf # 包含上述 module "openclaw" 的配置 ├── variables.tf # 输入变量定义（可选） ├── outputs.tf # 输出变量定义（可选） └── terraform.tfvars # 变量赋值文件（建议，避免密码泄露）

在terraform.tfvars中，你可以设置敏感度较低的变量，但像cognito_users这种包含邮箱的信息，建议还是放在非版本控制的文件中或通过环境变量传入。

4.2 初始化与规划部署

打开终端，进入项目目录，执行以下命令：

# 初始化 Terraform，下载模块和 Provider terraform init # 检查配置语法 terraform validate # 生成执行计划，预览将要创建的资源 terraform plan -out=tfplan

仔细查看terraform plan的输出。你会看到它将创建大约 30-40 项 AWS 资源，包括 ALB、Cognito 用户池、EC2 启动模板、ASG、EFS、CloudWatch 日志组等。确认无误后，进行部署。

4.3 执行部署与监控进度

# 应用计划，开始创建资源 terraform apply tfplan

apply过程通常需要15 到 25 分钟。耗时最长的步骤通常是：

ACM 证书颁发和验证：模块会为你的域名创建证书，并自动在 Route53 中添加 CNAME 记录来完成 DNS 验证。这需要几分钟时间等待 AWS 和 DNS 传播。
EC2 实例启动和初始化：实例启动后，会执行cloud-init脚本，依次安装 Node.js、Ollama、OpenClaw，拉取指定的 Ollama 模型，并配置 systemd 服务。拉取一个几 GB 的模型文件可能会花费较长时间，取决于网络速度和模型大小。
ALB 目标组健康检查：服务启动后，ALB 会对实例进行健康检查，直到返回成功状态，实例才会被注册到目标组并开始接收流量。

你可以通过以下方式监控部署进度：

CloudWatch Logs：查看/var/log/cloud-init-output.log流，这是实例初始化脚本的输出。
EC2 实例控制台：查看实例的状态检查和系统日志。
ALB 控制台：查看目标组的健康状态。

4.4 获取访问凭证与首次登录

部署成功后，Terraform 会输出一系列重要信息：

terraform output

关键输出包括：

url：OpenClaw 的访问地址，例如https://openclaw.yourdomain.com。
cognito_user_pool_id：Cognito 用户池 ID，用于管理用户。
ssh_private_key：如果未指定key_name，模块会生成一个密钥对，并输出私钥。请妥善保存此私钥，这是你 SSH 登录到后端 EC2 实例的唯一方式（出于安全考虑，实例在私网子网，通常需要通过堡垒机或 SSM Session Manager 访问，但私钥是备用方案）。

首次登录流程：

在浏览器中打开输出的url。
你将被重定向到 AWS Cognito 的托管登录页面。
使用你在cognito_users中配置的邮箱登录。初始密码在哪里？它被打印在 Terraformapply的输出中（标记为sensitive），你也需要从 Terraform 输出中获取。一个更安全的方法是使用 AWS CLI 为相应用户设置临时密码：
```
aws cognito-idp admin-set-user-password \ --user-pool-id <你的用户池ID> \ --username <用户邮箱> \ --password <你的新密码> \ --permanent
```
登录成功后，浏览器将被重定向回 OpenClaw 的 Web 界面。

4.5 配置 LLM 提供商

首次进入 OpenClaw 界面，你可能看不到可用的模型。这是因为除了默认的 AWS Bedrock（使用 IAM 角色认证，无需额外配置）外，其他提供商需要手动添加 API 密钥。

找到密钥存储位置：Terraform 输出中的secret_arn和secret_name指明了 Secrets Manager 中存储密钥的机密。
添加 API 密钥：前往 AWS 控制台的 Secrets Manager，找到对应的机密。点击“检索机密值”，然后点击“编辑”。你会看到一个初始的 JSON 结构：
```
{ "OPENAI_API_KEY": "", "ANTHROPIC_API_KEY": "" }
```
将你的 OpenAI 或 Anthropic API 密钥填入对应的字段。保存更改。
重启 OpenClaw 服务：为了让实例上的应用读取到新的密钥，需要重启服务。你可以 SSH 到实例上执行：
```
sudo systemctl restart openclaw
```
或者更优雅地，通过替换实例来触发滚动更新（如果你熟悉 ASG 生命周期钩子或使用 CodeDeploy）。
刷新界面：等待几分钟后刷新 OpenClaw 网页，对应的模型提供商（如 OpenAI GPT-4, Anthropic Claude）就应该出现在模型选择列表中了。

实操心得：Secrets Manager 的密钥更新不是实时同步到实例的。实例在启动时通过cloud-init从 Secrets Manager 读取一次并写入本地环境变量文件。因此，更新密钥后，必须重启应用进程才能生效。一种更自动化的模式是使用 Secrets Manager 的 Lambda 轮换功能，或者在 user data 中编写脚本定期拉取最新密钥，但这会增加复杂性。对于不常变动的 API 密钥，手动重启是可以接受的。

5. 安全加固与运维管理

模块已经内置了相当多的安全最佳实践，但在投入生产前，你还需要考虑以下几个层面：

5.1 网络访问精细化控制

模块默认允许0.0.0.0/0访问 ALB，依赖 Cognito 做应用层认证。在某些严格的内网环境中，你可能希望进一步限制网络层访问。

使用allowed_cidrs变量：将其设置为公司办公网的 IP 段，例如["203.0.113.0/24", "198.51.100.0/24"]。这样，只有来自这些 IP 的请求才能到达 ALB。
考虑 VPC 端点：如果后端 EC2 实例需要访问的 AWS 服务（如 Secrets Manager, Bedrock）在公有端点，流量会经过 NAT 网关。对于高安全要求或节省 NAT 流量成本，可以为这些服务创建 VPC 端点 (Gateway 或 Interface Endpoint)，让流量在 AWS 内部网络流转。

5.2 密钥管理与轮换

API 密钥的写入权限：模块的api_keys_writers变量允许你指定哪些 IAM 角色可以写入 Secrets Manager 中的密钥。在生产中，应该将其限制为特定的运维角色或 CI/CD 系统的角色，而不是部署模块的 Terraform 执行角色本身，实现职责分离。
Cognito 用户密码策略：模块创建的 Cognito 用户池使用了 AWS 的默认密码策略。你可以在部署后，通过 AWS 控制台或后续的 Terraform 资源，加强密码策略，如要求最小长度、包含大小写字母和数字、设置密码过期时间等。
SSH 密钥管理：如果使用模块自动生成的密钥对，务必安全地保存输出的私钥。更好的做法是使用 AWS Systems Manager Session Manager 来访问实例，完全避免在互联网上开放 SSH 端口和管理密钥。这需要对实例角色附加AmazonSSMManagedInstanceCore策略，并在你的本地环境配置 AWS CLI 和 Session Manager 插件。

5.3 监控、日志与告警

模块已经配置了基础的 CloudWatch 告警（5xx错误、高延迟、不健康主机）。你还需要关注：

应用日志：OpenClaw 和 Ollama 的日志通过 systemd 的 journald 导出到 CloudWatch Logs。你可以在输出的cloudwatch_log_group_name对应的日志组中查看/var/log/openclaw.log和/var/log/ollama.log。可以设置日志指标过滤器，来监控错误关键词或高频事件。
成本监控：尤其是当使用 Bedrock 或第三方 API 时，模型推理成本可能快速增加。建议在 AWS Cost Explorer 中为这个环境创建成本分配标签（模块会为资源添加Environment和Service标签），并设置预算告警。
Ollama 模型内存使用：如果实例内存不足，除了性能下降，还可能被 OOM Killer 终止进程。可以创建一个自定义的 CloudWatch 代理，收集MemAvailable或SwapUsed指标，并设置警报。

5.4 备份与灾难恢复

EFS 备份：模块默认启用了 EFS 的 AWS Backup 策略，这是数据持久化的核心。确保你了解备份的保留周期和恢复流程。
Terraform 状态文件：这是你整个基础设施的蓝图。务必使用远程后端（如 S3 + DynamoDB）存储状态文件，并启用版本控制。丢失状态文件将使管理现有资源变得极其困难。
定期演练恢复流程：在一个隔离的 AWS 账户或区域，尝试使用你的 Terraform 代码和状态文件重新部署整个栈。这能验证你的代码和流程的可靠性。

6. 常见问题与故障排查实录

在实际部署和使用中，你可能会遇到以下问题。这里记录了我踩过的坑和解决方法。

6.1 部署失败：ACM 证书验证超时

现象：terraform apply卡在aws_acm_certificate_validation资源，长时间不前进，最终超时失败。原因：模块尝试在 Route53 中为你的域名创建用于验证的 CNAME 记录，但 DNS 传播可能需要时间，或者你的 Route53 托管区域权限配置有误。排查：

检查zone_id输入是否正确，确保执行 Terraform 的 IAM 角色/用户有对该托管区域的route53:ChangeResourceRecordSets权限。
前往 Route53 控制台，查看对应托管区域是否成功添加了_random_string.acm开头的 CNAME 记录。
手动在命令行使用dig或nslookup查询该 CNAME 记录，看是否已解析到 AWS 提供的值。解决：如果权限和记录都已存在但验证仍慢，可以尝试增加aws_acm_certificate_validation资源中的timeouts配置（这需要你 fork 或自定义模块）。更简单的方法是，先手动在 ACM 中申请并验证好证书，然后将证书的 ARN 通过变量传入模块（当前版本模块不支持传入现有证书 ARN，这是一个潜在的改进点）。

6.2 服务不可用：ALB 返回 502 Bad Gateway

现象：能打开登录页面，但登录后或访问应用时出现 502 错误。原因：后端 EC2 实例上的 OpenClaw 或 Ollama 服务没有正常运行，或者健康检查失败。排查步骤：

检查 ALB 目标组：在 EC2 控制台 -> 负载均衡 -> 目标组，找到模块创建的目标组，查看“目标”选项卡中实例的健康状态。如果是“unhealthy”或“unused”，点击查看“健康检查详情”，看失败原因（如超时、返回非200状态码）。
检查实例系统日志：在 EC2 控制台选中实例，点击“操作”->“监视和故障排除”->“获取系统日志”。查看启动过程中是否有错误，特别是cloud-init执行失败。
检查应用日志：通过 Session Manager 或 SSH 连接到实例（如果网络可达）。查看服务状态：
```
sudo systemctl status openclaw sudo systemctl status ollama
```
查看具体的应用日志：
```
sudo journalctl -u openclaw -f sudo journalctl -u ollama -f
```
CloudWatch Logs 中的对应日志流也是重要的信息来源。常见原因与解决：

端口冲突：OpenClaw 默认运行在 3000 端口，Ollama 在 11434。确保没有其他进程占用。
内存不足：如果ollama_default_model设置的模型太大，而instance_type内存太小，Ollama 会启动失败或运行崩溃。查看dmesg或系统日志是否有 OOM（内存耗尽）记录。解决方案是选择更大内存的实例类型，或设置ollama_default_model = null暂时禁用本地模型。
Secrets Manager 权限：实例角色需要权限从 Secrets Manager 读取密钥。检查实例的 IAM 角色是否附加了正确的策略。模块应该已经处理了，但如果是自定义角色，请确保包含secretsmanager:GetSecretValue权限。

6.3 模型不显示：API 密钥未生效

现象：登录 OpenClaw 后，模型列表里只有 Bedrock 模型，没有 OpenAI 或 Anthropic 的模型。排查：

确认密钥已保存：在 Secrets Manager 中确认OPENAI_API_KEY或ANTHROPIC_API_KEY字段已填入有效的密钥，且没有多余的空格或换行。
确认服务已重启：更新密钥后，必须重启 OpenClaw 服务（sudo systemctl restart openclaw）。你可以检查服务重启后的日志，看是否有读取新密钥的记录。
检查环境变量：在实例上执行sudo cat /etc/systemd/system/openclaw.service.d/10-environment.conf，查看服务加载的环境变量文件路径，然后检查该文件是否包含从 Secrets Manager 获取的最新密钥值。
检查 OpenClaw 配置：OpenClaw 的配置文件通常在 EFS 挂载点下，如/mnt/efs/openclaw/.openclaw/config.json。检查其中providers部分是否配置正确。但请注意，模块采用“深度合并”策略，Terraform 管理基础配置，UI 的修改会持久化在 EFS 上。如果 UI 里添加了提供商但这里没有，可能是配置未同步。

6.4 性能问题：响应缓慢或超时

现象：使用本地 Ollama 模型时，响应非常慢，甚至超时。排查：

检查实例监控：在 CloudWatch 中查看实例的CPUUtilization、MemoryUtilization和EBSReadOps/EBSWriteOps。如果内存使用率持续高于 90%，或交换内存 (SwapUsage) 很高，说明实例规格不足。
检查 Ollama 日志：查看 Ollama 日志中是否有loading model或GPU相关的警告。在没有 GPU 的实例上运行大模型，纯靠 CPU 推理会非常慢。
检查网络延迟：如果使用的是云 API 模型（如 OpenAI），延迟可能来自你的 VPC 到互联网出口。考虑使用 VPC 端点（如果服务支持）或确保 NAT 网关有足够的带宽。
调整 ALB 超时设置：默认情况下，ALB 与目标的空闲超时是 60 秒。对于生成长文本的 LLM 请求，这个时间可能不够。你可以在部署后，手动修改 ALB 目标组的属性，增加“空闲超时”值。但请注意，这需要权衡，过长的超时会占用 ALB 连接资源。

6.5 成本优化建议

实例选型：如果不使用 Ollama 本地模型，将instance_type降为t3.medium或t3.small可以显著节省成本。使用t3系列时，启用“无限模式”可以应对突发 CPU credits 需求，但需注意额外费用。
Auto Scaling 策略：目前模块使用固定容量（默认最小、最大、期望容量均为 1）。对于有明显使用波动的场景（如只在工作时间使用），可以自定义 Auto Scaling 策略，基于 CloudWatch 指标（如 ALB 请求数）在非高峰时段缩容到 0，高峰时段扩容。但注意，缩容到 0 会导致 EFS 挂载点卸载，可能需要额外的 user data 脚本来处理。
EFS 存储类型：模块创建的是通用性能模式的 EFS。如果 IOPS 需求很低，可以手动将其更改为“弹性吞吐量”模式以节省成本。
CloudWatch Logs 保留期：模块默认保留日志 365 天以满足审计要求。如果不需要，可以修改aws_cloudwatch_log_group资源的retention_in_days参数，缩短保留期以降低成本。

这个terraform-aws-openclaw模块将一个复杂的生产级 AI 应用部署抽象化、产品化，让团队能够快速获得一个安全、可扩展、可观测的 OpenClaw 环境。它的价值不仅在于节省了手动编写数百行 Terraform 代码的时间，更在于它集成了经过实战检验的安全和运维模式。在使用的过程中，理解其架构设计、熟练掌握配置参数的含义、并建立一套针对性的监控和故障排查流程，是确保其稳定运行的关键。对于希望将 AI 能力安全、可控地引入内部工作流的团队来说，这是一个非常值得投入的解决方案。

查看全文

http://www.jsqmd.com/news/813631/