はじめに
どーも！shihopowerです！
今回は、Lambda 関数が AWS RAM でアカウント間共有できない理由についてお話しします。
SAP（AWS認定 Solutions Architect - Professional）の対策をしていると、こんな解説に出会いました。
「Lambda 関数は AWS アカウントに限定されており、RAM を使用してアカウント間で直接共有することはできない」
これを見たとき、「え！そうなの！？」と驚きました。
こういう新しい発見をしたとき、「なぜそうなのか」という仕組みのところまで理解するのが大事だと思っています。
というわけで、AWS 公式ドキュメントをもとに掘り下げてみました。それでは解説に入ります！
目次
- AWS RAM とは？（30秒おさらい）
- RAM で共有できるリソース一覧を確認する
- Lambda がリストにない ＝ 共有できない、その理由
- Lambda のクロスアカウント利用、じゃあどうするの？
- まとめ
1. AWS RAM とは？（30秒おさらい）
AWS RAM（Resource Access Manager） とは、AWS リソースを複数のアカウント間で安全に共有するためのサービスです。
たとえば、こんなことができます。
- VPC サブネットを組織内の別アカウントと共有する
- Transit Gateway を複数アカウントで共有する
- License Manager の設定を組織全体に適用する
マルチアカウント構成をとっている企業にとって、「一度作ったリソースを使い回せる」というのは運用コスト削減に直結する便利な機能です。
2. RAM で共有できるリソース一覧を確認する
AWS 公式ドキュメント「Shareable AWS resources」には、RAM で共有できるリソースタイプの一覧が掲載されています。
主なサービスを抜粋すると、以下のものが対応しています。
| サービス | 共有できるリソース例 |
|---|---|
| Amazon VPC | サブネット、Transit Gateway、Prefix List など |
| Amazon EC2 | キャパシティ予約、Dedicated Host など |
| Amazon Aurora | DB クラスター |
| AWS License Manager | ライセンス設定 |
| AWS Network Firewall | ファイアウォール、ポリシー、ルールグループ |
| Amazon Route 53 | Resolver ルール、DNS Firewall ルールグループ |
| Amazon SageMaker AI | Feature Group、パイプライン など |
この一覧には、App Mesh、AppSync、API Gateway、Backup、Bedrock など、多くのサービスが名を連ねています。
しかし、AWS Lambda はどこにも載っていません。
これが答えです。
3. Lambda がリストにない ＝ 共有できない、その理由
3-1. RAM の設計思想と Lambda の性質のミスマッチ
RAM が共有対象とするリソースは、主に 「インフラ基盤・設定的なリソース」 です。
- VPC サブネット → 複数アカウントのリソースを同じネットワーク上に展開できる
- Transit Gateway → 複数の VPC やオンプレとの通信ハブを共有できる
- ライセンス設定 → 一度定義したルールを組織全体に適用できる
これらに共通するのは、「インフラの土台や設定」を共有するという考え方です。
一方、Lambda 関数は コード・ランタイム・IAM ロール・環境変数・VPC 設定・レイヤー などがすべてひとまとまりになった「実行ロジックそのもの」です。特定の AWS アカウントおよびリージョンに強く紐づいており、RAM が想定する「インフラ基盤・設定の共有」とは性質が根本的に異なります。 そのため、RAM の共有対象リソースとして設計されていません。
3-2. 公式ドキュメントの結論
AWS 公式ドキュメントでは、共有可能なリソースタイプは明示的にリストアップされており、一覧に掲載されていないリソースは共有できないというシンプルなルールが適用されています。
Lambda はそのリストに存在しない = RAM による共有はサポートされていない、ということです。
4. Lambda のクロスアカウント利用、じゃあどうするの？
「RAM では共有できないとわかった。でも別アカウントから Lambda を呼び出したいケースはある！」という方もいるかと思います。AWS は Lambda のクロスアカウント利用に対して、別の仕組みを提供しています。
方法①：リソースベースポリシーで呼び出し権限を付与する
最もシンプルな方法です。lambda:AddPermission を使い、Lambda 関数のリソースベースポリシーに別アカウントからの呼び出し許可を追加します。
aws lambda add-permission \
--function-name my-function \
--statement-id cross-account-invoke \
--action lambda:InvokeFunction \
--principal 123456789012 \ # 呼び出し元のアカウントID
--region ap-northeast-1
これにより、指定したアカウントから直接 Lambda を呼び出せるようになります。
方法②：Amazon VPC Lattice 経由で共有する
Amazon VPC Lattice とは、複数の VPC やアカウントにまたがるサービス間通信を、一元的に接続・認証・監視できるマネージドサービスです。サービスメッシュのような役割を担い、Lambda や EC2、ECS などをバックエンドとして登録できます。
VPC Lattice のサービスは RAM での共有に対応しています。Lambda をバックエンドとした VPC Lattice サービスを作成し、そのサービスを RAM で他アカウントと共有することで、マルチアカウント環境でも安全に Lambda を利用できます。
方法③：Amazon EventBridge でクロスアカウントにトリガーする
EventBridge のイベントバスをクロスアカウントに設定することで、別アカウントのイベントをトリガーに Lambda を起動することもできます。
5. まとめ
最後に今回の内容を整理します。
| ポイント | 内容 |
|---|---|
| Lambda が RAM で共有できない理由 | RAM の共有可能リソース一覧に Lambda が含まれていないから |
| なぜリストにないのか | Lambda は「実行ロジックそのもの」であり、RAM が想定する「インフラ基盤・設定リソースの共有」という設計思想とミスマッチ |
| 代替手段 | リソースベースポリシー / VPC Lattice / EventBridge |
SAP の試験対策をしていると、「なぜ？」と立ち止まれる問題が多くあります。単に「Lambda は RAM で共有できない」と暗記するのではなく、公式ドキュメントまで立ち返って仕組みを理解する習慣が、応用問題への対応力につながると感じました。
同じように SAP を勉強している方の参考になれば嬉しいです！