0. はじめに
こんにちは。株式会社NTTデータ九州 ビジネス共創部 デジタルビジネス推進室 1年目の濱里です。
普段は、主にAmazon Web Services（AWS）を扱うチームに所属しており、AWSを用いた環境の構築や運用・保守を担当しています。
私は、ある案件において「dify-self-hosted-on-aws」を使用し、Difyを構築する機会がありました。ただし、セキュリティやスペックの観点から提供されたものをそのまま使うことができず、構成を再設計する必要がありました。
この記事では、その設計工程において役立った、AWS CDKの設定ポイントやコードの確認箇所を当時の設計判断と合わせて紹介します。
以下のような目的でDify OSS版を利用したい方の参考になれば幸いです。
- 業務で利用するためセキュリティを向上させたい
- 複数ユーザーが利用しても快適に動作するようスペックを調整したい
- 個人利用のためコスト重視の構成にしたい
※本記事は2026年2月時点の情報に基づいて作成しています。記載されているサービスの仕様や情報は変更される可能性があります。実際の利用にあたっては、最新の公式ドキュメントをご確認ください。
1. DifyをAWSでセルフホストする構成
まず、dify-self-hosted-on-awsのサンプル構成について説明します。
以下に構成図を示します。
コンピュートは、Amazon Elastic Container Service（ECS）とAWS Fargateを利用しており、Api/workerタスクのスペックは1 vCPU/2 GB、Webタスクのスペックは0.25 vCPU/0.5 GBです。
ECS上で構築されていますが、README.mdによるとアプリケーションの制約により、スケールアウトには対応していません。
ベクトルDBはAurora PostgreSQL（Serverless v2）を利用しています。
ACUは0.5 ACU～2.0 ACUの間で、リソースの使用率に応じてオートスケールされます。
キャッシュにはAmazon ElastiCache for Redisが利用されています。
マルチAZで構成されており、プライマリとレプリカノードのノードタイプは共にcache.t4g.microです。
構成図にはCloudFrontやWAFが含まれていますが、optional（オプション）となっており、デフォルトでは有効化されません。
これらを利用する際は、2章で紹介する設定が必要です。
2. CDKでカスタマイズできるポイント
AWS Samplesで公開されているリポジトリではcdk deployを実行するだけで、Dify OSS版をAWS上にデプロイできます。
一方で、実際の利用においては、用途に応じてリソース構成やスペックを変更する必要がある場合も多くあります。
例：
- Aurora PostgreSQLのスケーリング設定を変更したい
- ECSタスクのCPUやメモリサイズを変更したい
- CloudFrontを利用するかどうかを選択したい
- NATゲートウェイの有無を選択したい
- 検証環境向けにコストを抑えた構成にしたい
サンプルリポジトリ内では、これらをAWS CDKのコード変更によって柔軟に調整できます。
ここでは、2種類のカスタマイズ方法を紹介します。
2.1 cdk.tsの引数
本リポジトリでは、エントリーポイントとなるbin/cdk.ts において、スタック生成時に渡す引数を変更するだけでAWSリソースの構成を切り替えられます。
渡す引数は、以下のようにコード内で定義されています。
export const props: EnvironmentProps = {
awsRegion: 'us-west-2',
awsAccount: process.env.CDK_DEFAULT_ACCOUNT!,
// Set Dify version
difyImageTag: '1.11.4',
// Set plugin-daemon version to stable release
difyPluginDaemonImageTag: '0.5.2-local',
// uncomment the below options for less expensive configuration:
// isRedisMultiAz: false,
// useNatInstance: true,
// enableAuroraScalesToZero: true,
// useFargateSpot: true,
// Please see EnvironmentProps in lib/environment-props.ts for all the available properties
};
各項目の内容は以下の通りです。
| 引数名 | 内容 |
|---|---|
| awsRegion | DifyのシステムをデプロイするAWSリージョン |
| awsAccount | AWSアカウントを明示的に設定する必要がある場合は設定 |
| difyImageTag | Difyのコンテナイメージのバージョン |
| difyPluginDaemonImageTag | Difyプラグインデーモンのコンテナイメージのバージョン |
| isRedisMultiAz | ElastiCacheをマルチAZにするか |
| useNatInstance | NATゲートウェイの代わりにNATインスタンスを利用するか |
| enableAuroraScalesToZero | Auroraのコールドスタートを有効にするか |
| useFargateSpot | Fargateのスポットキャパシティを利用するか |
例：ElastiCacheをシングルAZに変更する
// isRedisMultiAz: false,
↓
isRedisMultiAz: false,
として再デプロイするだけで、ElastiCacheをマルチAZ→シングルAZにでき、コストを削減できます。（可用性は低下します）
また、lib/environment-props.tsにはその他いくつかの便利な引数が記載されています。必要なものがあれば、bin/cdk.ts に引数を追加することで、要件に合わせた構成を実現できます。
例：CloudFrontとWAFによってアクセスを制限する
allowedIPv4Cidrs: ['xxx.xxx.xxx.xxx/xx']
をEnvironmentPropsに追加すると、自動的にCloudFrontとWAFが追加され、IPアドレス単位でアクセスを制限できます。
2.2 construct内の設定
さらに、詳細な調整を行う場合は、各AWSリソースを定義するCDKコードを変更します。
例えば以下のようなファイルで主要なリソースが定義されています。
| リソース | ファイル |
|---|---|
| ECSタスク | lib/constructs/dify-services/ |
| Aurora | lib/constructs/postgres.ts |
| ElastiCache | lib/constructs/redis.ts |
これらのコードを修正することで、
- ECSタスクのCPU/メモリ
- Aurora Serverlessのスケーリング設定
- Redis（ElastiCache）のインスタンスタイプ
などを変更できます。
実際の案件では、これらの設定を要件に応じて調整しています。
次章では、実際に行った設定変更と設計判断について紹介します。
3. 実案件で調整したCDK設定と設計判断
本章では、実案件で要件に応じて調整したCDK設定と、その設計判断を4つ紹介します。
今回構築した環境は検証環境であり、
- 最大同時利用者数：15名程度
- LLM機能の利用を想定
- 検証用途のため一定の遅延は許容
- システムが動く範囲で可能な限りコストを抑える
- IPアドレスによるアクセス制限が必要
という条件のもとで構成を検討しました。
3.1 ECSタスクのCPU/メモリ
DifyをAWS上で運用する際、ECSタスクのCPU・メモリ設定は重要な調整ポイントの一つです。
特にDifyでは、LLMの推論結果処理やEmbedding生成などの処理が行われるため、Apiコンテナのリソース使用量が大きくなる場合があり、それが許容できないレスポンス遅延につながる場合があります。
dify-self-hosted-on-aws のサンプル構成では、ECSタスクのCPU・メモリは以下のように設定されています。
| タスク | CPU/メモリ |
|---|---|
| Apiタスク | 1 vCPU/2 GB |
| Webタスク | 0.25 vCPU/0.5 GB |
しかし今回の環境では、最大同時利用者数を15名程度と想定しており、
LLM機能の利用を考慮すると、デフォルト設定ではリソース不足になる可能性がありました。
そのため、ECSタスクのリソースを以下のように変更しました。
| タスク | CPU/メモリ |
|---|---|
| Apiタスク | 2 vCPU/4 GB |
この変更は以下のCDKコードを修正することで対応しています。
lib/constructs/dify-services/api.ts
例えばApiタスクでは、FargateTaskDefinitionの設定を以下のように変更しています。
const taskDefinition = new FargateTaskDefinition(this, 'Task', {
cpu: 2048,
memoryLimitMiB: 4096, // We got OOM frequently when RAM=512MB
・・・
});
このように、ECSタスクのリソース設定は想定ユーザー数やアプリケーションの処理内容に応じて調整することが重要です。
3.2 Aurora Serverless v2（Scale to Zero）
DifyではベクトルDBとして Aurora PostgreSQL が利用されており、本構成ではAurora Serverless v2を採用しています。
Aurora Serverless v2では、最小ACU（Aurora Capacity Unit）を設定することで、アイドル時のコストを削減できます。
3.2.1 初期設計
今回の環境は検証用途であり、
- 常時アクセスがあるわけではない
- 多少のレスポンス遅延は許容できる
- 可能な限りコストを抑えたい
という要件がありました。
そのため、Auroraのコスト削減を目的としてScale to Zero（最小ACU = 0）の構成を検討しました。
CDKではbin/cdk.ts 上で以下のように変更することで有効化できます。
//enableAuroraScalesToZero: true,
↓
enableAuroraScalesToZero: true,
3.2.2 実際に発生した問題
しかし実際に利用を開始したところ、AuroraがDeep Sleep状態から復帰する際に30秒以上のレスポンス遅延が発生するケースがありました。
AuroraのDeep Sleepについては、以下の記事を参照してください。
Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング
特に以下のような状況で顕著でした。
- 長時間アクセスがない状態でのAPIリクエスト
- Difyのバックエンド処理がAuroraへ接続するタイミング
その結果、初回アクセス時に大きな遅延が発生することを確認しました。
3.2.3 コスト比較
そこで、Scale to Zeroを有効にした場合と、デフォルト設定である最小0.5ACUの場合のコストを比較しました。
結果として、両者の差は 約54 USD/月 程度でした。
3.2.4 設計判断
検証環境とはいえ、
- 初回アクセス時に30秒以上の遅延が発生する
- 利用者がシステム障害と誤認する可能性がある
という点から利用者体験を考慮し、最終的には最小ACUを0.5に設定する構成としました。
（この値はデフォルト値です。）
// enableAuroraScalesToZero: true,
これによりAuroraが常時起動状態となり、Deep Sleepからの復帰による遅延を回避できます。
3.3 ElastiCacheの構成（インスタンスサイズ/AZ構成）
3.3.1 インスタンスサイズ
Difyではキャッシュおよびキュー用途としてRedis（ElastiCache）が利用されています。
そのため、利用ユーザー数に応じてインスタンスタイプを調整する必要があります。
サンプル構成では、以下のサイズが使用されています。
cacheNodeType: 'cache.t4g.micro',
cache.t4g.microは小規模環境向けのインスタンスであり、同時利用ユーザーが増えるとメモリ不足やパフォーマンス低下が発生する可能性があります。
今回の環境では、最大同時利用者数を15名程度と想定していたため、性能余裕を確保するために以下のインスタンスタイプへ変更しました。
cacheNodeType: 'cache.t4g.small',
この変更は以下のCDKコードを修正することで対応しています。
lib/constructs/redis.ts
3.3.2 AZ構成
ElastiCacheは、可用性向上のためデフォルトではマルチAZ構成となっています。
ただし、マルチAZ構成では追加ノードが必要となるため、コストが増加します。
（東京リージョンでcache.t4g.smallを利用する場合、1ノードあたり28.2 USD/月）
今回の環境は検証環境用途であり、Redis停止による影響は限定的であること、および高可用性よりコスト削減を優先したいという要件があったため、シングルAZ構成で運用することとしました。
CDKではbin/cdk.ts 上で以下の引数でシングルAZ構成に切り替えられます。
isRedisMultiAz: false
3.4 WAFによるアクセス制限
今回の環境では、特定のIPアドレスからのみアクセス可能とするセキュリティ要件がありました。
そのため、AWS WAFを利用してIPアドレスによるアクセス制限を実装しました。
dify-self-hosted-on-awsでは、CDKの引数を設定することでWAFを有効化し、許可するIPアドレスを指定できます。
具体的には、以下のようにbin/cdk.ts 上でallowedIPv4Cidrsを設定することで、指定したIPアドレスのみアクセス可能な環境を構築できます。
allowedIPv4Cidrs: ['xxx.xxx.xxx.xxx/xx']
この設定を追加してcdk deployを実行すると、CloudFrontとAWS WAFが自動的に作成され、指定したIPアドレス以外からのアクセスがブロックされます。
今回の案件では、社内ネットワークからのみアクセス可能とする要件があったため、この設定を利用してIPアドレスベースのアクセス制御を実装しました。
3.5 最終構成まとめ
今回の検証環境では、以下のような構成としました。
| リソース | 設定 |
|---|---|
| Apiタスク | 2 vCPU / 4 GB |
| Aurora Serverless v2 | 0.5 〜 2 ACU |
| ElastiCache | cache.t4g.small |
| ElastiCache構成 | シングルAZ |
| セキュリティ | WAFによるIP制限 |
これにより、最大同時利用者15名の検証環境として十分な性能を確保しつつ、コストを抑えた構成を実現しています。
4. まとめ
この記事では、Dify OSS版をAWS上で構築した際に、実際の案件で調整したCDK設定と設計判断について紹介しました。
dify-self-hosted-on-aws では、cdk deployを実行することで基本構成を簡単に構築できますが、実際の利用環境では要件に応じたリソース調整やセキュリティ設定が必要になる場合があります。
今回の環境では、以下のような観点で構成を調整しました。
- ECSタスクのCPU / メモリを調整し、LLM利用時の処理負荷に対応
- Aurora Serverless v2の最小ACUを検討し、コストとレスポンス遅延のバランスを考慮
- ElastiCacheのインスタンスタイプやAZ構成を変更し、想定ユーザー数に対応しつつコスト削減
- WAFを利用したIPアドレス制限を実装し、セキュリティ要件に対応
これらの設定はすべてAWS CDKによってコード管理されているため、環境に応じた柔軟な調整が可能です。
Dify OSS版をAWS上でセルフホストする際には、デフォルト構成をそのまま利用するだけでなく、想定ユーザー数・用途・コスト要件に応じてCDK設定を調整することが重要です。
本記事が、DifyをAWS上で構築する際の参考になれば幸いです。