Dify Enterprise Edition デプロイメントガイド(AWS)
本ドキュメントでは、AWS クラウド環境に Dify Enterprise Edition をデプロイする方法について説明します。以下のいずれかの方法でデプロイを完了できます:- Terraform 経由(推奨)
- CDK 経由
- 手動でインフラストラクチャを作成してデプロイ(非推奨)
オプション 1:Terraform によるビルド
Terraform 関連のスクリプトとドキュメントを取得するには、Dify 技術サポートチームにお問い合わせください。
前提条件
- ローカルに
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 Charts のホスティングも可能
- AWS RDS Aurora Postgres:アプリケーションデータと監査レコードを保存するリレーショナルデータベース
- AWS OpenSearch:RAG(Retrieval Augmented Generation)関連機能用のベクトルデータベース
- Amazon ElastiCache:データアクセスを高速化するマネージド Redis キャッシュサービス
オプション 2:CDK によるビルド
AWS CDK デプロイメント を参照してください。オプション 3:手動でインフラストラクチャを作成してデプロイ
1. インフラストラクチャの作成
以下の表の推奨設定を参考に、実際のニーズに応じてインフラストラクチャを作成してください。(二重括弧内のコンテンツを実際の値に置き換えてください)バージョンに関する注意(重要): 以下の表に記載しているバージョンは「利用可能な範囲/バージョン系列」の目安です。実際のデプロイ前に、必ず対象 AWS リージョンのコンソール、または AWS CLI で各サービスが現在サポートしているバージョン(EKS Kubernetes、Aurora PostgreSQL、OpenSearch、ElastiCache Redis など)を確認してください。リージョン差分やバージョン廃止により、リソース作成に失敗する可能性があります。
テスト環境インフラストラクチャ設定リファレンス
注意: 単一ノードで unstructured サービスを有効にする場合は、ディスク容量を 40 GB に増やしてください。
| コンポーネントタイプ | 設定項目 | 仕様 | 説明 |
|---|---|---|---|
| EKS クラスター | クラスター名 | dify-{your_custom_deployment_id}-eks-cluster | カスタム命名 |
| Kubernetes バージョン | 1.2x~1.3x(対象リージョンの EKS でサポートされるバージョンに準拠) | 事前確認:対象リージョンの EKS Kubernetes バージョン対応一覧 | |
| ノードインスタンスタイプ | m7a.xlarge (amd64) / m7g.xlarge (arm64) | 4 vCPU、16GB RAM | |
| ノード数 | 1-2(希望:1) | 最小コスト設定 | |
| ノードディスクサイズ | 40 GB | gp3、暗号化 | |
| AMI タイプ | AL2023_x86_64 / ARM_64_STANDARD | Amazon Linux 2023 | |
| S3 バケット | バケット名 | dify-{your_custom_deployment_id}-storage | カスタム命名 |
| バージョニング | 有効 | ファイルバージョン管理 | |
| 暗号化 | AES256 | サーバーサイド暗号化 | |
| パブリックアクセス | 完全にブロック | セキュリティ設定 | |
| ストレージ容量計画 | 100GB | テスト環境容量 | |
| RDS (Aurora Serverless v2) | クラスター識別子 | dify-{your_custom_deployment_id}-aurora-postgres | カスタム命名 |
| エンジンバージョン | Aurora PostgreSQL(PostgreSQL 14+ 互換、対象リージョンのサポートに準拠) | 事前確認:対象リージョンで選択可能な Aurora PostgreSQL エンジンバージョン | |
| インスタンス数 | 1 | 単一インスタンス、コスト最適化 | |
| インスタンスタイプ | db.serverless | Serverless v2 専用 | |
| 最小/最大キャパシティ | 1 - 8 ACU | 自動スケーリング | |
| ストレージ暗号化 | 有効 | 保存時暗号化 | |
| バックアップ保持期間 | 7 日 | 自動バックアップ | |
| Performance Insights | 無効 | コスト最適化 | |
| 作成するデータベース | dify, enterprise, audit, dify_plugin_daemon | 4 つのデータベース | |
| OpenSearch | ドメイン名 | dify-{your_custom_deployment_id}-opensearch | カスタム命名 |
| エンジンバージョン | OpenSearch 2.x(対象リージョンのサポートに準拠) | 事前確認:Amazon OpenSearch Service がサポートするエンジンバージョン | |
| インスタンスタイプ | t3.medium.search | 2 vCPU, 4 GB RAM | |
| インスタンス数 | 1 | 単一ノード | |
| ストレージタイプ/サイズ | EBS gp3 / 100 GB | テスト環境(単一ノード) | |
| セキュリティ機能 | 保存時暗号化、ノード間暗号化、HTTPS 強制 | 包括的セキュリティ | |
| ElastiCache (Redis) | レプリケーショングループ ID | dify-{your_custom_deployment_id}-redis | カスタム命名 |
| エンジンバージョン | Redis 7.x(対象リージョンの ElastiCache のサポートに準拠) | 事前確認:ElastiCache for Redis がサポートするエンジンバージョン | |
| ノードタイプ | cache.t4g.small | 2 vCPU, 1.37 GB RAM | |
| キャッシュノード数 | 1 | 単一ノードモード | |
| マルチ AZ | 無効 | 単一 AZ デプロイメント | |
| スナップショット保持期間 | 0 日 | バックアップなし | |
| IAM ロール | EKS クラスターロール | dify-{your_custom_deployment_id}-cluster-role | AmazonEKSClusterPolicy |
| EKS ノードグループロール | dify-{your_custom_deployment_id}-node-group-role | Worker + CNI + ECR ポリシー | |
| S3 アクセスロール | dify-{your_custom_deployment_id}-s3-role | S3 フルアクセス | |
| S3+ECR アクセスロール | dify-{your_custom_deployment_id}-s3-ecr-role | S3 + ECR フルアクセス | |
| ECR プルロール | dify-{your_custom_deployment_id}-ecr-pull-role | ECR 読み取り専用アクセス | |
| その他のリソース | ECR リポジトリ | 2(メインアプリ + プラグイン) | イメージストレージ |
| Secrets Manager | 1 | RDS 認証情報 |
本番環境インフラストラクチャ設定リファレンス
| コンポーネントタイプ | 設定項目 | 仕様 | 説明 |
|---|---|---|---|
| EKS クラスター | クラスター名 | dify-{your_custom_deployment_id}-eks-cluster | カスタム命名 |
| Kubernetes バージョン | 1.2x~1.3x(対象リージョンの EKS でサポートされるバージョンに準拠) | 事前確認:対象リージョンの EKS Kubernetes バージョン対応一覧 | |
| ノードインスタンスタイプ | m7a.xlarge (amd64) / m7g.xlarge (arm64) | 4 vCPU、16GB RAM | |
| ノード数 | 6~10(希望:6) | 本番環境構成 | |
| ノードディスクサイズ | 20 GB | gp3、暗号化 | |
| AMI タイプ | AL2023_x86_64 / ARM_64_STANDARD | Amazon Linux 2023 | |
| S3 バケット | バケット名 | dify-{your_custom_deployment_id}-storage | カスタム命名 |
| バージョニング | 有効 | ファイルバージョン管理 | |
| 暗号化 | AES256 | サーバーサイド暗号化 | |
| パブリックアクセス | 完全にブロック | セキュリティ設定 | |
| ストレージ容量計画 | 512GB | 本番環境容量 | |
| RDS (Aurora Serverless v2) | クラスター識別子 | dify-{your_custom_deployment_id}-aurora-postgres | カスタム命名 |
| エンジンバージョン | Aurora PostgreSQL(PostgreSQL 14+ 互換、対象リージョンのサポートに準拠) | 事前確認:対象リージョンで選択可能な Aurora PostgreSQL エンジンバージョン | |
| インスタンス数 | 1 | 単一インスタンス、コスト最適化 | |
| インスタンスタイプ | db.serverless | Serverless v2 専用 | |
| 最小/最大キャパシティ | 4 - 8 ACU | 自動スケーリング | |
| ストレージ暗号化 | 有効 | 保存時暗号化 | |
| バックアップ保持期間 | 30 日 | 自動バックアップ | |
| Performance Insights | 有効 | 本番では有効化推奨 | |
| 作成するデータベース | dify, enterprise, audit, dify_plugin_daemon | 4 つのデータベース | |
| OpenSearch | ドメイン名 | dify-{your_custom_deployment_id}-opensearch | カスタム命名 |
| エンジンバージョン | OpenSearch 2.x(対象リージョンのサポートに準拠) | 事前確認:Amazon OpenSearch Service がサポートするエンジンバージョン | |
| インスタンスタイプ | r5.large.search | 2 vCPU, 16 GB RAM(各ノード) | |
| インスタンス数 | 3 | 3 ノードクラスター(合計 6 vCPU, 48 GB RAM) | |
| ストレージタイプ/サイズ | EBS gp3 / 30 GB | 各ノード 30 GB | |
| セキュリティ機能 | 保存時暗号化、ノード間暗号化、HTTPS 強制 | 包括的セキュリティ | |
| ElastiCache (Redis) | レプリケーショングループ ID | dify-{your_custom_deployment_id}-redis | カスタム命名 |
| エンジンバージョン | Redis 7.x(対象リージョンの ElastiCache のサポートに準拠) | 事前確認:ElastiCache for Redis がサポートするエンジンバージョン | |
| ノードタイプ | cache.t4g.medium | ~2 vCPU, ~3 GB RAM | |
| キャッシュノード数 | 2 | プライマリ + 読み取りレプリカ | |
| 自動フェイルオーバー | 有効 | 高可用性 | |
| マルチ AZ | 有効 | クロス AZ デプロイ | |
| スナップショット保持期間 | 7 日 | 自動バックアップ | |
| IAM ロール | EKS クラスターロール | dify-{your_custom_deployment_id}-cluster-role | AmazonEKSClusterPolicy |
| EKS ノードグループロール | dify-{your_custom_deployment_id}-node-group-role | Worker + CNI + ECR ポリシー | |
| S3 アクセスロール | dify-{your_custom_deployment_id}-s3-role | S3 フルアクセス | |
| S3+ECR アクセスロール | dify-{your_custom_deployment_id}-s3-ecr-role | S3 + ECR フルアクセス | |
| ECR プルロール | dify-{your_custom_deployment_id}-ecr-pull-role | ECR 読み取り専用アクセス | |
| その他のリソース | ECR リポジトリ | 2(メインアプリ + プラグイン) | イメージストレージ |
| Secrets Manager | 1 | RDS 認証情報 |
2. values.yaml の設定
データベース、S3、その他のインフラストラクチャを作成した後、以下の例を参考にvalues.yaml を設定してください(二重括弧内のコンテンツを実際の値に置き換えてください)。その前に、データベースに dify、enterprise、audit、dify_plugin_daemon の 4 つのデータベースを作成し、values.yaml の rds_main_database_name などの対応する設定項目を置き換える必要があります。
3. S3 と ECR 権限の設定
Dify サービスが正常に起動し、プラグインシステムが正しく機能するために、api、worker、workerBeat、plugin_daemon、plugin_connector サービスには S3 アクセス権限が必要であり、plugin_connector サービスには ECR アクセス権限も必要です。plugin_connector サービスがこれらの権限を必要とする具体的な理由については、後で詳しく説明します。
権限は以下の 2 つの方法のいずれかで設定できます:
- IRSA モード:IAM Roles for Service Accounts、安全できめ細かな権限制御を可能にする(推奨)
- アクセスキー(AK/SK)モード:環境変数を介して認証情報を提供
IRSA モード設定
Dify では、IRSA を使用して ServiceAccount 権限を設定することを推奨しています。ワンクリック IRSA デプロイメントスクリプトについては、Dify 技術サポートチームにお問い合わせください。 IRSA は OIDC プロバイダーを介して EKS クラスターと IAM 間の信頼関係を確立し、Pod がアクセスキーを設定することなく ServiceAccount を通じて安全に AWS 権限を取得できるようにします。全体的なアーキテクチャは以下のとおりです:| Service Account | コンポーネント | 権限の説明 | スコープ |
|---|---|---|---|
dify-enterprise | Enterprise サービス | namespaces に対する get、list、watch 権限を持ち、名前空間情報の取得と監視に使用。 | Role(名前空間レベル) |
dify-plugin-sa | Plugin Controller | difyplugins(CRD)とその finalizers/status、leases、events、services、configmaps、deployments、jobs、ingresses などのリソースに対する完全な管理権限を持つ。 | Role(プラグイン名前空間) |
dify-plugin-connector-sa | Plugin Connector & Daemon | dify-plugin-connector-role(dify-plugin-sa と同じ)から権限を継承。 | Role(プラグイン名前空間) |
| Custom Service Account | 各種サービスコンポーネント | デフォルトでは空(default サービスアカウントを使用)、values.yaml で設定可能。 | 設定に応じて |
customServiceAccount | プラグインカスタムサービスアカウント | プラグイン実行時のカスタム権限用、デフォルトでは空、設定で指定可能。 | 設定に応じて |
runnerServiceAccount | Plugin Runner サービスアカウント | プラグインランナー専用のサービスアカウント、デフォルトでは空、設定で指定可能。 | 設定に応じて |
💡 CRD インストールに関する特別な注意 Dify Enterprise Edition は、インストール時に名前空間レベルの権限のみを必要とします。ただし、CRD 自体はクラスターレベルのリソースであるため、インストール時には適切なクラスター権限が必要です。クラスターレベルの権限がない場合は、最初に CRD を別途インストールし、その後残りのコンポーネントをインストールできます。CRD 自体は、Kubernetes に登録された API 構造宣言にすぎません。対応する Controller が名前空間レベルの場合、名前空間をまたいでリソースにアクセスしたり変更したりすることはできません。
ステップ 1:IAM OIDC プロバイダーの確認
IRSA を設定する前に、クラスターで IAM OIDC プロバイダーが有効になっていることを確認してください。クラスターが手動で作成された場合は、eksctl コマンドラインツールを使用して有効化または確認することをお勧めします。IAM OIDC プロバイダーは、EKS クラスターが Pod の ID を IAM に証明できる信頼関係を確立し、Pod が AWS 権限を安全に取得できるようにします。
ステップ 2:AWS IAM ポリシーの作成
以下の 3 つの 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 ロールの作成
以下の 3 つのロールを作成し、ステップ 2 のポリシーを対応するロールにアタッチします(ロール名はカスタマイズ可能):| ロール名(例) | アタッチするポリシー | 用途 |
|---|---|---|
DifyS3Role | S3 アクセスポリシー | S3 ストレージアクセス |
DifyS3ECRRole | S3 アクセスポリシー + ECR フルアクセスポリシー | S3 + ECR イメージプッシュ/管理 |
DifyECRPullRole | ECR プル専用ポリシー | ECR イメージプル |
{oidc_id}を EKS クラスターの OIDC プロバイダー ID に置き換えてください。以下のコマンドで取得できます:
ステップ 4:ロールを EKS ServiceAccount にバインド
ServiceAccount(SA)は、EKS の Pod が特定の AWS 権限を取得してクラウドリソース(S3 など)にアクセスできるようにするメカニズムです。以下の 4 つの ServiceAccount を作成し、対応するロール ARN を
eks.amazonaws.com/role-arn アノテーションに追加します:
| ServiceAccount | 名前空間 | バインドするロール | 有効な権限 |
|---|---|---|---|
dify-api-sa | dify | S3 アクセスロール | S3 アクセス |
dify-plugin-crd-sa | dify | S3+ECR アクセスロール | S3 + ECR プッシュ/プル |
dify-plugin-runner-sa | dify | ECR プルロール | ECR プルのみ |
dify-plugin-connector-sa | dify | S3 アクセスロール | S3 アクセス(Helm が自動割り当て) |
$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 に使用されます。
アクセスキーモード設定
ステップ 1:認証情報の準備
S3 と ECR 権限のみを持つ IAM ユーザーを作成し、そのアクセスキーとシークレットキーを取得します。ステップ 2:Kubernetes Secret の作成
values.yaml の imageRepoSecret を介して plugin_connector サービスに設定する必要があります。
ステップ 3:values.yaml の設定
4. AWS ALB(Application Load Balancer)のインストール
Dify Enterprise Edition をドメイン名でアクセス可能にするには、AWS ALB(Application Load Balancer)をインストールする必要があります。Nginx Ingress Controller やその他の Ingress Controller を使用することもできます。AWS ALB は Dify Enterprise Edition とシームレスに統合され、より良いパフォーマンスとスケーラビリティを提供するため推奨されます。 AWS ALB のインストールガイドについては、https://docs.aws.amazon.com/eks/latest/userguide/lbc-manifest.html をご覧ください。AWS ALB をインストールできない場合は、代替として Nginx Ingress Controller を使用できます:AWS ALB のインストールが完了したら、以下のコマンドでサービスが正常に実行されているか確認できます:
values.yaml で Ingress を設定します:
global 設定で TLS を有効にします。AWS Certificate Manager を通じてドメインを検証し、証明書を作成できます。
5. インストールの実行
詳細なインストール手順については、https://langgenius.github.io/dify-helm/#/ をご覧ください。
‼️ default 名前空間に Dify をインストールすることは推奨されません。
6. サービスステータスの確認
- kubectl アクセス認証情報を更新:
- EKS ノードが正常に実行されていることを確認:
- Dify サービスステータスを確認:
- ALB が正常に動作していることを確認:
‼️ 上記のコマンド出力から DNSName を CNAME レコードとして設定し、Dify に必要な各ドメインに解決してください。