Amazon SOA-C02: サーバーレスとアプリケーション統合 — 学習ガイド
こちらの一部です： AWS SysOps Administrator Associate SOA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
サーバーレスとアプリケーション統合は、サーバーを管理せずにイベント駆動型アプリケーションを実行し、サービスを確実に接続することを対象とします。運用上の重要性は、コストを予測可能に保ちながら、スケーリング、レイテンシー、障害モード、最小権限アクセスを管理することにあります。この分野では、Lambdaの動作（コールドスタート、同時実行）、信頼性の高いイベント配信（EventBridge、SNS、SQS）、セキュリティ制御（実行ロールとアクセス許可）、非同期フローのオブザーバビリティに焦点を当てます。
AWS Lambdaの運用面と同時実行
Lambdaのパフォーマンスと可用性は、コールドスタート、同時実行数の上限、スロットリング制御にかかっています。コールドスタートは、Lambdaが新しい実行環境を初期化する必要がある場合に発生します。レイテンシーが重要なパスにはプロビジョニングされた同時実行 (
undefined
) を使用し、軽量なランタイムや初期化処理の少ないものを優先することで、影響を軽減します。予約された同時実行 (
undefined
) を使用して同時実行数を予約および制限し、ダウンストリームサービスを保護して関数ごとのクォータを強制します。ConcurrentExecutions と Throttles のCloudWatchメトリクスを監視します。
再試行と呼び出しモデルはモードによって異なります。同期呼び出し（API Gateway、直接のInvoke）はエラーを即座に返します。非同期呼び出し（EventBridge、SNS、S3の非同期通知）はLambdaの非同期再試行ポリシー（バックオフ付きで2回再試行）を使用し、DLQや送信先を利用できます。イベントソースマッピング（SQS、Kinesis、DynamoDBストリーム）の場合、Lambdaのポーラーはメッセージが期限切れになるか、イベントソースのリドライブポリシーがデッドレターをトリガーするまで再試行します。タイムアウトとメモリは控えめに設定し (
undefined
)、重複処理を減らすためにSQSの可視性タイムアウトを関数のタイムアウトより長く設定します（推奨：可視性 >= 関数タイムアウト * 2）。
EventBridgeによるイベント駆動型アーキテクチャ
EventBridgeは、柔軟なルーティング、スキーマレジストリ、クロスアカウント配信、再試行/DLQ設定を備えたマネージドイベントバスを提供します。ドメイン分離にはカスタムイベントバスを、SaaS統合にはパートナーイベントバスを使用します。パターンを用いてルールを作成し (
undefined
)、デッドレターと再試行設定を持つターゲットをアタッチします (ターゲットのJSONはDeadLetterConfigとRetryPolicyをサポート)。スキーマレジストリを使用してイベントの形状を検出し、強制します。プロデューサーが明確に定義されている場合はスキーマを登録し、役立つ場合はコードバインディングを使用して型付きモデルを生成します。
以下が必要な場合はEventBridgeを選択します：
- 豊富なイベントパターンやクロスアカウント/イベントバス分離による複雑なルーティングとフィルタリング
- 複数のターゲット（Lambda、Step Functions、Kinesis、SQS、SNS）のネイティブサポート
- チーム間でのスキーマ検出とガバナンス
よりシンプルなファンアウトや保証されたキューセマンティクスが必要な場合は、直接SNS/SQSを選択します：
- 多くのサブスクライバーへのファンアウトとプッシュセマンティクスにはSNS
- 可視性タイムアウトとリドライブポリシーを備えた、耐久性のあるプルベースの処理にはSQS
SNSとSQSによるメッセージング（DLQ、可視性タイムアウト）
SNSはpub/subプッシュサービスであり、SQSはプルセマンティクスを持つ耐久性のあるキューです。高信頼性の処理には、SNS -> SQS -> Lambdaパターンを優先して、取り込みと処理を分離し、再試行と可視性を制御できるようにします。SQSのリドライブポリシー (
undefined
) を設定してmaxReceiveCountを超えた後にメッセージをDLQに移動させ、早すぎる再配信を避けるために可視性タイムアウトを十分に長く設定します（推奨：可視性 >= 関数タイムアウト * 2）。FIFOの要件には、SQS FIFOまたはSNS FIFOをメッセージグループIDと共に使用して順序を保持し、重複排除IDを使用して重複を回避します。
デッドレター処理のオプションと使用場面：
- Lambdaの非同期呼び出し：
DeadLetterConfigまたはDestinations(AsyncEventInvokeConfig) を設定して、失敗したイベントをSQS/SNSに送信するか、別のLambdaを呼び出します。 - SQS：ポイズンメッセージに対してSQS DLQへのリドライブポリシーを設定し、適切な
maxReceiveCountを設定します。 - EventBridge：ルールターゲットに
DeadLetterConfigとRetryPolicyを設定して、配信不能なイベントをキャプチャします。
べき等性は不可欠です。DynamoDBの条件付き書き込み（ConditionExpression attribute_not_exists(pk) を使用したPutItem）、TTL付きで保存されたべき等性トークン、または厳密に1回のセマンティクスのためのSQS FIFOの重複排除を使用して、べき等なハンドラを実装します。
関数のアクセス許可、ロール、最小権限
Lambdaの実行ロールと関数のリソースポリシーには最小権限を適用します。まずCloudWatch Logs用のAWSLambdaBasicExecutionRoleから始め、次にサービスに対して明示的なリソースARN（例：arn:aws:dynamodb:region:acct:table/MyTableに対するdynamodb:PutItem）を付与します。特定のARNが可能な場合は、Resource: "*"のようなワイルドカードを避けます。アクションとリソースでスコープを限定したマネージドポリシーまたはカスタムポリシーを使用し、サービスからの呼び出し許可を追加する際には条件（aws:SourceAccount、aws:SourceArn）を含めます。
- EventBridgeからの呼び出し許可を追加：
undefined
- SNSの場合：
source-arn条件を使用して、どのトピックが関数を呼び出せるかを制限します。
判断基準：
- サービスの呼び出し（EventBridge、SNS、CloudWatch Events）を許可するには、関数のリソースベースのポリシーを使用します。
- ランタイムのアクセス許可（DynamoDB、S3、Secrets Manager）には、IAM実行ロールを使用します。
- 影響範囲を減らすために、リソースレベルのアクセス許可と条件付き制約を優先します。
サーバーレスの可観測性とトラブルシューティング
可観測性は、メトリクス、ログ、トレース、非同期配信ステータスをカバーする必要があります。主要なCloudWatchメトリクスは、Invocations、Duration、Errors、Throttles、ConcurrentExecutions、IteratorAge（ストリームおよびSQSトリガー用）です。非同期の失敗を可視化するには、AsyncEventInvokeメトリクスを監視し、DeadLetterErrorsとThrottlesに対してCloudWatchアラームを設定します。X-Rayトレースを有効化（aws lambda update-function-configuration --function-name MyFn --tracing-config Mode=Active）して、サービス間のエンドツーエンドのトレースを取得し、コールドスタート、ダウンストリームのレイテンシー、例外を可視化します。
構造化JSONログとCloudWatch Logs Insightsクエリを使用して、エラーパターンを迅速に発見します。べき等性チェックを実装し、相関IDをログに記録します。分散トレーシングでは、自動的なコンテキストが失われるEventBridge/SNSフローの場合、イベントペイロード内でトレースIDを明示的に伝播させます。SQSイベントソースマッピングでは、ApproximateAgeOfOldestMessageを監視し、この値が増加している場合（バックプレッシャーやスロットリングを示唆）はアラームを設定します。LambdaのThrottlesメトリクスを捕捉してアラートを出し、プロビジョニングされた同時実行の使用状況とコストのトレードオフを追跡します。
よくある落とし穴と判断基準
- DLQを設定しない、またはデフォルトのリトライのみに依存する：非同期LambdaにはDLQまたはDestinationsを、キューにはSQSリドライブを設定し、手動調査のためにポイズンメッセージを捕捉します。
- SQSの不適切な可視性タイムアウトによる重複処理：重複を避けるため、可視性タイムアウトを「関数のタイムアウト * 2」以上に設定し、リトライやダウンストリームの呼び出しを考慮に入れます。
- 過度に寛容なLambda実行ロール：
Resource: "*"を避け、呼び出しポリシーとリソースポリシーにサービス/ソース条件（aws:SourceArn、aws:SourceAccount）を追加します。 - 同時実行数の上限を無視してスロットリングを引き起こす：予約された同時実行を使用して関数の上限を設定し、レイテンシーに敏感な関数にはプロビジョニングされた同時実行を使用し、
ConcurrentExecutions/Throttlesを監視します。 - 非同期境界を越えるトレースの欠落：イベントに相関IDを追加し、X-Rayを有効化するか、トレースヘッダーを伝播させてフローを再構築します。
- 耐久性の要件に対してSNSからLambdaへの直接連携を誤用する：耐久性のあるバッファリング、可視性の制御、より簡単なDLQ処理が必要な場合は、SNS->SQS->Lambdaの構成を優先します。
実践的な問題：ユースケースシナリオ
AcmePayments社は、大量の支払いイベントをEventBridge経由で受信しており、ピーク時に断続的なLambdaのスロットリングと重複処理が発生しています。同社は、信頼性の高い処理、データ損失の防止、およびDynamoDBへの下流の負荷の抑制を必要としています。
- EventBridgeのカスタムバスと、支払いイベントに一致するルールを作成します。ターゲット設定に
DeadLetterConfigとRetryPolicyを持つ耐久性のあるターゲットとして、SQS FIFOキューを追加します。 - ダウンストリームのキャパシティに合わせて調整されたバッチサイズと、「関数のタイムアウト * 2」以上に設定された可視性タイムアウトで、LambdaがSQSキューをポーリングするように設定します（イベントソースマッピング）。
- DynamoDBへの書き込みバーストを制限するために、Lambdaに予約された同時実行を設定します（
aws lambda put-function-concurrency ...）。低レイテンシーが要求される場合は、小規模なプールに対してプロビジョニングされた同時実行を実装します。 - payment-idをキーにしたDynamoDBの条件付き書き込みを使用してべき等性を実装し、クリーンアップのためにTTL付きでべき等性レコードを保存します。
- X-Rayトレースと、イベントに相関IDを含む構造化ログを有効にして処理を追跡します。
ApproximateAgeOfOldestMessage、Throttles、およびDLQメトリクスに対してCloudWatchアラームを設定します。
論理的根拠：EventBridgeをSQSに分離することで、耐久性のあるバッファリングとリトライのセマンティクスが提供されます。予約された同時実行はダウンストリームのDynamoDBをバーストから保護し、べき等性は重複を防ぎ、トレース/アラームは障害モードに対する運用上の可視性を提供します。
← データベースとキャッシング · すべてのドメイン · コスト管理とリソースタギング →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →