Uncategorized

#69

 

了解しました！問題1を指定フォーマットで整理しました。

■問題文

あるイベント会社が AWS でチケット販売プラットフォームを運営しています。同社のお客様は、プラットフォーム上でイベントを設定およびスケジュールします。イベントにより、プラットフォームへのトラフィックが大幅に増加します。同社は各お客様のイベントの日時を把握しています。

同社は、Amazon Elastic Container Service (Amazon ECS) クラスター上でプラットフォームを運営しています。ECS クラスターは、Auto Scaling グループに属する Amazon EC2 オンデマンドインスタンスで構成されています。Auto Scaling グループは、予測スケーリングポリシーを使用しています。

ECS クラスターは、チケットアセットをダウンロードするために、Amazon S3 バケットに頻繁にリクエストを送信します。ECS クラスターと S3 バケットは、同じ AWS リージョンおよび同じ AWS アカウント内にあります。ECS クラスターと S3 バケット間のトラフィックは、NAT ゲートウェイを経由して流れます。

同社は、プラットフォームの可用性を低下させることなく、プラットフォームのコストを最適化する必要があります。

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

■選択肢

A：スケジュールされたスケーリングポリシーの期間、該当するインスタンスタイプのオンデマンドキャパシティー予約を作成します。

B：スケジュールされたイベントの予測スケーリングポリシーをスケジュールされたスケーリングポリシーに置き換えます。

C：S3 バケットのゲートウェイ VPC エンドポイントを作成します。

D：スポットインスタンスの Auto Scaling グループを使用する別の ECS キャパシティープロバイダーを追加します。新しいキャパシティープロバイダー戦略を、既存のキャパシティープロバイダー戦略と同じ重みになるように設定します。

E：S3 バケットで S3 Transfer Acceleration を有効にします。

■問題文の要件の概要

  • イベントの日時が事前に分かっている → スケジュール型のスケーリングで効率的に対応可能。
  • ECS → S3 通信が NAT GW 経由 → 不要なコスト発生。
  • 可用性を下げずにコスト最適化 → 不必要なリソース予約や無駄な機能は避ける。

■正解の選択肢と解説

正解：B, C

  • B：予測スケーリング → スケジュールスケーリング
    イベント日時が既知なので予測スケーリングよりもスケジュールスケーリングの方が適切。無駄なスケーリングを避けつつ必要なときにリソースを確保でき、コスト最適化に直結する。
  • C：S3 ゲートウェイ VPC エンドポイント
    同一リージョン内通信で NAT Gateway を経由しているのは無駄。S3 ゲートウェイエンドポイントを利用することで、NAT Gateway コストを削減しつつ可用性を維持できる。

■不正解の選択肢の理由

  • A：オンデマンドキャパシティ予約は常時料金が発生し、コスト最適化の目的と逆行。
  • D：スポットインスタンスは安価だが中断リスクがあり、イベント対応に必要な安定性を確保できない。
  • E：S3 Transfer Acceleration はグローバル通信向けで、同一リージョン内では無駄なコストが増える。

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

  • **イベント日時が分かっている場合は「スケジュールスケーリング」**が最適。
  • **S3 へのアクセスで NAT GW を避けるには「ゲートウェイ VPC エンドポイント」**を使う。
  • Transfer Acceleration, Spot 依存, CapRes 予約はコスト最適化のシナリオでは不適切になる場合が多い。

👉 試験では「可用性を下げずにコスト削減」がキーワード。無駄な転送コスト削減（VPCエンドポイント）と予測可能負荷の計画スケーリングをセットで覚えておくと良いです。

次は 問題2 も同じ形式で整理しますか？

了解しました！問題2を指定フォーマットで整理しました。

■問題文

ある企業は、レガシーアプリケーションをオンプレミスのデータセンターから AWS に移行しています。このアプリケーションは、キーと値のデータベースとして MongoDB を使用します。同社の技術ガイドラインによると、すべての Amazon EC2 インスタンスは、インターネット接続のないプライベートサブネットでホストする必要があります。さらに、アプリケーションとデータベース間の接続はすべて暗号化する必要があります。データベースは、需要に基づいて拡張できる必要があります。

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

■選択肢

A：プロビジョンド IOPS ボリュームを使用して、アプリケーション用に新しい Amazon DocumentDB テーブルを作成します。インスタンスエンドポイントを使用して Amazon DocumentDB に接続します。

B：プロビジョンド IOPS ボリュームを使用して、アプリケーション用に新しい Amazon DocumentDB テーブルを作成します。クラスターエンドポイントを使用して、Amazon DocumentDB に接続します。

C：オンデマンドキャパシティでアプリケーション用に新しい Amazon DynamoDB のテーブルを作成します。DynamoDB のインターフェイス VPC エンドポイントを使用して、DynamoDB テーブルに接続します。

D：オンデマンドキャパシティでアプリケーション用に新しい Amazon DynamoDB のテーブルを作成します。DynamoDB のゲートウェイ VPC エンドポイントを使用して、DynamoDB テーブルに接続します。

■問題文の要件の概要

  • MongoDB を利用中 → NoSQL/Key-Value データベース互換が必要
  • 需要に応じた自動スケーリング → DocumentDB は手動スケール、DynamoDB はオンデマンド自動スケール可能
  • プライベートサブネットから接続（インターネット接続禁止） → VPC エンドポイント必須
  • 暗号化通信必須 → DynamoDB は HTTPS 経由で暗号化通信

■正解の選択肢と解説

正解：D

  • Amazon DynamoDB オンデマンドキャパシティ
    → アプリケーションのワークロードに応じてスループットを自動でスケーリング可能。予測不能な負荷に最適。
  • DynamoDB ゲートウェイ VPC エンドポイント
    → EC2 がプライベートサブネットにあっても、インターネットに出ずに DynamoDB に直接アクセス可能。追加コスト不要。
  • DynamoDB は標準で 暗号化 (HTTPS) 通信を提供するため、セキュリティ要件も満たす。

■不正解の選択肢の理由

  • A（DocumentDB + インスタンスエンドポイント）
    → DocumentDB はストレージ自動拡張は可能だが、コンピュートリソースは手動スケールが必要。インスタンス単位接続は SPOF（単一障害点）となり可用性低下。
  • B（DocumentDB + クラスターエンドポイント）
    → クラスターエンドポイントは冗長性があるが、DocumentDB 自体が需要に基づいた自動スケーリングに対応していないため不適切。
  • C（DynamoDB + インターフェイスエンドポイント）
    → DynamoDB には追加料金なしで利用できる ゲートウェイ VPC エンドポイント がベストプラクティス。インターフェイスエンドポイントは余分なコストがかかる。

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

  • MongoDB → AWS マネージド代替の選択肢では、
    • DocumentDB：MongoDB互換だがコンピュートの自動スケール不可
    • DynamoDB：Key-Value/ドキュメントDBでオンデマンド自動スケール対応
  • VPC エンドポイントの使い分け
    • S3/DynamoDB → ゲートウェイ VPC エンドポイント
    • その他（Secrets Manager, SSM, API Gatewayなど）→ インターフェイス VPC エンドポイント
  • オンデマンドキャパシティは「予測不能な負荷」「従量課金」で最適。

👉 この問題は「DynamoDB オンデマンド + ゲートウェイ VPC エンドポイント」が模範解答になる典型パターンです。

次は 問題3 も同じ形式で整理しますか？

了解しました！問題3を指定フォーマットで整理しました。

■問題文

