Uncategorized

#8

 

■ 問題文（文字列を編集せずに出力）

業界の規制を遵守するために、ソリューションアーキテクトは、企業の重要なデータを、企業の本社がある米国を含む複数のパブリック AWS リージョンに保存するソリューションを設計する必要があります。ソリューションアーキテクトは、AWS に保存されたデータへのアクセスを、企業のグローバル WAN ネットワークに提供する必要があります。セキュリティチームは、このデータにアクセスするトラフィックがパブリックインターネットを通過しないようにすることを義務付けています。

要件を満たし、コスト効率に優れた高可用性ソリューションの最適な設計を選択してください。

■ 選択肢（正解を伏せてそのまま出力）

A.
本社から使用中のすべての AWS リージョンへの AWS Direct Connect 接続を確立します。会社の WAN を使用して本社にトラフィックを送信し、次にそれぞれの DX 接続に接続してデータにアクセスします。

B.
本社から AWS リージョンに 2 つの AWS Direct Connect 接続を確立します。会社の WAN を使用して、DX 接続経由でトラフィックを送信します。リージョン間 VPC ピアリングを使用して、他の AWS リージョンのデータにアクセスします。

C.
本社から AWS リージョンに 2 つの AWS Direct Connect 接続を確立します。会社の WAN を使用して、DX 接続経由でトラフィックを送信します。AWS トランジット VPC ソリューションを使用して、他の AWS リージョンのデータにアクセスします。

D.
本社から AWS リージョンに 2 つの AWS Direct Connect 接続を確立します。会社の WAN を使用して、DX 接続経由でトラフィックを送信します。Direct Connect Gateway を使用して、他の AWS リージョンのデータにアクセスします。

■ 問題文の要件の概要

  • 米国を含む複数の パブリック AWS リージョンにまたがるデータ配置
  • グローバル WAN ネットワークから AWS にプライベートアクセスが必要
  • パブリックインターネットを経由しない通信経路
  • コスト効率と高可用性

■ 正解の選択肢と解説

正解：D

Direct Connect Gateway を使用することで、1つの AWS Direct Connect 接続で複数の AWS リージョンの VPC にプライベートに接続可能。これにより、複数の Direct Connect をリージョンごとに用意する必要がなく、コスト効率・可用性の両方を確保できます。

加えて、Direct Connect を経由する通信はパブリックインターネットを経由しないため、セキュリティ要件にも合致しています。

■ 不正解の選択肢の理由

  • A.
    　各リージョンに Direct Connect を個別に設けるのは コスト・管理面で非効率。マルチリージョン対応を目的とするなら、Direct Connect Gateway を使うべき。
  • B.
    　リージョン間 VPC ピアリングは、VPC同士をプライベートで接続できるが、オンプレミス→AWS間の接続には使えず、WAN経由のトラフィックを他リージョンに流せない。
  • C.
    　Transit VPC ソリューションは、サードパーティ仮想アプライアンスを経由するためコストが高く、管理も煩雑。また、AWSは代替としてTransit Gatewayの利用を推奨しており、SAP試験においては非推奨な設計。

■ SAP試験で押さえておくべきポイント

  • AWS Direct Connect Gatewayは、複数リージョンにまたがる VPC にプライベートアクセスを提供できるベストプラクティス構成。
  • パブリックインターネットを経由しない接続が求められたら、**Direct Connect（+ Gateway）**または VPN over DXを検討。
  • コスト効率を求められる場合、物理的な DX を各リージョンに構築するよりも、一拠点＋DXGWの拡張構成が理想解。
  • VPC ピアリングや Transit VPC などの旧来アーキテクチャでは要件を満たせない場合が多い。

次の問題もあれば、引き続きこの形式で解説いたします。

以下は、提供いただいた SAP試験・問題2 に関する完全な分析・整理です。

■問題文（文字列を編集せずに出力）

ある企業が、Amazon Aurora MySQL DB クラスターを既存の AWS アカウントから同じ AWS リージョンの新しい AWS アカウントに移行したいと考えています。両方のアカウントは、AWS Organizations の同じ組織のメンバーです。

同社は、新しいデータベースへの DNS カットオーバーを実行する前に、データベースサービスの中断を最小限に抑える必要があります。

この要件を満たす移行戦略を選択してください。 (2 つ選択)

■選択肢（正解がどれかは伏せて出力）

A.
既存の Aurora データベースのスナップショットを作成します。スナップショットを新しい AWS アカウントと共有します。スナップショットから新しいアカウントに Aurora DB クラスターを作成します。

B.
新しい AWS アカウントに Aurora DB クラスターを作成します。AWS Database Migration Service (AWS DMS) を使用して、2 つの Aurora DB クラスター間でデータを移行します。

C.
AWS Backup を使用して、既存の AWS アカウントから新しい AWS アカウントに Aurora データベースのバックアップを共有します。スナップショットから新しい AWS アカウントに Aurora DB クラスターを作成します。

D.
新しい AWS アカウントに Aurora DB クラスターを作成します。AWS Application Migration Service を使用して、2 つの Aurora DB クラスター間でデータを移行します。

■問題文の要件の概要

要件内容
対象データAurora MySQL DBクラスター（同一リージョン）
アカウント構成同一 AWS Organizations 内の異なるアカウント
中断要件データベースのサービス中断を最小限に抑えたい
解決策の条件DNSカットオーバー前に新DBを準備し、移行作業を分割・段階的に行える方法が望ましい

■正解の選択肢と解説

✅ A：スナップショットの共有 + 復元

  • Auroraのスナップショット共有機能は、異なるAWSアカウント間でのデータベース移行に最適。
  • 事前にスナップショットを共有しておけば、新アカウントでクラスター作成後にDNSを切り替えるだけで済む。
  • 一時的な停止（カットオーバー時）以外はダウンタイムなし。

✅ B：AWS DMSを使ったオンライン移行

  • AWS Database Migration Service (DMS) を使うことで、移行元Auroraと移行先Aurora間でリアルタイムの変更レプリケーションが可能。
  • 本番環境のアプリケーションを停止せずに段階的に移行を進められ、DNSの切り替え時のみに短時間の停止で済む。

■不正解の選択肢の理由

❌ C：AWS Backup 経由の共有

  • AWS BackupではAuroraのスナップショットを他アカウントと共有できない。
  • Auroraのアカウント間スナップショット共有は、RDS/Aurora固有の機能により実現される。
  • Backup経由の移行は不可。

❌ D：AWS Application Migration Service 使用

  • Application Migration Service (MGN) はEC2ベースの物理・仮想マシンの移行が対象で、AuroraなどのマネージドDBは対象外。
  • データベース移行にはDMSやスナップショットの利用が前提。

■SAP試験で押さえておくべきポイント

観点ポイント
アカウント間移行Auroraのスナップショット共有が可能。Organizationsメンバー間では簡易に共有できる。
最小ダウンタイムの移行DMSでリアルタイムレプリケーション → DNS切り替えだけで本番移行可。
AWS Backup vs スナップショット共有AWS BackupはAuroraに対応していても、スナップショット共有機能を使う必要がある。
MGNの用途EC2などのOSレベルVM移行用。RDS/AuroraなどのマネージドDBは対象外。

次の問題があれば、引き続き同様の形式で解説いたします。

以下は、SAP試験・問題3 に関する詳細な解説です。

■ 問題文（文字列を編集せずに出力）

ある企業が、オンプレミスのインフラストラクチャと AWS の間に専用接続を確立したいと考えています。同社は、アカウント VPC に 1 Gbps の AWS Direct Connect 接続を設定しています。このアーキテクチャには、複数の VPC とオンプレミスのインフラストラクチャを接続するための Transit Gateway と Direct Connect ゲートウェイが含まれています。

同社は、Direct Connect 接続を使用して、トランジット VIF 経由で VPC リソースに接続する必要があります。

これらの要件を満たす手順の組み合わせを選択してください。(2 つ選択)

■ 選択肢（正解がどれかは伏せて出力）

A.
1 Gbps の Direct Connect 接続を 10 Gbps に更新します。

B.
オンプレミスネットワークのプレフィックスをトランジット VIF 上でアドバタイズします。

C.
AWS Direct Connect ゲートウェイからオンプレミスネットワークへの VPC プレフィックスをトランジット VIF 上でアドバタイズします。

D.
Direct Connect 接続の MACsec 暗号化モード属性を must_encrypt に更新します。

E.
MACsec 接続関連付けキー名 / 接続関連付けキー (CKN/CAK) のペアを Direct Connect 接続に関連付けます。

■ 問題文の要件の概要

要件内容
接続形態オンプレミス ↔ AWS 間の専用接続（AWS Direct Connect）
既存構成Transit Gateway + Direct Connect Gateway を使用、1Gbps DX
技術的要件Transit VIF 経由で複数の VPC リソースにアクセス
求められること正しくルートをアドバタイズすることによる接続確立

■ 正解の選択肢と解説

✅ B. オンプレミスネットワークのプレフィックスをトランジット VIF 上でアドバタイズ

  • オンプレミスからのルート情報を AWS に通知する必要があります。
  • オンプレ側→AWSへのトラフィックが許可されるルートを形成するために、この手順は必須です。

✅ C. Direct Connect Gateway からオンプレミスネットワークへの VPC プレフィックスをアドバタイズ

  • AWS 側（VPC）からオンプレミスへルートを流す必要があります。
  • 双方向通信を実現するためには、VPC側のプレフィックスも通知する必要があり、Transit VIF を通じてアドバタイズします。

■ 不正解の選択肢の理由

❌ A. 1Gbps → 10Gbps へアップグレード

  • 帯域幅の増加にはつながるが、接続構成やルーティングには直接関係ない。
  • 問題の焦点は接続確立であり、速度は無関係。

❌ D. MACsec 暗号化モードを must_encrypt に更新

  • セキュリティ強化の設定であり、VIF 経由の接続ルーティング要件には関係しない。
  • この問題では暗号化の有無は問われていない。

❌ E. MACsec CKN/CAK を関連付け

  • 同様に、MACsec に関する設定は今回のルーティング手順と無関係。
  • セキュリティ設定を行っても、アドバタイズや接続性は確立されない。

■ SAP試験で押さえておくべきポイント

項目説明
Transit VIF複数VPCとオンプレミスを接続する場合、Transit VIF + DXGW + TGWの構成が推奨。
BGP アドバタイズの役割双方向通信には、オンプレ→AWS（オンプレプレフィックス）とAWS→オンプレ（VPCプレフィックス）両方をアドバタイズする必要がある。
接続速度は設計要件と一致していなければならないが、ルーティングの手順には関係ない
MACsec設定は暗号化用途問題でセキュリティ要件がある場合にのみ検討対象となる（この問題では不要）。

次の問題も、同様に詳細に解説いたします。送信をお待ちしています。

以下は、SAP試験・問題4 に関する詳細な解説です。

■問題文（文字列を編集せずに出力）

ある企業は、インターネットに接続されていない遠隔地での実験からデータを収集する必要があります。実験中、ローカルネットワークに接続されたセンサーは、1 週間で 6 TB のデータを独自のフォーマットで生成します。センサーは、定期的に FTP サーバーにデータファイルをアップロードするように設定できますが、センサーは独自の FTP サーバーを持っていません。また、センサーは他のプロトコルにも対応していません。同社は、データを一元的に収集し、実験後できるだけ早く AWS クラウドのオブジェクトストレージにデータを移動する必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢（正解がどれかは伏せて出力）

A.
AWS Snowball Edge Compute Optimized デバイスを注文します。デバイスをローカルネットワークに接続します。AWS DataSync をターゲットバケット名で構成し、NFS 経由でデータをデバイスにアンロードします。実験後、デバイスを AWS に返却して、データを Amazon S3 にロードできるようにします。

B.
Amazon Linux 2 AMI を含む AWS Snowcone デバイスを注文します。デバイスをローカルネットワークに接続します。デバイス上で Amazon EC2 インスタンスを起動します。各センサーから定期的にデータをダウンロードするシェルスクリプトを作成します。実験後、デバイスを AWS に返却して、データを Amazon Elastic Block Store (Amazon EBS) ボリュームとしてロードできるようにします。

C.
Amazon Linux 2 AMI を含む AWS Snowcone デバイスを注文します。デバイスをローカルネットワークに接続します。デバイス上で Amazon EC2 インスタンスを起動します。EC2 インスタンスに FTP サーバーをインストールして構成します。EC2 インスタンスにデータをアップロードするようにセンサーを設定します。実験後、デバイスを AWS に返却して、データを Amazon S3 にロードできるようにします。

D.
AWS Snowcone デバイスを注文します。デバイスをローカルネットワークに接続します。Amazon FSx を使用するようにデバイスを構成します。デバイスにデータをアップロードするようにセンサーを構成します。アップロードされたデータを Amazon S3 バケットと同期するように、デバイス上で AWS DataSync を構成します。デバイスを AWS に返却して、データを Amazon Elastic Block Store (Amazon EBS) ボリュームとしてロードできるようにします。

■問題文の要件の概要

要件内容
ネットワークオフライン（インターネット未接続の遠隔地）
プロトコルセンサーは FTP のみ対応
データ量1週間で6TB
処理条件ローカルに収集 → AWS S3へ迅速に転送
センサー要件自分で FTP サーバーを持たないため、受信側に FTP サーバーが必要

■正解の選択肢と解説

✅ C. Snowcone + EC2 + FTPサーバー構成

  • センサーは FTP のみサポート → 受信側に FTP サーバーが必須。
  • AWS Snowcone デバイスは EC2 を起動可能 → FTP サーバー構築が可能。
  • オフライン環境でデータを受け取り、実験後デバイス返却で S3 へのオフライン取り込みが可能。
  • 実際の現場に即した、堅牢かつAWS推奨構成。

■不正解の選択肢の理由

❌ A. Snowball Edge + NFS + DataSync

  • センサーは FTP のみ → NFS 経由のデータアンロードは非対応。
  • DataSync はオンライン転送前提が多く、今回の要件（オフライン＋FTP）に合致しない。

❌ B. Snowcone + EC2 + シェルスクリプトでダウンロード

  • センサー側は「FTPサーバーにアップロードする」設定しかできない。
  • EC2で定期的に取得（pull型）するスクリプトは、センサーのpush型FTP仕様と矛盾。

❌ D. Snowcone + FSx + DataSync

  • FSxはNFSやSMBの共有ストレージ用途 → FTP非対応。
  • DataSyncとの連携もFTPベースのアップロードには不適切。

■SAP試験で押さえておくべきポイント

観点説明
Snowcone小規模でオフライン環境に適したエッジデバイス。EC2起動可能。FTPサーバーの構築も可。
センサー制約の理解問題文で 「FTP以外は非対応」 と明記 → この仕様を満たす構成が正解になる。
プロトコル適合性FTPに対して NFSやFSxなどの構成を選ぶのはNG。
DataSyncの利用条件通常は オンラインの同期用途。オフライン環境では活用が制限される。
EBS vs S3データの一元管理・永続保存が目的の場合は、EBSよりS3が基本的に適切。

引き続き、他の問題があればお送りください。同様に整理して解説いたします。

以下は、SAP試験・問題5 の詳細な整理と解説です。

■問題文（文字列を編集せずに出力）

ある企業は、ユーザーベースのライセンススキーマに変換する戦略の一環として、アプリケーションから主要業績評価指標 (KPI) を記録したいと考えています。アプリケーションは、ウェブベースの UI を備えた多層アプリケーションです。同社は、CloudWatch エージェントを使用して、すべてのログファイルを Amazon CloudWatch に保存します。アプリケーションへのログインはすべてログファイルに保存されます。

新しいライセンススキーマの一部として、同社は、各クライアントが日次、週次、月次ベースで何人のユニークユーザーを持つかを調べる必要があります。

アプリケーションへの変更を最小限に抑えてこの情報を提供するソリューションを選択してください。

■選択肢（正解を伏せて出力）

A.
成功した各ログインをメトリクスとして保存する Amazon CloudWatch Logs メトリクスフィルターを構成します。ユーザー名とクライアント名をメトリクスのディメンションとして構成します。

B.
成功した各ログインが AWS SDK への呼び出しを生成し、CloudWatch にユーザー名とクライアント名のディメンションを記録するカスタムメトリクスをインクリメントするように、アプリケーションロジックを変更します。

C.
ログから成功したログインメトリクスを抽出するように CloudWatch エージェントを構成します。さらに、ユーザー名とクライアント名をメトリクスのディメンションとして使用するカスタムメトリクスとして、成功したログインメトリクスを保存するように CloudWatch エージェントを構成します。

D.
AWS Lambda 関数を構成して、アプリケーションログの Amazon CloudWatch Logs ストリームを消費します。さらに、ユーザー名とクライアント名をメトリクスのディメンションとして使用する CloudWatch のカスタムメトリクスをインクリメントするように Lambda 関数を構成します。

■問題文の要件の概要

要件内容
計測目的ユニークユーザー数（日次・週次・月次）
データ源既存のログファイル（CloudWatch Logs に送信済）
制約条件アプリケーションへの変更は最小限に抑えたい

■正解の選択肢と解説

✅ A. CloudWatch Logs メトリクスフィルターを使用

  • CloudWatch Logs にすでにログが存在するため、ログを解析してメトリクス化するアプローチが適切。
  • CloudWatch Logs メトリクスフィルターは、ログ内の文字列パターンに基づいてメトリクスを生成可能。
  • ユーザー名とクライアント名を メトリクスのディメンション に設定すれば、ユニークユーザー数を柔軟に分析可能。
  • アプリのコード変更が不要なため、「変更最小化」の要件も満たす。

■不正解の選択肢の理由

❌ B. AWS SDKでアプリ改修 → カスタムメトリクス送信

  • SDK呼び出しを埋め込むにはアプリケーションコードの改修が必要。
  • 要件は「最小限の変更」なので不適合。

❌ C. CloudWatch エージェントでメトリクス抽出

  • CloudWatch エージェントはログを収集・送信する機能はあるが、ログからメトリクス抽出は非対応。
  • メトリクス化は メトリクスフィルター側の責務。

❌ D. Lambda でログストリームを処理しカスタムメトリクス作成

  • Lambda の導入は 新規開発・コスト・テスト工数が発生。
  • アプリ改修ほどではないが、「変更最小化」の観点で最適解ではない。

■SAP試験で押さえておくべきポイント

観点解説
CloudWatch Logs メトリクスフィルターログからパターンマッチでメトリクスを生成する機能。アプリ改修不要で運用可能。
メトリクスのディメンション利用者やクライアントごとに分析可能にするためには、username, clientname をディメンションに活用する。
アプリ改修 vs ログ解析最小限の変更が求められる場合は、既存ログの活用がベストプラクティス。
CloudWatch エージェントの役割ログの転送や基本メトリクス収集には使えるが、ログからのメトリクス抽出は非対応。
Lambda＋メトリクス送信柔軟な拡張性があるが、コスト・開発負担が大きく「変更最小化」の要件には適さない。

他の問題があれば、引き続きお送りください。すぐに対応いたします。

以下は、SAP試験・問題6 の構造化された解説です。

■問題文（文字列を編集せずに出力）

ある会社は、単一の Amazon S3 バケットにデータを保存するアプリケーションがあります。同社はすべてのデータを 1 年間保持する必要があります。同社のセキュリティチームは、漏洩した長期的な認証情報を通じて攻撃者が AWS アカウントにアクセスする可能性があることを懸念しています。

S3 バケット内の既存および将来のオブジェクトが保護されていることを保証するソリューションを選択してください。

■選択肢（正解を伏せて出力）

A.
セキュリティチームのみが引き受けたロールを通じてアクセスできる新しい AWS アカウントを作成します。新しいアカウントで S3 バケットを作成します。S3 バージョニングと S3 オブジェクトロックを有効にします。デフォルトの保持期間を 1 年に設定します。既存の S3 バケットから新しい S3 バケットへのレプリケーションを設定します。S3 Batch Replication ジョブを作成し、既存のデータをすべてコピーします。

B.
s3-bucket-versioning-enabled の AWS Config マネージドルールを使用します。AWS Lambda 関数を使用する自動修復アクションを構成し、非準拠リソースで S3 Versioning と MFA Delete を有効にします。1 年後にオブジェクトを削除する S3 ライフサイクルルールを追加します。

