AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA Lambda・サーバーレス設計の頻出パターン10選｜トリガー・疎結合・同時実行・Step Functions を要件文で即断する

AWS SAA-C03 でサーバーレス（Lambda + API Gateway + DynamoDB）とイベント駆動設計は出題が増え続ける最重要テーマ。本記事は Lambda・サーバーレス設計問題を「実行ロール（IAM）／トリガーの種類（同期・非同期・ストリーム）／API Gateway 連携／データストア選定（DynamoDB）／SQS・SNS・EventBridge による疎結合／ファンアウト／Step Functions オーケストレーション／同時実行数とコールドスタート／15分・ペイロード等の制約と Fargate 使い分け／VPC 設定」の頻出10パターンに分解する。各パターンで要件文のどのキーワードが正解を一意に決めるかを示す。結論は「サーバーレス問題はサービス名の暗記ではなく、トリガー・状態・結合度・スケール制約という4つの評価軸で解く」こと。

#AWS #SAA #SAA-C03 #Solutions Architect #Lambda #サーバーレス #API Gateway #EventBridge #Step Functions #試験対策 #AWS認定資格

サーバーレスの設計問題を「Lambda を使えば正解」で片づけようとすると、トリガーの種類・疎結合の道具・同時実行やタイムアウトの制約で足をすくわれる。 SAA-C03 で AWS Lambda を中核とするサーバーレス／イベント駆動アーキテクチャは、改訂のたびに出題比重が増している最重要テーマだ。だが問われるのは「Lambda の仕様暗記」ではなく、何がその関数を起動するのか（トリガー）・状態をどこに持つのか・コンポーネントをどう疎結合するのか・スケールと制約をどう捌くのかという設計判断である。攻略の鍵は、頻出テーマを「Lambda の基礎（ロール・トリガー・同時実行）」「API とデータストア連携」「疎結合（SQS/SNS/EventBridge）」「オーケストレーションと制約」の4系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、サーバーレス設計問題の頻出10パターンを分解する。読み終えれば、「最も疎結合でスケーラブル、かつ要件を満たす構成はどれか」という問いに、迷わず正解を当てられるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：サーバーレス問題は「サービス名」ではなく「4つの評価軸」で解く
  2. パターン1〜3：Lambda の基礎（実行ロール・トリガー・同時実行）
  3. パターン4〜5：API Gateway 連携とデータストア選定
  4. パターン6〜7：SQS・SNS・EventBridge による疎結合
  5. パターン8〜10：オーケストレーション・制約・Fargate 使い分け
  6. 頻出ひっかけパターンと打ち手の整理
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論：サーバーレス問題は「サービス名」ではなく「4つの評価軸」で解く

SAA-C03 のサーバーレス問題を最短で解く骨格は、**「要件文が4つの評価軸——起動のトリガー・状態の持ち方・コンポーネントの結合度・スケールと制約——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。

理由は明快で、サーバーレスの構成要素はどれも「ある評価軸を制御するための道具」だからだ。API Gateway は「同期リクエストの受け口」を、SQS は「非同期・バッファリングによる疎結合」を、EventBridge は「イベントのルーティング」を、Step Functions は「複数処理のオーケストレーション」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。

具体例で見よう。「ユーザーの HTTP リクエストを受けて処理を返す」——これは同期トリガーの軸だから API Gateway ＋ Lambda。「急激なアクセス増でも取りこぼさず、後続処理の負荷を平準化したい」——非同期バッファの軸だから SQS を挟む。「1つのイベントを複数のシステムに同時通知したい」——ファンアウトの軸だから SNS。「注文処理を複数ステップで順序制御・リトライしたい」——オーケストレーションの軸だから Step Functions。ここで「Lambda が万能だから全部 Lambda で」と考えると、疎結合やオーケストレーションを問う設問で誤答する。軸で解く——この一点がサーバーレス問題の攻略法だ。

2. パターン1〜3：Lambda の基礎（実行ロール・トリガー・同時実行）

最も出題頻度が高いのが、この3パターンだ。ここはサーバーレス問題の“主砲”であり、確実に得点したい。

