🐕大してアクセスないサイトにECSはオーバースペック2025/09/15に公開2025/09/169件テーマ「インフラ・セキュリティ」AWSAWS LambdaECSzennfes2025infratechDiscussionkanarus2ヶ月前に更新 lambdaではapi gatewayがないとインターネット経由でlambdaを呼び出せません。これらの料金をシンプルに加算して比較してみましょう。 API Gatewayは100万アクセスでも月1.29USDくらいです。アクセス数が少なければもっと安いですが、簡単のために全部この金額がかかることにします。 ここで Lambda Function URLs が最初から選択肢に入っていないのは何か理由があるのでしょうか？ (文脈を掴めていなかったらすみません…) gyana2ヶ月前に更新普通に知りませんでした。API Gateway使わなくてもパブリックアクセスができると追記しておきます。 知見ありがとうございます🙇 返信を追加acomagu2ヶ月前に更新うちは会社の方針で可能な限り Web サイトには Lambda を採用する方針となっています。(もう10年くらい？) Lambda で Web サイトをホストできるか？の一番の判断のポイントは「Cold Start が許容できるか」です。ECS では常時起動になりますが、Lambda では Cold Start があります。(Lambda はコンテナと違い複数リクエストを1コンテナで受ける、みたいなことができないのでこれは Provisioned Concurrency 等を用意していても基本避けられないと考えたほうがいいです。めちゃめちゃリクエストがあるなら別ですが) ランタイム自体の起動時間は多くの場合無視できますが、アプリケーション自体に起動時に時間のかかる処理が必要な場合、もしくは起動に数秒かかってしまうほど大規模なアプリケーションな場合、Lambda は諦めることになります。 しかし Cold Start の問題がクリアできれば、Lambda は驚くほどスムーズに Web バックエンドとして機能してくれます。前段は API Gateway でもいいですし、Function URL + CloudFront でも OK です。最近は VPC Lambda も癖無く動いてくれます。 Lambda をうまく使うコツは、「Function だからと言ってむやみに責務を複数の Lambda に分けない(界隈では Lambdalith という名前で知られています)」「できる限り Cold Start(起動時間)を速くするよう意識してコードを書く」「RDS に直接繋がない(RDS Proxy や DSQL を検討する)」「メモリキャッシュはできる限り使わない」あたりでしょうか。 あと最新の Next.js は正直現状 Lambda だと微妙なので、OpenNext で Cloudflare に上げたほうが体験はいいです。(この数か月で改善されていたらすみません) gyana2ヶ月前会社単位でlambda使ってるところもあるんですね！社内で提案する勇気が湧いてきます 確かにコールドスタートの問題がありましたね。前Django乗せる方法あるじゃん！と思って起動遅いって書いてあってやめた記憶がよみがえってきました 知見をありがとうございます🙇 返信を追加takanari7日前に更新私が直近でやった案件では React SPA + Lambda + DSQL（最近 GA されたやつ）で構築しました。DSQL は RDS と違い常時起動ではない PostgreSQL 互換の DB （一部制約あり）で、 リクエスト単位の動作（起動も一瞬）なので DB の稼働も節約できる（無料枠もあって、場合によってはかからない）構成です。 担当者数人しか使わない、極めて小規模な業務アプリの受託開発でした。それほどアクセスも高頻度でなく、データ量もそこまでなので、この場合インスタンスのランニングコストは当分かからない可能性もあります。小さい規模だとそれほど Cold Start も気にならない（Hono が薄いのもある）ですし、UIの工夫次第で感じ方を軽減できる可能性はあると思います。 ただし、Lambda と CloudFront を直接繋ぐ際、リクエストボディのハッシュ値をx-amz-content-sha256ヘッダーとして渡す必要があります。これらの解決を Lambda@Edge で行ったり等の多少の工夫が必要になります。 私が前提としている詳しい構成や設定方法等は、（私の友人が書いた著書ですが）以下の本をご参照ください。Pulumi による IaC まで含んでいます。ご参考までに。 https://zenn.dev/utcarnivaldayo/books/pulumi-lambadlith 返信を追加ひかる2ヶ月前apprunnerはどうですか？ 以前会社で小規模アプリを構築するときに採用しました。ECSより手軽に構築できますが、ECSほど細かく設定することはできない感じなので、スモールスタートに良い印象でした。費用感の比較はしていないので、参考までに🙏 https://aws.amazon.com/jp/apprunner/ 返信を追加がれっと2ヶ月前Lambda良いですよね！！！個人的にはAPI Gatewayと組み合わせてWebSocketを作れるところが好きです。 VPCにlamdba置いてRDS建てましょう。IG分余計にお金とられるけど Lambdaを置くのがPrivate Subnet, Public Subnetに関わらず、IGWのみで外部ネットワークに接続することはできません。NATインスタンスを使うのが定石ですが、コストを極限まで抑えるのであればLambdaにEIPをアタッチする方法もあります。 https://dev.classmethod.jp/articles/20230829-vpc-lambda/ 外部APIを叩くなどしなければ、そもそも不要ですが…（リクエストを受け付けることはできる） RDBに関してはAWS縛りがなければ、SupabaseやD1などに逃がしてしまうのが手っ取り早い気がします。 返信を追加nixieminton2ヶ月前わかりやすい記事をありがとうございました。 コンテナになるのはまだこれまでの延長線上にありますが、lambdaは理の外にあります lanbda web adapterというライブラリを用いることで、webサーバに限ってはコンテナと同等の負担でlambdaデプロイが可能になります。 こちらの記事が大変わかりやすいので、ご参考にしていただけると嬉しいです。 https://aws.amazon.com/jp/builders-flash/202301/lambda-web-adapter/ 返信を追加Satoshi Kita2ヶ月前Lambda良いですよね。私も大好きで、Lambdaで完結しているWebシステムもいくらかあるので少しコメントさせて頂きます。 「モダンなフレームワークを使えば勝手にLambdaでデプロイしてくれる」と書かれていますが、私の場合はLaravelを使うことが多いので、そのときはLaravel Vaporを使ってデプロイします。長いものだともう5年以上経ちますが、非常に安定して動いてくれています。 お金のかかり方は構成によってかなり違いますよね。 記事でも書かれていますが、DynamoDBで済ませるようなケースもあり、その場合は固定費はほとんどかかりません。外部サービスではありますが、Tursoのようなサービスが利用可能であれば、固定費のほぼかからないRDBとの組み合わせも作れるかもしれません。 一方でRDSを組み合わせると、RDSやらNATゲートウェイやらで途端に固定費が嵩みます。こちらのパターンは相当な規模までいかないとLambdaの費用が固定費を超えることはない印象です。こちらの場合、小規模だとVPS1台で済ませたりする方がずっと安上がりなので、必ずしもコスト的なメリットはありません。ですが個人的には、インフラのメンテから解放されるだけでも結構大きいと思っています。 複数のLambda関数の組み合わせについては、一般的にはLambdaからLambdaの直呼び出しはアンチパターンと言われていますが、現実的には同期処理したいことも多いので私は結構やってしまいます…。 正直Cloudflare Workersを使いたいシーンもあるんですけどね…ネットワーク待機中は課金されないのとか魅力的ですし。ですがそれを差し引いても、Lambdaの自由度はとても魅力的です。 返信を追加
kanarus2ヶ月前に更新 lambdaではapi gatewayがないとインターネット経由でlambdaを呼び出せません。これらの料金をシンプルに加算して比較してみましょう。 API Gatewayは100万アクセスでも月1.29USDくらいです。アクセス数が少なければもっと安いですが、簡単のために全部この金額がかかることにします。 ここで Lambda Function URLs が最初から選択肢に入っていないのは何か理由があるのでしょうか？ (文脈を掴めていなかったらすみません…) gyana2ヶ月前に更新普通に知りませんでした。API Gateway使わなくてもパブリックアクセスができると追記しておきます。 知見ありがとうございます🙇 返信を追加
acomagu2ヶ月前に更新うちは会社の方針で可能な限り Web サイトには Lambda を採用する方針となっています。(もう10年くらい？) Lambda で Web サイトをホストできるか？の一番の判断のポイントは「Cold Start が許容できるか」です。ECS では常時起動になりますが、Lambda では Cold Start があります。(Lambda はコンテナと違い複数リクエストを1コンテナで受ける、みたいなことができないのでこれは Provisioned Concurrency 等を用意していても基本避けられないと考えたほうがいいです。めちゃめちゃリクエストがあるなら別ですが) ランタイム自体の起動時間は多くの場合無視できますが、アプリケーション自体に起動時に時間のかかる処理が必要な場合、もしくは起動に数秒かかってしまうほど大規模なアプリケーションな場合、Lambda は諦めることになります。 しかし Cold Start の問題がクリアできれば、Lambda は驚くほどスムーズに Web バックエンドとして機能してくれます。前段は API Gateway でもいいですし、Function URL + CloudFront でも OK です。最近は VPC Lambda も癖無く動いてくれます。 Lambda をうまく使うコツは、「Function だからと言ってむやみに責務を複数の Lambda に分けない(界隈では Lambdalith という名前で知られています)」「できる限り Cold Start(起動時間)を速くするよう意識してコードを書く」「RDS に直接繋がない(RDS Proxy や DSQL を検討する)」「メモリキャッシュはできる限り使わない」あたりでしょうか。 あと最新の Next.js は正直現状 Lambda だと微妙なので、OpenNext で Cloudflare に上げたほうが体験はいいです。(この数か月で改善されていたらすみません) gyana2ヶ月前会社単位でlambda使ってるところもあるんですね！社内で提案する勇気が湧いてきます 確かにコールドスタートの問題がありましたね。前Django乗せる方法あるじゃん！と思って起動遅いって書いてあってやめた記憶がよみがえってきました 知見をありがとうございます🙇 返信を追加
gyana2ヶ月前会社単位でlambda使ってるところもあるんですね！社内で提案する勇気が湧いてきます 確かにコールドスタートの問題がありましたね。前Django乗せる方法あるじゃん！と思って起動遅いって書いてあってやめた記憶がよみがえってきました 知見をありがとうございます🙇
takanari7日前に更新私が直近でやった案件では React SPA + Lambda + DSQL（最近 GA されたやつ）で構築しました。DSQL は RDS と違い常時起動ではない PostgreSQL 互換の DB （一部制約あり）で、 リクエスト単位の動作（起動も一瞬）なので DB の稼働も節約できる（無料枠もあって、場合によってはかからない）構成です。 担当者数人しか使わない、極めて小規模な業務アプリの受託開発でした。それほどアクセスも高頻度でなく、データ量もそこまでなので、この場合インスタンスのランニングコストは当分かからない可能性もあります。小さい規模だとそれほど Cold Start も気にならない（Hono が薄いのもある）ですし、UIの工夫次第で感じ方を軽減できる可能性はあると思います。 ただし、Lambda と CloudFront を直接繋ぐ際、リクエストボディのハッシュ値をx-amz-content-sha256ヘッダーとして渡す必要があります。これらの解決を Lambda@Edge で行ったり等の多少の工夫が必要になります。 私が前提としている詳しい構成や設定方法等は、（私の友人が書いた著書ですが）以下の本をご参照ください。Pulumi による IaC まで含んでいます。ご参考までに。 https://zenn.dev/utcarnivaldayo/books/pulumi-lambadlith 返信を追加
ひかる2ヶ月前apprunnerはどうですか？ 以前会社で小規模アプリを構築するときに採用しました。ECSより手軽に構築できますが、ECSほど細かく設定することはできない感じなので、スモールスタートに良い印象でした。費用感の比較はしていないので、参考までに🙏 https://aws.amazon.com/jp/apprunner/ 返信を追加
がれっと2ヶ月前Lambda良いですよね！！！個人的にはAPI Gatewayと組み合わせてWebSocketを作れるところが好きです。 VPCにlamdba置いてRDS建てましょう。IG分余計にお金とられるけど Lambdaを置くのがPrivate Subnet, Public Subnetに関わらず、IGWのみで外部ネットワークに接続することはできません。NATインスタンスを使うのが定石ですが、コストを極限まで抑えるのであればLambdaにEIPをアタッチする方法もあります。 https://dev.classmethod.jp/articles/20230829-vpc-lambda/ 外部APIを叩くなどしなければ、そもそも不要ですが…（リクエストを受け付けることはできる） RDBに関してはAWS縛りがなければ、SupabaseやD1などに逃がしてしまうのが手っ取り早い気がします。 返信を追加
nixieminton2ヶ月前わかりやすい記事をありがとうございました。 コンテナになるのはまだこれまでの延長線上にありますが、lambdaは理の外にあります lanbda web adapterというライブラリを用いることで、webサーバに限ってはコンテナと同等の負担でlambdaデプロイが可能になります。 こちらの記事が大変わかりやすいので、ご参考にしていただけると嬉しいです。 https://aws.amazon.com/jp/builders-flash/202301/lambda-web-adapter/ 返信を追加
Satoshi Kita2ヶ月前Lambda良いですよね。私も大好きで、Lambdaで完結しているWebシステムもいくらかあるので少しコメントさせて頂きます。 「モダンなフレームワークを使えば勝手にLambdaでデプロイしてくれる」と書かれていますが、私の場合はLaravelを使うことが多いので、そのときはLaravel Vaporを使ってデプロイします。長いものだともう5年以上経ちますが、非常に安定して動いてくれています。 お金のかかり方は構成によってかなり違いますよね。 記事でも書かれていますが、DynamoDBで済ませるようなケースもあり、その場合は固定費はほとんどかかりません。外部サービスではありますが、Tursoのようなサービスが利用可能であれば、固定費のほぼかからないRDBとの組み合わせも作れるかもしれません。 一方でRDSを組み合わせると、RDSやらNATゲートウェイやらで途端に固定費が嵩みます。こちらのパターンは相当な規模までいかないとLambdaの費用が固定費を超えることはない印象です。こちらの場合、小規模だとVPS1台で済ませたりする方がずっと安上がりなので、必ずしもコスト的なメリットはありません。ですが個人的には、インフラのメンテから解放されるだけでも結構大きいと思っています。 複数のLambda関数の組み合わせについては、一般的にはLambdaからLambdaの直呼び出しはアンチパターンと言われていますが、現実的には同期処理したいことも多いので私は結構やってしまいます…。 正直Cloudflare Workersを使いたいシーンもあるんですけどね…ネットワーク待機中は課金されないのとか魅力的ですし。ですがそれを差し引いても、Lambdaの自由度はとても魅力的です。 返信を追加
Discussion
ここで Lambda Function URLs が最初から選択肢に入っていないのは何か理由があるのでしょうか？
(文脈を掴めていなかったらすみません…)
普通に知りませんでした。API Gateway使わなくてもパブリックアクセスができると追記しておきます。
知見ありがとうございます🙇
うちは会社の方針で可能な限り Web サイトには Lambda を採用する方針となっています。(もう10年くらい？)
Lambda で Web サイトをホストできるか？の一番の判断のポイントは「Cold Start が許容できるか」です。ECS では常時起動になりますが、Lambda では Cold Start があります。(Lambda はコンテナと違い複数リクエストを1コンテナで受ける、みたいなことができないのでこれは Provisioned Concurrency 等を用意していても基本避けられないと考えたほうがいいです。めちゃめちゃリクエストがあるなら別ですが) ランタイム自体の起動時間は多くの場合無視できますが、アプリケーション自体に起動時に時間のかかる処理が必要な場合、もしくは起動に数秒かかってしまうほど大規模なアプリケーションな場合、Lambda は諦めることになります。
しかし Cold Start の問題がクリアできれば、Lambda は驚くほどスムーズに Web バックエンドとして機能してくれます。前段は API Gateway でもいいですし、Function URL + CloudFront でも OK です。最近は VPC Lambda も癖無く動いてくれます。
Lambda をうまく使うコツは、「Function だからと言ってむやみに責務を複数の Lambda に分けない(界隈では Lambdalith という名前で知られています)」「できる限り Cold Start(起動時間)を速くするよう意識してコードを書く」「RDS に直接繋がない(RDS Proxy や DSQL を検討する)」「メモリキャッシュはできる限り使わない」あたりでしょうか。
あと最新の Next.js は正直現状 Lambda だと微妙なので、OpenNext で Cloudflare に上げたほうが体験はいいです。(この数か月で改善されていたらすみません)
会社単位でlambda使ってるところもあるんですね！社内で提案する勇気が湧いてきます
確かにコールドスタートの問題がありましたね。前Django乗せる方法あるじゃん！と思って起動遅いって書いてあってやめた記憶がよみがえってきました
知見をありがとうございます🙇
私が直近でやった案件では React SPA + Lambda + DSQL（最近 GA されたやつ）で構築しました。DSQL は RDS と違い常時起動ではない PostgreSQL 互換の DB （一部制約あり）で、 リクエスト単位の動作（起動も一瞬）なので DB の稼働も節約できる（無料枠もあって、場合によってはかからない）構成です。
担当者数人しか使わない、極めて小規模な業務アプリの受託開発でした。それほどアクセスも高頻度でなく、データ量もそこまでなので、この場合インスタンスのランニングコストは当分かからない可能性もあります。小さい規模だとそれほど Cold Start も気にならない（Hono が薄いのもある）ですし、UIの工夫次第で感じ方を軽減できる可能性はあると思います。
ただし、Lambda と CloudFront を直接繋ぐ際、リクエストボディのハッシュ値を
x-amz-content-sha256ヘッダーとして渡す必要があります。これらの解決を Lambda@Edge で行ったり等の多少の工夫が必要になります。私が前提としている詳しい構成や設定方法等は、（私の友人が書いた著書ですが）以下の本をご参照ください。Pulumi による IaC まで含んでいます。ご参考までに。
apprunnerはどうですか？ 以前会社で小規模アプリを構築するときに採用しました。ECSより手軽に構築できますが、ECSほど細かく設定することはできない感じなので、スモールスタートに良い印象でした。費用感の比較はしていないので、参考までに🙏
Lambda良いですよね！！！個人的にはAPI Gatewayと組み合わせてWebSocketを作れるところが好きです。
Lambdaを置くのがPrivate Subnet, Public Subnetに関わらず、IGWのみで外部ネットワークに接続することはできません。NATインスタンスを使うのが定石ですが、コストを極限まで抑えるのであればLambdaにEIPをアタッチする方法もあります。 外部APIを叩くなどしなければ、そもそも不要ですが…（リクエストを受け付けることはできる）
RDBに関してはAWS縛りがなければ、SupabaseやD1などに逃がしてしまうのが手っ取り早い気がします。
わかりやすい記事をありがとうございました。
lanbda web adapterというライブラリを用いることで、webサーバに限ってはコンテナと同等の負担でlambdaデプロイが可能になります。
こちらの記事が大変わかりやすいので、ご参考にしていただけると嬉しいです。
Lambda良いですよね。私も大好きで、Lambdaで完結しているWebシステムもいくらかあるので少しコメントさせて頂きます。
「モダンなフレームワークを使えば勝手にLambdaでデプロイしてくれる」と書かれていますが、私の場合はLaravelを使うことが多いので、そのときはLaravel Vaporを使ってデプロイします。長いものだともう5年以上経ちますが、非常に安定して動いてくれています。
お金のかかり方は構成によってかなり違いますよね。
記事でも書かれていますが、DynamoDBで済ませるようなケースもあり、その場合は固定費はほとんどかかりません。外部サービスではありますが、Tursoのようなサービスが利用可能であれば、固定費のほぼかからないRDBとの組み合わせも作れるかもしれません。
一方でRDSを組み合わせると、RDSやらNATゲートウェイやらで途端に固定費が嵩みます。こちらのパターンは相当な規模までいかないとLambdaの費用が固定費を超えることはない印象です。こちらの場合、小規模だとVPS1台で済ませたりする方がずっと安上がりなので、必ずしもコスト的なメリットはありません。ですが個人的には、インフラのメンテから解放されるだけでも結構大きいと思っています。
複数のLambda関数の組み合わせについては、一般的にはLambdaからLambdaの直呼び出しはアンチパターンと言われていますが、現実的には同期処理したいことも多いので私は結構やってしまいます…。
正直Cloudflare Workersを使いたいシーンもあるんですけどね…ネットワーク待機中は課金されないのとか魅力的ですし。ですがそれを差し引いても、Lambdaの自由度はとても魅力的です。