はい！問題1を指定フォーマットで整理しました。
■問題文
ある企業が、オンプレミスの IoT プラットフォームを AWS に移行しています。このプラットフォームは、次のコンポーネントで構成されています。
・収集および処理されたすべての IoT データのデータストアとしての MongoDB クラスター
・Message Queuing Telemetry Transport (MQTT) を使用して、5 分ごとに IoT デバイスに接続し、データを収集するアプリケーション
・IoT データからレポートを生成するために定期的にジョブを実行するアプリケーション。ジョブの実行が完了するまでに 120 ～ 600 秒かかります。
・ウェブサーバー上で実行されるウェブアプリケーション。エンドユーザーはこのウェブアプリケーションを使用して、一般のユーザーがアクセスできるレポートを生成します。
同社は、パフォーマンスを維持しながら運用上のオーバーヘッドを削減するために、プラットフォームを AWS に移行する必要があります。
最も少ない運用オーバーヘッドでこれらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)
■選択肢
A：IoT デバイスを AWS IoT Core に接続してメッセージを公開します。メッセージを受信したときに実行される AWS IoT ルールを作成します。AWS Lambda 関数を呼び出すようにルールを設定します。デバイスメッセージデータを解析、変換し、データストアに保存するように Lambda 関数をプログラムします。
B：MongoDB クラスターを Amazon EC2 インスタンスに移行します。
C：AWS Lambda タスクを使用して AWS Step Functions ステートマシンを作成し、レポートを準備して Amazon S3 に書き込みます。レポートを提供するために、S3 オリジンを持つ Amazon CloudFront ディストリビューションを構成します。
D：Amazon EC2 インスタンスを使用して Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを設定し、レポートを準備します。レポートを提供するためのイングレスコントローラーを EKS クラスターに作成します。
E：MongoDB クラスターを Amazon DocumentDB (MongoDB 互換) に移行します。
F：AWS Lambda 関数を作成します。IoT デバイスに接続し、データを処理し、データをデータストアに書き込むように Lambda 関数をプログラムします。処理のためにメッセージを一時的に保存するように Lambda レイヤーを設定します。
■問題文の要件の概要
- オンプレミス IoT プラットフォームを AWS へ移行
- データ収集（MQTT 利用）をクラウドへ移行
- MongoDB データベースをマネージド化して運用負荷削減
- レポート生成（数分かかる）を効率的に実行
- 一般ユーザーが利用する Web レポートはスケーラブルかつ低運用コストで配信
■正解の選択肢と解説
正解：A, C, E
- A：IoT Core + IoT ルール + Lambda
→ IoT デバイスの MQTT 接続を AWS IoT Core にオフロード。IoT ルールで Lambda を呼び出し、処理・保存を行う。スケーラブルで運用負担が少ない。 - C：Step Functions + Lambda + S3 + CloudFront
→ レポート生成は長時間ジョブに対応できる Step Functions を活用。結果は S3 に保存し、CloudFront で配信することで運用管理不要・低レイテンシ。 - E：DocumentDB
→ MongoDB 互換のマネージドサービスであり、スケーリング・バックアップ・パッチ適用を自動化。運用負担を大幅に削減。
■不正解の選択肢の理由
- B：EC2 上に MongoDB
→ 自分で運用管理が必要（スケーリング、パッチ適用、バックアップ）。運用オーバーヘッドが高い。 - D：EKS + EC2
→ Kubernetes 管理やクラスター維持の負担が大きく、要件の「少ない運用オーバーヘッド」に反する。 - F：Lambda 単独で IoT デバイス接続
→ Lambda は長時間接続維持に不向き。MQTT は IoT Core を使うべきであり、Lambda レイヤーは一時保存用途ではない。
■SAP試験で押さえておくべきポイント
- IoT デバイス接続には IoT Core を利用（直接 Lambda 接続は不可）
- DocumentDB = MongoDB 互換マネージドDB → EC2 上の MongoDB より低運用コスト
- 長時間処理 = Step Functions を活用（120～600秒ジョブに最適）
- レポート配信は S3 + CloudFront を利用してスケーラブルかつ低コストに提供
- 「運用オーバーヘッド最小化」が問われる場合 → フルマネージド・サーバーレスを選択するのが基本戦略
この問題は 「AWSサービスの責務分担」と「マネージド/サーバーレスの選択」 を問う典型パターンですね。
次の問題も整理しますか？
はい！問題2を指定フォーマットで整理しました。
■問題文
ある企業はアプリケーションを AWS クラウドに移行しました。アプリケーションは、Application Load Balancer (ALB) の背後にある 2 つの Amazon EC2 インスタンスで実行されます。アプリケーションのデータは、追加の EC2 インスタンス上で実行される MySQL データベースに保存されます。アプリケーションによるデータベースの使用は読み取り負荷が高くなります。
アプリケーションは、各 EC2 インスタンスにアタッチされている Amazon Elastic Block Store (Amazon EBS) ボリュームから静的コンテンツをロードします。静的コンテンツは頻繁に更新されるため、各 EBS ボリュームにコピーする必要があります。
アプリケーションの負荷は 1 日を通して変化します。ピーク時には、アプリケーションはすべてのリクエストを処理できません。トレースデータによると、データベースがピーク時の読み取り負荷を処理できないことを示しています。
アプリケーションの信頼性を向上させるソリューションを選択してください。
■選択肢
A：アプリケーションをコンテナ化します。アプリケーションを Amazon Elastic Container Service (Amazon ECS) クラスターに移行します。アプリケーションをホストするタスクに AWS Fargate 起動タイプを使用します。静的コンテンツ用に新しい単一の EBS ボリュームを作成します。新しい EBS ボリュームを ECS クラスターにマウントします。ECS クラスターで AWS Application Auto Scaling を構成します。ECS サービスを ALB のターゲットとして設定します。Amazon RDS for MySQL マルチ AZ DB クラスターにデータベースを移行します。
B：アプリケーションを一連の AWS Lambda 関数に移行します。ALB のターゲットとして Lambda 関数を設定します。静的コンテンツ用に新しい単一の EBS ボリュームを作成します。新しい EBS ボリュームから読み取るように Lambda 関数を設定します。Amazon RDS for MySQL マルチ AZ DB クラスターにデータベースを移行します。
C：アプリケーションをコンテナ化します。アプリケーションを Amazon Elastic Container Service (Amazon ECS) クラスターに移行します。アプリケーションをホストするタスクに AWS Fargate 起動タイプを使用します。静的コンテンツ用に Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。EFS ファイルシステムを各コンテナにマウントします。ECS クラスターで AWS Application Auto Scaling を構成します。ECS サービスを ALB のターゲットとして設定します。リーダー DB インスタンスを使用してデータベースを Amazon Aurora MySQL Serverless v2 に移行します。
D：アプリケーションを一連の AWS Step Functions ステートマシンに移行します。ステートマシンを ALC のターゲットとして設定します。静的コンテンツ用に Amazon Elastic File System (Amazon EFS) ファイルシステムを作成します。EFS ファイルシステムから読み取るようにステートマシンを設定します。リーダー DB インスタンスを使用してデータベースを Amazon Aurora MySQL Serverless v2 に移行します。
■問題文の要件の概要
- 現状：EC2 + ALB + EC2 MySQL + EBS 静的コンテンツ
- 課題：
- 静的コンテンツの EBS 複製管理が非効率
- DB の 読み取り負荷が高すぎる → 信頼性低下
- 負荷は時間帯で変動 → スケーラビリティ確保が必要
- 目的：アプリの信頼性とスケーラビリティ改善
■正解の選択肢と解説
正解：C
- ECS + Fargate → サーバレスコンテナ運用、EC2 管理不要、負荷変動に応じて Auto Scaling。
- EFS → 複数タスク/コンテナから共有可能、静的コンテンツの更新同期が不要。
- Aurora MySQL Serverless v2 + リーダーインスタンス → 読み取り負荷に強く、自動スケーリング可能。DB 信頼性と可用性が向上。
→ この組み合わせが「静的コンテンツの一元管理」と「DB 読み取り性能の向上」に直結し、最も信頼性を高める。
■不正解の選択肢の理由
- A
- 単一 EBS を使うと依然として「EBS の単一アタッチ問題」が残る。共有アクセス不可。
- DB を RDS MySQL にしても、読み取り負荷への対応は不十分。
- B
- Lambda は ALB のターゲットにできるが、大規模 Web アプリ全体の移行には不適。
- EBS を Lambda が直接扱う設計は現実的でない。
- D
- Step Functions はワークフロー管理用であり、Web アプリの実行基盤には適さない。
- 静的コンテンツや DB 読み取り負荷の問題解決にはつながらない。
■SAP試験で押さえておくべきポイント
- 静的コンテンツ共有 → EFS（複数インスタンス/タスク間での共通ストレージに最適）
- DB 読み取り負荷対策 → Aurora リーダーインスタンス or Aurora Serverless v2
- コンテナ運用 → ECS + Fargate によるサーバレス化で運用負担を軽減
- EBS は単一インスタンス依存 → コンテンツ同期用途には不向き
この問題は 「EBS か EFS か」、「RDS MySQL か Aurora Serverless v2 か」 の使い分けを理解しているかを試していますね。
次の問題（問題3）も整理しますか？
はい！問題3を指定フォーマットで整理しました。
■問題文
ある大手企業では、AWS への依存度が時間とともに管理されない形で拡大してしまいました。その結果、さまざまな事業部門、プロジェクト、環境において、多数の個別の AWS アカウントを維持しています。この組織は、AWS アカウントを含む AWS クラウドのすべての要素を管理するために、クラウドセンターオブエクセレンス (CCoE) を設立しました。クラウドセンターオブエクセレンス (CCoE) チームが要件を集中させるために最初に達成する必要がある方法を選択してください。 (2 つ選択）
■選択肢
A：AWS Organizations を設定します。一括請求を有効にし、既存のすべての AWS アカウントを請求する管理アカウントにリンクします。すべての AWS リソースに、事業部門、プロジェクト、および環境に関する詳細のタグを付けます。Amazon Athena や Amazon QuickSight などのツールを使用してコストと使用状況レポートを分析し、事業部門ごとに請求の詳細を収集します。
B：AWS Marketplace を使用して、コスト管理ツールを選択してデプロイします。すべての AWS リソースに、事業部門、プロジェクト、および環境に関する詳細のタグを付けます。分析のために、AWS アカウントのすべての AWS のコストと使用状況レポートをこのツールに送信します。
C：すべての AWS アカウントのルートユーザーの認証情報を管理します。AWS リソースにアクセスする必要がある各ユーザーのアカウントに、AWS IAM ユーザーを割り当てます。各ユーザーに権限を割り当てる際に、最小特権のポリシーに従います。
D：AWS の管理アカウントを使用し、管理アカウント内に IAM ユーザーを作成します。他の AWS アカウントに IAM ロールを定義し、アカウントに必要な各機能をカバーします。各ロールに権限を割り当てる際の最小特権のポリシーに従い、IAM ユーザーが使用する必要のあるロールを引き受けることができるようにします。
E：すべての AWS リソースに、事業部門、プロジェクト、および環境に関する詳細のタグを付けます。すべての AWS のコストと使用状況レポートを中央の Amazon S3 バケットに送信し、Amazon Athena や Amazon QuickSight などのツールを使用して事業部門ごとに請求の詳細を収集します。
■問題文の要件の概要
- 企業全体で 多数の個別 AWS アカウントを乱立
- CCoE がクラウドガバナンスを集中管理する必要がある
- 最初にやるべきは：
- 請求・コストの統合管理（アカウント単位のコスト見える化）
- IAM の統合管理（アカウント間のアクセス制御の標準化）
■正解の選択肢と解説
正解：A, D
- A：AWS Organizations + 一括請求 + タグ付け + コスト分析
- AWS Organizations によるアカウント統合管理が第一歩。
- 一括請求でコストを集中化し、Athena / QuickSight による可視化で部門ごとの使用状況を管理可能。
- タグ付けはコスト配分・分析の基盤になる。
- D：管理アカウントに IAM ユーザー作成 + 他アカウントにクロスアカウントロール
- 各部門がバラバラに IAM 管理をするのではなく、中央アカウントからロールを利用することで統制が取れる。
- 最小権限ポリシーを守りつつ、アカウント間アクセスを効率化。
■不正解の選択肢の理由
- B：Marketplace ツール導入
→ 外部ツール依存であり、AWS ネイティブ機能（Organizations, CUR）より初動としては不適切。 - C：各アカウントで IAM ユーザー作成
→ IAM の分散管理となり、統制が取れない。スケーラビリティに欠ける。 - E：タグ付け + S3 CUR 集約
→ コスト分析手法としては有効だが、アカウント統合管理や IAM ガバナンスを確立しないと本質的な課題解決にならない。
■SAP試験で押さえておくべきポイント
- AWS Organizations が複数アカウント統制の出発点
- Consolidated Billing でコストを一元化
- IAM ロールによるクロスアカウントアクセス がベストプラクティス（IAM ユーザー乱立はNG）
- タグ付け + CUR + Athena/QuickSight でコスト配分を可視化
- CCoE の役割は「ガバナンス・セキュリティ・コスト管理の標準化」
👉 この問題は **「複数アカウント管理の初動」**を問う典型例ですね。
次の問題（問題4）も整理しましょうか？
了解しました！問題4を指定フォーマットで整理しました。
■問題文
ある企業では、レガシーアプリケーションをオンプレミスのデータセンターから AWS に移行しています。このアプリケーションは、1 台のアプリケーションサーバーと Microsoft SQL Server データベースサーバーで構成されています。各サーバーは VMware VM 上にデプロイされており、複数の接続されたボリュームで 500 TB のデータを消費します。同社は、最も近い AWS リージョンからオンプレミスのデータセンターへ 10 Gbps の AWS Direct Connect 接続を確立しています。Direct Connect 接続は現在、他のサービスで使用されていません。ダウンタイムを最小限に抑えてアプリケーションを移行するために、どの手順の組み合わせを実行する必要がありますか？ (2 つ選択）
■選択肢
A：VM Import/Export を使用して、アプリケーションサーバーの VM をインポートします。
B：VM イメージを AWS Snowball Edge Storage Optimized デバイスにエクスポートします。
C：Dump コマンドを使用して、データベースサーバーの VM を AWS に移行します。
D：AWS Application Migration Service (AWS MGN) レプリケーションジョブを使用して、アプリケーションサーバーの VM を AWS に移行します。
E：AWS Database Migration Service (AWS DMS) レプリケーションインスタンスを使用して、データベースを Amazon RDS DB インスタンスに移行します。
■問題文の要件の概要
- 移行対象：アプリケーションサーバー（VM）＋ SQL Server データベース
- データ量：500TB
- 利用可能なネットワーク：専用の 10Gbps Direct Connect
- 移行要件：ダウンタイム最小化
■正解の選択肢と解説
正解：D, E
- D：AWS MGN を使ったアプリケーションサーバー移行
- MGN はVMwareからAWSへのレプリケーションを継続的に行い、切替時のみ短時間ダウンタイムで移行できる。
- VM Import/Export のような静的インポートではなく、差分同期を利用できるためダウンタイムが最小限になる。
- E：AWS DMS を使ったデータベース移行
- DMS は継続的レプリケーションをサポートし、移行中もソースDBを稼働状態に保てる。
- フルロード＋CDC（Change Data Capture）により、移行時の停止時間を最小化できる。
- SQL Server → RDS への移行シナリオに最適。
■不正解の選択肢の理由
- A：VM Import/Export
→ 静的なVMコピーであり、大量データ（500TB）かつダウンタイム最小化要件には不向き。 - B：Snowball Edge
→ 大規模データ移行には有効だが、発送・処理時間が必要で「ダウンタイム最小化」の要件に合わない。 - C：Dump コマンド
→ 手動移行で長時間ダウンタイムが必要。運用要件に適さない。
■SAP試験で押さえておくべきポイント
- サーバー移行：オンプレVM → AWS は AWS MGN が推奨（差分レプリケーションでダウンタイム最小）。
- データベース移行：商用DB（Oracle, SQL Serverなど） → AWS は DMS を利用（フルロード＋CDCで最小ダウンタイム）。
- Snowball / VM Import/Export は「一括転送」「長期停止可」なケースでのみ利用。
- 移行戦略問題は「ダウンタイム制約」「データ量」「ネットワーク帯域」「既存接続有無」を軸に判断する。
👉 この問題は **「最小ダウンタイム移行パターン」**の典型問題ですね。
次の問題（問題5）も整理しますか？
了解しました！問題5を指定フォーマットで整理しました。
■問題文
あるライフサイエンス企業では、データ解析のワークフローを管理するためのオープンソースツールと、オンプレミスデータセンターのサーバ上で稼働する Docker コンテナを組み合わせて、ゲノムデータの処理を行っています。シーケンスデータを生成し、ローカルストレージエリアネットワーク (SAN) に保存した後、データを処理します。研究開発チームは容量の問題に直面しており、AWS 上のゲノミクス分析プラットフォームを再構築し、ワークロードの需要に基づいてスケーリングし、所要時間を数週間から数日に短縮することを決定しました。同社は、高速の AWS Direct Connect 接続を利用しています。シーケンサーは各ゲノムに対して約 200 GB のデータを生成しますが、理想的な計算能力では、個々のジョブがデータを処理するのに数時間かかることがあります。最終結果は、Amazon S3 に保存されます。同社では、1 日に 10～15 件のジョブリクエストを想定しています。これらの要件を満たすソリューションを選択してください。
■選択肢
A：AWS DataSync を使用して、シーケンスデータを Amazon S3 に転送します。S3 イベント通知を使用して、AWS Step Functions のワークフローを開始する AWS Lambda 関数をトリガーします。Amazon Elastic Container Registry (Amazon ECR) に Docker イメージを保存し、AWS Batch をトリガーしてコンテナを実行し、シーケンスデータを処理します。
B：AWS Data Pipeline を使用して、シーケンスデータを Amazon S3 に転送します。S3 イベント通知を使用して、Amazon EC2 Auto Scaling グループをトリガーし、データを処理するために Docker コンテナを実行するカスタム AMI EC2 インスタンスを起動します。
C：AWS Storage Gateway ファイルゲートウェイを使用して、シーケンスデータを Amazon S3 に転送します。S3 イベント通知を使用して、Docker コンテナを実行している Amazon EC2 インスタンス上で実行される AWS Batch ジョブをトリガーしてデータを処理します。
D：定期的にスケジュールされた AWS Snowball Edge デバイスを使用して、シーケンスデータを AWS に転送します。AWS が Snowball Edge デバイスを受信し、データが Amazon S3 に読み込まれると、S3 イベント通知を使用して AWS Lambda 関数をトリガーし、データを処理します。
■問題文の要件の概要
- ゲノム解析用の 大容量データ処理基盤をAWSに再構築したい
- データサイズ：各ジョブ約200GB、1日10～15件
- 高速Direct Connectを利用可能
- ワークロードに応じてスケーリングし、所要時間を数週間 → 数日に短縮したい
- 最終結果は Amazon S3 に保存
■正解の選択肢と解説
正解：A
- AWS DataSync + Amazon S3
- SANからDirect Connect経由で高速にS3へデータ転送可能。大容量のゲノムデータに最適。
- S3 イベント通知 + Lambda + Step Functions
- データ到着をトリガーにワークフローを自動実行。解析処理のオーケストレーションにStep Functionsを活用。
- ECR + AWS Batch
- 既存のDockerイメージをECRに格納し、AWS Batchが必要に応じてスケールアウトして処理。大規模ジョブの並列実行に最適。
この組み合わせにより、大規模データの高速転送・サーバレスオーケストレーション・大規模並列処理が実現でき、数週間 → 数日への短縮が可能。
■不正解の選択肢の理由
- B：Data Pipeline + EC2 Auto Scaling
→ Data Pipelineは非推奨であり、EC2ベースは運用オーバーヘッドが大きい。大規模スケーリングには不向き。 - C：Storage Gateway + EC2 Batch
→ Storage Gatewayはオンプレキャッシュ用途であり、大量転送にはDataSyncが適切。さらにS3イベントから直接Batchはトリガーできない。 - D：Snowball Edge
→ 定期的な物理転送は時間がかかり、日々のデータ転送（200GB × 複数件/日）には不向き。リアルタイム性要件に合わない。
■SAP試験で押さえておくべきポイント
- 大容量データ転送：オンライン（Direct Connect + DataSync）とオフライン（Snowball系）を正しく使い分ける。
- HPCワークロード：DockerコンテナはECRに保存し、AWS Batchでスケーラブルに実行。
- ワークフロー管理：Step Functionsで処理フローを自動化。
- イベント駆動：S3イベント → Lambda → Step Functions という構成は代表的なサーバレスパターン。
👉 この問題は「HPC + Genomics解析の典型パターン」を問う出題ですね。
次（問題6）も整理しますか？
了解しました！問題6を指定フォーマットで整理しました。
■問題文
ある企業は、書き込みの多いモバイルアプリケーションを動かすために、Amazon API Gateway、AWS Lambda、Amazon DynamoDB を採用しています。アプリケーションは順調に拡張されましたが、Lambda の利用料が予想以上に高くなったため、支出が大幅に増加しました。このアプリケーションの使用は不規則ですが、毎月 20％ ずつ増加しています。ソリューションアーキテクトは、現在の Lambda 関数の平均実行時間が 4.5 分であることを確認しています。遅延時間の大部分は、オンプレミスの 3 TB MySQL データベースサーバーへの高レイテンシーネットワーク呼び出しによるものです。VPC は VPN 経由でアクセスされるため、Lambda 関数は 5 分のタイムアウトで設定されています。
現在のアーキテクチャのコストを最小限に抑える最適な方法を選択してください。
■選択肢
A：MySQL データベースサーバーを Amazon RDS for MySQL マルチ AZ に移行します。
API Gateway で API キャッシュを有効にして、Lambda 関数の呼び出しを最小にします。
AWS Lambda 関数のパフォーマンスを監視し、許容できる実行時間を維持しながら、タイムアウトとメモリ特性を段階的に減らします。
DynamoDB Auto Scaling を有効にします。
B：MySQL データベースサーバーを Amazon RDS for MySQL マルチ AZ に移行します。
Amazon API Gateway のレスポンスの Amazon CloudFront キャッシングを有効にして、Lambda 関数の呼び出し回数を最小化します。
AWS Lambda 関数のパフォーマンスを監視し、許容できる実行時間を維持しながら、タイムアウトとメモリ特性を段階的に減らします。
頻繁にアクセスされるレコードに対して、DynamoDB Accelerator と DynamoDB Auto Scaling を有効にします。
C：VPN の代わりに AWS Direct Connect を使用して、オンプレミスの MySQL データベースへのネットワークレイテンシーを最小にします。
Lambda 関数の呼び出しを最小限に抑えるために、モバイルアプリケーションでローカルキャッシュを有効にする必要があります。
Lambda 関数のパフォーマンスを監視し、許容できる実行時間を維持しながら、タイムアウトとメモリ特性を段階的に減らします。
DynamoDB のよくアクセスされるレコードを Amazon ElastiCache にオフロードします。
D：VPN の代わりに AWS Direct Connect を使用して、オンプレミスの MySQL データベースへのネットワークレイテンシーを最小にします。
API Gateway の応答データを Amazon CloudFront にキャッシュします。
AWS Lambda の代わりに、Amazon EC2 リザーブドインスタンスを使用します。
Amazon EC2 で Auto Scaling を有効にし、ピーク時にスポットインスタンスを使用します。
ターゲット消費を制御するために、 DynamoDB Auto Scaling を有効にします。
■問題文の要件の概要
- モバイルアプリは API Gateway + Lambda + DynamoDB を利用
- Lambda 実行時間が長く（平均4.5分）、コストが急増
- 主因は オンプレ MySQL への高レイテンシアクセス
- 毎月20%ずつ利用増加 → コスト最適化が急務
- 解決策は「オンプレDB依存を解消し、Lambda処理時間を短縮」すること
■正解の選択肢と解説
正解：A
- MySQL → Amazon RDS (Multi-AZ)
→ オンプレから移行することで高レイテンシ問題を解消。Lambda 実行時間短縮に直結し、コスト削減効果が大きい。 - API Gateway キャッシュ
→ 頻繁なリクエストをキャッシュし、Lambda 呼び出し回数を削減。 - Lambda のリソース調整
→ 実行時間短縮後、タイムアウトやメモリを適切に調整し、コスト最適化。 - DynamoDB Auto Scaling
→ ワークロードの変動に合わせて自動スケーリングし、コスト効率化。
→ 全体として、オンプレDB依存を排除して Lambda 実行時間を削減し、かつキャッシュ・スケーリングで効率化を図るのが最適解。
■不正解の選択肢の理由
- B：CloudFrontキャッシュやDAXの導入は可用性・性能改善には有効だが、DAX導入で追加コストが発生し、コスト削減目的には合わない。
- C：Direct Connect導入はレイテンシ改善にはなるが、費用がかかり、コスト削減とは逆行する。ElastiCacheも追加コスト増。
- D：EC2 RI/スポット利用は長時間稼働型には有効だが、このケースでは不規則な利用パターンに合わない。Direct Connectも不要なコスト増。
■SAP試験で押さえておくべきポイント
- コスト削減の基本：
- 処理時間を短縮する（レイテンシ削減＝Lambda課金時間削減）
- 不要な呼び出しを減らす（APIキャッシュ活用）
- 適切なリソースサイズに調整する（Lambdaのメモリ・タイムアウト）
- オンプレ依存からAWSマネージドサービスへ移行：
- 高レイテンシのオンプレDB依存はコスト高＆性能劣化要因
- AWS RDS/Aurora に移行することで可用性・性能・コスト効率を改善
- 試験対策の観点：
- 「Direct Connect」や「ElastiCache」などは性能改善には有効だが、問題が「コスト削減」に焦点を当てている場合は不正解となるケースが多い。
👉 この問題は「Lambdaコスト高騰の原因がオンプレDB依存であることを見抜けるか」を問う典型的なシナリオです。
次（問題7）も整理しますか？
了解しました！問題7を指定フォーマットで整理しました。
■問題文
企業は、Amazon S3 バケットでの認証の問題により、個人情報の侵害に直面しました。情報セキュリティチームは、アクセスをさらに制限するために、バケットポリシーを強化しました。さらに、将来の攻撃に備えるためには、次のニーズを満たす必要があります。
- バケットオブジェクトにアクセスしようとしている外部 IP アドレスを特定します。
- バケットのセキュリティポリシーが変更されたときに通知を受け取ります。
- ポリシーの変更を自動的に修正します。
ソリューションアーキテクトはどの戦術を使用する必要がありますか ?
■選択肢
A：Amazon OpenSearch Service と Kibana で S3 アクセスログを使用し、外部 IP アドレスを識別します。Amazon Inspector の評価テンプレートを使用して、S3 バケットポリシーの変更を自動的に修正します。アラートには Amazon SNS を使用します。
B：外部 IP アドレスを識別するために、S3 アクセスログで Amazon Athena を使用します。AWS Systems Manager オートメーションで AWS Config ルールを使用し、S3 バケットポリシーの変更を自動的に修正します。アラートには、AWS Config ルールで Amazon SNS を使用します。
C：アクセスパターンと外部 IP アドレスを識別するために、S3 バケットで Amazon Macie を使用します。AWS Lambda と Macie を使用して、S3 バケットポリシーの変更を自動的に修正します。アラートには Macie 自動アラート機能を使用します。
D：外部 IP アドレスを識別するために、CloudWatch フィルターと Amazon CloudWatch Logs を使用します。AWS Lambda と一緒に Amazon EventBridge (Amazon CloudWatch Events) ルールを使用して、S3 バケットポリシーの変更を自動的に修正します。アラートには、Amazon EventBridge (Amazon CloudWatch Events) ルールで Amazon SES を使用します。
■問題文の要件の概要
- 外部からのアクセスIPを特定する必要あり → S3アクセスログ解析が必要
- ポリシー変更を検知し通知 → AWS Config + SNS
- ポリシー変更を自動修復 → Systems Manager Automation で修復ランブック実行
■正解の選択肢と解説
正解：B
- Athena × S3アクセスログ：外部IPを効率的に検索可能。サーバーアクセスログを保存し、Athenaでクエリを実行するのが標準的。
- AWS Config ルール + SNS：バケットポリシーの変更を検出し、違反時に通知。
- Systems Manager Automation：Configルール違反をトリガーに自動修復が可能（例：ポリシーをセキュアな状態に戻す）。
→ セキュリティ要件「識別・通知・自動修復」を満たす唯一の統合ソリューション。
■不正解の選択肢の理由
- A：Inspectorは脆弱性スキャン用サービスであり、S3ポリシー修復には非対応。OpenSearchはオーバーエンジニアリング。
- C：Macieは機密データ検出サービスであり、外部IPやポリシー変更修復は担当外。
- D：CloudWatch LogsはS3アクセスログを直接収集できず、SESによる通知も適切ではない。
■SAP試験で押さえておくべきポイント
- S3アクセスログ解析 → Athena がベストプラクティス
- Configルール → リソースポリシー変更検知 & 非準拠検出
- Systems Manager Automation → Config違反を自動修復する仕組み
- SNS通知 → セキュリティイベントのアラート手段
👉 「監査・検知・修復」の流れを統合的に構築できる組み合わせを選べるかが問われる問題です。
この問題は セキュリティ運用自動化 (S3 + Config + Systems Manager) の組み合わせを覚えるのが重要ですね。
次（問題8）も整理しますか？