パターン1：Lambda 実行ロール（IAM）による権限付与

サーバーレス問題で最初に問われるのが権限だ。Lambda が他の AWS サービス（S3・DynamoDB など）にアクセスするには、実行ロール（IAM ロール）に必要な権限を付与する必要がある。「Lambda 関数が DynamoDB に書き込めない／S3 を読めない」というトラブル系の設問は、ほぼ実行ロールの権限不足が原因だ。セキュア設計の最小権限原則に従い、その関数が触るリソースだけを許可するのが正解になる。

パターン2：トリガーの種類（同期・非同期・ストリーム）

Lambda は「何が起動するか」で挙動が変わる。ここを3分類で押さえると、多くの設問が即断できる。

Lambda トリガーの3分類（要件キーワード → 正解の型）
評価項目
同期呼び出し
非同期呼び出し 推奨
ストリーム/ポーリング
代表的なソース API Gateway・ALB S3 イベント・SNS SQS・DynamoDB Streams・Kinesis
呼び出し側の待ち 結果を待つ 待たない（投げっぱなし） Lambda が取りに行く
リトライ 呼び出し側が制御 自動リトライ＋DLQ バッチ単位で再試行
キーワード 「即座に結果を返す」「REST API」 「イベント通知」「処理は後続で」 「キュー」「ストリームを処理」
迷ったら『結果を待つ＝同期』『イベントで発火＝非同期』『キュー/ストリームを取りに行く＝ポーリング』で振るう。

パターン3：同時実行数とコールドスタート

「急激なトラフィック増で Lambda がスロットリングされる」「初回応答が遅い」——これはスケール制約の設問だ。押さえる打ち手は2つ。

  • 同時実行数の制御：アカウント単位のデフォルト上限（リージョンあたり）を超えるとスロットリングされる。重要な関数には**予約済み同時実行（Reserved Concurrency）**で枠を確保し、上限緩和申請でスケールさせる。
  • コールドスタート対策：初回起動やスケールアウト時の遅延が問題なら、**プロビジョンド同時実行（Provisioned Concurrency）**で関数を温めておく。「一貫した低レイテンシが必要」がキーワード。

3. パターン4〜5：API Gateway 連携とデータストア選定

「HTTP でリクエストを受けて処理する」——サーバーレス Web/API の王道がこの2パターンだ。

パターン4：API Gateway × Lambda の同期 API

「認証付きの REST API を、サーバー管理なしで公開したい」——これは API Gateway ＋ Lambda が正解だ。API Gateway がリクエストの受け口・認証・スロットリング・キャッシュを担い、Lambda がビジネスロジックを実行する。認証は用途で使い分ける。

  • ユーザーのサインアップ／ログインを含むアプリ認証 → Amazon Cognito：ユーザープールで認証し、API Gateway の Cognito オーサライザーでトークン検証。
  • 独自の認可ロジックが必要 → Lambda オーサライザー：トークンやヘッダーを自前ロジックで検証。
  • AWS サービス間・IAM 主体のアクセス → IAM 認証。

「スケーラブルなサーバーレス Web アプリの標準形」は API Gateway ＋ Lambda ＋ DynamoDB ＋ Cognito の4点セットで覚えておくと、多くのアーキ設問がこれ一発で当たる。

パターン5：サーバーレスのデータストア選定

サーバーレス構成の相棒は、原則 DynamoDB だ。理由は、接続数無制限・オートスケール・ミリ秒応答という Lambda の大量同時実行と相性が良い特性にある。リレーショナルが必須なら選択肢が変わる。

サーバーレスのデータストア（要件キーワード → 正解）
評価項目
DynamoDB 推奨
Aurora Serverless v2
RDS + RDS Proxy
データモデル キーバリュー / NoSQL リレーショナル（自動スケール） リレーショナル（従来型）
Lambda との接続 HTTP API・接続数を気にしない 接続あり コネクション枯渇に注意
向くケース 大量同時・スキーマ柔軟 変動負荷でSQLが必要 既存RDBを活かしたい
キーワード 「サーバーレスで無限にスケール」 「SQLだが負荷が変動」 「Lambdaの接続過多を防ぐ」
迷ったら『NoSQLで良い＝DynamoDB』『SQL必須で変動負荷＝Aurora Serverless』『既存RDB＋接続過多対策＝RDS Proxy』で振るう。