ある企業は、すべての機能を有効にした AWS Organizations で、全アカウントのコスト管理を実施したいと考えています。同社は組織単位 (OU) をビジネスユニットにマッピングしており、これらのビジネスユニットに個々の AWS の支出を請求したいと考えています。最近、同社の AWS の請求額が急増しており、財務チームから注目を集めています。ソリューションアーキテクトは、組織内の AWS コストを追跡し、あるビジネスユニットからのコストが特定の金額のしきい値を超えた場合に必要なチームへの通知を生成するソリューションを設計しながら、急増の原因を調査する必要があります。これらの要件を満たすソリューションを選択してください。

■選択肢

A：Cost Explorer を使用して、追加コストの理由をトラブルシューティングします。リンクされたアカウントをグループ化して、OU ごとに財務チームが設定した金額で AWS Budgets を使用して予算を作成します。予算内の必要なチームへの Amazon SNS 通知を設定します。

B：AWS Trusted Advisor を使用して、追加コストの理由をトラブルシューティングします。リンクされたアカウントをグループ化して、OU ごとに財務チームが設定した金額で AWS Budgets を使用して予算を作成します。社内で使用する Amazon EC2 インスタンスタイプを予算フィルターとして追加します。予算通知を受信するために、財務チームの E メールアドレスのサブスクリプションを設定した Amazon SNS トピックを設定します。

C：AWS Trusted Advisor を使用して、追加コストの理由をトラブルシューティングします。AWS Lambda 関数を設定して、OU 内の AWS アカウントごとに会社の AWS 請求額を監視します。財務チームが設定した金額のしきい値を AWS Systems Manager パラメータストアに保存します。Lambda 関数にカスタムルールを記述し、AWS アカウントの隠れたコストを確認します。予算のしきい値に違反した場合、Amazon SNS を使用して Lambda 関数から必要なチームに E メールをトリガーします。

D：Cost Explorer を使用して、追加コストの理由をトラブルシューティングします。AWS Lambda 関数を設定して、OU 内の AWS アカウントごとに会社の AWS 請求額を監視します。財務チームが設定した金額のしきい値を AWS Systems Manager パラメータストアに保存します。Lambda 関数にカスタムルールを記述し、AWS アカウントの隠れたコストを確認します。予算のしきい値に違反したときに、Lambda 関数から Amazon SNS トピックへの通知をトリガーします。

■問題文の要件の概要

  • AWS Organizations + 全アカウントコスト管理
  • OU 単位でコストを可視化・課金管理
  • コスト急増の原因を調査 → 可視化・分析が必要
  • しきい値超過時に通知 → 自動通知が必要

■正解の選択肢と解説

正解：A

  • Cost Explorer
    → アカウントや OU 単位でのコスト分析に最適。コスト急増の原因を可視化できる。
  • AWS Budgets
    → OU 単位の予算を設定可能。しきい値超過を Amazon SNS で通知できる。
  • OU 単位でのコスト管理要件と、通知機能による財務チーム対応をシンプルに満たす。

■不正解の選択肢の理由

  • B（Trusted Advisor + Budgets）
    → Trusted Advisor はリソース最適化やセキュリティベストプラクティス確認には有効だが、コスト分析・急増原因特定には不適切。
  • C（Trusted Advisor + Lambda）
    → コスト監視を Lambda で実装するのは過剰で、Budgets 機能を使えば済むため非効率。
  • D（Cost Explorer + Lambda）
    → Cost Explorer の分析は正しいが、監視と通知を Lambda で構築する必要はない。AWS Budgets がネイティブに対応しているため冗長。

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

  • コスト分析 → Cost Explorer
  • 予算設定 + 通知 → AWS Budgets + SNS
  • OU 単位でのコスト管理は Organizations と統合して実現可能
  • Trusted Advisor は「コスト最適化の推奨」には使うが、「急増原因分析」には向かない
  • 「Lambda で独自監視」は試験的に NG。既存マネージドサービス（Budgets, Cost Explorer）を優先

👉 この問題は 「Cost Explorer で原因調査」＋「AWS Budgets でしきい値監視とSNS通知」 がベスト解答になります。

次は 問題4 も同じフォーマットで整理しますか？

はい！問題4を指定フォーマットで整理しました。

