0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【AWS SAA対策】AWS Lambda まとめ ― 制限値・VPCアクセス・設計パターンを整理する

0
Posted at

はじめに

AWS Solutions Architect Associate (SAA) の学習中に整理した AWS Lambda 関連の知識をまとめました。
試験で超頻出の制限値(特に15分タイムアウト)から、VPC アクセスの仕組み、サーバーレス設計パターンまで網羅しています。

本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。


サービス概要

制限値(超重要)

Lambda の制限値は試験の引っかけ問題で頻繁に登場します。特に 最大タイムアウト15分 は最も出題されるポイントです。

  • 最大タイムアウト: 15分(超頻出)
  • 最大メモリ: 10GB
  • デプロイパッケージ: ZIP 50MB(直接)/ 250MB(展開後)/ 10GB(コンテナイメージ)
  • /tmp ストレージ: 512MB〜10GB(エフェメラル)
  • 同時実行数: デフォルト 1,000(引き上げ可能)

「処理時間が30分」と書いてあったら Lambda は使えません。その場合は ECS Fargate などが選択肢になります。


VPC アクセスの仕組み

Lambda の VPC 設定はネットワーク構成に直結するため、正しく理解しておく必要があります。

  • デフォルト: AWS 所有の VPC で動作し、パブリックインターネットや AWS API に直接アクセスできる
  • VPC 有効化時: 顧客の VPC に配置され、プライベートリソース(RDS など)にアクセス可能になる
  • VPC に配置すると、パブリックインターネットへのアクセスには NAT Gateway が必要になる

Lambda Layer

Lambda Layer は、再利用可能なコードやライブラリを ZIP アーカイブとして管理する仕組みです。

  • 関数あたり最大5レイヤーまでアタッチ可能
  • デプロイパッケージを小さく保てる
  • 複数の Lambda 関数で共通ライブラリを共有できる

ベストプラクティス

  • タイムアウトをオーバープロビジョニングしない(AWS 非推奨)
  • 依存関係はデプロイパッケージに含める(分離しない)
  • コンテナイメージとしてデプロイ可能
  • CloudWatch アラームで ConcurrentExecutions / Invocations を監視する

Provisioned Concurrency

  • 実行環境を事前にウォームアップしておく機能
  • コールドスタートを排除できる
  • 追加コストあり(常時ウォーム状態を維持するため)
  • レイテンシーに敏感なワークロードで有効

Lambda で不可能なこと

以下は試験の引っかけ選択肢としてよく登場します。

  • ウェブサイトのホスティング(CloudFront のオリジンに直接 Lambda は設定不可。Lambda@Edge は別の用途)
  • 30分以上の処理(15分制限)
  • 大規模なバッチ処理(Fargate やバッチサービスが適切)

試験で問われる設計パターン

SAA の試験では「この処理を最もコスト効率よく、運用負荷を最小に実現するにはどうするか?」というシナリオが多く出題されます。Lambda が正解になるケースと、Lambda では対応できないケースの両方を整理します。


Lambda が正解になるケース

S3 アップロード → ニアリアルタイム画像処理 → Lambda

シナリオ: ユーザーがアップロードした画像を処理するシステムを構築しています。処理時間は約3分、ファイルサイズは最大512MBです。コストを最小限に抑えたい場合、どの構成が最適でしょうか?

正解: S3 Event Notifications → SQS → Lambda

  • 3分・512MB は Lambda の制限内(15分 / 10GB)
  • アイドル時はコストゼロ
  • EC2 RI はアイドル時もコストが発生するため非効率

S3 アップロード → 自動サムネイル生成 → Lambda

シナリオ: 1日あたり約200枚の画像がアップロードされます。アップロードのたびに自動的にサムネイルを生成したいです。低コストでインフラ管理を最小にする構成はどれでしょうか?

正解: S3 Event Notification → Lambda → 別 S3 バケット

  • S3 Event と Lambda はネイティブ統合
  • Glue(定期実行)や Fargate(ポーリング)はこのユースケースには非効率

週次 cron ジョブ(5分、Python)→ EventBridge + Lambda

シナリオ: 毎週月曜日に実行する Python スクリプト(所要時間5分)があります。サーバーレスでコストを最小限に抑えたい場合、どの構成が最適でしょうか?