4. パターン6〜7：SQS・SNS・EventBridge による疎結合

「コンポーネント同士を直接呼ばず、疎結合にしたい」——弾力性ドメインの主役がこの2パターンだ。

パターン6：SQS でバッファリング・非同期処理

「処理のピークを平準化したい」「後続が落ちても取りこぼしたくない」——これは SQS でキューを挟むのが正解だ。生産者はキューに投入するだけ、消費者（Lambda など）は自分のペースで処理する。バースト吸収・疎結合・リトライ・順序保証がキーワードになる。

パターン7：SNS・EventBridge によるファンアウトとルーティング

1つのイベントを複数の宛先へ届けたいときは、SQS ではなく Pub/Sub 系を使う。

  • 同報配信（ファンアウト） → SNS：1つのメッセージを複数のサブスクライバー（複数の SQS キュー・Lambda・メール等）へ同時配信。「1つのイベントを複数システムで並行処理」がキーワード。SNS ＋ 複数 SQS のファンアウトパターンは SAA 頻出。
  • イベントの内容でルーティング → EventBridge：多数の AWS サービスや SaaS のイベントを、ルール（内容フィルタ）で振り分ける。「スケジュール実行」「AWS サービスの状態変化をトリガー」「イベント内容で宛先を変える」がキーワード。

5. パターン8〜10：オーケストレーション・制約・Fargate 使い分け

パターン8：Step Functions による複数処理のオーケストレーション

「複数の Lambda を順序立てて実行し、分岐・リトライ・エラー処理を管理したい」——これは Step Functions が正解だ。複数関数を Lambda 内から直接呼び合う（オーケストレーションをコードに埋める）と、状態管理・リトライ・可視化が破綻する。Step Functions はワークフローを状態機械として定義し、各ステップの成否・分岐・待機・並列を宣言的に管理する。**「複数ステップのワークフロー」「長時間の業務プロセス」「ステップごとのリトライ・分岐」**がキーワード。

パターン9：Lambda の制約（15分・ペイロード・メモリ）

Lambda には SAA で問われる明確な制約がある。要件がこの制約を超えるなら Lambda は不正解になる、という切り分けが重要だ。

  • 実行時間は最大15分：これを超える長時間バッチや常時稼働が必要なら、Fargate や ECS／EKS を選ぶ。
  • ペイロード・一時ストレージに上限：大きなファイルは S3 に置き、Lambda はその参照（キー）を扱う設計にする。
  • VPC 内リソースへのアクセス：RDS 等プライベートリソースに接続するなら Lambda を VPC に配置する（サブネット・SG の設定が必要）。

パターン10：Lambda と Fargate の使い分け

サーバーレスの総仕上げが、Lambda とコンテナ（Fargate）の使い分けだ。**「起動モデル」と「実行時間・移植性」**で選ぶ。

Lambda vs Fargate（要件キーワード → 正解）
評価項目
Lambda 推奨
Fargate
実行モデル イベント駆動・短時間 常時 or 長時間のコンテナ
実行時間 最大15分 制限なし
課金 リクエスト＋実行時間（ミリ秒） vCPU・メモリ×稼働時間
移植性 関数コード 既存コンテナをそのまま
キーワード 「イベントで発火」「使った分だけ」 「既存コンテナ」「長時間・常駐」
迷ったら『短時間・イベント駆動＝Lambda』『長時間・常駐・既存コンテナ＝Fargate』で振るう。どちらもサーバー管理は不要。

6. 頻出ひっかけパターンと打ち手の整理

サーバーレス問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。

7. 次のアクション チェックリスト

サーバーレス設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。

8. 関連記事

9. 関連サイト

AWS 公式