以下に、AWS SAP 試験の問題1を指定の形式で整理しました。
■ 問題文（そのまま）
ある世界的な製造会社は、アプリケーションの大部分を AWS に移行することを計画しています。しかし、同社は、データ規制要件や 1 桁ミリ秒のレイテンシーを要求するため、特定の国やオンプレミスの中央データセンターにとどまる必要があるアプリケーションを懸念しています。同社はまた、ネットワークインフラストラクチャが限られている一部の工場サイトでホストしているアプリケーションについても懸念しています。
同社は、開発者がアプリケーションを一度構築すれば、オンプレミス、クラウド、またはハイブリッドアーキテクチャに展開できるように、一貫した開発者エクスペリエンスを望んでいます。開発者は、使い慣れた同じツール、API、サービスを使用できる必要があります。
これらの要件を満たす一貫したハイブリッドエクスペリエンスを提供するソリューションを選択してください。
■ 選択肢（そのまま）
- A.
データ規制要件があるアプリケーション、またはレイテンシが 1 桁ミリ秒の要件があるアプリケーションには、AWS Snowball Edge Storage Optimized デバイスを使用します。デバイスをオンプレミスに保管します。工場サイトのワークロードをホストするために AWS Wavelength をデプロイします。 - B.
AWS Outposts を、データ規制要件またはレイテンシが 1 桁ミリ秒の要件があるアプリケーション用にインストールします。工場サイトのワークロードをホストするために、AWS Snowball Edge Compute Optimized デバイスを使用します。 - C.
すべてのアプリケーションを、準拠する最も近い AWS リージョンに移行します。中央のオンプレミスのデータセンターと AWS の間に AWS Direct Connect 接続を設定します。Direct Connect ゲートウェイをデプロイします。 - D.
データ規制要件またはレイテンシが 1 桁ミリ秒の要件があるアプリケーションを AWS Local Zones に移行します。工場サイトのワークロードをホストするために AWS Wavelength をデプロイします。
■ 問題文の要件の概要
- 一貫した開発者エクスペリエンス（同じAPI、ツールを使える）
- ハイブリッド対応（オンプレミス・クラウド両方で展開可能）
- データ規制要件への準拠（国単位のデータ保護）
- 1桁ミリ秒レイテンシーの対応
- ネットワークが脆弱な工場サイトでも利用可能
■ 正解の選択肢と解説
✅ B. AWS Outposts + AWS Snowball Edge Compute Optimized
- AWS Outposts：AWSのハードウェアを顧客オンプレミスに設置することで、レイテンシやデータ主権要件を満たしつつ、クラウドと同一のAPI・サービスを利用可能。ハイブリッド環境に最適。
- Snowball Edge Compute Optimized：限られたネットワーク環境（例：工場）でも利用可能なエッジデバイス。強力なローカル処理能力を持ち、開発者にAWSと同じツール群を提供。
この組み合わせにより、クラウドでもエッジでも一貫した環境での開発・運用が可能。
■ 不正解の選択肢の理由
- A. Snowball Edge Storage Optimized + Wavelength
→ Storage Optimizedは主に大容量データ転送用途で、コンピューティング性能が不十分。
→ Wavelengthはモバイルネットワークのエッジ向けで、5G前提の通信基盤が必要なため、ネットワークが弱い工場には不適。 - C. 最寄りのリージョン + Direct Connect
→ AWSリージョンではデータ規制要件に対応できない可能性がある（国境を越える）。
→ Direct Connect でも1桁msの低レイテンシは難しい。 - D. Local Zones + Wavelength
→ Local Zones は特定都市のみで利用可能かつ、レイテンシがギリギリ1桁に届くか不明。
→ Wavelength は前述の通り、限定されたユースケース（モバイル）に特化しており、工場のような場所には不適。
■ SAP試験で押さえておくべきポイント
| テクノロジー | 特徴・適用場面 |
|---|---|
| AWS Outposts | オンプレミスにAWSの機能を展開。クラウドと同様のAPI、ツール使用可。低レイテンシ・データ主権に対応。 |
| AWS Snowball Edge Compute | ネットワークが限定的なエリアでのローカルコンピューティングに最適。開発体験もクラウドと一致。 |
| AWS Local Zones | 一部都市に展開されており、低レイテンシを部分的に実現。全世界対応ではない。 |
| AWS Wavelength | 5Gネットワークベースのエッジ向け。スマートフォンアプリやIoTが主対象。 |
| AWS Direct Connect | 安定・高速な接続は可能だが、物理距離による限界レイテンシあり。 |
引き続き、別の問題もお送りいただければ同様に整理します。お気軽にどうぞ。
以下に「問題2」を指定の形式で整理しました。
■ 問題文（そのまま）
ある宅配会社は AWS クラウドでサーバーレスソリューションを運用しています。このソリューションは、ユーザーデータ、配送情報、過去の購入詳細を管理しています。このソリューションは、いくつかのマイクロサービスで構成されています。中央のユーザーサービスは、Amazon DynamoDB のテーブルに機密データを保存します。他のいくつかのマイクロサービスは、機密データの一部のコピーを異なるストレージサービスに保存します。
同社は、要求に応じてユーザー情報を削除する機能を必要としています。中央のユーザーサービスがユーザーを削除すると、他のすべてのマイクロサービスもデータのコピーを直ちに削除する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（そのまま）
- A.
DynamoDB テーブルで DynamoDB Streams を有効にします。ユーザー削除に関するイベントを Amazon Simple Queue Service (Amazon SQS) のキューにポストする DynamoDB Streams 用の AWS Lambda トリガーを作成します。各マイクロサービスがキューをポーリングし、DynamoDB テーブルからユーザーを削除するように構成します。 - B.
会社がユーザーを削除したときに Amazon Simple Queue Service (Amazon SQS) キューにメッセージを投稿するように中央のユーザーサービスを設定します。SQS キューにイベントフィルターを作成し、DynamoDB テーブルからユーザーを削除するように各マイクロサービスを設定します。 - C.
会社がユーザーを削除したときに、カスタム Amazon EventBridge イベントバスにイベントを投稿するように中央のユーザーサービスを設定します。各マイクロサービスに、ユーザー削除イベントパターンに一致する EventBridge ルールを作成し、マイクロサービス内のロジックを呼び出して、DynamoDB テーブルからユーザーを削除します。 - D.
DynamoDB テーブルに DynamoDB イベント通知を設定します。DynamoDB イベント通知のターゲットとして、Amazon Simple Notification Service (Amazon SNS) トピックを作成します。各マイクロサービスが SNS トピックをサブスクライブし、DynamoDB テーブルからユーザを削除するように設定します。
■ 問題文の要件の概要
- ユーザー削除要求に応じて、関連データを即時にすべてのマイクロサービスから削除する必要がある
- 各マイクロサービスが別々のストレージを使用しており、中央サービスからの通知が必要
- アーキテクチャはサーバーレス、マイクロサービス構成
■ 正解の選択肢と解説
✅ C. EventBridge イベントバスによる通知分配
理由：
- Amazon EventBridgeはマイクロサービスアーキテクチャでのイベントドリブンな通信に最適。
- 各マイクロサービスはEventBridge ルールでイベントをフィルタリングし、リアルタイムかつ即時に反応可能。
- キューのポーリングや通知のラグがなく、効率的かつ即時性のある削除処理が実現できる。
■ 不正解の選択肢の理由
- A. DynamoDB Streams + Lambda + SQS + ポーリング
- 複雑な構成で、SQSのポーリングが必要。即時性に欠ける。
- Lambdaを経由しSQSに投稿しても、他のマイクロサービスが能動的にポーリングしないと反応できず、遅延が発生し得る。
- B. 中央サービスが SQS に投稿し、フィルタと削除処理
- SQSにイベントフィルター機能は存在しない（これはSNSの機能）。
- 各マイクロサービス側でポーリングが必要で、リアルタイム性が低い。
- D. DynamoDB の「イベント通知」+ SNS
- DynamoDB にイベント通知機能は存在しない。存在するのはDynamoDB Streams。
- 前提が不正確で、実装不能な選択肢。
■ SAP試験で押さえておくべきポイント
- EventBridgeはサーバーレスなイベント通知基盤として、マイクロサービス間の連携に適している。
- 特定イベント発生時に、複数のターゲット（Lambda、Step Functions、他サービス）に即時通知可能。
- イベントパターンによるフィルタリングが強力。
- SQSやSNSは非同期通知に強いが、即時かつ複数マイクロサービスへの伝播にはEventBridgeがベスト。
- DynamoDB StreamsはDynamoDBの変更ログを取得可能だが、ポーリング方式でリアルタイム性には限界あり。
- AWSのサービス間連携におけるイベント駆動型設計（Event-Driven Architecture）はSAPで非常に頻出。
続けて他の問題もあれば、お送りください。順次対応します。
以下に「問題3」を指定フォーマットで整理しました。
■ 問題文（そのまま）
ある企業が、さまざまなベンダーから家電製品を購入しました。家電にはすべて IoT センサーが搭載されています。センサーは、ベンダー独自の形式で、情報を JSON に解析するレガシーアプリケーションにステータス情報を送信します。解析は単純ですが、各ベンダーは独自の形式を持っています。毎日、アプリケーションはすべての JSON レコードを解析し、分析のためにリレーショナルデータベースにレコードを保存します。
同社は、より迅速でコストを最適化できる新しいデータ分析ソリューションを設計する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（そのまま）
- A.
IoT センサーを AWS IoT Core に接続します。AWS Lambda 関数を呼び出して情報を解析し、.csv ファイルを Amazon S3 に保存するルールを設定します。AWS Glue を使用してファイルをカタログ化します。分析には Amazon Athena と Amazon QuickSight を使用します。 - B.
AWS Snowball Edge を使用して、IoT センサーから直接データを収集し、ローカル分析を実行します。定期的に Amazon Redshift にデータを収集し、グローバル分析を実行します。 - C.
AWS Transfer for SFTP サーバーを作成します。IoT センサーのコードを更新して、情報を .csv ファイルとして SFTP 経由でサーバーに送信します。AWS Glue を使用してファイルをカタログ化します。分析には Amazon Athena を使用します。 - D.
アプリケーションサーバーを AWS Fargate に移行すると、IoT センサーから情報が受信され、情報がリレーショナル形式に解析されます。解析された情報を分析用に Amazon Redshlft に保存します。
■ 問題文の要件の概要
- ベンダーごとに形式が異なる IoT センサーデータの取り扱い
- データは JSON 形式、簡易なパースが必要
- 毎日解析・保存していた処理を、より高速かつコスト最適化
- データ分析に適した構成が求められる
■ 正解の選択肢と解説
✅ A. IoT Core + Lambda + S3 + Glue + Athena + QuickSight
この構成は、AWSが推奨するIoTデータ処理パターンの1つです。
- AWS IoT Core：各センサーからメッセージを受け取るエントリポイント。
- AWS Lambda：受信データをJSONから.csvに変換し、構造を統一。
- Amazon S3：低コストでスケーラブルなストレージ。
- AWS Glue：S3に保存したデータをカタログ化。
- Amazon Athena：S3上のデータに直接SQLクエリを発行。
- Amazon QuickSight：可視化とBIダッシュボード。
→ 一連の構成で、リアルタイム処理・コスト削減・スケーラビリティをすべて満たす。
■ 不正解の選択肢の理由
- B. Snowball Edge + Redshift
- Snowball Edge はオフラインのデータ転送用デバイス。
- IoTセンサーのような継続的・リアルタイムなデータ収集には不向き。
- Redshift も大規模バッチ分析には良いが、小規模なリアルタイム解析には過剰かつ高コスト。
- C. Transfer for SFTP + Glue + Athena
- IoTセンサーのコード更新が必要で非現実的。
- SFTP経由での転送はレガシー方式で、低遅延やリアルタイム性が損なわれる。
- D. Fargate + Redshift
- Fargate はコンテナ実行には向くが、IoTセンサーの受信には過剰。
- Redshift の使用はコスト・性能の観点から、簡易データ分析には不適切。
■ SAP試験で押さえておくべきポイント
| 項目 | 解説 |
|---|---|
| AWS IoT Core | センサー等の IoT デバイスからデータを取り込むためのマネージドサービス。 |
| AWS Lambda | IoTデータの整形や軽処理に最適なサーバーレス関数。 |
| Amazon S3 | 分析用データの保存先として、コスト効率・耐久性に優れる。 |
| AWS Glue | データレイク上のファイルをクローラで構造化・カタログ化する。 |
| Amazon Athena | S3上のデータに直接SQLクエリを実行できるサーバーレス分析サービス。 |
| Amazon QuickSight | データの可視化やダッシュボード化に使うBIツール。 |
引き続き、他の問題もあればお送りください。分析と解説を続けてご提供します。
以下に「問題4」を指定フォーマットで整理しました。
■ 問題文（そのまま）
ソリューションアーキテクトは、新しく買収した会社のアプリケーションとデータベースのポートフォリオを評価する必要があります。ソリューションアーキテクトは、ポートフォリオを AWS に移行するためのビジネスケースを作成する必要があります。新しく買収した会社は、オンプレミスのデータセンターでアプリケーションを実行しています。そのデータセンターは文書化されていません。ソリューションアーキテクトは、いくつのアプリケーションとデータベースが存在するのかすぐに判断できません。アプリケーションのトラフィックは変動します。一部のアプリケーションは月末に実行されるバッチ処理です。
ソリューションアーキテクトは、AWS への移行を開始する前に、ポートフォリオをより深く理解する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（そのまま）
- A.
Migration Evaluator を使用してサーバーのリストを生成します。ビジネスケースのレポートを作成します。AWS Migration Hub を使用して、ポートフォリオを表示します。AWS Application Discovery Service を使用して、アプリケーションの依存関係を理解します。 - B.
AWS Application Migration Service を使用します。オンプレミスのインフラストラクチャ上でエージェントを実行します。AWS Migration Hub を使用してエージェントを管理します。AWS Storage Gateway を使用して、ローカルストレージのニーズとデータベースの依存関係を評価します。 - C.
宛先アカウントで AWS Control Tower を使用して、アプリケーションポートフォリオを生成します。AWS Application Migration Service (AWS MGN) を使用して、より詳細なレポートとビジネスケースを生成します。コアアカウントとリソースにはランディングゾーンを使用します。 - D.
AWS Application Migration Service (AWS MGN) と AWS Database Migration Service (AWS DMS) を使用して移行を評価します。AWS Service Catalog を使用して、アプリケーションとデータベースの依存関係を理解します。
■ 問題文の要件の概要
- 移行前にポートフォリオ（アプリやDBの全体像）を把握する必要がある
- 現状は未文書化のオンプレ環境
- トラフィックが変動的、バッチ処理も存在
- 移行実行ではなく、事前調査・評価が目的
■ 正解の選択肢と解説
✅ A. Migration Evaluator + Migration Hub + Application Discovery Service
理由：
- Migration Evaluator（旧 TSO Logic）：オンプレ環境の使用状況をもとに、サーバーリストとコスト見積り付きのビジネスケースを自動生成できる。
- AWS Migration Hub：複数の移行ツールや分析結果を一元管理し、ポートフォリオの全体像を把握。
- AWS Application Discovery Service：オンプレミスのアプリケーションやその依存関係（通信経路・DBなど）を自動検出し、移行計画の精度を高める。
■ 不正解の選択肢の理由
- B. Application Migration Service + Storage Gateway
- **Application Migration Service (MGN)**は実際の移行用ツールであり、事前評価や可視化はできない。
- Storage Gatewayはハイブリッド構成用ストレージ接続ツールであり、アプリやDB依存関係の調査には使わない。
- C. Control Tower + MGN + ランディングゾーン
- Control Towerはアカウント構築とガバナンスの自動化ツールであり、ポートフォリオ調査には無関係。
- MGNも評価用途には不適。
- D. MGN + DMS + Service Catalog
- すべて移行実行フェーズのツールであり、移行前の「可視化」「分析」には向いていない。
- Service Catalogは承認済みリソースのデプロイ管理用ツールで、依存関係分析には使用しない。
■ SAP試験で押さえておくべきポイント
| 項目 | 解説 |
|---|---|
| Migration Evaluator | オンプレのリソース使用量とコストを評価し、AWS移行のビジネスケースを作成するツール。 |
| AWS Application Discovery Service | オンプレミスのサーバー・アプリの情報を収集し、依存関係を可視化。 |
| AWS Migration Hub | 移行プロジェクトの可視化と進捗管理のための中核ツール。 |
| “移行前”と“移行中”のフェーズで使うツールは異なることを見極めるのがSAP試験の重要ポイント。 |
次の問題も続けてどうぞ。すべてこの形式で整理していきます。
以下に「問題5」を指定フォーマットで整理しました。
■ 問題文（そのまま）
企業が IT ポートフォリオ全体を AWS に移行しています。社内の各部門には、開発環境とテスト環境の両方をサポートする 1 つの AWS アカウントがあります。今後、本番環境をサポートする新しいアカウントが必要です。財務部門では、支払い方法の管理、各部門の費用の可視化、および費用の配分を行う必要があります。セキュリティ部門では、会社の AWS アカウントのすべてを一元管理し、アクセス制御を強化する必要があります。
最低限の労力で要件を満たす方法を選択してください。 (2 つ選択)
■ 選択肢（そのまま）
- A.
各アカウントで共通の IAM のアクセス許可を定義するパラメーター化された AWS CloudFormation テンプレートのコレクションを使用します。最小権限の原則を適用するために、新規および既存のアカウントに適切なスタックを作成します。 - B.
AWS Organizations のすべての機能を有効にして、IAM のアクセス権限をフィルタリングする適切なサービスコントロールポリシー (SCP) を確立します。 - C.
AWS Organizations を使用して、新しい組織の支払者アカウントとなる管理アカウントから、組織を作成します。既存のアカウントを招待して組織に統合します。組織に自動的にリンクされているアカウントを作成します。 - D.
会社のすべての AWS アカウントを単一の AWS アカウントに統合します。コスト配分タグを使用し、IAM のアクセスアドバイス機能を使用して最小権限の原則を適用します。 - E.
各部門に独自の AWS アカウントを使用するようにします。各 AWS アカウントに適切なタグを付けて、Cost Explorer で費用の配分を管理できるようにします。
■ 問題文の要件の概要
- 本番環境用の新しいアカウントが必要
- 財務部門の要件：一括請求、コスト可視化、費用配分
- セキュリティ部門の要件：すべてのアカウントの一元管理、アクセス制御強化
- 最小限の労力での実現が求められる
→ AWS OrganizationsとSCPの活用がカギ
■ 正解の選択肢と解説
✅ B. AWS Organizations + SCP の使用
✅ C. AWS Organizations の作成とアカウント統合
理由：
- B（SCPの設定）
- SCP（Service Control Policy）は、組織全体のアクセス制御を一元化し、セキュリティ要件を満たす。
- IAMポリシーの上位制約として働き、アクセス制御のガードレールとなる。
- C（Organizationsの構築）
- 組織管理アカウントを作成し、既存のアカウントを招待・一括請求を実現できる。
- 統合請求・一元管理・新アカウント作成の簡便化が可能。
■ 不正解の選択肢の理由
- A（CloudFormationテンプレートによるIAM統制）
- アクセス制御を各アカウント内で実装する方式。組織横断の一元管理や一括請求には非対応。
- 管理コストが高く、”最低限の労力”という条件に合致しない。
- D（単一アカウント統合）
- 全部を1アカウントにまとめるのはスケーラビリティ・セキュリティの観点で非推奨。
- 各部門の責任分離やコストトラッキングが困難。
- E（タグによるコスト管理のみ）
- タグでの費用管理はできるが、一括請求やセキュリティの一元管理機能が不足。
- Organizationsを使わずタグだけでは不十分。
■ SAP試験で押さえておくべきポイント
| 項目 | 解説 |
|---|---|
| AWS Organizations | 複数アカウントの統合管理、支払い管理（コンソリデーティッドビリング）、SCPによるアクセス制御、一元化を支援 |
| SCP（Service Control Policy） | IAMポリシーと併用し、アカウントレベルでアクセスを制限。SCPがDENYするとIAMで許可してもブロックされる。 |
| 一元管理と最低限の労力 | AWS OrganizationsとSCPの組み合わせは、セキュリティとコスト管理のベストプラクティス。SAP試験で頻出。 |
| アカウント構成のベストプラクティス | 開発・テスト・本番・管理・監査などの環境をアカウント単位で分離するのが推奨 |
次の問題もお送りください。引き続きこの形式で対応いたします。
以下に「問題6」を指定のフォーマットで整理しました。
■ 問題文（そのまま）
ある製造会社が工場の検査ソリューションを構築しています。同社は各組立ラインの最後に IP カメラを設置しています。同社は Amazon SageMaker を使用して、静止画像から一般的な欠陥を特定する機械学習 (ML) モデルをトレーニングしました。同社は、欠陥が検出された場合に工場作業員に現地のフィードバックを提供したいと考えています。
企業は、工場のインターネット接続がダウンした場合でも、このフィードバックを提供できる必要があります。同社は、作業員にローカルフィードバックを提供する API をホストするローカル Linux サーバーを持っています。
これらの要件を満たす最適な ML モデルを選択してください。
■ 選択肢（そのまま）
- A.
AWS Snowball デバイスを注文します。SageMaker のエンドポイントと ML モデル、そして Snowball デバイス上の Amazon EC2 インスタンスをデプロイします。カメラから静止画を撮影します。EC2 インスタンスから推論を実行します。欠陥が検出されたときにローカル API を呼び出すようにインスタンスを設定します。 - B.
AWS IoT Greengrass をローカルサーバーにデプロイします。ML モデルを Greengrass サーバにデプロイします。カメラから静止画を取得し、推論を実行する Greengrass コンポーネントを作成します。欠陥が検出されたときにローカル API を呼び出すようにコンポーネントを構成します。 - C.
各 IP カメラに Amazon Monitron デバイスをデプロイします。Amazon Monitron Gateway をオンプレミスにデプロイします。Amazon Monitron デバイスに ML モデルをデプロイします。Amazon Monitron ヘルス状態アラームを使用して、欠陥が検出されたときに AWS Lambda 関数からローカル API を呼び出します。 - D.
各 IP カメラから AWS に Amazon Kinesis Video Streams を設定します。Amazon EC2 インスタンスを使用して、ストリームの静止画像を取得します。Amazon S3 バケットに画像をアップロードします。ML モデルで SageMaker エンドポイントをデプロイします。新しい画像がアップロードされたら、AWS Lambda 関数を呼び出して推論エンドポイントを呼び出します。欠陥が検出されたときにローカル API を呼び出すように Lambda 関数を設定します。
■ 問題文の要件の概要
- IPカメラの静止画像から製造欠陥をリアルタイム検出
- MLモデルはすでに SageMaker でトレーニング済
- インターネット接続断でも動作できること
- ローカルLinuxサーバーに API をホストし、工場作業員に即時フィードバックを提供する必要あり
■ 正解の選択肢と解説
✅ B. AWS IoT Greengrass を使ってローカル実行
理由：
- AWS IoT Greengrass は、ローカルデバイス上で Lambda 関数や ML モデルの推論などの AWS 機能を動作させるエッジコンピューティング環境。
- モデルをローカルにデプロイでき、インターネットが切れていても推論とローカル API 呼び出しが可能。
- まさに「ローカルサーバー + オフライン可 + 即時反応」の要件に合致するサービス。
■ 不正解の選択肢の理由
- A. AWS Snowball
→ Snowball はデータ転送やエッジ処理向けであり、ローカルでの軽量リアルタイム推論向きではない。
→ 毎回 Snowball に頼るのは重すぎて現実的でない。 - C. Amazon Monitron
→ Monitron は「回転機器の異常検知」に特化した専用ハード＋MLサービス。静止画での欠陥検出には不適。
→ カメラの画像分析には向かない。 - D. Kinesis Video Streams + SageMaker + Lambda
→ クラウド中心の構成でインターネット接続が必須。ネットが落ちると検出もフィードバックもできない。
→ 問題の前提条件（オフライン対応）を満たさない。
■ SAP試験で押さえておくべきポイント
| 項目 | 解説 |
|---|---|
| AWS IoT Greengrass | ローカルデバイスに AWS の機能を拡張可能。MLモデルの推論も Lambda 関数もオフライン実行できる。IoTデバイスやローカルサーバーに最適。 |
| エッジコンピューティング | SageMakerで学習したモデルをクラウドに頼らずローカルで実行可能にするソリューションが問われやすい。GreengrassやSnowball Edgeが候補に挙がる。 |
| インターネット切断に対する設計 | 「接続断でも動く設計」は、SAP試験での設問パターンとして頻出。クラウドに依存しない構成の重要性を理解すること。 |
| Greengrass vs Snowball | Greengrassは常時稼働するローカル処理向け。Snowball Edgeはバッチデータ移行や一時的処理に向く。使い分けが大事。 |
次の問題もどうぞ！同じフォーマットで整理します。
以下に「問題7」を指定された形式でまとめます。
■ 問題文（そのまま）
ある企業が、Amazon EC2 の Linux インスタンス上で独自のステートレス ETL アプリケーションを稼働させています。アプリケーションは Linux のバイナリで、ソースコードは変更できません。アプリケーションはシングルスレッドで、2 GB の RAM を使用し、CPU の負荷が高くなります。アプリケーションは 4 時間ごとに実行されるようにスケジュールされており、最大 20 分間実行されます。ソリューションアーキテクトが、このソリューションのアーキテクチャを修正したいと考えています。
ソリューションアーキテクトはどの戦略を使用する必要がありますか ?
■ 選択肢（そのまま）
- A.
AWS Lambda を使用してアプリケーションを実行します。Amazon CloudWatch Logs を使用して、4 時間ごとに Lambda 関数を呼び出します。 - B.
Amazon EC2 スポットインスタンスを使用してアプリケーションを実行します。AWS CodeDeploy を使用して、4 時間ごとにアプリケーションをデプロイして実行します。 - C.
AWS Batch を使用してアプリケーションを実行します。AWS Step Functions ステートマシンを使用して、4 時間ごとに AWS Batch ジョブを呼び出します。 - D.
AWS Fargate を使用してアプリケーションを実行します。Amazon EventBridge (Amazon CloudWatch Events) を使用して、4 時間ごとに Fargate タスクをトリガーします。
■ 問題文の要件の概要
- ソースコードが変更できない Linux バイナリアプリケーション（既存資産）
- ステートレス、CPU負荷が高く、2GB RAM 使用
- 実行時間は最大20分、4時間ごとにスケジュール実行
- メンテナンスが少なく、自動実行できる形に修正したい
■ 正解の選択肢と解説
✅ D. AWS Fargate を使用してアプリケーションを実行し、EventBridgeで定期実行する
解説：
- AWS Fargate はサーバーレスなコンテナ実行環境であり、インフラ管理不要でコンテナ化されたアプリケーションを定期実行するのに最適。
- 問題文のバイナリアプリは、コンテナにパッケージすることが可能で、Fargate により自動実行できる。
- 実行時間が20分で、4時間おきに繰り返される処理 → EventBridge によりスケジューリングが可能。
- アプリはステートレスかつ短時間実行型のため、都度実行されるFargateタスクとの親和性が高い。
■ 不正解の選択肢の理由
- A. AWS Lambda
→ Lambda は実行時間の上限が15分なので、最大20分かかるこのアプリには不適。
→ また、Linuxバイナリの実行にも制約あり。 - B. EC2スポット + CodeDeploy
→ スポットインスタンスはいつ中断されるか不明で、安定稼働が求められるETL処理には不向き。
→ CodeDeploy による4時間ごとの手動デプロイも冗長で複雑。 - C. AWS Batch + Step Functions
→ AWS Batch は大規模なバッチ処理に向いており、本件のような小規模・短時間・定期実行にはオーバーエンジニアリング。
→ ステップ関数との組み合わせも構成が複雑になりやすい。
■ SAP試験で押さえておくべきポイント
| 項目 | 内容 |
|---|---|
| Fargate の適用場面 | ステートレス・短時間実行・定期処理には最適。インフラ管理不要で、コスト効率も良い。 |
| EventBridge の役割 | CloudWatch Events の進化系。時間ベース（cron）やイベントベースのトリガーに利用。 |
| Lambda の制限 | 最大実行時間15分。長時間処理、重い処理には適さない。 |
| スポットインスタンスの欠点 | コストは安いが、中断リスクがあるため、定時実行や安定性が必要なジョブには不向き。 |
| Batch vs Fargate | Batch は大規模・並列処理向け、Fargate は短時間・簡素なジョブ実行向け。 |
次の問題もあれば、引き続きこの形式で整理します。お気軽にどうぞ。
