Lambda×EFS×SQLiteの構成を解説。AWSのサーバー代はEFS代が中心

出典: 【AWS】サーバ代ほぼ0円でWebアプリを動かす方法【Lambda × EFS × SQLite】

動画が最初に置くのは、作り方ではありません。小さなWebアプリを動かすだけなのに、料金が重くなります。その困りごとが、話の入り口。社内で数人しか開かない画面に、毎月いくら払えるでしょうか？

りょうまさんは冒頭で、実務でも月200円程度で動いている実績がある、と切り出します。要になるのは、API を Lambda に、データベースを EFS 上の SQLite にすること。

出発点の困りごとは、EC2 と RDS とロードバランサーと静的IPを組むと、あっという間に月1万円ぐらいになること。ECS や EKS なら、さらに高くつきます。

頭にあるのは、社内の管理画面を動かしたいだけの場面です。小さなアプリのたびに ECS を立てていたら、月に1万円や2万円かかって痛い。そんな本音の話が続きます。

りょうまさん（動画 0:55〜）

その時にも毎回毎回このECS立てるってなったら月1万とか2万かかってしまうので、これはちょっと痛いなという風に率直に思ったりするわけですね。

Google Cloud や Cloudflare、VPS など、他社のクラウドで安くする手もあります。それでも、すでにAWSで運用している会社なら、ベンダーが分散するのが面倒。ここがりょうまさんの立ち位置です。

合う前提の1つ目は、定常的なリクエストがなく、今後もスケールする予定がない物。スケールするなら最初からちゃんとした構成で、とりょうまさんははっきり言い切ります。

2つ目は、VPC やサブネット、NAT Gateway、Route 53 のホストゾーンを、すでにAWSで運用している人。料金は2026年10月時点の感覚なので、最新は公式の料金表で確かめてほしい、という断りも添えています。

すでにAWSで運用しているなら、AWSの中に収めます。りょうまさんの話は、Lambda や EFS より前に、置き場をどこにするかで始まります。

ベンダーが分散するのが面倒、という一言。構成の話より先に、これは置き場の数の話だ、と私は考えます。小さな物を、どこに出すか。私の手元にも、この問いに答えた場面が2つあります。

10月13日、まっちんぐーのリアル会のLPを、Cloudflare Pages に公開しました。

その3日後の10月16日には、納豆本をもとにした調べのサイトを、Cloudflare Pages に公開。全部で69ページ。

リアル会のLPと、69ページの調べのサイト。目的も大きさも違う2つを、同じ置き場に出したわけです。

置き場を先に決めておくと、出すたびに場所から選び直さずに済みます。

私の記事より（Cloudflare Workersの料金を、月5ドルの有料版との違いや他社との比べ方で整理した記事・Cloudflareを選ぶ理由と、向かない場面の節）

私がCloudflareを選ぶのは、軽い処理を小さく足したい時です。WorkersとD1とR2を同じ提供元の中でつなげて、サーバーのOSの面倒を見ずに済む。そこを選ぶ理由にしています。

置き場を選ぶ理由は、サーバーのOSの面倒を見ずに済むかどうか。同じ提供元の中でつなげられるかどうか。

りょうまさんは、すでにAWSにいるから、AWSの中に収めます。向きは逆でも、置き場を先に決めてから公開する流れは、私の2つの公開と同じです。

社内で数人しか開かない管理画面なら、手元にあるどの置き場の延長に置くでしょうか？

全体の構成は、API とデータベースの2つに分かれます。この章は API の側。リクエストを受けて、処理して、返す部分です。

全体の形は、API Gateway と Lambda が API を受け持ち、Lambda にマウントした EFS の上で SQLite がデータベースになる、というもの。認証や配信が要るなら、Cognito と CloudFront と S3 を足します。

Lambda を選ぶ理由は、リクエストごとに起動して、終われば止まること。使わない時間には料金がかからない、というのがりょうまさんの説明です。

りょうまさん（動画 3:12〜）

ラムダってのがリクエストベースで起動して終わったら停止してくれるっていうそういうゼロスケールができるサービスになるので、

例に挙がるのは、実行環境が Node.js、ORM が Prisma という組み合わせ。Prisma は SQLite と相性がよい、とりょうまさんは言います。Python など他の言語でもかまわない、という添え書きつきです。

証明書は ACM に置き、API Gateway で TLS を終端する形。

呼ばれた時だけ起きて、終わったら止まります。Lambda の話を短くすると、これだけ。