C.
AWS Service Catalog の起動制約ロールを除く、すべてのユーザーとロールからバケット作成を明示的に拒否します。S3 バケットの作成に Service Catalog 製品を定義して、S3 バージョニングと MFA Delete を強制的に有効にします。ユーザーが S3 バケットを作成する必要があるときに、製品を起動する権限を与えます。

D.
アカウントと AWS リージョンの S3 保護機能を使用して Amazon GuardDuty を有効にします。1 年後にオブジェクトを削除する S3 ライフサイクルルールを追加します。

■問題文の要件の概要

要件内容
データの保存すべてのオブジェクトを1年間保持
セキュリティ懸念認証情報漏洩→攻撃者アクセスの防止
保護対象既存および将来の S3 オブジェクト
ゴールデータを削除・変更から防御し、保持ポリシーを保証すること

■正解の選択肢と解説

✅ A. 新アカウント＋S3バージョニング＋オブジェクトロック＋バッチレプリケーション

  • 新しいAWSアカウントでデータを隔離 → 認証情報漏洩時のリスク分離に有効。
  • S3バージョニング → 過去バージョンを保持できる（改ざん・削除対策）。
  • S3オブジェクトロック（WORM） → オブジェクト削除防止、保持期間（Retention）指定可。
  • S3 Batch Replication → 既存のデータもまとめて保護対象に転送可能。

この構成により、将来・現在のデータの保全＋削除不可保証＋アカウント分離による攻撃耐性強化を実現しています。

■不正解の選択肢の理由

❌ B. AWS Config ルール＋Lambda 自動修復

  • Configの検出→Lambda修復は「リアクティブ対応」であり、即時性・完全性に欠ける。
  • MFA Delete は有用だが、手動操作やCLIが必要。
  • 攻撃者がアクセスしてしまった時点で復旧に頼るのはリスクが高い。

❌ C. Service Catalog による作成制限

  • 新規作成時の制御には有効だが、既存バケット/オブジェクトへの保護が不足。
  • 管理面ではよいが、「オブジェクトの保持保証」「削除対策」に直接寄与しない。

❌ D. Amazon GuardDuty の検知＋S3 ライフサイクル

  • GuardDuty は異常検知には有用だが、データの変更・削除を防ぐ機能は持たない。
  • ライフサイクルポリシーは「削除を行う」ものであり、保持要件に逆行する可能性がある。

■SAP試験で押さえておくべきポイント

観点解説
S3 バージョニング削除・上書き前のバージョンを保持。災害・誤操作対策。
S3 オブジェクトロックWORMモデルによる削除・変更の防止。「リーガルホールド」「保持期間設定」が可能。
セキュリティ強化のためのアカウント分離長期的認証情報の漏洩対策には、別アカウントにセキュアコピー＋限定アクセスが有効。
S3 Batch Replication既存のS3オブジェクトを別バケットに一括複製可能（バージョン管理が有効である必要あり）。
GuardDutyやConfigは補助的データ保護の検知・モニタリングには良いが、防御・防止には不十分なことが多い。

次の問題も引き続きどうぞ。構造化して丁寧に解説します。

以下は SAP試験・問題7 の構造化された解説です。

■問題文（文字列を編集せずに出力）

ある企業は、AWS を使用して本番環境のウェブアプリケーションを開発および管理しています。このアプリケーションには、AWS Lambda 関数を呼び出す Amazon API Gateway HTTP API が含まれています。Lambda 関数は、データを処理してデータベースに保存します。

同社は、統合された方法でウェブアプリケーションのユーザー認証を実装したいと考えています。同社はすでにサードパーティーの ID プロバイダーを使用しており、同社の他のアプリケーション用に OAuth トークンを発行しています。

これらの要件を満たすソリューションを選択してください。

■選択肢（正解を伏せて出力）

A.
会社のサードパーティーの ID プロバイダーを API Gateway に統合します。ID プロバイダーからのトークンを検証するように、API Gateway Lambda オーソライザーを設定します。すべての API ルートで Lambda オーソライザーを必須にします。ウェブアプリケーションを更新して、ID プロバイダーからトークンを取得し、API Gateway HTTP API を呼び出すときに Authorization ヘッダーにトークンを含めます。

