- API Gateway の「統合リクエスト」の変更
現在、API Gatewayのバックエンド（統合タイプ）が「HTTP」または「HTTPプロキシ」でEBSのALBを指しているはず。これをLambda用に作り直す必要があるよ。
設定箇所: API Gateway コンソールの「リソース」→「メソッド（GET）」→「統合リクエスト」
変更内容: 統合タイプを 「Lambda 関数」 に変更。
プロキシ統合: Spring Bootのパス（/api/users など）をそのまま活かすなら、**「Lambda プロキシ統合の使用」**にチェックを入れるのが一番楽だよ。これで、リクエスト内容（ヘッダーやクエリパラメータ）が丸ごとLambdaに渡されるようになるんだ。
- Lambda 側の「リソースベースのポリシー」設定
API GatewayがLambdaを呼び出す「許可」を与えてあげないといけないよ。
設定内容: Lambda コンソールの「設定」→「権限」タブにある「リソースベースのポリシー文」。
アクション: lambda:InvokeFunction を許可する。
プリンシパル: apigateway.amazonaws.com を指定。
※API GatewayのコンソールでLambdaを選択して保存すると、自動でこのポリシーを追加してくれることが多いけど、念のため確認してね。
- セキュリティグループとVPC設定
ここが一番のハマりポイントだよ。
LambdaをVPCに入れる場合:
LambdaがDB（RDSなど）にアクセスする必要があるなら、VPC内に配置するよね。
Lambda用セキュリティグループ: 「アウトバウンド（送信）」でDBや外部APIへの通信を許可する。
DB側セキュリティグループ: インバウンド（受信）で「Lambda用セキュリティグループ」からの接続を許可するように書き換える（以前はEBSのセキュリティグループを許可してたはず）。
インバウンド制限:
Lambdaは「呼び出し（Invoke）」で動くから、Lambda自体に「インバウンドのセキュリティグループ」を設定して通信を制限する概念はないんだ（リソースベースポリシーで制限する）。
- 経路とターゲットの削除（クリーンアップ）
移行が完了したら、不要になる設定を外していくよ。
VPC リンク / プライベート統合: もしVPCリンク経由でEBSに繋いでいたなら、これは不要になるよ。
ALB / EBS の削除: 完全にLambdaに寄せたら、EBS環境とそれに関連するロードバランサー（ALB）を停止・削除することでコストを抑えられるね。
- 実行ロール (IAM Role) の変更
EBSのインスタンスプロファイルで許可していた権限（S3へのアクセスやログ出力など）を、Lambdaの 「実行ロール」 に移植してあげる必要があるよ。
基本権限: AWSLambdaVPCAccessExecutionRole（VPCに入れる場合）や AWSLambdaBasicExecutionRole（CloudWatch Logs出力用）は必須
まとめ：チェックリスト
[ ] API Gateway: 統合タイプを「Lambdaプロキシ」に変更
[ ] Lambda: API Gatewayからの Invoke 許可設定（リソースポリシー）
[ ] IAM: Lambda実行ロールに、以前EBSで使っていた権限を付与
[ ] Security Group: DB側の許可リストを「EBS用」から「Lambda用」に差し替え
[ ] API Gateway: 変更後に「デプロイ」を実行してステージを更新
特に、**DBへの接続許可（セキュリティグループの付け替え）**を忘れると、LambdaからDBに繋がらなくてタイムアウトしちゃうから注意してね。