社内の管理画面を思い浮かべてみてください。朝に誰かが開いて、昼に少し使って、夜は誰も触りません。そういう画面は、1日の大半を待って過ごしています。

サーバーを立てたままにすると、その待っている時間にも料金が乗ります。Lambda なら、待っている時間は料金の外。

料金の形そのものが、動いた回数に合わせて変わります。API の側で Lambda を選ぶ理由は、ここに集まっています。

第1章の前提を思い出すと、つながりが見えてきます。定常的なリクエストがない物。使う人が少ないほど、止まっている時間は長くなります。

反対に、1日じゅう呼ばれ続ける物なら、止まる時間そのものがありません。りょうまさんが、スケールするなら最初からちゃんとした構成で、と話していたのも、この線の上で読めます。

言語や ORM を選ぶのは、その後の話。先に決めるのは、動かし続けるかどうか。

その画面は、1日のうち何時間、誰かに開かれているでしょうか？

この構成でいちばん目を引くのは、データベースの置き方です。選ぶのはRDSではなく、ファイルで動くSQLite。なぜ、わざわざファイルにするのでしょう？りょうまさんの説明は、この問いから始まります。

EFS は、AWSのマネージドなファイルシステム。ネットワーク越しに、手元のディレクトリのように使える置き場です。そして SQLite は、ファイルベースで動くリレーショナルデータベース。

りょうまさん（動画 5:03〜）

ファイルベースで動かすことができるリレーショナルデータベースだからっていうところです。

ここで名前が挙がるのが、PostgreSQL と MySQL。どちらもファイルベースでは動かせないので、この構成には載せられない、というのがりょうまさんの説明です。

料金を比べる相手は RDS。常にサーバーを起動させるので、例として月7000円ほどかかる、とりょうまさんは話します。EFS のほうは、Lambda が起動する時だけマウントして、ストレージ量に応じた従量課金。

りょうまさん（動画 6:27〜）

リレーションのデータベースを使いたいと。だから普通はRDSを使いたいってなるんですけど、RDSは高いのでEFSでケチケチ節約しようっていう、そういう発想になります。

では、DynamoDB ではだめなのか。動画の答えは、NoSQL だけでプロダクトを運用するのは辛い、というもの。インデックスをあらかじめ決めておく必要があるからです。

土台にあるのは、リレーショナルデータベースを使いたい需要の大きさ。けれど RDS は高いので、EFS で節約します。そういう発想で組まれた構成です。

普通なら RDS。そこを EFS 上の SQLite に替えて節約します。りょうまさんの話は、この順番で進みます。

節約の工夫に入る前に、1つだけ立ち止まりたい所があります。標準の道で、本当に足りないのか？

10月17日のことです。メールと公式の窓口の読者を、同じ人にまとめる仕組み。自作の受け口を含む6つの手順で、作り込んでいた件がありました。

そこで私は「まずリサーチすること。成功方法を真似て車輪の再発明を絶対にしないこと」と返しました。続けて返したのが、「複雑にしないこと」と「シンプルイズベスト、ゼロベースで常に本質見ること。」の2つ。

ツールの公式ヘルプには、標準の手順がありました。同じシナリオを指定したメールフォームと、サンキューページのボタンだけでまとめられる手順。

6つの手順と、フォームとボタンだけの手順。同じ目的に、道が2本あったんです。

動画の場合、標準の道で足りない所は、RDS を常に起動させておく、月7000円ほどの料金です。ここを言葉にできているから、EFS と SQLite の道に意味が出ます。足りない所を言えないまま道を足すと、6つの手順で作り込んでいた時の私と、同じ形になります。

私なら、EFS で節約する前に、RDS で足りない所がどこかを先に調べます。標準で足りるなら、自作しません。

EFSを使うと決めると、次に出てくるのがネットワークの話です。ファイルの置き場は、どこにあるのか。Lambdaは、そこへどうやって届くのか？動画の構成図が、この道筋を見せてくれます。

EFS の Mount Target は VPC の中に置かれます。だから Lambda も VPC Lambda として動かす必要がある、とりょうまさんは続けます。

りょうまさん（動画 8:06〜）

ラムダをVPC上で動かすための何かしらの仕組みが必要で、それがVPCラムダというものになります。

道筋をたどると、プライベートサブネットにある ENI を経由して、そこから Mount Target へ NFS で接続する形。構成図にも、この2つが描かれています。

画面の中央には、Lambda から Mount Target までの道筋をまとめた1枚の構成図。黒い背景の上に、つなぐ順番がそのまま並んでいます。

