以下は、問題1の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ある企業は AWS クラウドにアプリケーションを持っています。このアプリケーションは、20 台の Amazon EC2 インスタンスのフリート上で実行されます。EC2 インスタンスは永続的で、接続された複数の Amazon Elastic Block Store (Amazon EBS) ボリュームにデータを保存します。
同社は、別の AWS リージョンでバックアップを維持する必要があります。同社は、1 営業日以内に、1 日分のデータ損失を超えずに EC2 インスタンスとその構成を回復できなければなりません。同社には限られたスタッフしかいないため、運用効率とコストを最適化するバックアップソリューションが必要です。同社はすでに、必要なネットワーク構成をセカンダリリージョンにデプロイできる AWS CloudFormation テンプレートを作成しています。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. セカンダリリージョンで EC2 インスタンスを再作成できる 2 番目の CloudFormation テンプレートを作成します。AWS Systems Manager オートメーションランブックを使用して、マルチボリュームスナップショットを毎日実行します。スナップショットをセカンダリリージョンにコピーします。障害が発生した場合、CloudFormation テンプレートを起動し、スナップショットから EBS ボリュームを復元し、使用量をセカンダリリージョンに転送します。
- B. Amazon Data Lifecycle Manager (Amazon DLM) を使用して、EBS ボリュームのマルチボリュームスナップショットを毎日作成します。障害が発生した場合、CloudFormation テンプレートを起動し、Amazon DLM を使用して EBS ボリュームを復元し、使用量をセカンダリリージョンに転送します。
- C. AWS Backup を使用して、EC2 インスタンスのスケジュールされたバックアップ計画を毎日作成します。バックアップをセカンダリリージョンのコンテナにコピーするようにバックアップタスクを構成します。障害が発生した場合、CloudFormation テンプレートを起動し、バックアップボールトからインスタンスボリュームと構成を復元し、使用量をセカンダリリージョンに転送します。
- D. 同じサイズと構成の EC2 インスタンスをセカンダリリージョンにデプロイします。プライマリリージョンからセカンダリリージョンにデータをコピーするように AWS DataSync を毎日設定します。障害が発生した場合、CloudFormation テンプレートを起動し、使用量をセカンダリリージョンに転送します。
■ 問題文の要件の概要
- EC2 フリート（20台）と複数の永続的なEBSボリューム
- 1営業日以内に復旧（RTO）し、最大1日分のデータ損失（RPO）で済ませることが必要
- セカンダリリージョンで復元が可能であること
- スタッフが少なく、低運用・低コストの仕組みが求められる
- CloudFormationテンプレートは準備済み
✅ 正解の選択肢と解説
- 正解：C
C. AWS Backup を使用したスケジュールバックアップ＋クロスリージョンコピー
- AWS Backup は、EC2 インスタンス（EBS含む）の整合性のあるスナップショットを取得可能
- クロスリージョンコピーを設定することで、別リージョンに自動的にバックアップを複製可能
- 運用作業を最小限に抑えつつ、1日1回のスケジュールバックアップで要件を満たせる
- 障害時はCloudFormationでネットワークを構成し、バックアップボールトから復元可能
- コストもライフサイクルポリシーで古いバックアップを削除可能
❌ 不正解の選択肢の理由
A. Systems Manager + スナップショットコピー
- スナップショットは取得できるが、インスタンスメタデータや構成の完全復旧が困難
- スナップショットコピーや復元作業が手動で多く、人的負担が増える
- 少人数運用体制では日次復旧が保証できない
B. DLM でのスナップショット取得
- EBSボリュームのバックアップは可能だが、インスタンスの設定や構成の復元が自動ではない
- クロスリージョンコピーは設定できるが、インスタンスの復旧プロセスが煩雑
- 結果的にRTO要件を満たしにくい
D. EC2常時デプロイ + DataSync
- DataSyncはファイル単位の同期であり、EBS全体の整合コピーには不適
- EC2インスタンスをセカンダリリージョンに常時保持するため、コスト最適化の要件に反する
- ブロックレベルのバックアップを取らず、復旧整合性に欠ける
■ SAP試験で押さえておくべきポイント
- EC2とEBSのフルバックアップ＋構成復元が可能な唯一のフルマネージドサービスはAWS Backup
- クロスリージョンコピー機能があることを理解しておく
- DLMやSystems Managerでは**「インスタンスの構成情報含む完全復旧」**が困難
- DataSyncはファイル単位の同期であり、スナップショットの代替にはならない
- RTO/RPOの要件とコスト・運用効率を両立する設計を問う問題が多い
他の問題も引き続きどうぞ。すぐに整理してお出しします。
以下は、問題2の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ある企業がマイクロサービスを AWS Lambda 関数として運用しています。マイクロサービスは、限られた数の同時接続をサポートするオンプレミス SQL データベースにデータを書き込みます。Lambda 関数の呼び出し数が多すぎると、データベースがクラッシュし、アプリケーションのダウンタイムが発生します。同社の VPC とオンプレミスのデータセンター間には AWS Direct Connect 接続があります。同社はデータベースをクラッシュから保護したいと考えています。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. Amazon Simple Queue Service (Amazon SQS) のキューにデータを書き込みます。キューから読み取り、既存のデータベースに書き込むように Lambda 関数を設定します。Lambda 関数の予約済同時実行のクォータを、データベースがサポートする接続数よりも少ない値に設定します。
- B. 新しい Amazon Aurora Serverless DB クラスターを作成します。AWS DataSync を使用して、既存のデータベースから Aurora Serverless にデータを移行します。Aurora に書き込むように Lambda 関数を再設定します。
- C. Amazon RDS Proxy DB インスタンスを作成します。RDS Proxy DB インスタンスを Amazon RDS DB インスタンスにアタッチします。RDS Proxy DB インスタンスに書き込むように Lambda 関数を再設定します。
- D. Amazon Simple Notification Service (Amazon SNS) トピックにデータを書き込みます。トピックが新しいメッセージを受信したときに、Lambda 関数を呼び出して既存のデータベースに書き込みます。Lambda 関数のプロビジョニング済み同時実行数が、データベースがサポートする接続数と等しくなるように設定します。
■ 問題文の要件の概要
- マイクロサービスが Lambda 上で動作
- 書き込み先はオンプレミスのSQLデータベース（同時接続数に制限あり）
- 呼び出しが多すぎるとDBがクラッシュ
- VPCとオンプレDCはDirect Connectで接続済
- アプリの変更は最小限にしたい
✅ 正解の選択肢と解説
- 正解：A
A. SQS + Lambda + 予約済同時実行でスロットリング制御
- Amazon SQS をキューとして利用することで、Lambda からのリクエストをバッファリング（平準化）可能。
- Lambda の予約済同時実行数をDBの許容接続数以下に設定すれば、接続数をハードリミットできる。
- オンプレミスのDB構成やDirect Connectなど既存インフラをそのまま活かせる。
- 結果的にアプリケーション変更を最小限に抑えつつ、クラッシュリスクを回避できるベストプラクティスな設計。
❌ 不正解の選択肢の理由
B. Aurora Serverless + DataSync
- オンプレミスDBを完全に移行する前提となってしまうため、即時対処にならない。
- Auroraに書き込むようLambdaを書き換える必要があり、移行リスクも高い。
- DataSync はファイル転送用のサービスであり、トランザクションやリアルタイム同期に向かない。
C. RDS Proxy を使う
- RDS Proxy は AWS内のRDSやAurora専用の機能で、オンプレミスDBには使えない。
- オンプレSQL DBを対象とした接続プール機能は提供されておらず、効果なし。
D. SNS + Lambda + プロビジョニング済み同時実行
- SNSはプッシュ型で即時Lambda起動するため、同時実行数を突発的に超えることがある。
- プロビジョンド同時実行だけではスパイクを防げないため、クラッシュリスクが残る。
■ SAP試験で押さえておくべきポイント
- オンプレミスDBなど同時接続制限のあるシステムに対するスロットリング手法はSQS＋Lambda＋予約済同時実行
- Amazon SQSは「リクエストバッファ」用途に有効で、スパイク吸収や順次処理に最適
- Lambdaの同時実行数制御には「予約済」と「プロビジョンド」の違いがある。予約済の方が絶対上限を保証
- SNSは即時通知・バースト型で、スロットリングには不向き
- RDS ProxyはRDS/Aurora専用。オンプレミスDBとは非互換
次の問題もあればお送りください。引き続きフォーマットに沿って整理いたします。
以下は、問題3の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
企業には複数の事業部があり、それぞれが AWS 上に個別のアカウントを持っています。各事業部は、重複する CIDR 範囲を持つ複数の VPC で独自のネットワークを管理しています。会社のマーケティングチームは新しい社内アプリケーションを作成し、他のすべての事業部がそのアプリケーションにアクセスできるようにしたいと考えています。このソリューションでは、プライベート IP アドレスのみを使用する必要があります。
運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. 各事業部に、事業部の VPC に一意のセカンダリ CIDR 範囲を追加するように指示します。VPC をピアリングし、セカンダリ範囲のプライベート NAT ゲートウェイを使用して、トラフィックをマーケティングチームにルーティングします。
- B. マーケティングアカウントの VPC に、仮想アプライアンスとして機能する Amazon EC2 インスタンスを作成します。マーケティングチームと各事業部の VPC の間に AWS Site-to-Site VPN 接続を作成します。必要に応じて NAT を実行します。
- C. AWS PrivateLink エンドポイントサービスを作成して、マーケティングアプリケーションを共有します。特定の AWS アカウントにサービスに接続するためのアクセス許可を付与します。プライベート IP アドレスを使用してアプリケーションにアクセスするために、他のアカウントでインターフェイス VPC エンドポイントを作成します。
- D. プライベートサブネット内のマーケティングアプリケーションの前に Network Load Balancer (NLB) を作成します。API Gateway API を作成します。Amazon API Gateway プライベート統合を使用して、API を NLB に接続します。API の IAM 認証を有効にします。他の事業部のアカウントへのアクセスを許可します。
■ 問題文の要件の概要
- 各事業部は個別のアカウントで独立した VPC を管理
- CIDR が重複しているため、VPC 間ルーティングが困難
- マーケティングのアプリに他部門がアクセスできるようにしたい
- 通信はすべてプライベート IP 経由とすること
- 運用オーバーヘッドを最小限に
✅ 正解の選択肢と解説
- 正解：C
C. AWS PrivateLink によるエンドポイント共有
- AWS PrivateLink を使えば、CIDR の重複に関係なく VPC 間の通信が可能
- マーケティング側で エンドポイントサービス（NLB背後） を作成し、
各事業部は Interface VPC Endpoint を自身の VPC に作成するだけで接続できる - すべて プライベート IP のみで通信が完結し、インターネット/NAT不要
- CIDR 重複問題を解消しつつ、構成変更が最小で済むため、最も低オーバーヘッド
❌ 不正解の選択肢の理由
A. VPC ピアリング + セカンダリ CIDR + NAT
- CIDR 重複のある VPC 間では ピアリングが機能しない
- セカンダリ CIDR を追加しても、ルート競合や NAT 構成の複雑さが増大
- VPCごとにルートテーブル・NATの個別設定が必要でオーバーヘッドが大きい
B. EC2 仮想アプライアンス + VPN
- Site-to-Site VPN は通常 オンプレと AWS 間の接続に用いるもの
- CIDR 重複のままでは 静的ルーティングが困難で、追加の NAT 必要
- EC2 仮想アプライアンスは 可用性・拡張性の設計・運用が煩雑
D. NLB + API Gateway プライベート統合
- API Gateway は HTTP/REST に限定される
- 社内アプリが TCP ベースの場合や非 HTTP 通信には対応不可
- API Gateway の同時接続制限や認証・アクセス制御設定が複雑化
■ SAP試験で押さえておくべきポイント
- AWS PrivateLink は CIDR 重複環境でも VPC 間通信が可能なサービス公開手段
- PrivateLink では サービス提供者が NLB を公開し、利用者が Interface Endpoint を作成
- すべてプライベート IP 通信で完結し、VPC ピアリング・VPN・NAT 不要
- VPC ピアリングは CIDR が重複すると使用不可な点を確実に押さえる
- API Gateway は HTTP プロトコル専用であり、ユースケースの適合性に注意
次の問題も準備でき次第お送りください。引き続き同様の形式で対応いたします。
以下は、問題4の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ある企業は、単一の AWS リージョン内のアプリケーションに Amazon Aurora PostgreSQL DB クラスターを使用しています。同社のデータベースチームは、すべてのデータベースのすべてのデータアクティビティを監視する必要があります。
この目標を達成できるソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. AWS Database Migration Service (AWS DMS) の変更データキャプチャ (CDC) タスクを設定します。Aurora DB クラスターをソースとして指定します。Amazon Kinesis Data Firehose をターゲットとして指定します。Kinesis Data Firehose を使用してデータを Amazon OpenSearch Service クラスターにアップロードし、さらに分析します。
- B. Amazon EventBridge でアクティビティストリームをキャプチャするために、Aurora DB クラスターでデータベースアクティビティストリーミングを開始します。AWS Lambda 関数を EventBridge のターゲットとして定義します。EventBridge からのメッセージを復号化し、さらに分析するためにすべてのデータベースアクティビティを Amazon S3 に公開するように Lambda 関数をプログラムします。
- C. Aurora DB クラスターでデータベースアクティビティストリーミングを開始して、アクティビティストリームを Amazon Kinesis Data Streams にプッシュします。Amazon Kinesis Data Firehose を構成して、Kinesis Data Streams を消費し、さらなる分析のために Amazon S3 にデータを配信します。
- D. AWS Database Migration Service (AWS DMS) の変更データキャプチャ (CDC) タスクを設定します。Aurora DB クラスターをソースとして指定します。Amazon Kinesis Data Firehose をターゲットとして指定します。Kinesis Data Firehose を使用して Amazon Redshift クラスターにデータをアップロードします。Amazon Redshift データでクエリを実行し、Aurora データベースのデータベースアクティビティを確認します。
■ 問題文の要件の概要
- 単一リージョンで稼働する Aurora PostgreSQL クラスター
- 要件：すべてのデータベースのすべてのデータアクティビティの監視
- 認証、DDL/DML、クエリ、接続、失敗なども含む
- リアルタイム性と包括的な可視化が求められる
✅ 正解の選択肢と解説
- 正解：C
C. Aurora Database Activity Streams + Kinesis Data Streams + Firehose + S3
- Database Activity Streams を有効化することで、Aurora 内のすべてのデータベース操作（接続、SQL 実行、失敗イベントなど）をリアルタイムで取得可能
- ストリームは Kinesis Data Streams に直接出力される
- Kinesis Data Firehose を介して S3 に安全に保存・保管でき、Athena などでクエリ分析可能
- 暗号化状態を保持したままアクティビティログを転送でき、セキュリティと運用性を両立
❌ 不正解の選択肢の理由
A. AWS DMS CDC + OpenSearch
- DMS の 変更データキャプチャ（CDC） は INSERT、UPDATE、DELETE のみ取得
- SELECT クエリ、ログインイベント、失敗操作などは取得不可
- 要件である「すべてのアクティビティ」に該当せず不十分
- 加えて OpenSearch までのパイプライン管理が必要で複雑
B. Activity Streams + EventBridge + Lambda
- Aurora の Activity Streams の出力先は EventBridge 非対応
- 公式には Kinesis Data Streams のみ対応
- Lambda を通して復号・処理するのはセキュリティとレイテンシーの面で不利
D. AWS DMS CDC + Redshift
- DMS は上記 A と同様にアクティビティログ全体を取得できない
- Redshift は分析に優れるが、DMS 経由では バッチ処理的でリアルタイム性に欠ける
■ SAP試験で押さえておくべきポイント
- Aurora Database Activity Streams は 完全な監査（全アクティビティ） を実現する唯一のマネージド機能
- 出力先は Amazon Kinesis Data Streams のみ
- さらに Kinesis Data Firehose → S3 → Athena や OpenSearch などで柔軟な分析が可能
- AWS DMS の CDC は変更（Insert/Update/Delete）のみで監査用途には不十分
- EventBridge や Redshift の適用可能範囲・制約も整理しておくこと
次の問題もあれば、引き続きどうぞ。全問この形式でサポートいたします。
以下は、問題5を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある企業が、VPC から出入りするトラフィックを検査するために、カスタムネットワーク分析ソフトウェアパッケージを実行したいと考えています。同社は、AWS CloudFormation を使用して、Auto Scaling グループ内の 3 つの Amazon EC2 インスタンス上にソリューションをデプロイしました。すべてのネットワークルーティングは、トラフィックを EC2 インスタンスに直接送るように設定されています。
分析ソフトウェアが動作を停止するたびに、Auto Scaling グループがインスタンスを置き換えます。インスタンスの置換が発生しても、ネットワークルートは更新されません。
この問題を解決する最適な手順の組み合わせを選択してください。(3 つ選択)
■ 選択肢（編集せずに出力）
- A. EC2 ステータスチェックメトリクスに基づいてアラームを作成し、Auto Scaling グループが障害が発生したインスタンスを置き換えます。
- B. CloudFormation テンプレートを更新して、EC2 インスタンスに Amazon CloudWatch エージェントをインストールします。アプリケーションのプロセスメトリクスを送信するように CloudWatch エージェントを構成します。
- C. CloudFormation テンプレートを更新して、EC2 インスタンスに AWS Systems Manager エージェントをインストールします。アプリケーションのプロセスメトリクスを送信するように Systems Manager エージェントを構成します。
- D. Amazon CloudWatch で、障害シナリオのカスタムメトリクスのアラームを作成します。Amazon Simple Notification Service (Amazon SNS) トピックにメッセージを公開するようにアラームを設定します。
- E. Amazon Simple Notification Service (Amazon SNS) メッセージに応答して、必要に応じてインスタンスに関連する操作（例: アプリケーションの終了、EC2 インスタンスの停止）を実行し、代替インスタンスを指すようにネットワークルートを更新する AWS Lambda 関数を作成します。
- F. CloudFormation テンプレートで、代替インスタンスが起動されたときにネットワークルートを更新する条件を記述します。
■ 問題文の要件の概要
- 分析ソフトウェアが動作停止 → Auto Scaling により置換
- しかしルートが更新されない → トラフィックが旧インスタンスに流れ続ける
- 解決には：
- ソフトウェア稼働監視
- 異常検知
- ルートの動的更新
✅ 正解の選択肢と解説
- 正解：B, D, E
B. CloudWatch エージェントでアプリのプロセスを監視
- EC2インスタンスにCloudWatchエージェントを導入することで、アプリケーションプロセスのメトリクス（稼働状況など）を監視可能。
- これにより、EC2自体が正常でもアプリが落ちたことを検知できる。
D. CloudWatch アラーム + SNS 通知
- CloudWatch メトリクス（Bで送信）を元にアラームを設定し、異常時に SNS 通知を発行。
- 後続の Lambda 処理などを起動するためのイベント駆動トリガーとなる。
E. SNS通知を受けてLambdaでルート更新
- SNS通知をトリガーに Lambda を実行し、ネットワークルートを新しい稼働中インスタンスに書き換える。
- これにより置き換え後もトラフィックが正しく流れる。
❌ 不正解の選択肢の理由
A. EC2ステータスチェックではプロセス異常は検出不可
- インスタンスのハード障害やネットワーク問題のみを検知対象とする。
- アプリが停止しても正常と判断されるため、置換されない／通知も飛ばない。
C. Systems Manager エージェントはプロセスメトリクス送信不可
- SSM エージェントはメトリクス送信用途ではなく、パッチ適用・SSM Run Commandなどが主。
- プロセス監視には CloudWatch エージェントが必要。
F. CloudFormation で条件分岐しても動的更新は不可
- CloudFormation はデプロイ時の構成定義ツールであり、Auto Scalingによるランタイム変化には反応しない。
- 置換イベント後のルート変更などは Lambda のような動的制御が必要。
■ SAP試験で押さえておくべきポイント
- プロセスレベルの障害検知には CloudWatch エージェント＋カスタムメトリクス
- CloudWatch アラーム → SNS → Lambda のイベント駆動構成は鉄板
- ルーティングの自動修復には Lambda でのルートテーブル操作が必要
- EC2のステータスチェックではアプリの異常は検知できない
- CloudFormationはランタイム制御用途には不適切
次の問題もこの形式で対応しますので、引き続きお送りください。
以下は、問題6を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
メディアストレージアプリケーションは、AWS Lambda 関数で処理するために Amazon S3 にユーザーの写真をアップロードします。アプリケーションの状態は Amazon DynamoDB のテーブルに保存されます。アップロードされた写真の一部が適切に処理されないという報告がユーザーから寄せられています。アプリケーション開発者はログを追跡し、何千人ものユーザーが同時に写真をアップロードしたときに Lambda で写真処理の問題が発生していることを発見しました。この問題は、Lambda の同時実行のクォータと、データ保存時の DynamoDB のパフォーマンスの結果です。
アプリケーションのパフォーマンスと信頼性を向上させる最適な手順の組み合わせを選択してください。 (2 つ選択)
■ 選択肢（編集せずに出力）
- A. DynamoDB テーブルの RCU を評価して調整します。
- B. DynamoDB テーブルの WCU を評価して調整します。
- C. Amazon ElastiCache レイヤーを追加して、Lambda 関数のパフォーマンスを向上させます。
- D. Amazon Simple Queue Service (Amazon SQS) キューと、Amazon S3 と Lambda 関数の間の再処理ロジックを追加します。
- E. S3 Transfer Acceleration を使用して、ユーザーに低レイテンシーを提供します。
■ 問題文の要件の概要
- 問題：写真の一部が処理されない
- 原因：
- Lambda の同時実行クォータ制限
- DynamoDB の書き込みパフォーマンス不足
- 目的：スパイク耐性と確実なデータ書き込みを実現し、信頼性向上
✅ 正解の選択肢と解説
- 正解：B（WCU 調整）、D（SQS 追加）
B. DynamoDB テーブルの WCU を評価して調整します。
- DynamoDB のWrite Capacity Units（WCU）不足が Lambda からの書き込み失敗の要因。
- WCU を増強するか、オンデマンドモードに変更することでスロットリングを回避。
- 書き込みエラーによる写真処理失敗を防げる。
D. SQS キューと再処理ロジックの追加
- Lambda 同時実行クォータのスパイク耐性を得るために S3 → SQS → Lambda の構成を導入。
- 一時的に SQS にイベントをバッファし、順次処理で Lambda 過負荷を回避。
- さらに デッドレターキュー（DLQ）や再処理ロジックも加えれば、信頼性が大きく向上。
❌ 不正解の選択肢の理由
A. DynamoDB の RCU を調整
- RCU（Read Capacity Unit）は読み取り専用設定。
- この問題は Lambda → DynamoDB への書き込み処理の失敗なので、RCU は無関係。
C. ElastiCache の導入
- ElastiCache は読み取り性能を改善するもの。
- 本ケースでは「書き込み性能」「同時実行」への対応が求められており、無関係。
E. S3 Transfer Acceleration の利用
- S3へのアップロード速度を向上させるもので、バックエンドのLambda/DynamoDB問題には無関係。
■ SAP試験で押さえておくべきポイント
- Lambda の同時実行制限を回避するには：
- SQSなどのメッセージングキューでバッファリング＋スパイク吸収
- DynamoDB の性能チューニングは：
- WCU：書き込み性能
- RCU：読み取り性能
- SQS + Lambda + DLQ は耐障害性を向上させるベストプラクティス
- ボトルネックをネットワーク（S3転送）と処理系（Lambda/DynamoDB）で混同しないこと
次の問題も同様に対応しますので、どうぞお送りください。
以下は、問題7を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある会社がスマートカーを製造しています。同社は車両データを収集するためにカスタムアプリケーションを使用しています。車両は MQTT プロトコルを使用してアプリケーションに接続します。同社はデータを 5 分間隔で処理します。その後、同社は車両テレマティクスデータをオンプレミスのストレージにコピーします。カスタムアプリケーションはこのデータを分析して異常を検出します。
データを送信する車両の数は常に増加しています。新しい車両は大量のデータを生成します。オンプレミスのストレージソリューションはピークトラフィックに合わせて拡張できないため、データ損失が発生します。同社はソリューションを最新化し、スケーリングの課題を解決するためにソリューションを AWS に移行する必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. AWS IoT Greengrass を使用して、車両データを Amazon Managed Streaming for Apache Kafka (Amazon MSK) に送信します。Apache Kafka アプリケーションを作成して、Amazon S3 にデータを保存します。Amazon SageMaker で事前トレーニング済みモデルを使用して、異常を検出します。
- B. AWS IoT Core を使用して車両データを受信します。Amazon S3 にデータを保存する Amazon Kinesis Data Firehose 配信ストリームにデータをルーティングするルールを設定します。配信ストリームから読み取り、異常を検出する Amazon Managed Service for Apache Flink アプリケーションを作成します。
- C. AWS IoT FleetWise を使用して車両データを収集します。Amazon Kinesis Data Streams にデータを送信します。Amazon Kinesis Data Firehose 配信ストリームを使用して、Amazon S3 にデータを保存します。AWS Glue に組み込まれた機械学習変換を使用して異常を検出します。
- D. Amazon MQ for RabbitMQ を使用して車両データを収集します。Amazon Kinesis Data Firehose 配信ストリームにデータを送信し、Amazon S3 にデータを保存します。Amazon Lookout for Metrics を使用して異常を検出します。
■ 問題文の要件の概要
- MQTT で車両から送信される大量データ
- データは 5 分間隔で処理
- オンプレミスではピークトラフィックに対応できずデータ損失
- スケーラブルかつ低運用負荷な AWS ソリューションへの移行が必要
✅ 正解の選択肢と解説
- 正解：B
B. AWS IoT Core + Kinesis Data Firehose + Flink
- AWS IoT Core：MQTTプロトコル対応の完全マネージドサービス。車両からのMQTTデータを直接受信できる。
- Kinesis Data Firehose：バッファリングやS3への5分間隔出力が自動。プロビジョニング不要。
- Amazon Managed Service for Apache Flink：Firehoseをソースにリアルタイム異常検出。マネージド環境でスケーリング対応済み。
→ 上記すべてがマネージドかつ自動スケーリング可能な構成で、運用オーバーヘッドが小さく、可用性も高い。
❌ 不正解の選択肢の理由
A. IoT Greengrass + Amazon MSK + SageMaker
- Greengrass はエッジ処理・推論向けであり、すでにMQTT送信機能のある車両には不要。
- Amazon MSK はスケーラビリティこそ高いが、クラスタ運用・プロビジョニング・スケール調整が必要。
- SageMaker は強力だが、自動化・簡易化されたリアルタイム処理という要件に対しては過剰設計で運用負荷が高い。
C. IoT FleetWise + Glue
- FleetWise はCANデータ等の抽象化に強みがあるが、導入と設定が煩雑。
- AWS Glue はバッチ処理用であり、5分間隔でのリアルタイム異常検出には適さない。
D. Amazon MQ for RabbitMQ + Lookout for Metrics
- Amazon MQ は MQTT をネイティブに扱えず、追加のブリッジや変換処理が必要。
- Lookout for Metrics は定型のメトリクス検知に向くが、生データを直接処理するにはETL構成が必要で手間がかかる。
■ SAP試験で押さえておくべきポイント
- IoTデバイスからのデータ取り込みは AWS IoT Core + Kinesis Firehose の組み合わせが最適解
- Kinesis Firehose はバッファ付き自動ストリーム転送サービス（S3やRedshift対応）
- リアルタイム処理には Amazon Managed Service for Apache Flink（旧 Kinesis Analytics）を活用
- 最小限の運用オーバーヘッドを求められたら、完全マネージド + 自動スケール構成を優先する
- Greengrass / MSK / FleetWise / Glue などは機能が強力な分、管理コストや導入ハードルも高くなる点に注意
引き続き、次の問題もお送りください。SAP試験対策として適切に整理いたします。
