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 に増やしてください。
本番環境インフラストラクチャ設定リファレンス
また、インフラストラクチャのセキュリティを確保するために、適切な Virtual Private Cloud（VPC）とセキュリティグループ（SG）を作成する必要があります。
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 権限を取得できるようにします。全体的なアーキテクチャは以下のとおりです：💡 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 のポリシーを対応するロールにアタッチします（ロール名はカスタマイズ可能）：
対応するロール ARN を取得します：
{oidc_id}を EKS クラスターの OIDC プロバイダー ID に置き換えてください。以下のコマンドで取得できます：
ステップ 4：ロールを EKS ServiceAccount にバインド
ServiceAccount（SA）は、EKS の Pod が特定の AWS 権限を取得してクラウドリソース（S3 など）にアクセスできるようにするメカニズムです。以下の 4 つの 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 に使用されます。
アクセスキーモード設定
ステップ 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 に必要な各ドメインに解決してください。