Lambda から EFS へ。図の上では、1本の線です。

でも、その線の途中には、部品がいくつも挟まります。VPC があって、その中にプライベートサブネット。サブネットの中に ENI、その先に Mount Target。

数えると4つ。線を1本引くつもりが、4つの部品を順に通る道になっています。

前の章の節約は、この道の上に乗っています。データベースをファイルにするから EFS を使い、Mount Target が VPC の中にあるから、Lambda も VPC に入ります。1つの選択が、次の選択を連れてくる形。

線の途中で動かなくなったら、VPC、サブネット、ENI、Mount Target のうち、どこから確かめるでしょうか？図を見る時は、線の長さより、通る部品の数を数えておくと、後の話が追いやすくなります。VPC の中にいる Lambda が外へ出る時の話も、運用の注意点の章で出てきます。

では、この部品と EFS に、月々いくらかかるのか。次の章で、りょうまさんがサービスを1つずつ並べていきます。

ここで動画は、この構成にかかる料金を、サービスごとに1つずつ並べていきます。りょうまさん自身、料金は2026年10月時点の感覚で、最新は公式の料金表で確かめてほしい、と断っています。

最初は API Gateway。定常的な料金はかからず、100万リクエストで1ドル、とりょうまさん。証明書を置く ACM にも、料金はかかりません。

続いて Lambda。月100万リクエストまでは料金がかからず、それを超えると100万リクエストで0.2ドル、という説明です。

料金が発生する本命は EFS。Standard で1GBあたり0.3ドルだと、りょうまさんは話します。

Cognito は、月50MAUまで料金がかからず、そこから先は1MAUあたり0.015ドル。Route 53 のホストゾーンは月0.5ドルで、他のプロダクトがすでにあれば使い回せる、という補足が付きます。

CloudFront と S3 は、少量ならほぼ料金がかからない扱い。VPC やサブネット、ルートテーブルにも料金はかかりません。

そして結論。実際にかかるのは EFS 代だけで、実務では月200円程度で数か月運用できている、というのがりょうまさんの話です。

りょうまさん（動画 10:50〜）

実際これ実務で稼働実績ありまして、月200円程度で数ヶ月運用できてるっていう実績もあるので、これはかなりおすすめの構成というか、ま、AWS上で実現できるほぼ最安値の構成になるかなと思います。

NAT Gateway は、既存のプロダクトの使い回しなので計算の対象外。この構成のためだけに新設すると月7000円ぐらいで、RDS も最低スペックで月7000円程度、と付け加えます。

月200円。この数字には、前提が1つ付いています。NAT Gateway も Route 53 のホストゾーンも、すでにある物を使い回す、という前提。

すでにある物を、どう数えるか。ここで思い出す場面があります。

9月29日、手元の環境で Cloudflare Pages を今も使っているかを、調べる場面がありました。

返ってきた答えは、手元では使っていない、というもの。調べたのは、グローバルのコマンドが見つからないことと、メモの記録だけでした。

実際は違いました。道具は、各プロジェクトの中にそれぞれ入っていて、その置き場に公開済みのサイトが6つありました。誤報告です。

見た場所が狭かったのです。それだけで、6つある物が、ないことになったんです。

動画の月200円を読む時も、気をつける所は同じ。NAT Gateway がすでにあるか。Route 53 のホストゾーンがすでにあるか。

すでにあると数えた物が、実は無かったら？NAT Gateway を新設するだけで、りょうまさんの話す月7000円ぐらいが乗ってきます。月200円の前提ごと外れる形。

あと1つ、見ておきたいのが枠の切れ目です。Lambda なら月100万リクエスト、Cognito なら月50MAU。どちらも、数が増えた先で料金が始まります。

私なら、料金表を開く前に、すでにある物を手元のどこまで見て数えたかを確かめます。NAT Gateway の有無と、枠が切れる点。料金の数字を追うのは、その2つを押さえてから。

ここまでは構成と料金の話でした。最後は、動かし始めてから気をつける点と、よくある質問への答え。りょうまさんは順に挙げていきます。

1つ目の注意点は NAT Gateway。VPC Lambda から外へ通信する時、たとえば Parameter Store や ECR、S3 を使う時に、NAT Gateway が要ります。月7000円程度でも、既存があれば使い回せる、という補足つき。

2つ目は、SQLite が同時に書き込めないこと。書き込みは直列化されて、複数の Lambda からの分は順に処理されます。止まるのではなく、待つ時間が延びるだけ、というのがりょうまさんの説明です。

