AWS公式サンプル「dify-self-hosted-on-aws」は、DifyをAWSマネージドサービスで安全・低運用に載せるためのCDKテンプレートです。Aurora Serverless v2、ElastiCache、ECS Fargateといった構成で、CloudFrontやWAFもオプションとして選べます。
さらにコスト配慮として「NAT Gatewayの代わりにNATインスタンス」「Fargate Spotを既定利用」といった設計の工夫が織り込まれています。まずはこのテンプレートの思想とシステム構成を理解し、適切にチューニングしていくのが近道です。
引用：Dify on AWS with CDK（README）
Aurora Serverless v2／ElastiCache／ECS Fargate等の採用、NATインスタンスとFargate Spotの活用、CloudFront/WAF/ACMのオプション対応が明記されています
Dify Community Editionの概要
「Dify」はオープンソースの生成AIアプリ基盤で、プロンプトの可視化オーケストレーション、RAG、エージェント、モデル管理、API連携などを一式で扱えるのが強みです。技術仕様の公開も手厚く、バックエンドはPython/Flask＋PostgreSQL、フロントはNext.jsが中心です。
セルフホスティングはDocker/Helmベースで、ベクトルDBはpgvectorやQdrantなど複数に対応します。これらはCommunity Editionでも扱えるため、PoCや小規模運用の入口として十分に機能します。
Dify側の整理では、まずCommunity Editionで試し、より厳密な統治やサポートが必要になればPremiumやEnterpriseへ進む、という段階的な導入を推奨しています。特にPremiumはAWS MarketplaceのAMIとして1クリック展開でき、ブランドカスタマイズなどが可能で、Enterprise前の検証にも適しています。
アーキテクチャ（CDK版）の全体像
上記はCDKテンプレートが想定する構成図です。ALB配下で「web」「api/sandbox/worker」のECSサービスを動かし、Aurora Postgres（Serverless v2）、ElastiCache（Valkey互換）、S3を併用します。CloudFront、WAF、ACMは任意で付加できます。
この構成のコアは「ステートはRDS/AuroraとElastiCache、バイナリ等はS3へ、実行系はECSで水平伸長」という典型的なSaaS基盤パターンです。NATインスタンスとFargate Spotの使い分けで運用コストにも目配りが効きます。
デプロイ前提とCloudShellを使う理由
前提としてNode.js v18+、Docker、AWS CLI（Admin権限プロファイル）が必要です。
CloudShellからのデプロイを強く勧める理由は、CDK依存物の取得やビルドを含む一連の流れが、CloudShell向けのシンプルスクリプトにパッケージングされているからです。CloudShellで以下を実行し、対話に従うだけでURLが払い出されます。
git clone <https://github.com/aws-samples/dify-self-hosted-on-aws.git>
cd dify-self-hosted-on-aws
./simple-deploy.shCloudShell推奨とスクリプトの存在はREADMEに明記されています。実行後はスタック出力にDifyUrlが表示されます。
/bin/cdk.tsで設定できる主なオプション
CDK実装では、/bin/cdk.tsから「EnvironmentProps」を渡す形で各種スイッチを集中管理します。READMEとサンプル断片から、要点と意味合いを解説します。
表 /bin/cdk.ts 主要オプション一覧（意味・用途・注意点）
プロパティ | 型 / 設定例 | 目的 | 主な利用シーン | 注意点 |
|---|---|---|---|---|
awsRegion | string / | デプロイ対象リージョンの明示 | 企業標準リージョンでの固定、閉域構成での地域統一 | READMEの手順に従い |
awsAccount | string / | デプロイ先アカウントの明示 | 既存VPC参照時や複数環境の切替 | 既存VPCを参照する場合は必須とされるケースがある旨に留意する GitHub |
allowedIPv4Cidrs | string[] / | 管理アクセスの許可範囲 | 閉域・社内ネットワークからのみ接続を許す構成 | 閉域例のコードスニペットで内部アドレス帯の指定が示されている GitHub |
useCloudFront | boolean / `true | false` | エッジ配信・TLS終端・WAF連携の有無 | インターネット公開時に有効化 |
internalAlb | boolean / `true | false` | ALBを内部向けに限定 | 閉域・社内限定の発行面 |
customEcrRepositoryName | string / | Dify公式イメージをECRへミラーする際のリポジトリ名 | Docker Hubへ出られないサブネットや閉域環境 |
|
vpcIsolated | boolean / `true | false` | IGW/NATなしの閉域VPCをCDKで新規作成 | 新設の閉域ネットワークで運用開始 |
vpcId | string / | 既存VPCのインポート | 既存ネットワーク標準に合わせたい場合 | 必要なVPCエンドポイントを事前に用意することが明記されている GitHub |
difyImageTag | string / | 利用するDify本体イメージのタグ | バージョン固定、検証と本番の切替 | タグ変更時はECRミラーを再実行する必要がある旨の注意書きがある GitHub |
difySandboxImageTag | string / | Difyサンドボックスイメージのタグ | コード実行系のバージョン管理 |
|
allowAnySysCalls | boolean / `true | false` | コード実行サンドボックスで追加のシステムコールを許容 | 信頼できるテナント前提でのPythonライブラリ拡張 |
additionalEnvironmentVariables | 配列 / 例： | Difyコンテナへ環境変数を注入 | Secrets ManagerやSSMの値を各コンテナに配布 |
|
setupEmail | boolean / `true | false` | ユーザー招待・パスワードリセットメール機能の有効化 | SaaSライクな運用でメールを使う場合 |
domainName | string / | SESドメインの指定 | 招待メールや通知メールの送信元ドメインを固定 | 非検証宛先に送るにはSESサンドボックス解除が必要である旨が記載されている GitHub |
設定値の保管戦略（重要）
CloudShellで対話実行して終わりにせず、/bin/cdk.tsの「プロダクトの設定」はGitリポジトリでバージョン管理することを強く推奨します。
そうしないと、都度ファイルを手作業で書き換えることになり、環境差分やヒューマンエラーの温床になります。プロファイル別やワークスペース別にブランチを切り、cdk.tsのパラメータ分離を併用すると運用が滑らかになります。
※ READMEのCloudShell推奨は「初回導入の容易さ」観点であり設定の永続化は別の話
デプロイされるAWSリソースの詳細
以下はCDKで生成される主要リソースと役割の整理です。Aurora、ElastiCache、S3、ECS、ALBがコアで、CloudFront／WAF／ACMは任意で付加されます。図示とREADMEの説明から要点を抽出しています。
表 Dify on AWS（CDK）でデプロイされる主要AWSリソース
リソース | サービス | 役割 | 補足 |
|---|---|---|---|
VPC（Public/Private Subnet） | Amazon VPC | ネットワーク基盤 | 閉域構成ではIGW/NAT無し、必要なVPCエンドポイントを追加 |
Application Load Balancer | Elastic Load Balancing | L7終端／ECSへのルーティング |
|
ECS Services（web, api/sandbox/worker） | Amazon ECS on Fargate | Difyの実行プレーン | 既定でFargate Spotを活用しコスト最適化 |
Aurora PostgreSQL（Serverless v2） | Amazon RDS | トランザクションとメタデータの永続化 | 既定の最大ACU値はREADMEに記載の通り調整可能 |
ElastiCache for Valkey（Redis互換） | Amazon ElastiCache | セッション／キュー／キャッシュ | Redis OSS互換のValkeyにElastiCacheが対応済み |
S3 バケット | Amazon S3 | ファイルやエクスポートの保存 | バックアップやログ置き場にも活用可能 |
CloudFront（任意） | Amazon CloudFront | エッジ配信・TLS終端 | ACM証明書やWAFと併用可能 |
AWS WAF（任意） | AWS WAF | L7保護 | CloudFront／ALBと連携 |
ACM 証明書（任意） | AWS Certificate Manager | TLS終端の証明書管理 | 既存証明書のインポートも可 |
この表は、READMEとアーキテクチャ図に示されたコンポーネントを元に整理しています。ValkeyのElastiCache対応はAWS公式アナウンス・ドキュメントが出ています (Amazon Web Services, Inc., AWS ドキュメント)。
手順（最短ルート）
初回はCloudShellでの一撃デプロイが速いです。
- CloudShellを開き、リポジトリをクローンして
./simple-deploy.shを実行する - 対話に従いリージョンや必要情報を入力する
- デプロイ完了後、出力された
DifyUrlにアクセスして初期セットアップを行う
CloudShell利用とスクリプトはREADMEに明記されています。ローカルから行う場合は npm ci → npx cdk bootstrap → npx cdk deploy --all の順序です。
モデル接続と「Amazon Bedrock」有効化の注意点
DifyからAmazon Bedrockのモデルを使う前に、AWSコンソールの「Model access」で対象モデルのアクセスを有効化しておく必要があります。これはデフォルトで無効なので、使うモデル（Claude、Llama、Cohere等）をリージョン単位で明示的に許可します。
Dify側は「WORKSPACE → Model Provider → AWS Bedrock」を選び、モデルを有効化済みのリージョンを選択して保存すればOKです。
引用：Access Amazon Bedrock foundation models
モデルアクセスは既定で付与されておらず、Bedrockコンソールから明示的に有効化する必要がある旨が記載されています (AWS ドキュメント)
エディション比較（Community / Premium / Enterprise）
Difyのエディションは「何をどこまでSLAつきで担保したいか」で選ぶのが現実的です。公式の説明に基づき、要点を比較します。
表 Difyのエディション比較（公式記載からの要点整理）
エディション | 位置づけ | 主な特徴 | 典型用途 |
|---|---|---|---|
Community Edition | OSSセルフホスト | オーケストレーション、RAG、エージェント、APIなど中核機能をOSSで提供。Docker/Helmで展開 | PoCや小規模運用の出発点。自社基盤合わせの検証に最適 |
Premium Edition | AWS MarketplaceのAMI | 1クリック展開、ブランドカスタマイズ、Enterprise前の検証に適する | シングルテナント前提の早期実装、Enterprise検討前の本格PoC |
Enterprise Edition | 企業導入向け | マルチテナント、SSO、2FA、セキュリティ・可用性・統合の強化、サポート提供 | 部門横断の本番利用、統治・監査・SLAが必要な領域 |
上表の内容は、Premiumが「EC2 AMIとして1クリック展開」「Enterprise前のPoCに最適」と説明されているページ、Enterpriseが「マルチテナント/SSO/2FA等に対応」とする公式ページ、Community Editionのセルフホスト説明に基づいています。
ここでの個人的な見立てとして、PoCや小規模のAI導入ならCommunity Editionで十分です。セキュリティ・統治やサポート窓口が必要になってきた段階でPremium/Enterpriseへ昇格するのが、費用対効果も説明しやすい順路です。
コスト設計の要点（経験則）
このテンプレートは既にコスト意識が織り込まれていますが、現場で効くのは次のポイントです。
- Aurora Serverless v2のACU上限は「最初は低く、負荷に合わせて上げる」で良い設計
- ElastiCacheは最小ノードで開始し、ミスキャッシュやジョブ量で段階調整するのが合理的
- Fargate Spotはコスト圧縮に効くが、ワークロードの中断耐性と最小台数（オンデマンド）確保のバランスを見るべき
- NATはインスタンス活用の思想がテンプレートにあるため、閉域要件や通信要件を満たす前提でインターネット経路を最小化するのが筋
これらはREADMEの趣旨（コスト効率の設計）と、一般的なSaaS運用の勘所からの実務的アドバイスです。
まとめ：最短で価値に到達し、設定はコードで残す
結論はシンプルです。初回はCloudShell＋CDKサンプルで最短構築し、/bin/cdk.tsの内容は必ず自社リポジトリで管理する。PoCや小規模デプロイはCommunity Editionで十分に価値が出ますが、統治・可用性・サポートが欲しくなったらPremiumまたはEnterpriseへ「上げる」前提で、拡張余地を残しておく。Bedrockのモデルアクセス有効化だけは忘れがちなので、Runbookの冒頭に固定化しておくのが安全です。
※ 本記事は、上記一次情報の記載内容に基づいて執筆しています、機能・仕様は随時更新されるため、最新ドキュメントを都度ご確認ください
