AWS Lambda × S3 Files: バケットを NFS マウントして SQLite を読む・書く
S3 Files でバケットを Lambda にマウントすると、/mnt/... 上の SQLite を普通のファイルとして扱える。読み取り向き。書き込みは NFS 上ではすぐ見えるが S3 反映は約 60 秒遅れ。バージョニング必須・VPC 必須。
どんなときに使う？
- 参照用の小さな SQLite を S3 に置き、Lambda からパス指定だけで検索したい
- EFS ほど常駐コストをかけずに「ファイルとしての DB」を試したい
- 個人・バッチ程度の軽い書き込みも許容できる
やり方（要点）
- S3 バケットで バージョニングを有効にする
- 同じ VPC に S3 Files のマウントターゲットを作る
- Lambda を VPC 内に置き、マウントパス（例:
/mnt/s3data）を設定。メモリは 512 MB 以上推奨 - SQLite ファイルを
aws s3 cpでバケットへ置く → Lambda からは/mnt/s3data/database.dbとして見える - コードは標準の
sqlite3でsqlite3.connect(DB_PATH)するだけ
検証で分かった挙動:
| 操作 | 結果 |
|---|---|
| 読み取り | 問題なく SELECT できる |
| 書き込み | INSERT は成功。S3 オブジェクトへの同期は約 60 秒後 |
| 同一実行内の write→read | NFS 層を見るので直後に読める |
| 同時書き込み（少数並列） | SQLite ロックで待ちつつ成功しうるが、大量並列向きではない |
| バージョニング | 同期サイクル単位でバージョンが増える（書き込み1件＝1バージョンではない） |
CDK による再現用リポジトリ: github.com
注意点
- Lambda は VPC 必須。外向き通信が必要なら NAT が要り、コストが一気に上がる
- バージョニング必須のため古い版が溜まる → ライフサイクルで期限切れ削除を推奨
- 本番の高並列 OLTP には向かない。参照データ・個人自動化向けの検証結果として読む
- 執筆時点では Terraform 未対応寄りで CDK 例が先行、という報告あり（現状は公式・プロバイダを再確認）