りょうまさん（動画 12:52〜）

順番待ちで処理されていくので待てば実行されるっていう感じですね。ですのでこうエラーになるわけじゃなくてあくまでちょっと時間かかるよっていう感じです。

読み込みのほうは、複数の Lambda から同時にできます。社内の管理画面で同時に使うのは数人なので、問題ないレベル、という見立てです。

3つ目は構築のハードル。API Gateway と Lambda をつなぎ、Lambda から EFS への疎通とセキュリティグループを通すのが、地味に難しい、とりょうまさんは言います。

インフラに慣れた人向けの構成なので、まず API Gateway と Lambda だけで練習して、その後で EFS を付ける順を勧めています。

ここからは Q&A。データベースの変更は、マイグレーション用の専用 Lambda を作り、CI/CD から aws lambda invoke で実行します。API 用の Lambda で動かすと、コールドスタートのたびに走ってしまうので避ける、という理由つき。

中身を見たい時は、踏み台の EC2 に EFS をマウントして、SQLite のコマンドで確認。バックアップは AWS Backup で、EFS を対象に定期的に取れます。

API Gateway ではなく Lambda の関数URLで足りるのは、レートリミット、Cognito のユーザープール認証、WAF、独自ドメインの4つが要らない時。

EFS 上で SQLite が壊れないか、という質問には、基本的には起こらない、と答えます。EFS 上のファイルには、通常の SQLite 相当のロックが使えるから、という理由。

その一方で、SQLite の公式は NFS 上での運用に注意を促している、とも付け加えます。心配なら、RDS のように公式が推奨する物を使う方がいい、という立場。

りょうまさん（動画 17:02〜）

心配であれば大人しくRDSなど公式が推奨してるものを使った方がいいんじゃないかなという風に思います。

締めは、API を VPC Lambda で動かすことと、データベースを EFS 上の SQLite で動かすこと。商用の一般ユーザー向けでは書き込みが厳しく、社内のちょっとした管理画面なら十分に動く、とりょうまさんは結びます。

壊れないかと聞かれて、基本的には起こらない、と答えます。そのうえで、SQLite の公式は NFS 上の運用に注意を促している、と自分から付け加えます。この並べ方が、私には大事に見えます。

説明を聞いて、大丈夫だと思うこと。確かめてから、大丈夫と言うこと。この2つの間には、距離があります。

10月16日、納豆本をもとにした調べのサイト69ページを、公開する前の場面です。画面を1枚も撮らないまま、完成と報告がありました。

その画面は、見にくいものでした。こんなに見にくいのに、なぜ完成と言うのか、と私は返しました。

そこで作ったのが、画面を撮る検査です。69ページを、1280と390の2つの幅で撮りました。合わせて138画面。

138画面を見て、14か所を直してから、69ページを出しました。

私の記事より（AI整体師さんの動画から、データの正本の置き場と戻し方を作る前に決める手順を読んだ記事・自作スライドシステムで、データの正本を1か所に決めると、何が守られるのかの節）

戻せるかは、作業の前に決めるしかない。

大丈夫かどうかも、戻せるかと同じ形をしています。出したあとで確かめるのではなく、出す前に、確かめる所を決めておく。完成の報告より先に、138画面がある順番です。

りょうまさんの Q&A を並べ直すと、AWS Backup で EFS を定期的に取ること、マイグレーションを専用の Lambda で回すこと、踏み台の EC2 から中身を見ること。どれも、戻す側と確かめる側の準備です。

AWS Backup から EFS を戻す手順を、出す前に一度でも通しておくのか。通さずに出した画面を、大丈夫だと思えるでしょうか？

りょうまさんの話は、この構成が合う場面から始まりました。API Gateway と Lambda、EFS 上の SQLite、VPC Lambda のつなぎ方、料金の内訳、運用の注意点へと、動画の順に進みます。

月200円は、NAT Gateway や Route 53 のホストゾーンがすでにある、という前提の上の数字。9月29日の私の場面のように、すでにある物は、見る場所が狭いと、ないと数えてしまいます。

壊れないかの答えも同じ形。69ページを138画面で撮ってから出したように、大丈夫かどうかは、聞いたあとで確かめてから言う物だと、私は考えます。

私なら、この構成を使う前に、すでにある NAT Gateway を手元で確かめ、同時に書き込む人の数を数え、AWS Backup から戻す手順を決めてから始めます。

まず、自分の環境に NAT Gateway がすでにあるのか。画面で数えるところから、始められるでしょうか？