Question#56(SAP-C02)
ある会社は、Amazon EC2 インスタンス上でデータ処理アプリケーションをホストしています。このアプリケーションは Amazon Elastic File System（Amazon EFS）のファイルシステムをポーリングして新規アップロードを検出します。新規ファイルを検出すると、アプリケーションはファイルからデータを抽出し、当該ファイルを処理するための Docker コンテナイメージを選択するロジックを実行します。アプリケーションは該当イメージのコンテナを起動し、ファイルの場所をパラメータとして渡します。コンテナが実施するデータ処理は最大 2 時間かかることがあり、処理完了後はコンテナ内のコードがファイルを Amazon EFS に書き戻して終了します。会社は、コンテナを動かしている EC2 インスタンスを排除するようにアプリケーションをリファクタリングする必要があります。どの解決策が要件を満たしますか。
正解：C
本件のゴールは、EC2 を排してコンテナ実行基盤をサーバーレス化しつつ、最大 2 時間かかる処理を継続して実施でき、かつ新規ファイルの到着をイベント駆動でトリガーできる構成に改めることです。まず、処理そのものはコンテナで継続実行したいので、ECS の AWS Fargate を用いれば、EC2 管理なしにコンテナタスクとして長時間のバッチ処理を走らせられます。これは要件の「EC2 排除」に合致します（Fargate はECSのサーバーレス実行基盤です）。
一方、「新規ファイルの到着を検知して起動する」ためのネイティブなイベントソースとして Amazon EFS はオブジェクト作成（ファイル作成）イベントを直接発火しません。EventBridge に出るのは管理プレーン（CloudTrail 経由の API）イベントが中心で、EFS へのファイル書き込みは API 越しではなく NFS プロトコル経由のため、S3 のような「オブジェクト作成イベント」は得られません。したがって、選択肢 A/B にある「EFS ファイル追加をトリガーとする EventBridge／EFS イベント通知」は前提が成り立ちません。 このため、ファイル保管を Amazon S3 に移行し、S3 イベント通知（オブジェクト作成）で Lambda を起動し、選択ロジックを Lambda に実装してRunTaskで該当の Fargate タスクを起動する、というパターンが素直で運用負荷も低く、イベント駆動を実現できます。S3 は Lambda 連携を公式にサポートしており、オブジェクト作成を確実にトリガーできます。 選択肢 D は一見サーバーレスで魅力的ですが、処理時間が最大 2 時間という条件に対し AWS Lambda の最大実行時間は 15 分（900 秒）というサービス制限があるため要件を満たしません。
コメント