B.
会社のサードパーティ ID プロバイダーを AWS Directory Service と統合します。ID プロバイダーからのトークンを検証するように、Directory Service を API Gateway オーソライザーとして設定します。すべての API ルートで Directory Service オーソライザーを必須にします。AWS IAM Identity Center を SAML 2.0 ID プロバイダーとして設定します。カスタム SAML 2.0 アプリケーションとして ウェブアプリケーションを構成します。

C.
会社のサードパーティ ID プロバイダーを AWS IAM Identity Center と統合します。ゼロ設定の認証と承認に IAM Identity Center を使用するように API Gateway を設定します。IAM Identity Center から AWS STS トークンを取得し、API Gateway HTTP API を呼び出すときに Authorization ヘッダーにトークンを含めるようにウェブアプリケーションを更新します。

D.
会社のサードパーティ ID プロバイダーを AWS IAM Identity Center と統合します。IAM ユーザーに API Gateway HTTP API を呼び出す権限を設定します。IAM ユーザーからリクエストパラメータを抽出し、API Gateway HTTP API を呼び出すときに Authorization ヘッダーにパラメータを含めるようにウェブアプリケーションを更新します。

■問題文の要件の概要

要件内容
ユーザー認証サードパーティ ID プロバイダー使用、OAuth トークン発行済
認証対象Webアプリケーションのユーザー（API呼び出し前に検証）
実行構成API Gateway → Lambda → DB保存
目的統合的・安全な方法で API アクセスを認証制御

■正解の選択肢と解説

✅ A. Lambda オーソライザーによる OAuth トークン検証

  • サードパーティ ID プロバイダーの OAuth トークン を活用
  • API Gateway Lambda オーソライザー を使ってトークンの署名・スコープ・有効期限などを検証
  • 全 API ルートにオーソライザーを適用し、統合的なアクセス制御を実現
  • アプリケーションは Authorization ヘッダーにトークンを付与して API 呼び出し

👉 この方法は、API Gateway がカスタムオーソライザー（Lambda）で OAuth トークンを検証できる点を活用しており、外部認証基盤と AWS サーバレス構成をうまく接続するベストプラクティスです。

■不正解の選択肢の理由

❌ B. Directory Service + SAML

  • AWS Directory Service は API Gateway オーソライザーと統合されていない
  • SAMLはWeb UI向けのSSOには有効だが、API向けのOAuthベースのヘッダー認証には不向き
  • 構成が冗長かつ非現実的（Directory Serviceでトークン検証は不可）

❌ C. IAM Identity Center + STS トークン

  • IAM Identity Center は OAuth トークンの検証や API Gateway オーソライザーへの統合を 直接サポートしない
  • STS トークンは IAM リソースアクセス制御向けであり、OAuth トークンでの API 認証には 不適切
  • 認証フローが現実に即していない（トークン取得→STS→Authorizationヘッダーという経路がない）

❌ D. IAM ユーザー認証でヘッダー制御

  • IAMユーザーのアクセスキーや認証情報をベースとした構成は、API認証としてOAuthベースと一致しない
  • パラメータやヘッダーにIAMユーザー情報を含めても、それをAPI Gatewayで検証する標準手段がない
  • セキュリティのベストプラクティスにも反する（静的認証情報）

■SAP試験で押さえておくべきポイント

項目説明
API Gateway Lambda オーソライザーOAuth や SAML トークンのカスタム検証を可能にする。ベアラートークン検証に最適。
OAuth トークンによる認証ユーザーが取得したトークンを Authorization ヘッダーに含め、API Gateway 側で検証
統合認証基盤との連携サードパーティの ID プロバイダーと API Gateway を直接統合せず、オーソライザーを間に挟むのが一般的
IAM Identity Center はリソースアクセス制御向けAPI 認証用途では直接使いにくく、OAuth トークンベースの認証にはLambda オーソライザーを使うのが適切

次の問題もどうぞ。ベストプラクティスと試験観点の両面から解説していきます。

RELATED POST