Q35 — AWS SAA-C03 第12章

第 35/100 問 | ← 第12章

Q835. ある企業が、AWS上で支払いアプリケーションを実行したいと考えています。このアプリケーションはモバイルデバイスから支払い通知を受信します。支払い通知は、さらに処理される前に基本的な検証を受ける必要があります。バックエンドの処理アプリケーションは長時間実行され、コンピューティングリソースおよびメモリの柔軟な調整が求められます。また、企業はインフラストラクチャの管理をしたくありません。これらの要件を満たす、運用オーバーヘッドが最も少ないソリューションはどれですか？

正解: D. Amazon API Gateway API を作成します。この API を AWS Lambda と統合し、モバイルデバイスからの支払い通知を受信します。Lambda 関数を呼び出して支払い通知を検証し、検証済みの通知をバックエンドアプリケーションに送信します。バックエンドアプリケーションを Amazon Elastic Container Service (Amazon ECS) 上にデプロイし、AWS Fargate 起動タイプで Amazon ECS を構成します。

解説

モバイルデバイスから支払い通知を受信し、基本的な検証を経て長時間実行されるバックエンド処理アプリケーションへと通知を送るという要件を満たしつつ、運用オーバーヘッドを最小限に抑えるには、選択肢 D が最も適しています。理由は以下の通りです。選択肢 D では、モバイルデバイスからの支払い通知を受信するための Amazon API Gateway API を作成し、それをサーバーレスでコードを実行できる AWS Lambda と統合します。Lambda 関数により支払い通知の基本検証を実施し、検証済みの通知をバックエンドアプリケーションへ送信できます。バックエンドアプリケーションは、コンテナのオーケストレーションと管理を提供する Amazon ECS にデプロイされます。さらに、AWS Fargate 起動タイプを用いることで、基盤となるインフラストラクチャ（EC2 インスタンスなど）のプロビジョニングや管理を一切不要にできます。このソリューションは、検証ロジックにサーバーレス（Lambda）を、バックエンドアプリケーションにコンテナオーケストレーション（ECS + Fargate）を活用することで、運用オーバーヘッドを最小限に抑えます。一方、選択肢 A、B、C はいずれも追加の運用負荷を伴います。A および B では Amazon EKS クラスターの管理が必要であり、特にセルフマネージドノードや EKS Anywhere の導入は運用複雑度を高めます。C では EC2 Spot Instances の使用によりコスト削減が可能ですが、中断リスクへの対応や監視・管理の手間が発生します。したがって、運用オーバーヘッドを最小限に抑えるには、API Gateway と Lambda を組み合わせて通知を受信・検証し、バックエンドアプリケーションを AWS Fargate 上の Amazon ECS で実行する選択肢 D が最適です。