少し今更感もある感じもしますが、Difyの操作感を試すのとAWS上での動きを確認するためにもとても良い気がしているので、本記事公開時点の使用に基づいたメモを残します。
仕事の動作確認などでも利用できそうなので、そのためにも後で使うかなと。
ただし、今回のALB構成スクリプトをただ回しただけですと、ALB のデフォルトドメインでは ACM 証明書を発行できないHTTPでの構成になるので、本番などでの利用を考えるとCloudFrontを挟むデフォルトの構成(HTTPS)の方がよいのかもしれません。
独自ドメインがあるのであれば、今回の構成でも良いかなとは思います。
Deployの仕組みとしては、Typescript CDKを利用したDeployのようです。
実行の仕方としては、npxのコマンドで実施していく方法と、リポジトリに含まれてるシェルスクリプト(simple-deploy.sh)を叩いて実行する方法のようで、前者は、ローカルでbuild類の処理を行ったのちにDeployがされ、後者はCodeBuildを利用するなどしてCloudShellからでも実行がしやすいようになっているようです。
既に先人を斬られてる方々も沢山おりますので、そちらも参考にしながら今回は実施します。
今回の内容はアクセスの制限の方法などを取り入れていますが、ご自身の責任において実施ください
公開されているリポジトリ
参照日本語ドキュメント
リポジトリのREADMEにも書かれている日本語ドキュメントも大変参考になると思いますので、ご確認ください。
【Cloud9版】AWS CDKでDifyを一撃構築|Shinoda
AWSマネージドサービスで Dify のセルフホスティングを試してみた | DevelopersIO
今回の環境
その他READMEの要件としては以下があります。
今回はローカルMacでも全て条件がそろっている状態で実施しています。
(CodeBuildを利用する付属のシェルスクリプトでDeployする際はDockerは不要なはずです)
Node.js (v18 or newer)
Docker
AWS CLI and IAM profile with Administrator policy
今回確認してみること
- 最低限の設定+アクセス制限やCloudFrontを使わない設定など
実行で試した際にかかった大凡の費用感
※後日わかれば追記予定
大まかな作業のながれ
- リポジトリを clone
- cdk.ts を編集(リージョン・コスト設定・IP制限)
- ./simple-deploy.sh でデプロイ
- 出力された URL にアクセス(HTTP)
- cdk destroy で削除
Deploy作業をおこなう
ローカルにリポジトリをクローンする
> git clone https://github.com/aws-samples/dify-self-hosted-on-aws > cd dify-self-hosted-on-aws
設定ファイルのcdk.tsを編集します
> vim ./lib/cdk.ts
まずは構築をさせるリージョンの設定をしましょう。
作成するリージョンをテキストで指定します。
初期値として、us-west-2が入っています。
(あらかじめaws configでの設定はしておく必要があります)
awsRegion: 'us-west-2',
次に、コストを抑える設定として以下をコメントアウトしておきます。この項目は初期の段階から入っているようです。
// uncomment the below options for less expensive configuration: // isRedisMultiAz: false, // useNatInstance: true, // enableAuroraScalesToZero: true, // useFargateSpot: true,
それぞれ以下のような感じです。
- isRedisMultiAz: RedisマルチAZ
- useNatInstance: NATインスタンス使用
- enableAuroraScalesToZero: Auroraのアイドル時に自動停止
- useFargateSpot: Fargate Spot使用
次に、初期では設定ファイルにコメントされた状態として入っていませんが、CloudFrontは使わずにALB構成かつIPv4でのACLを入れてアクセス制限をつけてみます。
もし独自ドメインを利用される場合は、追加でdomainNameとsubDomainのパラメータを指定してください。(今回は未指定)
また、その他の設定が可能なパラメータなどについては、READMEの通りlib/environment-props.ts を確認すると初期値を含めて設定できるパラメータが確認できます。
クローズドネットワークで試す方法のパラーメータの参考は、READMEに記載があるので参考に。
ちなみにですが、ここでCloudFrontはTrueにし、アクセス制限(WAF Web ACL Rule)をかけることも可能です。(できた)
// CloudFrontを無効にする
useCloudFront: false,
// アクセス制限を設定(例:特定のIPアドレスからのみアクセス許可)
allowedIPv4Cidrs: [
'192.168.1.0/32', // 例:これを作業環境のグローバルIPアドレスなどにします
'10.0.0.0/8', // 必要に応じて追加のCIDRを指定
],
// uncomment the below options for less expensive configuration:
isRedisMultiAz: false,
useNatInstance: true,
enableAuroraScalesToZero: true,
useFargateSpot: true,
ちなみに、設定を間違った場合は、再度IPアドレスを修正などをするなどして、再度Deployを実行しなおせば反映できます。
Deployの実行
今回はCloudShellを使わないですが、buildもCodeBuildを利用するとして、dify-self-hosted-on-aws直下にある、simple-deploy.shを用いて実施します。
> ./simple-deploy.sh
実行を行うと、以下のメッセージのように始まります。
仮に、npxのコマンドがない場合などは、途中でエラーメッセージがでると思いますので、そこで確認します。
❯ ./simple-deploy.sh ⏱️ Preparing CloudFormation stack DifySimpleDeployStack...
途中Deployについて聞かれるので、yesを入力
Are you sure you want to deploy? Please check the configuration parameters in bin/cdk.ts. If you are ready, type 'yes': yes
あとは、実行処理が進むのを待ちます。大体10から20分くらいで問題がなければ完了すると思われます。
途中、AWSのマネージメントコンソール上の、CodeBuildやCloudFormationのステータスを確認すると状況も掴みやすいです。
実行が完了するとプロンプトが私の場合は帰ってこなかったので、最終的にはCloudFormtionのステータスをチェックして完了の判断をしてました。
ターミナル上ですと以下のメッセージ付近がでていれば完了していそうです。
2025-MM-DDT12:16:47 [Container] 2025/MM/DD 12:16:47.093522 Phase complete: UPLOAD_ARTIFACTS State: SUCCEEDED
また、この際の実際のDifyへのアクセスするためのURLは、ターミナル上のログに出てきますのでそこで確認します。
DifyOnAwsStack.DifyUrl = http://DifyOn-XXXXXXXXXXXXXXXXX.us-west-2.elb.amazonaws.com
それでも見つけられない場合は、CloudFormationのログを見るとわかります。
> aws cloudformation describe-stacks \ --stack-name DifyOnAwsStack \ --query 'Stacks[0].Outputs[?OutputKey==`DifyUrl`].OutputValue' \ --output text http://DifyOn-XXXXXXXXXXXXXXXXX.us-west-2.elb.amazonaws.com
Difyへのアクセス
Difyへは上記で表示されたURLへアクセスすることでアクセスができます。
※TLSの設定はしていないのでHTTPアクセスです
※必ずAlllowしていないIPの端末(スマートフォン使ってみるとか)から表示ができない事の確認もしてくださいね

作成したリソースの削除
npxコマンドではなく、simple-deploy.shを実行した場合も以下で削除になるそうです。
ただし、リソースによっては削除が失敗または削除対象にない場合もあるため、AWS コンソールや CLI で個別に確認をして削除する必要がありそうです。
(何度か試していますが、S3バケットやRoleなど細かい部分は残ってしまうようです)
> npx cdk destroy --all
さいごに
気軽に試せるのはとてとありがたいポイントです。
その他気づいた点としては、このCloudFormationを実行するとリソースネームがしっかり設定されるので、仮にリソースの削除ができてない場合でも、それなりにdescribeなどで探すことができるということです。
当たり前ではあるのですが、一貫性がなかったり後でつけるから良いやっていうのは避けないといけないなと、本筋ではないところの気づきもありました。
あと、設定を更新した際に、上手く反映が効かないような事象(環境依存かもしれない)もあったので、設定後の動作確認は必ず実施しましょう。
別の設定方法やDify側のネタのあれば改めて投稿しようと思います。