Q80 — AWS SAA-C03 第15章

第 80/100 問 | ← 第15章

Q1180. ある会社がVPC内でのAWS Lambda関数を使用しています。このLambda関数は、Lambdaレイヤーのクォータを超過するサイズの依存関係にアクセスする必要があります。また、Lambda関数が取得するデータは、通信中の暗号化（in-transit encryption）が必須です。これらの要件を満たすうち、運用上のオーバーヘッドが最も少ない解決策はどれですか？

正解: A. 依存関係をAmazon Elastic File System（Amazon EFS）ファイルシステムに格納し、そのファイルシステムをLambda関数にマウントします。依存関係はファイルシステムから取得します。

解説

Lambdaレイヤーのサイズ制限を超える依存関係へのアクセスと、通信中の暗号化の両方を満たしつつ、運用上のオーバーヘッドを最小限に抑えるには、選択肢Aが最適です。つまり、「依存関係をAmazon EFSファイルシステムに格納し、Lambda関数にマウントして、そこから依存関係を取得する」方法です。 各選択肢の検討： 選択肢A：Amazon EFSファイルシステムに依存関係を格納し、Lambda関数にマウントする。 利点：Amazon EFSは、VPC内のLambda関数にマウント可能な、拡張性・共有性に優れたフルマネージドなファイルストレージです。これにより、Lambdaレイヤーのサイズ制限を超える大規模な依存関係を扱えます。また、EFSはTLSによる通信中暗号化をサポートしており、Lambda関数からのアクセス時にもデータが暗号化されます。運用オーバーヘッドは極めて低く、マウント設定もシンプルです。 選択肢B：インスタンスストア付きEC2インスタンス上でWebサーバーを稼働させ、HTTPSで毎回依存関係を取得。 課題：EC2インスタンスの運用・管理が必要であり、可用性・パッチ適用・スケーリングなど、運用負荷が大幅に増加します。また、Lambda実行ごとにネットワーク経由で依存関係をダウンロードするため、レイテンシと複雑さが増します。HTTPSによる通信中暗号化は可能ですが、全体としてEFSより非効率かつ高オーバーヘッドです。 選択肢C：EC2インスタンス上でNFSサーバーを稼働させ、毎回ファイルを読み込む。 課題：EC2およびNFSサーバーの運用管理が必要で、選択肢Bと同様に運用負荷が高くなります。さらに、NFS接続の暗号化（例：TLSまたはIPsec）を実現するには追加設定や専門知識が必要で、セキュリティ面でも複雑さが増します。パフォーマンスも、毎回ネットワーク経由でファイルを読み込む点で劣ります。 選択肢D：依存関係を2つのLambdaレイヤーに分割し、アプリケーションを2つのLambda関数に再設計。 課題：Lambdaレイヤーには個別のサイズ制限（合計10GB未満、展開パッケージ含む250MB未満など）があり、単に分割しても制限を超える可能性があります。また、アプリケーションの再設計・テスト・デプロイメントの複雑化により、運用負荷が増大します。 結論：選択肢Aが、要件を満たしつつ運用オーバーヘッドを最小限に抑える最適解です。スケーラブルで共有可能なフルマネージドなストレージを提供し、通信中暗号化をネイティブにサポートし、Lambdaとの統合も簡易です。