以下は、提供いただいた【SAP試験の問題1】の整理・解説です。
◆ 問題文（原文ママ）
ある企業は AWS CodeCommit リポジトリを使用しています。この会社は、リポジトリにあるデータのバックアップコピーを、2 番目の AWS リージョンに保存する必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢（原文ママ）
A.
AWS Elastic Disaster Recovery を構成して、CodeCommit リポジトリのデータを 2 番目のリージョンにレプリケートします。
B.
AWS Backup を使用して、1 時間ごとのスケジュールで CodeCommit リポジトリをバックアップします。2 番目のリージョンにクロスリージョンのコピーを作成します。
C.
Amazon EventBridge ルールを作成し、企業がリポジトリにコードをプッシュするときに AWS CodeBuild を起動します。CodeBuild を使用して、リポジトリをクローンします。コンテンツの .zip ファイルを作成します。そのファイルを 2 番目のリージョンの S3 バケットにコピーします。
D.
AWS Step Functions ワークフローを 1 時間ごとのスケジュールで作成し、CodeCommit リポジトリのスナップショットを取得します。スナップショットを 2 番目のリージョンの S3 バケットにコピーするようにワークフローを構成します。
◆ 問題文の要件の概要
- AWS CodeCommit にあるコードリポジトリを
- 2番目のAWSリージョンにバックアップ（レプリケート）保存したい
- そのための適切かつ対応サービスに合ったソリューションを選ぶ
◆ 正解の選択肢と解説
✅ 正解：C
Amazon EventBridge ルールを作成し、企業がリポジトリにコードをプッシュするときに AWS CodeBuild を起動します。CodeBuild を使用して、リポジトリをクローンします。コンテンツの .zip ファイルを作成します。そのファイルを 2 番目のリージョンの S3 バケットにコピーします。
- EventBridge + CodeBuild + S3 の組み合わせでイベント駆動型の自動バックアップが可能。
- git push のたびに CodeBuild がリポジトリを zip 形式でバックアップ。
- S3 バケットを別リージョンに設けることで、クロスリージョン保護が実現。
- 手動操作なしに継続的かつ即時なリポジトリ保護ができ、現実的かつ実績のある構成。
◆ 不正解の選択肢の理由
❌ A. AWS Elastic Disaster Recovery は CodeCommit 非対応
- Elastic Disaster Recovery は EC2やオンプレサーバー向けのブロックレベルレプリケーション。
- CodeCommit や Git リポジトリのようなサービスには非対応。
❌ B. AWS Backup は CodeCommit をサポートしない
- AWS Backup が対応しているのは RDS, EFS, DynamoDB などのデータサービス。
- CodeCommit はバックアップ対象として非対応。バックアッププランに追加できない。
❌ D. Step Functions 単体ではバックアップ機能を持たない
- Step Functions はワークフロー管理サービスであり、CodeCommitのスナップショット取得機能はない。
- 実現には Lambda や CodeBuild などを別途呼び出す必要があり、選択肢として不完全。
◆ SAP試験で押さえておくべきポイント
| 項目 | 内容 |
|---|---|
| CodeCommitのバックアップ | イベント駆動（例：git push）によって自動処理される設計がベスト |
| 非対応サービスを見抜く力 | Elastic Disaster Recovery や AWS Backup が 対象リソースに非対応である点を見落とさないこと |
| 組み合わせ設計 | EventBridge（イベント検知） + CodeBuild（zip処理） + S3（高耐久ストレージ）という複合構成力が問われる |
| S3クロスリージョン保存 | 災害対策の基本手法。DR/BCP要件にはS3保存が第一選択肢 |
この問題は、**“対応サービスの見極め”と“イベントドリブンによるDR構成”**をテーマとした典型的な設問です。
他の問題も引き続きお送りいただければ、同様に解説いたします。
以下は、問題2のSAP形式による整理です。
■ 問題文（原文のまま）
ある企業は、オンプレミスシステムから Amazon S3 バケットにデータを送信したいと考えています。同社は 3 つの異なるアカウントで S3 バケットを作成しました。同社は、インターネットを経由することなく、非公開でデータを送信する必要があります。同社には AWS への既存の専用接続がありません。
これらの要件を満たす最適な手順の組み合わせを選択してください。 (2 つ選択)
■ 選択肢（原文のまま）
A. AWS クラウドでネットワークアカウントを確立します。ネットワークアカウントにプライベート VPC を作成します。オンプレミス環境とプライベート VPC の間に、プライベート VIF を使用して AWS Direct Connect 接続を設定します。
B. AWS クラウドでネットワークアカウントを確立します。ネットワークアカウントにプライベート VPC を作成します。オンプレミス環境とプライベート VPC の間に、パブリック VIF を使用して AWS Direct Connect 接続を設定します。
C. ネットワークアカウントに Amazon S3 インターフェイスエンドポイントを作成します。
D. ネットワークアカウントに Amazon S3 ゲートウェイエンドポイントを作成します。
E. AWS クラウドでネットワークアカウントを確立します。ネットワークアカウントにプライベート VPC を作成します。S3 バケットをホストするアカウントの VPC をネットワークアカウントの VPC とピアリングします。
■ 問題文の要件の概要
- オンプレミスから Amazon S3 へ 非公開経路 でデータ送信したい。
- 既存の Direct Connect は未保有。
- 3つの異なるアカウントの S3 バケットへ送信。
- インターネット非経由（Private）な経路構築が必要。
■ 正解の選択肢と解説
✅ A. プライベート VIF を使用した Direct Connect の構成
✅ C. S3 インターフェイスエンドポイントの作成
解説：
- A（プライベート VIF）：
- プライベート VIF はオンプレミスと VPC を直接接続する完全にプライベートな経路です。
- この構成によりインターネットを経由せずに AWS クラウドへアクセス可能になります。
- ネットワークアカウント経由で複数アカウントへルート拡張すれば、効率よく集約可能。
- C（S3 インターフェイスエンドポイント）：
- AWS PrivateLink によって S3 との通信が VPC 内の ENI 経由で行われます。
- これにより、VPC 内で完結し、インターネットを経由せずに S3 にアクセスできます。
- セキュリティグループでトラフィック制御も可能。
■ 不正解の選択肢の理由
❌ B. パブリック VIF
- パブリック VIF 経由では AWS のパブリックサービス（例：S3）にアクセスできますが、経路上で AWS のグローバルネットワークを経由し、完全なプライベート通信ではないため要件を満たさない。
❌ D. S3 ゲートウェイエンドポイント
- ゲートウェイエンドポイントは VPC 内のリソース用。オンプレミスからのアクセスには対応していない。
- Direct Connect 経由で S3 へアクセスする際には使用できない。
❌ E. VPC ピアリング
- ピアリングは VPC 間通信には有効だが、S3 はリージョンサービスであり、ピアリング越しにアクセスできない。
- 経路設計が煩雑になり、S3 バケットへの直接通信は実現できない。
■ SAP試験で押さえておくべきポイント
- Direct Connect のプライベート VIFはオンプレミス⇔VPC 間の完全プライベート接続に使用。
- **S3 インターフェイスエンドポイント（AWS PrivateLink）**を使うと、S3 に対してプライベート IP でアクセスできる。
- S3 ゲートウェイエンドポイントは VPC 内リソース専用で、オンプレミスとの接続には不向き。
- VPC ピアリングでは S3 などリージョンサービスへの経路は張れない。
- プライベートな転送経路構築には「Direct Connect + インターフェイスエンドポイント」の組み合わせが重要。
必要であれば図解・設計図パターンの要約も添付可能です。続きを希望される場合や、類似問題の解説をご希望であればお知らせください。
以下は、【SAP問題3】の整理・解説です。
◆ 問題文（原文のまま）
ある企業が数百の AWS アカウントを持っています。同社は AWS Organizations の組織を使用して、すべてのアカウントを管理しています。同社はすべての機能を有効にしています。
財務チームは、AWS コストの日次予算を割り当てています。組織の AWS コストが割り当てられた予算の 80% を超えた場合、財務チームは電子メール通知を受け取る必要があります。ソリューションアーキテクトは、コストを追跡し、通知を配信するソリューションを実装する必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢（原文のまま）
A.
組織の管理アカウントで、AWS Budgets を使用して、日単位の期間を持つ予算を作成します。アラートのしきい値を追加し、値を 80% に設定します。Amazon Simple Notification Service (Amazon SNS) を使用して、財務チームに通知します。
B.
組織の管理アカウントで、AWS Trusted Advisor の組織ビュー機能を設定します。コスト最適化のための組織ビューレポートを作成します。アラートのしきい値を 80% に設定します。通知設定を構成します。財務チームの電子メールアドレスを追加します。
C.
AWS Control Tower に組織を登録します。オプションのコストコントロール (ガードレール) を有効にします。コントロール (ガードレール) パラメータを 80% に設定します。コントロール (ガードレール) 通知の設定を構成します。Amazon Simple Notification Service (Amazon SNS) を使用して財務チームに通知します。
D.
組織の管理アカウントの Amazon S3 バケットに毎日の AWS コストと使用状況レポートを保存するようにメンバーアカウントを構成します。Amazon EventBridge を使用して、組織のコストを計算するために毎日の Amazon Athena クエリをスケジュールします。コストの合計が割り当てられた予算の 80% 以上になった場合、Amazon CloudWatch アラートを送信するように Athena を設定します。Amazon Simple Notification Service (Amazon SNS) を使用して、財務チームに通知します。
◆ 問題文の要件の概要
- AWS Organizations を使って複数アカウントを管理。
- 日次予算の進捗が 80% を超えたら即時に通知を出す必要がある。
- 全アカウントのコスト合計のモニタリングと通知が必要。
- 実装が過剰でなく、効率的に通知できる構成が求められている。
◆ 正解の選択肢と解説
✅ A. AWS Budgets + SNS を使ったしきい値通知
解説：
- AWS Budgets は組織の管理アカウントで設定でき、Organizations 全体の合計コストを対象とした日次予算を定義可能。
- SNS 経由で通知を送る仕組みが組み込まれており、80% などのしきい値設定が可能。
- 財務チームのメールアドレスを SNS サブスクリプションに追加すれば、即時通知が実現。
- 実装も保守もシンプルで、最も現実的かつ公式推奨の方法。
◆ 不正解の選択肢の理由
❌ B. Trusted Advisor
- Trusted Advisor の「コスト最適化」はチェック項目の一つで、予算管理やしきい値通知機能はない。
- SNS 通知と連携できるが、80%超えなどの細かな予算ベース通知は不可能。
❌ C. Control Tower のガードレール
- Control Tower のガードレールは セキュリティや構成ポリシーの強制用。
- 予算の進捗やしきい値通知には対応していない。
- SNS 通知設定もコスト基準での発火はできない。
❌ D. CUR + Athena + EventBridge + CloudWatch + SNS
- 実現可能だが過剰設計で、更新ラグがある（CURの反映は遅延あり）。
- Athena クエリのスケジューリングや CloudWatch 連携は複雑かつ即時性に欠ける。
- 運用・保守コストが高く、本番環境向けとしては非効率。
◆ SAP試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| ✅ AWS Budgets の用途 | 予算の設定・アラート・SNS通知が可能。Organizations全体にも対応。 |
| ✅ SNS連携 | 予算超過時に自動でメール通知を飛ばせる。 |
| 🚫 Trusted Advisor | しきい値通知ではなく、リソース利用状況のアドバイス用途。 |
| 🚫 Control Tower ガードレール | コスト監視目的には使用不可。構成準拠用。 |
| ⚠️ CUR+Athena方式 | コスト分析には有用だが、即時性が求められる通知には不向き。 |
この問題は「一番シンプルで運用可能な通知手段を選べるか」が問われており、AWS Budgets + SNS の基本を確実に理解しているかどうかが合否の分かれ目です。
次の問題もどうぞお送りください。引き続き対応いたします。
以下は、問題4の出力形式に沿った整理です。
■ 問題文（文字列を編集せずに出力）
あなたの会社は市場データをストリーミングで取り込んで処理しています。データレートは一定です。毎夜、集約された統計値を計算するプロセスが実行され、各実行には約 4 時間かかります。統計分析はビジネスにとってミッションクリティカルではありません。
特定の実行が失敗しても、次の実行で以前のデータポイントが取得されます。現在のアーキテクチャでは、1 年予約の Amazon EC2 リザーブドインスタンスのプールをフルタイムで使用して、ストリーミングデータを取り込み、Amazon EBS ボリュームに保存しています。オンデマンド EC2 インスタンスは毎晩起動され、取り込みサーバー上の NFS 共有から保存データにアクセスして夜間処理を実行し、完了したら夜間処理サーバーを終了させます。
リザーブドインスタンスの予約は有効期限が切れているため、会社は新しいリザーブドインスタンスを購入するか、新しい設計を実装するかを決定する必要があります。
最も費用対効果の高い設計を選択してください。
■ 選択肢（文字列を編集せずに出力）
A.
Amazon Kinesis Data Firehose を使用して Amazon S3 にデータを保存するために取り込みプロセスを更新します。毎晩起動するオンデマンド EC2 インスタンスのフリートを使用して、S3 データのバッチ処理を実行し、処理が完了したら終了させます。
B.
Amazon Kinesis Data Firehose を使用して Amazon S3 にデータを保存するように取り込みプロセスを更新します。AWS Batch を使用して、オンデマンド価格の 50% のスポットインスタンスの入札価格で夜間処理を実行します。
C.
Network Load Balancer の背後にある 3 年契約の EC2 リザーブドインスタンスのフリートを使用するように取り込みプロセスを更新します。オンデマンド価格の 50 % のスポットインスタンスの入札価格で夜間処理を実行します。
D.
Amazon Kinesis Data Firehose を使用して Amazon Redshift にデータを保存するように取り込みプロセスを更新します。Amazon CloudWatch Events で毎晩実行するようにスケジュールされた AWS Lambda 関数を使用して、Amazon Redshift にクエリを実行して毎日の統計情報を生成します。
■ 問題文の要件の概要
- 一定量のストリーミングデータ取り込み
- 夜間に4時間の統計処理
- 失敗しても次回再処理可能（可用性重視ではない）
- 現在はRI＋オンデマンド構成
- RI期限切れ、費用対効果の見直しが目的
■ 正解の選択肢と解説
正解：B
Amazon Kinesis Data Firehose を使用して Amazon S3 にデータを保存するように取り込みプロセスを更新します。AWS Batch を使用して、オンデマンド価格の 50% のスポットインスタンスの入札価格で夜間処理を実行します。
解説：
- Firehose + S3 で取り込みを完全マネージド化し、常時稼働のEC2やEBSを排除
- AWS Batch によって、ジョブスケジューリングとキャパシティ確保を自動化
- スポットインスタンス を活用することで大幅なコスト削減（50%以上）
- 処理の失敗リスクも受容できる要件のため、スポットの中断にも耐えられる
- 結果として 低コスト・低運用負荷の設計 となる
■ 不正解の選択肢の理由
A. オンデマンドEC2を使用：
コストが高く、スポット活用やBatchの自動化もないため非効率。
C. RI＋NLB構成：
長期固定費が発生し、可変負荷に向かない構成。マネージドサービス未使用で運用負荷も高い。
D. Redshift＋Lambda構成：
- Redshiftは高コスト（常時課金）
- Lambdaは最大15分の制限があり、4時間の処理に適さない
■ SAP試験で押さえておくべきポイント
- Kinesis Firehose + S3 は低コストで信頼性の高いストリーミング取り込み基盤を構築可能。
- AWS Batch + スポットインスタンス は費用対効果の高いバッチ処理手段。再試行も自動対応。
- ミッションクリティカルでないワークロード においては、スポット中断のリスクは受容できる前提で設計すべき。
- Redshiftの常時課金やLambdaの時間制限など、各サービスの特性と制限を正確に把握する必要がある。
続けて問題を貼り付けていただければ、同様に整理していきます。
以下、AWS SAP試験の「問題5」の整理と解説です。
◆ 問題文
ある企業が AWS クラウドで IoT アプリケーションを運用しています。同社は、米国内の住宅からデータを収集する数百万のセンサーを持っています。センサーは MQTT プロトコルを使用して、カスタム MQTT ブローカーに接続してデータを送信します。MQTT ブローカーは、単一の Amazon EC2 インスタンスにデータを保存します。センサーは、iot.example.com というドメインを介してブローカーに接続します。同社は DNS サービスとして Amazon Route 53 を使用しています。同社は Amazon DynamoDB にデータを保存します。
データ量が原因で MQTT ブローカーに過負荷がかかり、センサーデータが失われることが何度かありました。同社はソリューションの信頼性を向上させる必要があります。
これらの要件を満たすソリューションを選択してください。
◆ 選択肢
A
MQTT ブローカーの Application Load Balancer (ALB) と Auto Scaling グループを作成します。Auto Scaling グループを ALB のターゲットとして使用します。Route 53 の DNS レコードをエイリアスレコードに更新します。エイリアスレコードが ALB を指すようにします。MQTT ブローカーを使用してデータを保存します。
B
センサーデータを受信するように AWS IoT Core をセットアップします。AWS IoT Core に接続するカスタムドメインを作成し、設定します。Route 53 の DNS レコードを更新して、AWS IoT Core Data-ATS エンドポイントを指すようにします。データを保存する AWS IoT ルールを構成します。
C
Network Load Balancer (NLB) を作成します。ターゲットとして MQTT ブローカーを設定します。AWS Global Accelerator アクセラレータを作成します。NLB をアクセラレータのエンドポイントとして設定します。Route 53 の DNS レコードを複数値回答レコードに更新します。Global Accelerator の IP アドレスを値として設定します。MQTT ブローカーを使用してデータを保存します。
D
センサーデータを受信するように AWS IoT Greengrass をセットアップします。Route 53 の DNS レコードを更新して、AWS IoT Greengrass エンドポイントを指すようにします。AWS Lambda 関数を呼び出してデータを保存するように、AWS IoT ルールを設定します。
◆ 問題文の要件の概要
- 数百万のセンサーが MQTT を通じてデータを送信している
- 現在は EC2 上のカスタムブローカーに依存し、過負荷でデータ損失が起きている
- 高信頼性・スケーラブルな仕組みへの移行が必要
- センサーは「iot.example.com」を使用し続ける（＝カスタムドメイン対応が望ましい）
◆ 正解の選択肢と解説
正解：B
AWS IoT Core を使用し、MQTT 接続をフルマネージドサービスに移行。DNS を ATS エンドポイントへ更新し、IoT ルールでデータを DynamoDB へ保存。
解説：
- AWS IoT Core は MQTT ブローカーをフルマネージドで提供し、数百万の同時接続やトラフィックスパイクに自動スケール可能。
- Data-ATSエンドポイント は TLS（暗号化）通信に対応しており、カスタムドメインと組み合わせて既存デバイスを変更せず接続先のみ更新可能。
- IoTルール を使えば受信データを直接 DynamoDB へ保存可能で、コード不要。
- 単一EC2の制限・障害・スケール課題をすべて排除できる。
◆ 不正解の選択肢の理由
A
ALBはL7ロードバランサであり、MQTTのTCP通信(ポート1883)を扱えないためセンサーが接続不可。Auto Scalingも機能せず不適。
C
NLBはTCP転送に対応しているが、ブローカーが単一EC2のままではスケーラビリティが解消せず根本的な改善にはならない。
D
Greengrassはエッジ処理用であり、クラウド集約型のMQTTブローカーとしての役割を果たさない。また、Lambdaへの直接保存も大量データに不向き。
◆ SAP試験で押さえておくべきポイント
- AWS IoT Core は MQTT に最適なフルマネージドサービスであり、IoT用通信基盤としてのスケーラビリティと信頼性が高い
- ALBはTCPを処理できない（HTTP/HTTPS専用）
- IoT Core + IoTルール + DynamoDB の組み合わせは、データ収集・保存のマネージド構成の王道
- カスタムドメイン機能により既存IoT機器を変更せず移行できる点も実務的に重要
次の問題も同様にお送りいただければ、順次対応します。
以下に、問題6について指定の形式で整理・解説いたします。
◆ 問題文
ある企業は、インターネットに接続された Application Load Balancer (ALB) の背後のプライベートサブネットにある Amazon EC2 インスタンスのフリート上でアプリケーションを実行しています。ALB は、Amazon CloudFront ディストリビューションのオリジンです。さまざまな AWS 管理ルールを含む AWS WAF を使用して、ウェブ ACL は、CloudFront ディストリビューションに関連付けられています。
同社は、インターネットトラフィックが ALB に直接アクセスするのを防ぐソリューションを必要としています。
運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションを選択してください。
◆ 選択肢
A. 既存の ウェブ ACL と同じルールを含む新しいウェブ ACL を作成します。新しい ウェブ ACL を ALB に関連付けます。
B. 既存の ウェブ ACL を ALB に関連付けます。
C. AWS マネージドプレフィクスリストからのトラフィックを CloudFront のみに許可するセキュリティグループのルールを ALB に追加します。
D. ALB にセキュリティグループのルールを追加して、CloudFront のさまざまな IP アドレス範囲のみを許可します。
◆ 問題文の要件の概要
- CloudFront を経由して ALB にアクセスさせたい。
- ALB への直接インターネットアクセスを防ぎたい。
- 運用負荷を最小限に抑えたい。
◆ 正解の選択肢と解説
正解：C
「AWS マネージドプレフィクスリスト」からのトラフィックのみを ALB に許可することで、CloudFront 以外の直接アクセスをブロックでき、運用上のオーバーヘッドも不要です。
解説：
- AWS は CloudFront の IP 範囲を常に更新し、マネージドプレフィクスリストとして提供しています。
- セキュリティグループでこのプレフィクスリストを指定すれば、常に最新の CloudFront IP 範囲だけを許可できます。
- 手動メンテナンス不要で、意図しないアクセスを排除できます。
- WAF では IP アドレスによる制御が困難なため、ネットワークレベルで制御するのが正解。
◆ 不正解の選択肢の理由
A. 新しい WAF ACL を ALB に適用
- WAF はアプリケーション層のルールであり、直接接続の遮断には不十分。
- 同じルールを重複作成するのは運用ミスの元で、運用オーバーヘッドが増加。
B. 既存の WAF ACL を ALB に適用
- WAF を ALB に適用しても、CloudFront 以外のIPからのアクセスはWAFで遮断できない。
- IP制限にはセキュリティグループの方が適切。
D. CloudFront の IP をセキュリティグループに手動追加
- CloudFront の IP 範囲は頻繁に更新されるため手動管理は非現実的。
- 更新漏れによる通信障害や過剰なメンテナンス工数が発生。
◆ SAP試験で押さえておくべきポイント
- ALB のインターネット遮断には WAF ではなく セキュリティグループ + IP 制御が必要。
- CloudFront の IP 範囲制御には AWS マネージドプレフィクスリストを活用すべき。
- マネージドプレフィクスリストは 自動更新されるIPリストであり、運用効率とセキュリティを両立する重要機能。
- WAF はアプリケーション層でのフィルタリングに使用し、IPレベルの制御には向かない。
次の問題があれば、引き続きお送りください。丁寧に整理して解説いたします。
以下に、問題7の解説を指定の形式で整理しました。
◆ 問題文
ある企業は AWS クラウドでアプリケーションを実行しています。このアプリケーションは、Application Load Balancer の背後にある複数のアベイラビリティーゾーンにある Amazon EC2 インスタンスのフリート上で実行されるマイクロサービスで構成されています。同社は最近、Amazon API Gateway で実装された新しい REST API を追加しました。EC2 インスタンス上で実行される古いマイクロサービスの一部は、この新しい API を呼び出す必要があります。
同社は、公共のインターネットから API にアクセスできることを望んでおらず、独自のデータが公共のインターネットを通過することも望んでいません。
これらの要件を満たす最適な方法を選択してください。
◆ 選択肢
A. VPC と API Gateway の間に AWS Site-to-Site VPN 接続を作成します。API Gateway を使用して、マイクロサービスごとに一意の API キーを生成します。キーを必要とする API メソッドを構成します。
B. API Gateway 用のインターフェース VPC エンドポイントを作成し、特定の API へのアクセスのみを許可するエンドポイントポリシーを設定します。API Gateway にリソースポリシーを追加し、VPC エンドポイントからのアクセスのみを許可します。API Gateway のエンドポイントタイプをプライベートに変更します。
C. IAM 認証を使用するように API Gateway を変更します。EC2 インスタンスに割り当てられている IAM ロールの IAM ポリシーを更新して、API Gateway へのアクセスを許可します。API Gateway を新しい VPC に移動する Transit Gateway をデプロイし、VPC に接続します。
D. AWS Global Accelerator でアクセラレータを作成し、API Gateway に接続します。すべての VPC サブネットのルートテーブルを、作成した Global Accelerator のエンドポイント IP アドレスへのルートで更新します。認証に使用する各サービスの API キーを追加します。
◆ 問題文の要件の概要
- EC2 インスタンス（VPC 内）から API Gateway の新しい REST API を呼び出したい。
- API Gateway はパブリックに公開せず、インターネットを経由したくない。
- データのプライバシーを確保し、閉域網での接続を希望。
◆ 正解の選択肢と解説
正解：B
解説：
API Gateway に対して プライベートエンドポイント（Private REST API） を構成し、それにアクセスするための インターフェース VPC エンドポイント（PrivateLink） を作成するのが最も適切な方法です。
この構成により、API Gateway への通信は VPC 内の AWS ネットワークで完結し、インターネットを一切経由しません。さらに、リソースポリシーで VPC エンドポイントからのアクセスのみに制限することで、セキュリティを強化できます。
◆ 不正解の選択肢の理由
A. Site-to-Site VPN + APIキー
→ Site-to-Site VPN はトンネル自体は暗号化されるが、経路はインターネット上を通るため、「インターネットを経由しない」要件を満たさない。APIキーは認証用途であり、ネットワーク制御にはならない。
C. IAM認証 + Transit Gateway
→ Transit Gateway は API Gateway を直接接続できない。IAM認証も認可の仕組みであって、インターネット経由を排除する設計にはならない。
D. Global Accelerator
→ Global Accelerator は高速化のためのサービスであり、API Gateway を パブリックなままで使用する構成になるため、外部アクセスを排除できない。
◆ SAP試験で押さえておくべきポイント
- Private REST API + Interface VPC Endpoint（PrivateLink） の組み合わせにより、API Gateway を閉域で利用できる。
- リソースポリシーとエンドポイントポリシーを組み合わせることで、アクセス制御を強化できる。
- API Gateway はパブリックなサービスだが、構成によってプライベートな使用が可能。
- Site-to-Site VPN や Global Accelerator は、経路がインターネットを通るため要件を満たさない場合がある。
次の問題もあればお送りください。引き続きこの形式で整理します。
