1. 项目概述：为什么我们需要一个专为 Dify 的 AWS CDK 项目？

如果你正在使用或评估 Dify 这个开源 LLM 应用开发平台，并且你的技术栈深度绑定 AWS 云服务，那么你很可能已经遇到了一个核心痛点：如何将 Dify 稳定、高效、可维护地部署到 AWS 上？手动在 AWS 控制台点点点，配置 VPC、EC2、RDS、ALB、S3 等一系列服务，不仅耗时费力，更致命的是缺乏可重复性和版本控制。一次成功的部署，其配置细节可能散落在团队的聊天记录和个人笔记里，下一次部署或环境重建，无异于一场灾难。

这正是 langgenius/aws-cdk-for-dify 这个项目要解决的核心问题。它不是一个简单的部署脚本，而是一个基于 AWS CDK（Cloud Development Kit）的、声明式的 IaC（基础设施即代码）解决方案。简单来说，它用你熟悉的编程语言（TypeScript/Python 等）来“描述”你想要的 Dify 运行环境，然后由 CDK 框架自动将其编译成 AWS CloudFormation 模板，并一键式地在你的 AWS 账户中创建出所有必要的资源。

这个项目的价值远不止于“一键部署”。它带来的是一种工程范式的转变：将你的基础设施定义为代码，使其可以像应用程序代码一样进行版本管理、代码审查、自动化测试和持续部署。对于需要维护开发、测试、生产多套环境的团队，或者计划将 Dify 作为产品核心组件对外提供服务的场景，这种能力至关重要。它确保了环境的一致性，极大地降低了运维复杂度和人为错误风险，是 Dify 走向生产级应用不可或缺的一环。

2. 架构设计与核心组件拆解

2.1 整体架构蓝图

aws-cdk-for-dify 项目设计的架构，充分考虑了 Dify 作为数据驱动型 AI 应用平台的特点：既有 Web 前端和 API 后端这类无状态服务，也有 PostgreSQL 数据库、Redis 缓存、向量数据库（如 Weaviate/OpenSearch）等有状态服务，同时还需要处理文件上传、模型推理等异步或计算密集型任务。

一个典型的高可用生产架构会包含以下层次：

1. 网络层 ：构建在一个独立的 VPC 内，通过公有子网和私有子网进行隔离。应用服务器通常部署在私有子网，通过 NAT 网关访问外网以下载模型和依赖；负载均衡器（ALB）部署在公有子网，接收外部流量。
2. 计算层 ：Dify 的核心服务（API Server 和 Worker）通常被部署在 Amazon ECS（弹性容器服务）上，以 Fargate 模式运行。Fargate 是 Serverless 容器服务，你无需管理底层 EC2 服务器，只需定义 CPU 和内存，AWS 负责资源的调配和运维，极大地简化了容器管理。这比直接部署在 EC2 上更符合云原生理念，也更容易实现弹性伸缩。
3. 数据层 ：
   • 关系型数据库 ：使用 Amazon RDS for PostgreSQL 作为主数据库，存储用户、应用、对话等核心元数据。RDS 提供了自动备份、多可用区部署、读写分离等高可用特性。
   • 缓存 ：使用 Amazon ElastiCache for Redis 作为缓存层，用于会话存储、任务队列状态和临时数据缓存，显著提升应用响应速度。
   • 向量数据库 ：这是 AI 应用的关键。项目可能支持集成 Amazon OpenSearch Service（内置向量引擎）或通过容器部署第三方向量数据库（如 Weaviate）。用于存储和检索由文本嵌入模型生成的向量，实现语义搜索和记忆功能。
   • 对象存储 ：使用 Amazon S3 存储用户上传的文件（如图片、文档）、应用生成的音频/视频文件，以及作为模型权重的备份存储。
4. 安全与访问控制 ：所有资源通过 IAM 角色和策略进行权限控制。Secrets Manager 用于安全地存储和管理数据库密码、API 密钥等敏感信息。安全组充当虚拟防火墙，严格控制各服务间的网络访问。

2.2 关键 AWS 服务选型解析

为什么是这些服务？这背后是成本、性能、运维复杂度与 AWS 最佳实践的权衡。