正解: EventBridge cron 式 → Lambda 関数

  • 5分 → Lambda の制限内
  • Glue は ETL 用途、EC2 はサーバーレスではない

Python マイクロサービス + 自動スケール + 運用最小 → Lambda + API Gateway

シナリオ: Python で書かれたマイクロサービスをデプロイしたいです。自動スケールに対応し、運用負荷を最小限にしたい場合、どの構成が最適でしょうか?

正解: Lambda(Python)+ API Gateway + Provisioned Concurrency

  • Fargate はコンテナ化が必要で、Lambda より運用負荷が高い
  • App Runner はアイドル時もウォーム維持のコストがかかる
  • EC2 Spot は中断リスクがあり、インフラ管理も必要

リアルタイムストリーミング + 順序保証 + 運用負荷最小 → Kinesis + Lambda + DynamoDB

シナリオ: IoT デバイスからのリアルタイムストリーミングデータを順序保証付きで処理し、DynamoDB に保存したいです。運用負荷を最小にする構成はどれでしょうか?

正解: Kinesis Data Streams → Lambda → DynamoDB

  • Lambda は Kinesis とネイティブ統合(ポーリング・チェックポイント・エラー処理を自動管理)
  • EC2 を使う選択肢は「管理オーバーヘッド最小」という要件に合わない

フィードバック収集 + 感情分析 + 1年保持 → API Gateway + SQS + Lambda + Comprehend + DynamoDB

シナリオ: ユーザーからのフィードバックを収集し、感情分析を行い、結果を1年間保持したいです。スパイク時にもスケーラブルな構成はどれでしょうか?

正解: API Gateway → SQS → Lambda → Comprehend → DynamoDB(TTL 365日)

  • SQS がスパイク時のバッファとして機能
  • Comprehend が感情分析を担当(Translate は翻訳サービス)
  • DynamoDB の TTL で1年後に自動削除

Lambda では対応できないケース

cron スクリプト(最大30分)→ EventBridge + ECS Fargate

シナリオ: 定期実行する cron スクリプトがあり、最大30分かかることがあります。サーバーレスで実現するにはどの構成が最適でしょうか?

正解: コンテナイメージ化 → EventBridge Scheduler → ECS Fargate

  • Lambda の最大タイムアウトは15分 → 30分は不可
  • 15分以内であれば EventBridge + Lambda で対応可能

30分処理 + サーバーレス + リアルタイムストリーミング → Kinesis + ECS Fargate

シナリオ: リアルタイムストリーミングデータを取り込み、1件あたり最大30分の処理を行いたいです。サーバーレスで実現する構成はどれでしょうか?

正解:

  1. Kinesis Data Streams(取り込み)
  2. ECS on Fargate(30分の処理)
  • Lambda は15分制限で不可
  • DMS はデータベース移行用であり、ストリーミング取り込みには適さない

セキュリティ系

Lambda → RDS の短期認証情報 → IAM DB 認証 + IAM ロール

シナリオ: Lambda から RDS PostgreSQL に接続する際、長期的なパスワードではなく短期認証情報を使いたいです。どの方法が適切でしょうか?(2つ選択)

正解:

  1. RDS PostgreSQL の IAM DB 認証を使用
  2. Lambda に IAM ロールをアタッチ
  • IAM DB 認証は15分有効なトークン(AWS Signature V4)を使用
  • MySQL / PostgreSQL に対応
  • SG / VPC / SSM はネットワーク層の対策であり、認証層の話ではない

Lambda(アカウントA)→ S3(アカウントB)クロスアカウント

シナリオ: アカウント A の Lambda から、アカウント B の S3 バケットにアクセスしたいです。必要な設定は何でしょうか?

正解: IAM ロールに S3 権限を付与 + S3 バケットポリシーで Lambda 実行ロールを許可

  • クロスアカウントアクセスには IAM ロール + バケットポリシーの両方 が必要

おわりに

Lambda は SAA の中でも出題頻度が非常に高いサービスです。特に 15分のタイムアウト制限 は引っかけ問題の定番なので、「処理時間が15分を超えていたら Lambda は選択肢から外す」という判断を反射的にできるようにしておくと安心です。

また、Lambda が正解になるケースと、Fargate が正解になるケースの境界線を意識して整理しておくと、試験本番での迷いが減るはずです。

間違いや補足があればぜひコメントで教えてください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?