■問題文

ソリューションアーキテクトは、ウェブアプリケーションのサポートに使用される Amazon RDS for PostgreSQL データベースのマルチリージョンアーキテクチャを設計する必要があります。データベースは、メインリージョンとセカンダリリージョンの両方で利用可能な AWS サービスと機能を活用する AWS CloudFormation テンプレートを使用して起動されます。

データベースは自動バックアップ用に設計されており、目標復旧時間 (RTO) は 15 分、目標復旧時点 (RPO) は 2 時間です。ウェブアプリケーションは、Amazon Route 53 レコードを使用してデータベースにトラフィックを送信するように設定されています。

すべての要件を満たす最も可用性の高いアーキテクチャになる一連の方法を選択してください。(2 つ選択)

■選択肢

A：プライマリリージョンで、障害が検出されたときに AWS Lambda 関数を呼び出すヘルスチェックをデータベースに作成します。Lambda 関数をプログラムして、セカンダリリージョンで最新のデータベーススナップショットからデータベースを再作成し、データベースの Route 53 ホストレコードを更新します。

B：最新の自動バックアップを 2 時間ごとにセカンダリリージョンにコピーする AWS Lambda 関数を作成します。

C：データベースの DNS レコード用に Route 53 でフェイルオーバールーティングポリシーを作成します。プライマリエンドポイントとセカンダリエンドポイントを各リージョンのエンドポイントに設定します。

D：セカンダリリージョンにホットスタンバイデータベースを作成します。AWS Lambda 関数を使用して、プライマリデータベースに障害が発生した場合に、セカンダリデータベースを最新の RDS 自動バックアップに復元します。

E：セカンダリリージョンにデータベースのクロスリージョンリードレプリカを作成します。セカンダリリージョンで AWS Lambda 関数を構成し、フェイルオーバーイベント中にリードレプリカを昇格させます。

■問題文の要件の概要

  • マルチリージョン構成（RDS for PostgreSQL）
  • RTO = 15分以内、RPO = 2時間以内
  • Route 53 による DNS ベースのフェイルオーバー
  • CloudFormation による自動構築
  • 高可用性を最優先

■正解の選択肢と解説

正解：C, E

  • C：Route 53 フェイルオーバールーティングポリシー
    → プライマリが利用できない場合、自動的にセカンダリリージョンのエンドポイントに切り替えられる。DNS ベースのフェイルオーバーで可用性を確保できる。
  • E：クロスリージョンリードレプリカ + Lambda による昇格
    → リードレプリカは非同期レプリケーションにより RPO 2時間を満たす。障害時に Lambda で昇格させることで RTO 15分以内で復旧可能。

■不正解の選択肢の理由

  • A
    → 障害時にスナップショットから再作成する方式では復旧に数十分〜数時間かかる可能性があり、RTO 15分を満たせない。
  • B
    → 自動バックアップのコピーは通常24時間ごとであり、Lambda で2時間ごとコピーしても RPO 2時間を確実に担保できない。
  • D
    → ホットスタンバイをバックアップから復元するアプローチは時間がかかりすぎ、RTO 15分を満たせない。

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

  • RPO と RTO の違いを正しく把握することが重要
    • RPO（復旧時点目標） → データ損失許容時間
    • RTO（復旧時間目標） → サービス復旧に要する時間
  • クロスリージョンリードレプリカ はマルチリージョン DR の基本選択肢
  • Route 53 フェイルオーバールーティング を使って自動切り替えを実現
  • バックアップからの復元は RTO が大きくなるため試験では NG
  • 「Lambda + 昇格」の組み合わせは DR シナリオで頻出

👉 この問題は 「Route 53 のフェイルオーバー」＋「クロスリージョンリードレプリカ」 がゴールデンパターンです。

次の 問題5 も整理しますか？

■問題文