• ECS Fargate vs. EC2 Auto Scaling Group ：对于 Dify 这类中等复杂度的应用，Fargate 的优势明显。你无需预置、打补丁或扩展虚拟机集群，也无需为闲置的 EC2 资源付费。计费精确到 vCPU 和内存每秒，弹性伸缩的响应速度也更快。虽然 Fargate 的单价略高于 EC2，但节省的运维成本和闲置资源成本往往能覆盖差价。只有当你有极特殊的定制化需求（如需要特定的 GPU 驱动、内核模块）或对成本极度敏感且能精准预测负载时，才需要考虑 EC2。
• RDS PostgreSQL vs. 自建数据库 ：除非你的团队有非常资深的 DBA，否则永远应该选择 RDS。它自动化了备份、软件更新、故障检测和恢复等繁重工作。多可用区部署能在基础设施故障时实现分钟级的自动故障转移，这是自建数据库难以企及的高可用保障。
• OpenSearch Service vs. 自托管向量库 ：OpenSearch Service 是托管服务，同样省去了运维 Elasticsearch/OpenSearch 集群的麻烦。它原生支持 k-NN 向量搜索，与 AWS 生态集成好（如通过 VPC 端点安全访问）。如果你的向量搜索规模不大，或者不想维护另一个数据库集群，这是一个稳妥的选择。但如果你需要更专业的向量数据库功能（如 Weaviate 的模块化设计、Qdrant 的性能），项目也可能提供在 ECS 上部署这些数据库的选项，这带来了更大的灵活性，但也增加了运维负担。
• Application Load Balancer (ALB) ：ALB 工作在应用层（HTTP/HTTPS），可以根据路径或主机名将流量路由到不同的后端服务（例如，将 /api/* 的请求路由到 Dify API 服务，将 / 的请求路由到前端服务）。它还能处理 SSL 终止，减轻后端服务的计算压力，并集成 WAF 提供 Web 应用防火墙能力。

注意 ：架构设计并非一成不变。 aws-cdk-for-dify 项目通常会提供配置参数，允许你根据实际需求“开关”某些组件。例如，在开发测试环境中，你可能会使用单可用区的 RDS 实例以节省成本；而在生产环境，则必须启用多可用区部署。

3. 项目代码结构与核心逻辑实现

3.1 CDK 栈（Stack）的组织艺术

一个优秀的 CDK 项目，其代码结构应该是清晰且符合逻辑的。 aws-cdk-for-dify 很可能采用多栈（Multi-Stack）设计，将不同生命周期或职责的资源分离到不同的 CloudFormation 栈中。这是一种最佳实践，因为它允许你独立地更新、回滚或销毁某一部分资源，而不会影响其他部分。

常见的栈划分可能包括：

• 网络基础栈 (NetworkStack) ：创建 VPC、子网、NAT 网关、VPC 端点等共享网络基础设施。这个栈通常是最稳定、变更最少的，可以被其他所有栈引用。
• 数据存储栈 (DataStack) ：创建 RDS、ElastiCache、OpenSearch 等有状态的数据存储资源。这些资源创建和删除耗时较长，且包含重要数据，独立成栈便于管理和保护。
• 应用服务栈 (AppStack) ：创建 ECS 集群、Fargate 服务、任务定义、ALB 等计算和负载均衡资源。这个栈会频繁更新，例如当你更新 Dify 的 Docker 镜像版本时。
• CI/CD 栈 (CICDStack, 可选) ：创建 CodePipeline、CodeBuild 等资源，用于实现基础设施和应用程序的持续部署。

在 lib/ 目录下，你可能会看到对应的 TypeScript 文件，如 network-stack.ts , data-stack.ts , app-stack.ts 。每个栈都是一个继承自 aws-cdk-lib.Stack 的类。主入口文件 bin/aws-cdk-for-dify.ts 负责实例化并组装这些栈。

3.2 核心资源配置详解

让我们深入一个关键栈，看看它是如何定义资源的。以 AppStack 为例，它需要创建一个能够运行 Dify 的 ECS Fargate 服务。

1. 创建 ECS 集群与任务定义

// 创建一个新的 ECS 集群，使用 Fargate 作为容量提供者
const cluster = new ecs.Cluster(this, 'DifyCluster', {
  vpc: props.vpc, // 从 NetworkStack 传入的 VPC
  containerInsights: true, // 启用 Container Insights，便于监控
});

// 创建任务定义，这是容器的“蓝图”
const taskDefinition = new ecs.FargateTaskDefinition(this, 'DifyTaskDef', {
  memoryLimitMiB: 4096, // 任务内存限制
  cpu: 2048, // 任务 CPU 单位 (1024 = 1 vCPU)
});

// 从 Docker Hub 或 ECR 添加容器
const apiContainer = taskDefinition.addContainer('DifyApiContainer', {
  image: ecs.ContainerImage.fromRegistry('langgenius/dify-api:latest'), // 建议固定版本标签，而非 latest
  logging: ecs.LogDrivers.awsLogs({ streamPrefix: 'DifyApi' }), // 日志自动发送到 CloudWatch
  environment: { // 环境变量
    MODE: 'production',
    DB_HOST: props.database.dbInstanceEndpointAddress, // 从 DataStack 传入
    REDIS_HOST: props.redis.attrRedisEndpointAddress,
  },
  secrets: { // 从 Secrets Manager 获取的敏感信息
    DB_PASSWORD: ecs.Secret.fromSecretsManager(props.dbSecret, 'password'),
  },
  healthCheck: { // 健康检查配置
    command: ['CMD-SHELL', 'curl -f http://localhost:5001/health || exit 1'],
    interval: Duration.seconds(30),
    timeout: Duration.seconds(5),
    retries: 3,
  },
});
// 映射容器端口
apiContainer.addPortMappings({ containerPort: 5001 });

这里的关键点在于，所有配置（如数据库地址、Redis 地址）都不是硬编码的，而是通过 props 从其他栈传入，或者从 Secrets Manager 动态获取，实现了栈间的解耦和安全的信息传递。

2. 创建 Fargate 服务并关联负载均衡器

// 创建 Fargate 服务
const apiService = new ecs.FargateService(this, 'DifyApiService', {
  cluster,
  taskDefinition,
  desiredCount: 2, // 期望运行的任务数量，用于高可用
  assignPublicIp: false, // 任务在私有子网运行，无需公网 IP
  vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
  securityGroups: [apiSecurityGroup],
});

// 创建应用负载均衡器
const alb = new elbv2.ApplicationLoadBalancer(this, 'DifyALB', {
  vpc: props.vpc,
  internetFacing: true,
});

// 添加监听器，将 80 端口重定向到 443
alb.addRedirect();

const listener = alb.addListener('HttpsListener', {
  port: 443,
  certificates: [certificate], // 需要预先在 ACM 申请或导入 SSL 证书
});

// 将 ALB 目标指向 ECS 服务
listener.addTargets('DifyApiTarget', {
  port: 80,
  targets: [apiService],
  healthCheck: {
    path: '/health',
    interval: Duration.seconds(60),
  },
});

这段代码构建了完整的访问链路：用户通过 HTTPS 访问 ALB，ALB 将请求转发到私有子网中运行的 Fargate 任务。 desiredCount: 2 确保了至少有两个任务实例在运行，如果一个实例或可用区发生故障，ALB 会自动将流量路由到健康的实例。

3.3 环境变量与敏感信息管理

Dify 的配置高度依赖环境变量。CDK 项目会系统地管理这些变量：

• 非敏感配置 ：如 LOG_LEVEL , CONSOLE_API_URL ，直接通过 environment 属性设置。
• 敏感信息 ：如数据库密码、第三方 API 密钥，必须通过 secrets 属性，从 AWS Secrets Manager 中引用。CDK 可以自动为任务执行角色授予读取特定 Secret 的权限。最佳实践是，在部署前，先手动或在 CI/CD 流水线中，将密码存入 Secrets Manager，然后在 CDK 代码中通过 ARN 引用。 绝对不要 将密码明文写在代码或配置文件中。

4. 部署流程与实操指南

4.1 前期准备与环境配置

在运行 cdk deploy 之前，你需要完成以下准备工作：

1. 安装必备工具 ：确保本地已安装 Node.js (>=16), AWS CLI，并配置好具有足够权限的 AWS 访问密钥和密钥对。通过 aws configure 命令进行配置。
2. 获取项目代码 ： git clone https://github.com/langgenius/aws-cdk-for-dify.git 并进入项目目录。
3. 安装依赖 ：运行 npm install 安装项目所需的 CDK 库和其他依赖包。
4. 引导 CDK 环境（首次使用） ：在目标 AWS 账户和区域执行 cdk bootstrap 。这个命令会创建一个 S3 桶和一个 CloudFormation 栈，用于存储部署过程中生成的模板和资源。每个账户/区域组合只需执行一次。
5. 准备敏感信息 ：在 AWS Secrets Manager 控制台创建新的密钥。例如，创建一个名为 Dify/Database 的密钥，以键值对形式存储 username 和 password 。记录下此密钥的 ARN。
6. 修改配置文件 ：项目根目录下通常会有一个 config.ts 或 context 文件。你需要根据你的需求修改配置：

   // config.ts 示例
   export const config = {
     env: {
       account: '123456789012', // 你的 AWS 账户 ID
       region: 'us-east-1',
     },
     dify: {
       apiImageTag: '0.6.0', // 指定 Dify API 镜像版本
       workerImageTag: '0.6.0', // 指定 Dify Worker 镜像版本
     },
     database: {
       instanceType: 't3.medium', // RDS 实例类型
       allocatedStorage: 100, // 存储空间 (GB)
       masterUsername: 'difyadmin', // 主用户名，密码从 Secrets Manager 获取
       secretArn: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:Dify/Database-xxxxx',
     },
     vpc: {
       cidr: '10.0.0.0/16', // VPC 的 IP 地址范围
       maxAzs: 2, // 使用的最大可用区数量
     },
     // ... 其他配置
   };
   

   请务必根据你的实际情况调整账户 ID、区域、实例类型、镜像版本和密钥 ARN。

4.2 部署执行与验证

配置完成后，即可开始部署。CDK 提供了强大的命令行工具来管理整个生命周期。

1. 合成 CloudFormation 模板 ：运行 cdk synth 。这个命令会执行你的 TypeScript 代码，生成一个或多个 CloudFormation 模板（JSON/YAML 格式），但不会真正部署任何资源。这是一个重要的安全检查步骤，你可以查看生成的模板是否符合预期。
2. 查看变更集 ：在部署前，运行 cdk diff 。这个命令会对比当前已部署的栈状态和即将部署的模板，清晰地列出所有将要创建、修改或删除的资源。 务必仔细审查这个输出 ，确认没有意外的变更。
3. 执行部署 ：运行 cdk deploy --all 。 --all 参数会部署所有在 app 中定义的栈。CDK 会先在 CloudFormation 中创建一个变更集，然后提示你确认是否执行。输入 y 后，部署正式开始。你可以在 AWS CloudFormation 控制台实时查看每个栈的创建进度。
4. 验证部署结果 ：
   • 部署完成后，CDK 会在命令行输出关键资源的输出值，如 ALB 的 DNS 名称（例如 DifyALB-XXXXXXXXXX.us-east-1.elb.amazonaws.com ）。
   • 在浏览器中访问 https://<你的ALB DNS> ，你应该能看到 Dify 的登录界面。
   • 通过 AWS 控制台检查各个服务：ECS 服务中的任务是否处于 RUNNING 状态？RDS 实例是否可用？CloudWatch Logs 中是否有应用日志且无大量错误？

4.3 日常运维与更新

基础设施一旦建立，日常的更新操作也变得标准化：

• 更新 Dify 版本 ：只需修改 config.ts 中的 apiImageTag 和 workerImageTag ，然后再次运行 cdk deploy 。CDK 会生成一个新的 ECS 任务定义（因为镜像改变了），并触发 ECS 服务的滚动更新，逐步用新容器替换旧容器，实现零停机更新。
• 调整资源规格 ：如果需要增加数据库存储空间或调整 ECS 任务的 CPU/内存，同样修改配置后部署即可。CDK/CloudFormation 会处理资源的原地更新或替换（某些属性更新需要替换资源，CloudFormation 会先创建新资源再删除旧资源）。
• 销毁环境 ：当不再需要该环境时，运行 cdk destroy --all 。 警告：此操作将删除该 CDK 应用创建的所有资源，包括数据库中的数据！ 请务必提前做好数据备份。

5. 常见问题与深度排查指南

即使有完善的 IaC，在实际部署和运行中仍可能遇到问题。以下是基于经验的排查思路。

5.1 部署阶段故障

问题1：CDK 部署失败，提示“IAM 角色权限不足”

• 排查 ：这是最常见的问题。CDK 部署需要一个具有足够权限的角色。确保你 AWS CLI 配置的凭证所属的 IAM 用户或角色，拥有以下关键权限： cloudformation:* , iam:* , ec2:* , ecs:* , rds:* , elasticache:* , s3:* (用于 bootstrap), secretsmanager:GetSecretValue 等。最简便的方式是附加管理员权限进行首次部署测试，但在生产环境中应遵循最小权限原则，创建细粒度的策略。
• 解决 ：为部署用户创建专属策略，或使用 CDK 的 PermissionsBoundary 特性。

问题2：RDS 实例创建失败，提示“存储类型不支持”或“实例类在所选区域不可用”

• 排查 ：检查 config.ts 中配置的 RDS 实例类型（如 db.t3.medium ）和存储类型（如 gp3 ）是否在你选择的 AWS 区域（Region）内可用。不同区域支持的实例类型有差异。
• 解决 ：查阅 AWS 官方文档，确认该区域可用类型，并修改配置。也可以先尝试使用更通用的类型，如 db.t3.micro （仅用于测试）。

问题3：ECS 任务无法启动，停留在 PENDING 状态

• 排查 ：进入 ECS 控制台，查看该任务的“停止”原因。常见原因有：
  1. 资源不足 ：Fargate 在指定可用区暂时没有足够的资源来放置你的任务。这通常发生在请求大量资源或冷门可用区时。
  2. 镜像拉取失败 ：检查任务定义中的镜像地址是否正确，以及 ECS 任务执行角色是否有权限从 Docker Hub 或 ECR 拉取镜像。对于私有镜像，需要配置正确的仓库认证信息。
  3. 子网或安全组配置错误 ：任务所在的子网没有路由到 NAT 网关（无法拉取外网镜像），或者安全组规则过于严格，阻止了任务与 Secrets Manager、CloudWatch Logs 等必需服务的通信。
• 解决 ：
  • 对于资源不足，可以尝试减少任务数量、更换实例规格，或切换到另一个可用区。
  • 对于镜像问题，确认镜像存在且可公开访问，或配置好私有仓库认证。
  • 对于网络问题，检查 VPC 的 NAT 网关配置，并确保任务的安全组有允许出站流量到 0.0.0.0/0 （或至少到必要的服务端点）的规则。

5.2 运行阶段故障

问题4：应用能访问，但无法连接数据库或 Redis

• 排查 ：
  1. 检查安全组 ：这是首要怀疑对象。确保 ECS 任务所在安全组的入站规则，允许来自自身安全组（或 ALB 安全组）的流量访问数据库/Redis 端口（通常是 5432 和 6379）。同时，出站规则必须允许访问数据库/Redis 的安全组。
  2. 检查网络位置 ：RDS 和 ElastiCache 是否创建在私有子网？ECS 任务是否也在同一 VPC 的私有子网？它们之间应能通过内网 IP 直接通信。
  3. 检查 Secrets Manager ：查看 ECS 任务的日志（CloudWatch Logs），确认是否成功获取到了数据库密码。任务执行角色必须有 secretsmanager:GetSecretValue 权限。
• 解决 ：逐项核对并修正安全组规则。一个简单的测试方法是，在同一个 VPC 内启动一个临时的 EC2 实例（测试机），配置与 ECS 任务类似的安全组，尝试从该 EC2 用 psql 或 redis-cli 连接数据库/Redis，以隔离问题。

问题5：Dify 工作流执行失败，或向量检索无结果

• 排查 ：这通常指向 Worker 服务或向量数据库的问题。
  1. 检查 Worker 服务 ：确认 Worker 的 Fargate 服务是否正常运行，日志中是否有错误。Worker 负责执行异步任务，如图文理解、工作流执行等。
  2. 检查向量数据库连接 ：确认 Dify 配置中向量数据库的连接地址、端口、认证信息是否正确。查看 Dify API 日志中是否有向量库连接错误。
  3. 检查数据索引 ：如果连接正常但检索无结果，可能是文本嵌入模型未正常工作，或向量索引尚未建立。尝试在 Dify 后台创建一个简单的知识库并上传文档，观察索引过程是否报错。
• 解决 ：根据日志定位具体组件的问题。向量数据库的配置相对复杂，务必参考 Dify 官方文档和所选向量数据库的文档进行核对。

5.3 成本与优化建议

使用这套架构，主要成本产生于：

1. RDS 实例 ：按实例类型和运行时间计费，多可用区部署会产生备用实例的费用。
2. ElastiCache 节点 ：同样按节点类型和运行时间计费。
3. OpenSearch Service 域 ：按实例类型和数据存储计费，成本可能较高。
4. ECS Fargate ：按任务消耗的 vCPU 和内存资源计费。
5. ALB ：按使用时长和处理的 LCU 数量计费。
6. NAT 网关 ：按使用时长和处理的流量计费，这是一笔容易被忽略但可能不小的固定支出。

优化建议 ：

• 开发/测试环境 ：使用单可用区、小规格的 RDS 和 ElastiCache 实例。可以考虑使用定时开关机（通过 Instance Scheduler 或自定义脚本）来在非工作时间停止这些资源，大幅节省成本。
• 利用自动伸缩 ：为 ECS 服务配置基于 CPU/内存利用率的 Target Tracking 策略。在低负载时减少任务数量，在高负载时自动扩展。
• 监控与告警 ：利用 Amazon CloudWatch 设置账单告警，监控各服务的资源利用率。对利用率持续很低的 RDS 实例，考虑降级实例类型。
• 评估向量数据库选项 ：如果 OpenSearch 成本过高，可以评估在 ECS 上部署 Weaviate 或 Qdrant 等开源方案的成本效益，但这会转移一部分运维成本到你的团队。

6. 进阶：定制化与扩展场景

aws-cdk-for-diy 项目提供了一个坚实的生产就绪基线，但真实业务场景往往需要定制。

场景一：集成自定义域名与 HTTPS 证书 项目默认使用 ALB 的自动生成的 DNS 名称。在生产中，你需要自定义域名（如 dify.yourcompany.com ）和由 ACM 管理的 SSL 证书。

1. 在 AWS Certificate Manager (ACM) 中申请或导入一个针对你域名的证书。
2. 在 AppStack 中，将证书的 ARN 作为配置参数传入，并在创建 ALB 监听器时使用该证书。
3. 部署后，在 Route 53 或你的域名注册商处，将域名 CNAME 记录指向 ALB 的 DNS 名称。

场景二：为 Dify 配置外部模型供应商 Dify 的强大之处在于能对接多种大模型。除了在 Dify 管理后台配置，你也可以通过环境变量或 Secrets Manager 来注入这些 API 密钥。

1. 在 Secrets Manager 中创建存储 OpenAI、Anthropic 等 API 密钥的密钥。
2. 在 CDK 代码中，将这些密钥作为 secrets 添加到 Dify 的容器定义中，对应的环境变量名需符合 Dify 的要求（如 OPENAI_API_KEY ）。
3. 这样，密钥的管理完全由 AWS 负责，更安全，也便于轮换。

场景三：实现蓝绿部署或金丝雀发布 对于要求高可用性的生产环境，你可能希望实现更平滑的发布策略。这可以通过以下方式结合 CDK 和 ECS 实现：

1. 使用 CodeDeploy ：在 CDK 中创建 ECS 服务时，可以配置 deploymentController 为 DeploymentControllerType.CODEDEPLOY 。然后，你可以定义 CodeDeploy 部署组，指定蓝绿或金丝雀发布策略。
2. CDK Pipelines ：你可以使用 CDK Pipelines 模块构建一个完整的 CI/CD 流水线。当代码仓库中的 CDK 代码或应用镜像更新时，流水线会自动执行 cdk synth 和 cdk deploy ，并可以集成 CodeDeploy 进行高级部署。这实现了从代码提交到基础设施和应用更新的全自动化。

场景四：接入企业级监控与日志分析 CloudWatch 提供了基础监控。为了更深入的洞察，你可以：

1. 启用 Container Insights ：在创建 ECS 集群时设置 containerInsights: true ，可以获得容器层级的性能指标（如 CPU/内存使用率、网络流量）。
2. 结构化日志处理 ：确保 Dify 应用输出结构化日志（如 JSON 格式）。然后，可以配置 FireLens 作为 ECS 任务的日志路由器，将日志流式传输到 Amazon OpenSearch Service 进行集中分析和可视化，或者发送到 Kinesis Data Firehose 进行归档或进一步处理。
3. 自定义指标 ：利用 CloudWatch Embedded Metric Format (EMF)，从 Dify 应用代码中直接发送自定义业务指标（如“每日活跃工作流数”、“平均响应延迟”）到 CloudWatch。

通过 langgenius/aws-cdk-for-dify 这个项目，你获得的不仅仅是一个部署工具，而是一套符合云原生最佳实践、可扩展、可维护的 Dify 上云标准方案。它抽象了底层云资源的复杂性，让你能更专注于 Dify 应用本身的业务逻辑开发和优化。从手动运维到声明式 IaC 的转变，是团队技术成熟度的一个重要标志。