Dify Enterprise Edition 部署指南（AWS）
本文档介绍如何在 AWS 云环境中部署 Dify 企业版。您可以选择以下任一方式完成部署：- 通过 Terraform（推荐）
- 通过 CDK
- 手动创建基础设施并部署（不推荐）
选项一：通过 Terraform 构建
请联系 Dify 技术支持团队获取 Terraform 相关脚本和文档。
前提条件
- 本地已安装
kubectl、helm和aws cli。 - 拥有具备创建以下资源权限的 AWS 账号。
- AWS EKS（Elastic Kubernetes Service）：用于部署 Dify 核心服务，节点需能访问互联网或配置 NAT Gateway
- AWS S3（Simple Storage Service）：用于持久化存储
- AWS ECR（Elastic Container Registry）：用于 Dify 插件安装，也可用于托管 Dify 镜像与 Helm Chart
- AWS RDS Aurora Postgres：关系数据库，用于存储应用数据和审计记录
- AWS OpenSearch：向量数据库，用于 RAG（检索增强生成）相关功能
- Amazon ElastiCache：托管 Redis 缓存服务，用于加速数据访问
选项二：通过 CDK 构建
请参考 AWS CDK 部署。选项三：手动创建基础设施并部署
1. 创建基础设施
请参考下表推荐的配置，根据实际需求创建基础设施。（请将双括号中的内容替换为实际值）版本说明（重要）： 下表中的版本以“可用范围/版本系列”为参考。在实际部署前，请务必在目标 AWS Region 的控制台或通过 AWS CLI 校验对应服务当前支持的版本（EKS Kubernetes、Aurora PostgreSQL、OpenSearch、ElastiCache Redis 等），避免因区域差异或版本下线导致无法创建资源。
测试环境基础设施配置参考
注意： 若在单节点上启用 unstructured 服务，需将磁盘容量提升至 40 GB。
生产环境基础设施配置参考
此外，您还需要创建适当的虚拟私有云（VPC）和安全组（SG）以确保基础设施的安全性。
2. 配置 values.yaml
完成数据库、S3 等基础设施的创建后，请参考以下示例配置values.yaml（将双括号中的内容替换为实际值）。在此之前，您需要先在数据库中创建 dify、enterprise、audit、dify_plugin_daemon 四个数据库，并相应替换 values.yaml 中的 rds_main_database_name 等配置项。
3. 配置 S3 和 ECR 权限
为确保 Dify 服务正常启动及插件系统正常运行，api、worker、workerBeat、plugin_daemon 和 plugin_connector 服务需要 S3 访问权限，plugin_connector 服务还需要 ECR 访问权限。关于 plugin_connector 服务需要这些权限的具体原因，将在后文详细说明。
您可以通过以下两种方式配置权限：
- IRSA 模式：IAM Roles for Service Accounts，实现安全、精细的权限控制（推荐）
- Access Key（AK/SK）模式：通过环境变量提供凭证
IRSA 模式配置
Dify 推荐使用 IRSA 配置 ServiceAccount 权限。您可联系 Dify 技术支持团队获取一键部署(one_click) IRSA 脚本。 IRSA 通过 OIDC Provider 建立 EKS 集群与 IAM 之间的信任关系，使 Pod 能够通过 ServiceAccount 安全获取 AWS 权限，无需在 Pod 中配置 Access Key。整体架构如下：💡 关于 CRD 安装的特殊说明 Dify 企业版在安装时仅需 namespace 级别权限。但由于 CRD 本身是集群级别资源，安装时需要相应的集群权限。如果没有集群级别权限，可以先单独安装 CRD，再安装其余组件。CRD 本身只是注册到 Kubernetes 中的 API 结构声明，当其对应的 Controller 为 namespace 级别时，不具备跨 namespace 访问或修改其他资源的能力。
步骤 1：验证 IAM OIDC Provider
在配置 IRSA 之前，请确保集群已启用 IAM OIDC Provider。如果是手动创建的集群，建议通过eksctl 命令行工具来启用或验证。IAM OIDC Provider 建立了信任关系，允许 EKS 集群向 IAM 证明 Pod 的身份，从而让 Pod 能够安全地获取 AWS 权限。
步骤 2：创建 AWS IAM 策略
需要创建以下三个 IAM 策略： 策略 1：S3 访问策略（名称可自定义，如DifyS3Policy）
DifyECRPolicy）
用于插件镜像的推送和管理，包含 ECR 认证、仓库管理、镜像推送以及审计日志权限：
策略 3：ECR 只读拉取策略（名称可自定义，如{your_ecr_repo_prefix}为您的 ECR 仓库名称前缀。例如您在步骤 5 中配置imageRepoPrefix为123456789.dkr.ecr.us-east-1.amazonaws.com/dify-ee，则此处 ECR 仓库前缀为dify-ee，对应 Resource 应填写arn:aws:ecr:us-east-1:123456789:repository/dify-ee*。
DifyECRPullOnlyPolicy）
仅用于拉取插件运行时镜像：
步骤 3：创建 AWS IAM 角色
创建以下三个角色，并将步骤 2 中的策略附加到对应角色上（角色名称可自定义）：
获取对应的角色 ARN：
请将{oidc_id}替换为 EKS 集群的 OIDC Provider ID。可通过以下命令获取：
步骤 4：将角色绑定到 EKS 的 ServiceAccount
ServiceAccount（SA）是一种机制，允许 EKS 中的 Pod 获取特定的 AWS 权限，以访问云资源（如 S3）。创建以下四个 ServiceAccount，并将对应的角色 ARN 添加到
eks.amazonaws.com/role-arn 注解中：
创建 ServiceAccount 的示例命令（请将
$DIFY_EE_* 替换为步骤 3 中获取的角色 ARN）：
步骤 5：在 values.yaml 中配置 ServiceAccount
修改 Helm 的values.yaml，添加以下配置（以下仅展示 ServiceAccount 和 ECR 相关配置，其他配置省略）。imageRepoPrefix 可自定义：
‼️dify-plugin-connector-sa会通过 Helm Chart 模板自动分配给plugin_connector服务；dify-plugin-crd-sa和dify-plugin-runner-sa将被用于构建和运行插件的 Pod。
Access Key 模式配置
步骤 1：准备凭证
创建一个仅具备 S3 和 ECR 权限的 IAM 用户，并获取其 Access Key 和 Secret Key。步骤 2：创建 Kubernetes Secret
values.yaml 中的 imageRepoSecret 配置给 plugin_connector 服务。
步骤 3：配置 values.yaml
4. 安装 AWS ALB（Application Load Balancer）
为使 Dify 企业版可通过域名访问，您需要安装 AWS ALB（Application Load Balancer）。您也可以选择使用 Nginx Ingress Controller 或其他 Ingress Controller。推荐使用 AWS ALB，因为它能与 Dify 企业版无缝集成，并提供更好的性能和可扩展性。 请访问 https://docs.aws.amazon.com/eks/latest/userguide/lbc-manifest.html 获取 AWS ALB 安装指南。如果无法安装 AWS ALB，可使用 Nginx Ingress Controller 作为备选方案：AWS ALB 安装完成后，可通过以下命令确认服务是否正常运行：
values.yaml 中配置 Ingress：
global 配置中启用 TLS。您可通过 AWS Certificate Manager 验证域名并创建证书。
5. 执行安装
请访问 https://langgenius.github.io/dify-helm/#/ 获取详细的安装说明。
‼️ 不建议将 Dify 安装在 default 命名空间中。
6. 验证服务状态
- 更新 kubectl 访问凭证：
- 验证 EKS 节点已正常启动：
- 验证 Dify 服务运行状态：
- 确认 ALB 是否正常工作：
‼️ 请将上述命令输出的 DNSName 配置为 CNAME 记录，解析到 Dify 所需的各个域名。