はじめに
2026 年 4 月 21 日に、Lambda から Amazon S3 バケットをファイルシステムとしてマウントできる「S3 Files」との統合が発表されました。
これまで Lambda から S3 のデータを扱うには SDK 経由でオブジェクトをダウンロード/アップロードする必要がありました。
S3 Files を使えば /mnt/data のようなローカルパスで fs.readFileSync するだけでアクセスできるようになります。
普段から初手はマニュアル読まない私なので、今回もマニュアルを読まずにマネジメントコンソールからポチポチ触ってみました。
結果、なかなか気づけない落とし穴がいくつかあったので共有します。
この記事で学べること
- S3 Files を Lambda にマウントする手順
- マネジメントコンソールから設定する際のハマりポイント 3 つ
- セキュリティグループの設定
- Lambda 実行ロールの権限
- アクセスポイントの rootDirectory
- 各エラーメッセージの意味と対処法
結論だけ知りたい方はまとめへどうぞ。
前提知識・条件
- 2026 年 4 月 28 日時点の情報
- ap-northeast-1（東京リージョン）で検証
- Lambda と S3 バケットは AWS CDK で事前に作成済み
やってみた
準備： Lambda と S3 の準備
まず準備として、CDK で Lambda と S3 バケットを作成しました。
ソースは以下の通りです（後述の気づいた点を反映した最終形の構成となっています）。
Lambda のコードは AI で準備し、マウントパス配下のファイルを読んでログに出すだけの処理です。
import { readFileSync, readdirSync, statSync } from 'node:fs';
import { join } from 'node:path';
export const handler = async (event) => {
const mountPath = '/mnt/data';
try {
const entries = readdirSync(mountPath);
console.log('--- Directory listing ---');
console.log(entries);
for (const entry of entries) {
const filePath = join(mountPath, entry);
const stat = statSync(filePath);
if (!stat.isFile()) {
console.log(`[skip] ${entry} (not a file)`);
continue;
}
try {
const content = readFileSync(filePath, 'utf-8');
console.log(`--- ${entry} ---`);
console.log(content);
} catch (err) {
console.error(`Failed to read ${entry}:`, err.message);
}
}
} catch (err) {
console.error('Failed to list directory:', err.message);
}
return {
statusCode: 200,
body: JSON.stringify({ message: 'Files read successfully' }),
};
};
S3 SDK を一切使わず、Node.js 標準の fs モジュールだけで S3 のデータにアクセスできるのが S3 Files の魅力ですね。
ファイルシステムの設定をしてみる
Lambda コンソールの設定画面を見てみると、「ファイルシステム」という項目がありました。ここから設定するみたいですね。
ふむふむ。VPC に所属しないといけないのですね。
あとで調べたところ、S3 Files は NFS（Amazon EFS と同じインフラ）を使っているので、VPC 内のネットワーク経由で接続する仕組みです。VPC に所属していない Lambda では使えません。
Lambda を VPC に所属させてみる
VPC に所属させた上でファイルシステムの設定画面を開くと、「S3 ファイル」が選べるようになりました。でも、アタッチするファイルシステムが選択できません。
S3 バケットがそのまま選べるわけではなく、S3 コンソール側で「ファイルシステム」を作成する必要があるみたいです。
ファイルシステムの作成
S3 コンソールでバケットを選択し、「File systems」タブからファイルシステムを作成します。
ここでバージョニングが必須と言われました。S3 Files はオブジェクトバージョンを使ってファイルシステムとの整合性を保つ仕組みなので、バージョニングが有効でないとファイルシステムを作成できません。
ボタンひとつで有効化できるので、ここはサクッと設定。
これでファイルシステムができました。コンソールから作成する場合は、これだけの操作で、マウントターゲットとアクセスポイントも自動で作成されています。
ファイルシステムの設定
Lambda コンソールに戻ってファイルシステムを設定します。ローカルマウントパスは /mnt/data にしました。
保存すると、エラーが出ました。
S3 Files file system arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0e5364e93a7a25930 referenced by access point arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0e5364e93a7a25930/access-point/fsap-05101c5a2192c4734 has mount targets created in all availability zones the function will execute in, but not all are in the available life cycle state yet. Please wait for them to become available and try the request again.
マウントターゲットがまだ作成中とのこと。
ファイルシステム自体は「利用可能」になっていても、マウントターゲットの作成には数分かかるようです。S3 コンソールでマウントターゲットのステータスが全て「Available」になるまで待ちます。
待つと設定できました。
動かしてみる（ハマりポイント1: セキュリティグループ）
設定が完了したので、Lambda を動かしてみましたが、エラーが出ています。
The function couldn't connect to the Amazon S3 Files file system with access point arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0e5364e93a7a25930/access-point/fsap-05101c5a2192c4734. Check your network configuration and try again.
ネットワーク設定を確認しろとのこと。
ここからドキュメントなしでは進められなかったので、トラブルシューティングを確認しました。
このエラー（S3FilesMountConnectivityException）は NFS（TCP ポート 2049）の通信ができていない場合に発生するようです。
マウントターゲットの設定を確認すると、VPC のデフォルトセキュリティグループ（以下、SG）が自動で適用されていました。
今回は CDK で VPC を作成しているのですが、CDK はセキュリティのベストプラクティスとしてデフォルト SG のルールを全て削除します。
デフォルト SG のインバウンドルールは「同じ SG からの全トラフィック許可」のみです。
Lambda の SG（別の SG）からの NFS トラフィックは許可されません。専用の SG を作成するか、インバウンドルールの追加が必要です。
専用の SG を作成し、Lambda の SG からのポート 2049 インバウンドを許可してマウントターゲットに適用します。
ハマりポイント2: Lambda 実行ロールの権限
SG を修正して再実行。まだエラーが出ます。
The function couldn't mount the Amazon S3 Files file system with access point arn:aws:s3files:ap-northeast-1:123456789012:file-system/fs-0e5364e93a7a25930/access-point/fsap-05101c5a2192c4734.
今度は S3FilesMountFailureException です。先ほどのトラブルシューティングページによると、マウントリクエストが拒否された場合に出るエラーで、権限を確認しろとのこと。
Lambda の実行ロールに S3 Files 用の権限が必要でした。マネージドポリシー AmazonS3FilesClientReadWriteAccess をアタッチします。
ちなみに、S3 Files の画像のアイコンはまだ存在しない模様です。
コンソールから S3 Files をアタッチしても、Lambda の実行ロールには自動で権限が追加されないので、手動で設定する必要があります。
ハマりポイント3: アクセスポイントの rootDirectory
ポリシーを追加して再実行しましたが、まだ同じエラーが出ます。
ここからはトラブルシューティングのドキュメントにも具体的な記載がなかったので、設定を 1 つずつ確認していきました。
アクセスポイントの設定を見てみると、ルートディレクトリの範囲が /lambda になっています。
これは S3 バケット内の lambda/ フォルダをマウント対象にするという設定です。
コンソールからファイルシステムを作成すると、アクセスポイントが自動作成されます。
ただし、rootDirectory が /lambda に設定され、creationPermissions（ディレクトリ自動作成の設定）は未設定になっています。
公式ドキュメントにはこう書かれています。
If you don't specify any root directory ownership and permissions, and the root directory does not already exist, S3 Files will not create the root directory. Any attempts to mount the file system by using the access point will fail.
つまり、S3 バケットに lambda/ フォルダが存在しないとマウントに失敗するということです。
S3 コンソールから lambda/ フォルダを作成しました。
合わせて、テスト用のファイルを lambda/ フォルダに入れておきます。
Hello from S3 Files!
このファイルは S3 Files のテスト用です。
Lambda から /mnt/data/hello.txt として読めるはずです。
成功
これでようやく Lambda が正常に動きました。
START RequestId: 8567fc06-d251-4045-bcc4-4bec429345ee Version: $LATEST
2026-04-27T20:52:14.664Z 8567fc06-d251-4045-bcc4-4bec429345ee INFO --- Directory listing ---
2026-04-27T20:52:14.666Z 8567fc06-d251-4045-bcc4-4bec429345ee INFO [ 'hello.txt' ]
2026-04-27T20:52:14.672Z 8567fc06-d251-4045-bcc4-4bec429345ee INFO --- hello.txt ---
2026-04-27T20:52:14.672Z 8567fc06-d251-4045-bcc4-4bec429345ee INFO Hello from S3 Files!
このファイルは S3 Files のテスト用です。
Lambda から /mnt/data/hello.txt として読めるはずです。
END RequestId: 8567fc06-d251-4045-bcc4-4bec429345ee
REPORT RequestId: 8567fc06-d251-4045-bcc4-4bec429345ee Duration: 18.17 ms Billed Duration: 175 ms Memory Size: 512 MB Max Memory Used: 100 MB Init Duration: 156.45 ms
S3 SDK を使わず、readFileSync だけで S3 のデータが読めています。Init Duration 含めても 175ms で、ファイル読み取り自体は 18ms。かなり速いですね。
まとめ
今回はマネジメントコンソールから S3 Files を Lambda にマウントする検証をしてみました。
機能自体はとても便利で、Lambda から S3 のデータにファイルシステムとしてアクセスできるのは大きな進歩です。
ただ、マニュアルなしで触ると以下の 3 つのハマりポイントがありました。
- マウントターゲットの SG に NFS（ポート 2049）のインバウンド許可が必要。コンソールから作成するとデフォルト SG が適用される。デフォルト SG には Lambda の SG からの NFS 通信を許可するルールがないため、専用の SG を作成するかインバウンドルールを追加する
- Lambda の実行ロールに
AmazonS3FilesClientReadWriteAccessポリシーが必要。コンソールから S3 Files をアタッチしても自動では追加されない - アクセスポイントの rootDirectory（デフォルト
/lambda）に対応するフォルダが S3 バケットに存在しないとマウントに失敗する。creationPermissionsが未設定だと自動作成もされない
特に 3 つ目は、エラーメッセージからは原因が読み取りにくい落とし穴でした。
公式ドキュメントのアクセスポイント作成ページまで辿らないと気付きにくいですね。
CDK で S3 Files のリソースも一緒に管理すれば、ある程度の問題は回避できそうなのですが、色々と詰まるところがあったので紹介でした！
誰かのお役に立てると嬉しいです。