以下に、AWS SAP 試験問題を指定フォーマットで整理・解説いたします。
■ 問題文
ある企業が、Amazon EC2 インスタンスで新しいオンラインゲームを立ち上げようとしています。このゲームは世界中で利用できる必要があります。同社は、3 つの AWS リージョン us-east-1、eu-west-1、ap-southeast-1 でゲームを実行することを計画しています。ゲームのリーダーボード、プレイヤーのインベントリ、イベントのステータスはリージョン間で利用できる必要があります。
ソリューションアーキテクトは、すべてのリージョンの負荷を処理するために、どのリージョンにも拡張能力を与えるソリューションを設計する必要があります。さらに、ユーザーは遅延が最も少ないリージョンに自動的に接続する必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢
A.
EC2 スポットフリートを作成します。スポットフリートを各リージョンの Network Load Balancer (NLB) に接続します。NLB を指す AWS Global Accelerator IP アドレスを作成します。Global Accelerator IP アドレスに対して、Amazon Route 53 レイテンシーベースのルーティングエントリを作成します。各リージョンの Amazon RDS for MySQL DB インスタンスにゲームのメタデータを保存します。他のリージョンにリードレプリカを設定します。
B.
EC2 インスタンス用に Auto Scaling グループを作成します。Auto Scaling グループを各リージョンの NLB にアタッチします。各リージョンに、地理的近接性ルーティングを使用し、そのリージョンの NLB を指す Amazon Route 53 エントリを作成します。各リージョンの EC2 インスタンス上の MySQL データベースにゲームのメタデータを保存します。各リージョンのデータベース EC2 インスタンス間のレプリケーションを設定します。
C.
EC2 インスタンス用に Auto Scaling グループを作成します。Auto Scaling グループを各リージョンの NLB にアタッチします。各リージョンに、レイテンシーベースのルーティングを使用し、そのリージョンの NLB を指す Amazon Route 53 エントリを作成します。Amazon DynamoDB グローバルテーブルにゲームのメタデータを保存します。
D.
EC2 Global View を使用します。EC2 インスタンスを各リージョンにデプロイします。インスタンスを NLB にアタッチします。各リージョンの EC2 インスタンスに DNS サーバーをデプロイします。各 DNS サーバーにカスタムロジックを設定して、遅延が最も短いリージョンにユーザーをリダイレクトします。Amazon Aurora Global Database にゲームのメタデータを保存します。
■ 問題文の要件の概要
- マルチリージョン構成（us-east-1、eu-west-1、ap-southeast-1）
- グローバルに利用できるオンラインゲーム
- ゲームメタデータ（リーダーボード等）のリージョン間共有
- ユーザーは最小遅延のリージョンに自動接続
- スケーラビリティの確保（どのリージョンにも拡張能力）
- 運用オーバーヘッド最小化
■ 正解の選択肢と解説
✅ C. Auto Scaling + Route 53 レイテンシールーティング + DynamoDB グローバルテーブル
- Auto Scaling + NLB：各リージョンのトラフィックに対応できるスケーラブルな設計。
- Route 53 レイテンシールーティング：ユーザーを最も遅延の少ないリージョンに誘導。
- DynamoDB グローバルテーブル：グローバルに一貫性を保ちつつ、マルチリージョン同期。データ同期もフルマネージド。
これにより、アプリケーションは高可用性・低レイテンシ・整合性の高いグローバル展開を実現し、しかも運用の手間が最小限になります。
■ 不正解の選択肢の理由
🔸 A. スポットフリート + RDS リードレプリカ
- スポットインスタンスはコスト面では有利だが、突然終了のリスクがあり、ゲームの安定性に不向き。
- RDS リードレプリカはリージョン間で非同期レプリケーション → 一貫性保証が難しい。
🔸 B. 地理的近接ルーティング + MySQL EC2 レプリケーション
- 地理的近接ルーティングはレイテンシベースではないため、最も速いリージョンを選ぶわけではない。
- EC2 上の MySQL を各リージョンでレプリケーションする構成は、管理が煩雑でデータ整合性の保証も弱い。
🔸 D. EC2 Global View + カスタム DNS + Aurora Global DB
- EC2 Global View は可視化ツールで、ルーティングや制御は行わない。
- カスタム DNS によるリダイレクトは高コスト・高オーバーヘッド。
- Aurora Global DB はレプリカへの書き込み制限があり、マルチアクティブに適さない。
■ SAP試験で押さえておくべきポイント
- DynamoDB グローバルテーブル：マルチリージョン・マルチアクティブなデータ同期のベストプラクティス。
- Route 53 レイテンシールーティング：ユーザーを最も速いリージョンにルーティングしたい時に有効。
- Auto Scaling + NLB の組み合わせ：スケーラブルな構成を複数リージョンに展開する基本。
- Aurora Global DB と DynamoDB Global Tables の違い：Aurora はリードレプリカ中心、DynamoDB は全リージョンでアクティブ書き込み可能。
- マルチリージョン設計では、低レイテンシ、整合性、運用性のバランスを考慮する
続けて他の問題も分析したい場合は、HTML形式でご送信ください。
以下、AWS SAP問題2について、指定のフォーマットで整理・解説いたします。
■ 問題文
オンラインマガジンが今月、最新号を創刊します。世界中に配信されるのは、この版が初めてになります。このマガジンの動的なウェブサイトは現在、ウェブ層の前に Application Load Balancer、ウェブおよびアプリケーションサーバー用の Amazon EC2 インスタンスのフリート、および Amazon Aurora MySQL を使用しています。ウェブサイトの一部には静的コンテンツが含まれており、ほぼすべてのトラフィックは読み取り専用です。
同誌は、新版が発売されるとインターネットトラフィックが大幅に急増すると予想しています。発売後 1 週間は、最適なパフォーマンスが最優先事項となります。
世界中のユーザーのシステム応答時間を短縮する最適な手順の組み合わせを選択してください。（2 つ選択）
■ 選択肢
A. 論理的なクロスリージョンレプリケーションを使用して、Aurora MySQL データベースをセカンダリリージョンにレプリケートします。ウェブサーバーを Amazon S3 に置き換えます。S3 バケットをクロスリージョンレプリケーションモードでデプロイします。
B. ウェブ層とアプリケーション層がそれぞれ Auto Scaling グループにあることを確認します。AWS Direct Connect 接続を導入します。ウェブ層とアプリケーション層を世界中のリージョンにデプロイします。
C. データベースを Amazon Aurora から Amazon RDS for MySQL に移行します。ウェブ、アプリケーション、データベースの 3 つのアプリケーション層がすべてプライベートサブネットにあることを確認します。
D. 物理的なクロスリージョンレプリケーションには Aurora Global Database を使用します。静的コンテンツとリソースには、クロスリージョンレプリケーションで Amazon S3 を使用します。ウェブ層とアプリケーション層を世界中のリージョンにデプロイします。
E. レイテンシーベースのルーティングと Amazon CloudFront ディストリビューションを備えた Amazon Route 53 を導入します。ウェブ層とアプリケーション層がそれぞれ Auto Scaling グループにあることを確認します。
■ 問題文の要件の概要
- 世界中に配信される動的ウェブサイト
- 静的コンテンツあり、トラフィックは読み取り中心
- 創刊号リリース時にトラフィック急増
- 1週間は最適なパフォーマンスが最優先
- 応答時間短縮が目的（特にグローバルなレイテンシー対策）
■ 正解の選択肢と解説
✅ D. Aurora Global Database + S3クロスリージョンレプリケーション + マルチリージョン展開
→ Aurora Global Database によって、世界中に分散された読み取りレプリカが提供され、データベースアクセスのレイテンシーを削減できる。また、S3クロスリージョンレプリケーションで静的コンテンツを近くに配置することで、遅延をさらに軽減できる。ウェブ・アプリ層のマルチリージョン展開も、レイテンシー削減に有効。
✅ E. Route 53 レイテンシールーティング + CloudFront + Auto Scaling
→ CloudFront により静的コンテンツをエッジでキャッシュし、Route 53 のレイテンシールーティングでユーザーを最も近いリージョンへ誘導可能。さらに Auto Scaling によって一時的なアクセス急増にも自動で対応できる。
■ 不正解の選択肢の理由
❌ A. S3にWebサーバーを置き換える + Aurora論理レプリケーション
→ 静的コンテンツならS3でも良いが、動的なWebアプリケーションにはS3は不適。また、Auroraの「論理的」レプリケーションでは、物理レプリケーション（Aurora Global DB）に比べて遅延が大きく、グローバルな読み取り性能に不利。
❌ B. AWS Direct Connectを導入
→ Direct Connect はオンプレミスとの専用線接続用。今回は世界中のインターネットユーザーが対象なので不要。無関係な選択肢。
❌ C. Aurora → RDSへの移行 + プライベートサブネット化
→ RDS for MySQL は Aurora よりスケーラビリティとパフォーマンスで劣る。移行は逆効果。また、プライベートサブネット化はセキュリティ向上にはなるが、パフォーマンス改善には直結しない。
■ SAP試験で押さえておくべきポイント
- Aurora Global Database：グローバルな読み取り性能・フェイルオーバーに最適。複数リージョンで高速レプリケーション（レイテンシー 1 秒未満）。
- Amazon S3のクロスリージョンレプリケーション：静的コンテンツの高速配信用。
- CloudFront：CDNとしてグローバルキャッシュ、レイテンシー削減。
- Route 53のレイテンシールーティング：ユーザーから最も近いリージョンへトラフィックをルーティング。
- Auto Scaling：突発的な負荷に自動対応できる。必須の冗長性・スケーラビリティ対策。
引き続き別の問題があれば、同様に分析いたしますので送ってください。
以下、AWS SAP問題3について、指定の形式で整理・解説いたします。
■ 問題文
ある会社は、何千もの気象観測所からの気象データを分析するソリューションを持っています。気象観測所は、AWS Lambda 関数を統合した Amazon API Gateway REST API を介してデータを送信します。Lambda 関数は、データの前処理のためにサードパーティーのサービスを呼び出します。サードパーティーのサービスが過負荷になり、前処理に失敗し、データの損失が発生しました。
ソリューションアーキテクトは、ソリューションの復元力を向上させる必要があります。ソリューションアーキテクトは、データが失われず、障害が発生しても後でデータを処理できることを保証する必要があります。
これらの要件を満たす最適な方法を選択してください。
■ 選択肢
A. Amazon Simple Queue Service (Amazon SQS) キューを作成します。そのキューを API のデッドレターキューとして構成します。
B. プライマリキューとセカンダリキューの 2 つの Amazon SQS キューを作成します。セカンダリキューを、プライマリキューのデッドレターキューとして設定します。プライマリキューへの新しい統合を使用するように API を更新します。Lambda 関数をプライマリキューの呼び出しターゲットとして設定します。
C. プライマリイベントバスとセカンダリイベントバスの 2 つの Amazon EventBridge イベントバスを作成します。プライマリイベントバスへの新しい統合を使用するように API を更新します。プライマリイベントバス上のすべてのイベントに反応するように EventBridge ルールを構成します。ルールのターゲットとして Lambda 関数を指定します。セカンダリイベントバスを Lambda 関数の障害発生先として構成します。
D. カスタム Amazon EventBridge イベントバスを作成します。そのイベントバスを Lambda 関数の障害発生先として設定します。
■ 問題文の要件の概要
- 気象観測所から継続的にデータが送信される
- API Gateway → Lambda → サードパーティ前処理という流れ
- サードパーティサービス障害で前処理失敗 → データ消失
- 要件：障害時にもデータを失わず、後で再処理できるようにする復元力の高い設計
■ 正解の選択肢と解説
✅ B. プライマリ・セカンダリ SQS構成を導入し、API統合とLambdaを更新
→ SQS を API Gateway の統合ターゲットとすることで、データはまずキューに入り、後続処理が失敗してもデータが保持される。
さらに、Lambda 処理で失敗したメッセージをデッドレターキュー（DLQ）に転送することで、問題があるメッセージの調査・再処理が可能。
結果として、サードパーティサービスが過負荷でも、データ損失を防ぎ、復旧も容易。
■ 不正解の選択肢の理由
❌ A. APIのDLQとしてSQSを設定
→ API Gateway に DLQ の概念は存在しない。DLQ はメッセージングサービスに対する設定であり、API から直接失敗したデータを SQS に送ることはできない。
また、処理前にSQSを介さない構成ではデータ損失のリスクが残るため、根本的な対策にならない。
❌ C. EventBridgeのプライマリ・セカンダリイベントバス
→ EventBridge はイベントルーティングには優れているが、確実なメッセージ保持・再試行管理には不向き。
DLQ相当の機能が不完全で、高信頼のバッファリング用途には SQS の方が適している。
❌ D. Lambdaの障害発生先として EventBridge を設定
→ Lambda に EventBridge を直接障害発生先（DLQ）として設定する機能は存在しない。DLQ を設定するには、SQS または SNS を使用する必要がある。
また、EventBridge に送られたイベントはすぐにルーティングされるため、バッファリングや再試行の保証は弱い。
■ SAP試験で押さえておくべきポイント
- ✅ SQS + DLQ の基本構成
- 耐障害性・データ損失防止に最も強力な設計パターン
- Lambda関数や他のサービスが処理失敗しても、メッセージを安全に保持可能
- 再処理可能な構造を構築できる
- ✅ DLQ（Dead Letter Queue）とは
- 処理失敗したメッセージを隔離して再確認・再処理するためのキュー
- プライマリ → DLQ という2段構成が一般的
- ❌ EventBridgeはメッセージ蓄積に向かない
- イベント駆動アーキテクチャには良いが、大量・継続データの保管・再処理用途には不向き
- ✅ API Gateway → SQS → Lambdaという構成は、信頼性重視の設計で頻出パターン
別の問題もあれば続けてどうぞ！引き続き分析をサポートします。
以下、AWS SAP問題4について、指定の形式で整理・解説いたします。
■ 問題文
企業は環境データを処理しています。同社はセンサーを設置し、都市のさまざまなエリアから継続的にデータを収集しています。データは JSON 形式で提供されます。
同社は、AWS ソリューションを使用して、保存に固定スキーマを必要としないデータベースにデータを送信したいと考えています。データはリアルタイムで送信する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢
A. Amazon Kinesis Data Firehose を使用して Amazon Redshift にデータを送信します。
B. Amazon Kinesis Data Streams を使用して Amazon DynamoDB にデータを送信します。
C. Amazon Managed Streaming for Apache Kafka (Amazon MSK) を使用して Amazon Aurora にデータを送信します。
D. Amazon Kinesis Data Firehose を使用して、Amazon Keyspaces (Apache Cassandra 用) にデータを送信します。
■ 問題文の要件の概要
- センサーから継続的に JSON データを収集
- データはリアルタイムで送信する必要がある
- 固定スキーマが不要なデータベースに保存したい（≒スキーマレス）
■ 正解の選択肢と解説
✅ B. Amazon Kinesis Data Streams を使用して Amazon DynamoDB にデータを送信します。
→ この組み合わせは以下の要件すべてを満たします：
- Kinesis Data Streams はリアルタイムのデータストリーミングに最適
- Amazon DynamoDB は NoSQL 型で、スキーマレス（柔軟なデータ構造）をサポート
- JSON データの格納にも適しており、IoT やセンサーデータにもよく使われる組み合わせ
■ 不正解の選択肢の理由
❌ A. Kinesis Data Firehose → Redshift
→ Redshift はリレーショナルデータウェアハウスであり、固定スキーマが必須。また、Kinesis Firehose はバッチ転送に向いておりリアルタイム性に欠ける。
❌ C. Amazon MSK → Aurora
→ Aurora はリレーショナル DB（固定スキーマ）。JSON のような柔軟なデータ形式には不向き。また、Kafka は構築・管理が複雑で、リアルタイム性はあるがこの要件には過剰。
❌ D. Kinesis Firehose → Amazon Keyspaces
→ Amazon Keyspaces はスキーマレスだが、Kinesis Firehose は直接 Keyspaces に配信できない。このため組み合わせが実現不可能。
■ SAP試験で押さえておくべきポイント
✅ Kinesis Data Streams vs Firehose
| 特性 | Kinesis Data Streams | Kinesis Data Firehose |
|---|---|---|
| リアルタイム性 | 高い | 中程度（バッチ転送） |
| データ保持 | 最大 365 日 | 一時的（バッファリング） |
| ターゲット | Lambda, Kinesis Analytics, etc. | S3, Redshift, OpenSearch, etc. |
✅ DynamoDB の特性
- NoSQL（スキーマレス）
- JSON 形式のデータ格納に適している
- 高速・スケーラブルで、IoTやセンサーデータに多用される
✅ Aurora や Redshift の違い
- Aurora：リレーショナル、スキーマ必須
- Redshift：分析用、固定スキーマ、大量データバッチ向き
- Keyspaces：NoSQLだが、Kinesis Firehose は対応していない
別の問題も引き続き送ってください。リアルタイム性やストレージ要件など、よく問われるテーマです。
以下、AWS SAP 問題5について、指定フォーマットで整理・解説いたします。
■ 問題文
大手給与会社は最近、小規模な人材派遣会社と合併しました。統合された会社には複数の事業部門があり、それぞれが既存の AWS アカウントを持っています。
ソリューションアーキテクトは、企業がすべての AWS アカウントの請求ポリシーとアクセスポリシーを一元管理できることを確認する必要があります。ソリューションアーキテクトは、集中管理アカウントから会社のすべてのメンバーアカウントに招待を送信することにより、AWS Organizations を構成します。
これらの要件を満たすために、ソリューションアーキテクトは次に何をすべきですか ?
■ 選択肢
A. 各メンバーアカウントに OrganizationAccountAccess IAM グループを作成します。各管理者に必要な IAM ロールを含めます。
B. 各メンバーアカウントに OrganizationAccountAccessPolicy IAM ポリシーを作成します。クロスアカウントアクセスを使用して、メンバーアカウントを管理アカウントに接続します。
C. 各メンバーアカウントに OrganizationAccountAccessRole IAM ロールを作成します。管理アカウントに IAM ロールを引き受けるアクセス許可を付与します。
D. 管理アカウントに OrganizationAccountAccessRole IAM ロールを作成します。IAM ロールに AdministratorAccess AWS 管理ポリシーをアタッチします。各メンバーアカウントの管理者に IAM ロールを割り当てます。
■ 問題文の要件の概要
- 複数の AWS アカウント（合併で発生）を 統合管理 したい
- 請求とアクセスの一元管理 が必要
- AWS Organizations を使用して組織構築 済み
- 次のアクション：一元アクセス管理の設定
■ 正解の選択肢と解説
✅ C. 各メンバーアカウントに OrganizationAccountAccessRole IAM ロールを作成します。管理アカウントに IAM ロールを引き受けるアクセス許可を付与します。
→ AWS Organizations を使用してアカウントを一元管理する際は、管理アカウントがメンバーアカウントにクロスアカウントでアクセスできる仕組みが必要。
このため、メンバーアカウントに OrganizationAccountAccessRole という名前の IAM ロールを作成し、信頼ポリシーに管理アカウントからの sts:AssumeRole を許可するのが正しいアプローチ。
このロールは新規アカウント作成時には自動生成されるが、既存アカウントを組織に招待した場合は手動で作成が必要。
■ 不正解の選択肢の理由
❌ A. IAM グループを作成し、管理者にロールを含める
→ IAM グループはユーザー管理のためのものであり、アカウント間アクセスや Organizations のアクセス制御には使用しない。
❌ B. OrganizationAccountAccessPolicy IAM ポリシーを作成しクロスアカウントアクセスを構成
→ そもそも OrganizationAccountAccessPolicy というポリシーは存在しない。また、ポリシーだけではクロスアカウントのアクセス権を設定できず、AssumeRole を許可する IAM ロールの設定が必要。
❌ D. 管理アカウントにロールを作成して各メンバーに割り当てる
→ ロールは引き受けられる側（＝メンバーアカウント）に作成しなければならない。
この選択肢では方向が逆であり、クロスアカウントアクセスとして正しくない。
■ SAP試験で押さえておくべきポイント
✅ AWS Organizations でのアクセス一元管理の仕組み
- 管理アカウントがメンバーアカウントの IAM ロールを引き受けることで一元管理を実現
- IAM ロール名は通常
OrganizationAccountAccessRole - 新規アカウント作成時は自動作成されるが、既存アカウント招待時は手動作成が必要
✅ IAM ロールと sts:AssumeRole の理解
- クロスアカウントアクセスでは、IAM ロールの信頼ポリシーで
sts:AssumeRoleを許可することが必須 - 管理アカウント側から
AssumeRoleを使って操作する流れをイメージできるようにしておく
✅ 誤答肢に多い混乱点
- IAM グループや IAM ポリシーだけではアカウント間アクセスは構成できない
- ロールはアクセスされる側に配置するもの（アクセスする側ではない）
この問題は SAP 試験で頻出の「Organizations を用いたマルチアカウント管理」に関する典型問題です。
次の問題もお送りください、続けて対応いたします。
以下、AWS SAP 問題6について、指定フォーマットに基づき解説します。
■ 問題文
ソリューションアーキテクトは、既存の VPC の DNS 戦略を決定しています。VPC は 10.24.34.0/24 CIDR ブロックを使用するようにプロビジョニングされています。また、VPC は DNS に Amazon Route 53 Resolver を使用しています。新しい要件では、DNS クエリはプライベートホストゾーンを使用する必要があります。さらに、パブリック IP アドレスを持つインスタンスは、対応するパブリックホスト名を受け取る必要があります。
VPC 内でドメイン名が正しく解決されることを保証するために、これらの要件を満たすソリューションを選択してください。
■ 選択肢
A. プライベートホストゾーンを作成します。VPC の enableDnsSupport 属性と enableDnsHostnames 属性を有効にします。VPC の DHCP オプションセットを更新して、domain-name-servers = 10.24.34.2 を含めます。
B. プライベートホストゾーンを作成して プライベートホストゾーンを VPC に関連付けます。VPC の enableDnsSupport 属性と enableDnsHostnames 属性を有効にします。新しい VPC の DHCP オプションセットを作成し、domain-name-servers = AmazonProvidedDNS を設定します。新しい DHCP オプションセットを VPC に関連付けます。
C. VPC の enableDnsSupport 属性を無効にします。VPC の enableDnsHostnames 属性を有効にします。新しい VPC の DHCP オプションセットを作成し、domain-name-servers = 10.24.34.2 を構成します。新しい DHCP オプションセットを VPC に関連付けます。
D. プライベートホストゾーンを作成します。プライベートホストゾーンを VPC に関連付けます。VPC の enableDnsSupport 属性を有効にします。VPC の enableDnsHostnames 属性を無効にします。VPC の DHCP オプションセットに domain-name-servers = AmazonProvidedDNS が含まれるように更新します。
■ 問題文の要件の概要
- DNS 解決に プライベートホストゾーン（Private Hosted Zone）を使用する
- パブリック IP アドレス付き EC2 インスタンスには パブリック DNS ホスト名が割り当てられる必要がある
- VPC は Amazon Route 53 Resolver を使用（つまり
AmazonProvidedDNSの使用が前提）
■ 正解の選択肢と解説
✅ B. プライベートホストゾーンを作成して プライベートホストゾーンを VPC に関連付けます。VPC の enableDnsSupport 属性と enableDnsHostnames 属性を有効にします。新しい VPC の DHCP オプションセットを作成し、domain-name-servers = AmazonProvidedDNS を設定します。新しい DHCP オプションセットを VPC に関連付けます。
→ この選択肢は、以下の全要件を満たす構成です：
- プライベートホストゾーン作成＆VPCに関連付け → Private DNS 解決を可能にする
- enableDnsSupport = true → DNS クエリが Route 53 Resolver に転送される
- enableDnsHostnames = true → EC2 インスタンスにパブリック DNS ホスト名が割り当てられる（特にパブリック IP がある場合）
- DHCP オプションセットで
AmazonProvidedDNSを使用 → Route 53 Resolver に正しく接続される
■ 不正解の選択肢の理由
❌ A
10.24.34.2を DNS サーバーとして指定 → AmazonProvidedDNS ではないため非推奨- プライベートゾーンの条件は満たしても、正しい名前解決ができない恐れ
❌ C
enableDnsSupport = false→ DNS 名前解決自体ができなくなる- 根本的に DNS 動作が無効になるため、ホストゾーンに関係なく失敗
❌ D
enableDnsHostnames = false→ インスタンスにパブリックホスト名が割り当てられない- 問題文の「パブリック IP を持つインスタンスはホスト名が必要」に反する設定
■ SAP試験で押さえておくべきポイント
✅ VPC での DNS 解決要件
enableDnsSupport = true：VPC で DNS クエリを有効にするenableDnsHostnames = true：ホスト名（パブリック/プライベート）が付与される- DHCP オプションセットには
AmazonProvidedDNSを指定するのが基本
✅ プライベートホストゾーンの要点
- Route 53 プライベートホストゾーンは、特定の VPC に紐づけて内部 DNS 解決を提供
- EC2 間で名前解決する際によく使われる
✅ DHCP オプションセットの設定
domain-name-servers = AmazonProvidedDNSを忘れずに設定- 指定しない場合、デフォルトが使われるが、明示的にセットするのがベストプラクティス
この問題は、VPC、Route 53、DHCP オプションの基礎的な連携知識が問われる定番テーマです。次の問題もお待ちしております。
以下は、SAP試験の問題7に対する解説と整理です。
■ 問題文
ある企業が、ワークロード用に Amazon Elastic Kubernetes Service (Amazon EKS) クラスターのデプロイを準備しています。同社は、このクラスターが予測不可能な数のステートレス Pod をサポートすることを期待しています。ワークロードが使用するレプリカの数がワークロードによって自動的にスケーリングされるため、Pod の多くは短期間に作成されます。
ノードの復元力を最大化するソリューションを選択してください。
■ 選択肢
A. 別の起動テンプレートを使用して、EKS コントロールプレーンをワークロードノードグループとは別の 2 番目のクラスターにデプロイします。
B. ワークロードノードグループを更新します。ノードグループの数を少なくし、ノードグループのインスタンスを大きくします。
C. Kubernetes Cluster Autoscaler を構成して、ワークロードノードグループのコンピューティング能力が不足しないようにします。
D. アベイラビリティーゾーンに基づく Topology Spread Constraints を使用するようにワークロードを構成します。
■ 問題文の要件の概要
- ステートレス Pod の急増・短命性に対応
- 自動スケーリングあり
- ノードの復元力（Resilience）を最大化する必要あり
- → 障害に強いノード分散がキー
■ 正解の選択肢と解説
✅ D. アベイラビリティーゾーンに基づく Topology Spread Constraints を使用するようにワークロードを構成します。
- Topology Spread Constraints は、Kubernetes の機能であり、Pod を複数のアベイラビリティーゾーン（AZ）やノードに均等に分散させる。
- これにより、特定のAZに障害が起きても残りのAZでPodが稼働し続け、ワークロードの高可用性とノード復元力が向上する。
- ステートレス Podは短期間で作成されることが多く、バランスよくAZに配置されることで障害耐性が強化される。
■ 不正解の選択肢の理由
❌ A. 別のクラスターにコントロールプレーンを分離
- EKS のコントロールプレーンは AWS 管理のサービスで、基本的に冗長化されている。
- 別クラスターに分けるのは管理分離にはなるが、復元力の向上とは無関係。
❌ B. ノードグループを少数にしてインスタンスを大型化
- 少数の大きなノードは、単一ノード障害のリスクが高くなる。
- スケーラビリティや復元性の観点では、小規模インスタンスを多く分散した方がよい。
❌ C. Cluster Autoscaler のみを構成
- スケーリングによる容量確保は有効だが、それだけではノードの復元力は保証されない。
- 特にAZ障害時の対応やPodの分散戦略には関与しないため、要件を満たさない。
■ SAP試験で押さえておくべきポイント
✅ Pod Topology Spread Constraints
topologySpreadConstraintsは Pod の配置戦略におけるKubernetesの機能。topologyKey: topology.kubernetes.io/zoneを使用することで、AZ間に均等配置が可能。- 高可用性設計の必須知識。
✅ EKSでの高可用性設計
- ノードは複数AZに分散
- Auto Scaling Group のAZ分散＋PodのTopology Spreadの併用がベストプラクティス
✅ Cluster Autoscaler vs Topology Constraints
- Cluster Autoscaler：ノードの数を増減する
- Spread Constraints：Podの配置場所を最適化
→ 両者は目的が異なるので混同しないこと
次の問題も送っていただければ、同様に丁寧に解説いたします。