企業のセキュリティコンプライアンス要件では、すべての Amazon EC2 イメージの脆弱性をスキャンし、CVE 評価に合格する必要があると規定されています。ソリューションアーキテクトは、開発者が使用できるセキュリティ承認済みの AMI を作成するメカニズムを開発しています。新しい AMI は、開発者が使用する前に、自動評価プロセスを経て、承認済みとしてマークする必要があります。コンプライアンスを確保するには、承認されたイメージを 30 日ごとにスキャンする必要があります。
ベストプラクティスに従いながら、ソリューションアーキテクトがこれらの要件を満たすために実行する必要がある手順の組み合わせを選択してください。 (2 つ選択）

■選択肢

A：AWS CloudTrail を使用して、スキャンが必要な AMI から起動された EC2 インスタンス上で CVE 評価を実行します。

B：AWS Lambda を使用して自動承認ルールを作成します。承認された AMI リストを AWS Systems Manager パラメータストアに保存します。すべての EC2 インスタンスで継続的にスキャンするためにマネージド AWS Config ルールを使用し、修復のために AWS Systems Manager Automation ドキュメントを使用します。

C：Amazon Inspector を使用して、スキャンが必要な AMI から起動した EC2 インスタンス上で CVE 評価を実行します。

D：AWS Lambda を使用して自動承認ルールを作成します。承認された AMI リストを AWS Systems Manager パラメータストアに保存します。Amazon EventBridge を使用して、30 日ごとにすべての EC2 インスタンス上で AWS Systems Manager Automation ドキュメントをトリガーします。

E：AWS Systems Manager EC2 エージェントを使用して、スキャンが必要な AMI から起動された EC2 インスタンスで CVE 評価を実行します。

■問題文の要件の概要

  • すべての AMI の脆弱性スキャンが必須
  • CVE 評価に合格したものだけを「承認済み AMI」として使用可能
  • 承認済みイメージも 30 日ごとに再スキャンする必要あり
  • 仕組みは自動化されていること（承認ルール、定期チェック）

■正解の選択肢と解説

C と D

  • C：Amazon Inspector
    • Amazon Inspector は EC2 インスタンスやコンテナイメージの 脆弱性スキャン（CVE評価） を自動で実施可能。
    • スキャンの結果に基づき、AMI 承認可否の判断ができるため要件を満たす。
  • D：Lambda + EventBridge + SSM
    • Lambda で承認ルールを自動化し、承認済み AMI リストを Systems Manager パラメータストア に保存。
    • EventBridge のスケジュールルール を使い、30 日ごとに SSM Automation ドキュメント を実行して再スキャンをトリガーする仕組みを構築。
    • これによりコンプライアンス要件の「30日ごとの再評価」を実現。

■不正解の選択肢の理由

  • A：CloudTrail で CVE 評価
    • CloudTrail は API 操作の監査ログを提供するサービス。CVE スキャン機能はなく要件を満たさない。
  • B：Config ルールで継続スキャン
    • AWS Config はリソースの構成準拠チェックを行うが、脆弱性スキャン機能は提供しない。
    • 継続的な定期スキャンを自動で実行する仕組みとしては不十分。
  • E：SSM エージェントで CVE 評価
    • SSM エージェントはコマンド実行や Automation を可能にするが、CVE スキャン機能そのものは持っていない。

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

  • 脆弱性スキャン＝Amazon Inspector が正解パターン
  • 再評価や定期実行＝EventBridge + SSM Automation がベストプラクティス
  • CloudTrail / Config / SSM Agent は「監査・設定管理・実行補助」であり、CVEスキャン用途では不適切
  • 承認済み AMI リストを Systems Manager パラメータストアに格納して管理する設計パターンは試験に頻出

この問題は「セキュリティ要件に応じたサービス選択」「Inspector の役割」「EventBridge による定期実行」の3点をセットで理解するのがポイントです。

■問題文

ソリューションアーキテクトは、Amazon EC2 インスタンスベースのアプリケーションをデバッグしています。EC2 インスタンスは、 Auto Scaling グループの一部として管理されています。このアプリケーションは、Amazon DynamoDB データベースに保存されたユーザーデータにアクセスする必要があります。追加の需要に対応するために、ソリューションアーキテクトは最近、Auto Scaling グループの最大サイズを引き上げました。現在、多くのインスタンスが同時に起動されると、一部のアプリケーションコンポーネントは、DynamoDB データベースをスキャンする際にスロットルされます。Auto Scaling グループは、すべてのアプリケーションが動作可能になるまで、障害が発生したインスタンスを停止させ、新しいインスタンスを作成します。なお、アプリケーションの需要は非常に予測が難しく、大きなスパイクが一時的に発生するため、設定した読み取り / 書き込み容量を超えるリクエストが発生しています。

ソリューションアーキテクトは、可能な限りコスト効率の高い方法でスロットルの問題を解決するソリューションを構築する必要があります。

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

■選択肢

A：DynamoDB テーブルのプロビジョニングされた読み取り容量を 2 倍にします。

B：DynamoDB Accelerator (DAX) をテーブルに追加します。

C：DynamoDB テーブルをオンデマンドモードに設定します。

D：DynamoDB テーブルを複製します。アプリケーションの実行中のコピーを構成して、アクセスするテーブルをランダムに選択します。

■問題文の要件の概要

  • Auto Scaling グループでインスタンス数が急増し、一時的に DynamoDB がスロットルされている。
  • トラフィックは予測困難でスパイク的。
  • コスト効率良くスロットルを防ぐ必要がある。

■正解の選択肢と解説

C：DynamoDB テーブルをオンデマンドモードに設定します。

  • オンデマンドモードはキャパシティ計画不要で、リクエスト数に応じて自動的にスケーリング。
  • スパイク的な負荷にも即応でき、利用した分だけ課金されるためコスト効率が良い。
  • 本問の「需要予測が難しくスパイク的」という条件に最も合致。

■不正解の選択肢の理由

  • A：プロビジョニング容量を 2 倍
    • スパイクが不定期かつ一時的なので、常時倍の容量を確保するとコスト浪費。
    • スパイクを完全に吸収できる保証もない。
  • B：DAX を追加
    • DAX はキャッシュによる読み取り性能向上が目的。
    • 書き込みスロットルやキャパシティ超過には直接対応できない。
  • D：テーブルを複製
    • ストレージコストが倍増し、アプリのロジックも複雑化。
    • データ整合性の維持が難しく、ベストプラクティスではない。

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

  • DynamoDB のスループット超過問題の解決策
    • 予測できるワークロード → プロビジョニング容量 + Auto Scaling
    • 予測困難 & スパイク型 → オンデマンドモード
  • DAX はキャッシュによる読み取り遅延解消用であり、スロットル防止やスパイク吸収の解決策ではない。
  • コスト効率と自動スケーリングの両立が求められるシナリオでは オンデマンドが正解。

👉 この問題は「DynamoDB 読み取り/書き込みモードの選択基準」を問う典型問題です。
次に貼っていただける問題も、この形式で整理しますか？

■問題文

ある会社が、静的ポートの TCP を使用してアクセスする新しいサービスを開発しています。ソリューションアーキテクトは、サービスの可用性が高く、アベイラビリティーゾーン全体に冗長性があり、パブリックにアクセス可能な DNS 名 my.service.com を使用してアクセスできることを保証しなければなりません。他社がそのアドレスを許可リストに追加できるように、サービスは固定アドレスの割り当てを使用する必要があります。リソースが単一のリージョン内の複数のアベイラビリティーゾーンにデプロイされていると仮定した場合、これらの要件を満たすソリューションはどれですか？

■選択肢

A：各インスタンスに Elastic IP アドレスを持つ Amazon EC2 インスタンスを作成します。Network Load Balancer (NLB) を作成し、静的 TCP ポートを公開します。EC2 インスタンスを NLB に登録します。my.service.com という名前のネームサーバーのレコードセットを新規に作成し、EC2 インスタンスの Elastic IP アドレスをレコードセットに割り当てます。EC2 インスタンスの Elastic IP アドレスを他社に提供し、許可リストに追加します。

B：サービス用の Amazon EC2 インスタンスを作成します。アベイラビリティーゾーンごとに 1 つの Elastic IP アドレスを作成します。Network Load Balancer (NLB) を作成し、割り当てられた TCP ポートを公開します。各アベイラビリティーゾーンの NLB に Elastic IP アドレスを割り当てます。ターゲットグループを作成し、EC2 インスタンスを NLB に登録します。my.service.com という名前の新しい A（エイリアス）レコードセットを作成し、NLB の DNS 名をレコードセットに割り当てます。

C：Amazon ECS クラスターとアプリケーションのサービス定義を作成します。ECS クラスターのパブリック IP アドレスを作成して割り当てます。Network Load Balancer (NLB) を作成し、TCP ポートを公開します。ターゲットグループを作成し、ECS クラスター名を NLB に割り当てます。my.service.com という名前の新しい A レコードセットを作成し、ECS クラスターのパブリック IP アドレスをレコードセットに割り当てます。ECS クラスターのパブリック IP アドレスを他社に提供し、許可リストに追加します。

D：Amazon ECS クラスターとアプリケーションのサービス定義を作成します。クラスター内の各ホストにパブリック IP アドレスを作成して割り当てます。Application Load Balancer (ALB) を作成し、静的 TCP ポートを公開します。ターゲットグループを作成し、ECS サービス定義名を ALB に割り当てます。新しい CNAME レコードセットを作成し、パブリック IP アドレスをレコードセットに関連付けます。Amazon EC2 インスタンスの Elastic IP アドレスを他社に提供して、許可リストに追加します。

■問題文の要件の概要

  • 高可用性（AZ 跨ぎ）
  • TCP 静的ポートでのアクセス
  • パブリックアクセス用 DNS 名（my.service.com）
  • 他社が許可リストに追加できるよう 固定 IP アドレス を使用
  • 単一リージョン・複数 AZ に展開

■正解の選択肢と解説

B：サービス用の Amazon EC2 インスタンスを作成し、NLB に Elastic IP を割り当てる構成

  • NLB はレイヤ 4（TCP/UDP）のロードバランサーで、静的 IP アドレスをサポート。
  • 各 AZ ごとに 1 つの Elastic IP を割り当て可能 → 他社の IP 許可リスト要件に適合。
  • Route 53 の A（エイリアス）レコードを NLB に設定することで、my.service.com でアクセス可能。
  • 冗長性（AZ 跨ぎ）、固定 IP、パブリック DNS、静的ポート公開をすべて満たす。

■不正解の選択肢の理由

  • A：Elastic IP を EC2 インスタンスに直接割り当ててしまっている。高可用性や冗長性を担保できず、NLB に EIP を付与していないため要件を満たさない。
  • C：ECS クラスターに「パブリック IP」を割り当てる概念はなく、NLB に ECS クラスター名を直接登録することもできない。誤り。
  • D：ALB はレイヤ 7（HTTP/HTTPS）向けであり、固定 IP を提供しない。また TCP 静的ポートを公開できないため要件を満たさない。

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

  • 固定 IP + 高可用性 + TCP → NLB + Elastic IP の組み合わせ。
  • ALB は固定 IP を提供しない → TCP/UDP 固定ポート要件には不適。
  • Route 53 の A エイリアスレコードを使って NLB の DNS 名と紐づけるのがベストプラクティス。
  • 「他社が IP を許可リストに追加できるように」＝ NLB に割り当てた EIP を提示する のが正解パターン。

👉 この問題は 「ロードバランサーの種類（ALB vs NLB）と Elastic IP の使い分け」 を理解しているかを確認する典型的な出題です。

次の問題もこの形式で整理しましょうか？

RELATED POST