Uncategorized

#19

 

以下に指定された形式で問題を整理・解説します。

■ 問題文（編集せずそのまま）

ある企業は、グローバルなスケーラビリティとパフォーマンスのために Amazon CloudFront を活用する複雑なウェブアプリケーションを持っています。時間が経つにつれて、ユーザーからウェブアプリケーションの速度が低下しているという報告がありました。
同社の運用チームは、CloudFront のキャッシュヒット率が着実に低下していると報告しています。キャッシュメトリクスレポートは、一部の URL のクエリ文字列の順序が一貫しておらず、大文字と小文字が混在した文字で指定されている場合と、小文字で指定されている場合があることを示しています。

キャッシュヒット率をできるだけ早く高める最適な一連の方法を選択してください。

■ 選択肢（編集せずそのまま）

A. Lambda@Edge 関数をデプロイして、パラメータを名前で並べ替え、強制的に小文字にします。CloudFront ビューワー (閲覧者) リクエストトリガーを選択して関数を呼び出します。

B. CloudFront ディストリビューションを更新して、クエリ文字列パラメータに基づいてキャッシュを無効にします。

C. ロードバランサーの後にリバースプロキシをデプロイして、アプリケーションで発行された URL を後処理し、URL 文字列を強制的に小文字にします。

D. CloudFront ディストリビューションを更新して、大文字と小文字を区別しないクエリ文字列処理を指定します。

■ 問題文の要件の概要

  • CloudFront のキャッシュヒット率が低下している。
  • 原因は、クエリ文字列の順序の違いや大文字・小文字の混在によるURLの非一貫性。
  • キャッシュヒット率をできるだけ早く高める方法を求めている。

■ 正解の選択肢と解説

✅ 正解：A. Lambda@Edge 関数をデプロイして、パラメータを名前で並べ替え、強制的に小文字にします。

解説：
CloudFront のキャッシュは URL の完全一致に依存するため、クエリ文字列の順序や大文字・小文字の違いによって別々にキャッシュされ、キャッシュヒット率が下がります。
Lambda@Edge 関数で以下を処理することで、URL を正規化し、キャッシュの一貫性を高めます：

  • クエリパラメータの順序をアルファベット順に並べ替える
  • パラメータを小文字化する

この処理は CloudFront の「ビューワーリクエスト」フェーズで行うことで、リクエストがキャッシュに到達する前に正規化されます。

■ 不正解の選択肢の理由

B. キャッシュを無効にする
→ キャッシュヒット率がさらに低下し、すべてのリクエストがオリジンに流れてパフォーマンス悪化。

C. リバースプロキシでURL後処理
→ CloudFront のキャッシュ前に処理されないため効果が薄い。また、構成が複雑になり遅延が発生。

D. 大文字小文字を区別しない処理
→ CloudFront にはそのような機能はない。加えて、順序の違いという問題はこの設定では解決しない。

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

  • CloudFront は URL（パス＋クエリ文字列）単位でキャッシュするため、一貫性が重要。
  • キャッシュ最適化のために Lambda@Edge を使って正規化処理（小文字化、並べ替えなど）を行える。
  • CloudFront の各フェーズ（ビューワーリクエスト、オリジンリクエストなど）で Lambda@Edge を使えることを押さえる。
  • キャッシュを無効にすることはパフォーマンス低下につながるリスクがあるため、避けるべきケースが多い。

必要であれば、Lambda@Edge の正規化スクリプトの例も提供できます。お気軽にどうぞ。

以下に問題2を指定の形式で整理・解説します。

■ 問題文（編集せずそのまま）

ある企業は、開発ワークロードと本番ワークロードを AWS Organizations の新しい組織に移行しています。同社は、開発用の独立したメンバーアカウントと本番用の独立したメンバーアカウントを作成しました。一括請求は管理アカウントにリンクされています。管理アカウントでは、ソリューションアーキテクトは、両方のメンバーアカウントのリソースを停止または終了できる IAM ユーザーを作成する必要があります。

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

■ 選択肢（編集せずそのまま）

A. 管理アカウントに IAM ユーザーとクロスアカウントロールを作成します。メンバーアカウントへの最小権限アクセスでクロスアカウントロールを構成します。

B. 各メンバーアカウントに IAM ユーザーを作成します。管理アカウントで、最小権限アクセスを持つクロスアカウントロールを作成します。信頼ポリシーを使用して、IAM ユーザーにクロスアカウントロールへのアクセスを許可します。

C. 管理アカウントで IAM ユーザーを作成します。メンバーアカウントで、最小権限アクセスを持つ IAM グループを作成します。管理アカウントの IAM ユーザーをメンバーアカウントの各 IAM グループに追加します。

D. 管理アカウントで IAM ユーザーを作成します。メンバーアカウントで、最小権限アクセスを持つクロスアカウントロールを作成します。信頼ポリシーを使用して、IAM ユーザーにロールへのアクセスを許可します。

■ 問題文の要件の概要

  • AWS Organizations配下で開発／本番のメンバーアカウントが存在
  • 管理アカウントのIAMユーザーから、両方のメンバーアカウントのリソース停止・終了が必要
  • アクセスは**最小権限（Least Privilege）**で制御すべき

■ 正解の選択肢と解説

✅ 正解：D. 管理アカウントで IAM ユーザーを作成します。メンバーアカウントで、最小権限アクセスを持つクロスアカウントロールを作成します。信頼ポリシーを使用して、IAM ユーザーにロールへのアクセスを許可します。

解説：
この構成は、クロスアカウントアクセスのベストプラクティスです。

  • 管理アカウント側に IAMユーザー を作成
  • メンバーアカウント側で 最小権限のIAMロール を作成（例：EC2の停止/終了権限のみ）
  • ロールの 信頼ポリシー により、管理アカウントのIAMユーザーが sts:AssumeRole できるようにする
    → 管理アカウントからロールをスイッチすることで、複数アカウントをセキュアに管理できる

■ 不正解の選択肢の理由

A. 管理アカウントにクロスアカウントロールを作成する
→ 誤り：クロスアカウントロールは**アクセスされる側（=メンバーアカウント）**に作成します。管理アカウントにロールを置いても、リソース操作対象にはなりません。

B. 各メンバーアカウントにIAMユーザーを作成する
→ 誤り：ユーザー管理が煩雑になります。セキュリティポリシー上も、一元管理されたIAMユーザー＋AssumeRole方式が推奨されます。

C. IAMグループを使って管理アカウントのユーザーをメンバーアカウントに追加する
→ 誤り：IAMはアカウント単位の閉じたスコープです。IAMユーザーは別アカウントのグループに所属できません。

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

  • クロスアカウントアクセスでは、ロールはアクセスされる側に作成し、アクセス元IAMユーザーにAssumeRoleを許可する。
  • IAMユーザーはグローバルに共有できないため、アクセス一元化にはJumpアカウント（管理アカウント）でのユーザー管理＋ロール切替が必須。
  • セキュリティの原則として、最小権限＋一元管理＋ロールベースアクセスは非常に重要。

必要であれば、AssumeRole設定例（IAMロール信頼ポリシー＋IAMユーザーのポリシー）も提供できます。お気軽にどうぞ！

以下に、問題3 を指定形式で整理・解説します。

■ 問題文（編集せずそのまま）

ソリューションアーキテクトは、AWS Elastic Beanstalk 内のアプリケーション環境を Blue/Green デプロイ方法を使用して更新する必要があります。ソリューションアーキテクトは、既存のアプリケーション環境と同じ環境を作成し、新しい環境にアプリケーションをデプロイします。

更新を完了するための最適な方法を選択してください。

■ 選択肢（編集せずそのまま）

A. Amazon Route 53 を使用して新しい環境にリダイレクトします。
B. [環境 URL のスワップ] オプションを選択します。
C. Auto Scaling の起動設定を置き換えます。
D. Green 環境を指すように DNS レコードを更新します。

■ 問題文の要件の概要

  • Elastic Beanstalk を使用している
  • Blue/Green デプロイを実施
  • アプリケーション更新後、トラフィックを 新しい環境（Green） に切り替えたい
  • 最適な（=安全かつ迅速な）方法を選ぶ必要がある

■ 正解の選択肢と解説

✅ 正解：B. [環境 URL のスワップ] オプションを選択します。

解説：
Elastic Beanstalk には Blue/Green デプロイのために専用の機能として [環境 URL のスワップ (Swap Environment URLs)] があります。
この機能は、既存環境（Blue）と新規環境（Green）の間で CNAMEレコード を即時に入れ替えるものであり、

  • トラフィックの切り替えが即時
  • DNS伝播の遅延がない
  • ダウンタイムをほぼゼロにできる
  • 問題があれば簡単にロールバック可能

といった利点があり、AWS が公式に推奨する方法です。

■ 不正解の選択肢の理由

A. Amazon Route 53 を使用して新しい環境にリダイレクト
→ Elastic Beanstalk の CNAME スワップと比べ、DNS変更は伝播に数分〜数時間かかる可能性があり、即時性に欠けるため Blue/Green には不適。

C. Auto Scaling の起動設定を置き換える
→ 起動設定の変更はインスタンスの構成変更に関する話で、環境そのものの切替ではない。Blue/Green の本質的な目的を果たさない。

D. Green 環境を指すように DNS レコードを更新する
→ Aと同様、DNS伝播の遅延問題あり。Elastic Beanstalk が提供する CNAMEスワップ機能 を使う方がベスト。

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

  • Elastic BeanstalkのBlue/Greenデプロイでは「環境URLのスワップ」機能が最も効率的で公式推奨手法
  • 「CNAMEレコードのスワップ」は、トラフィックの切り替えを高速・安全に行うベストプラクティス
  • DNSレベルでの手動切り替え（Route 53等）は、DNS伝播の遅延リスクがあるため非推奨
  • Elastic Beanstalk の Blue/Green デプロイは「環境まるごと複製＋切り替え」であることを理解

必要であれば、Blue/Greenデプロイの実践手順や Swap Environment URLs の操作画面の説明もできます。お気軽にどうぞ。

以下に問題4を指定形式で整理・解説します。

■ 問題文（編集せずそのまま）

Software-as-a-Service (SaaS) プロバイダーは、Application Load Balancer (ALB) を介して API を公開しています。ALB は、us-east-1 リージョンにデプロイされた Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに接続します。公開されている API には、いくつかの非標準的な REST メソッド (LINK、UNLINK、LOCK、UNLOCK) の使用が含まれています。

米国外のユーザーから、これらの API に対する応答時間が長く、一貫性がないという報告を受けています。ソリューションアーキテクトは、運用上のオーバーヘッドを最小限に抑えるソリューションでこの問題を解決する必要があります。

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

■ 選択肢（編集せずそのまま）

A. Amazon CloudFront ディストリビューションを追加します。ALB をオリジンとして構成します。
B. Amazon API Gateway エッジ最適化 API エンドポイントを追加して API を公開します。ALB をターゲットとして構成します。
C. AWS Global Accelerator にアクセラレータを追加します。ALB をオリジンとして構成します。
D. API を 2 つの追加の AWS リージョン (eu-west-1 と ap-southeast-2) にデプロイします。Amazon Route 53 にレイテンシーベースのルーティングレコードを追加します。

■ 問題文の要件の概要

  • ALB を介した API のレスポンスが「米国外」で遅く・不安定
  • API は非標準メソッドを含む（LINK、UNLINK など）
  • ソリューションは「運用のオーバーヘッドを最小化」する必要あり

■ 正解の選択肢と解説

✅ 正解：C. AWS Global Accelerator にアクセラレータを追加します。ALB をオリジンとして構成します。

解説：
AWS Global Accelerator は、世界中のユーザーからのトラフィックを最寄りの AWS エッジロケーションで受け取り、AWS グローバルネットワーク（専用バックボーン）を通じて ALB へ転送するサービスです。

  • 米国外ユーザーも レイテンシの少ない高速・安定な通信が可能
  • ALB や NLB をそのままオリジンにでき、既存構成を変える必要がほとんどない
  • SaaS 型 API において 非標準メソッドもサポート可能（L4/L7に依存しない）
  • グローバル展開に比べて最小限の運用コストでパフォーマンス向上

したがって、非標準APIでもそのままサポートでき、既存構成を変更せず導入できるGlobal Acceleratorが最適解です。

■ 不正解の選択肢の理由

A. CloudFront + ALB

  • CloudFrontは静的コンテンツキャッシュ向き
  • 非標準メソッド（LINK/UNLINKなど）を正しく処理できない
  • キャッシュ対象外でレイテンシ改善効果も小さい → ✕

B. API Gateway + ALB

  • API Gatewayは**標準HTTPメソッド(GET, POST, PUT, DELETE)**のみをサポート
  • 非標準メソッド（LINKなど）は受け付けずエラーとなる
  • さらに ALB をターゲットにする構成はそもそも推奨されない → ✕

D. 複数リージョン＋Route 53

  • マルチリージョン展開＋レイテンシールーティングは技術的に有効だが、
    • アプリのマルチリージョンデプロイ
    • データのレプリケーション
    • 管理・CI/CDの複雑化
  • これらにより運用オーバーヘッドが大きくなる → 問題要件「最小の運用負荷」に反する → ✕

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

  • 非標準メソッドや動的APIの高速化には、CloudFrontではなく Global Accelerator が適している
  • Global Accelerator は TCP/UDPベースの全てのトラフィックに対応
  • API Gateway や CloudFront は 標準RESTメソッドやキャッシュ前提であり、APIの制限がある
  • マルチリージョン展開は効果は高いが、コスト・運用の観点で慎重に

必要であれば、Global Accelerator 導入の具体手順や構成図も提供可能です。お気軽にどうぞ！

以下に、問題5 を指定の形式で整理・解説します。

■ 問題文（編集せずそのまま）

ソリューションアーキテクトは、企業が Amazon Workspaces で新しいセッションを確立できない問題を調査しています。初期分析の結果、この問題はユーザープロファイルに関係していることがわかりました。Amazon Workspaces 環境は、プロファイル共有ストレージとして Amazon FSx for Windows File Server を使用するように構成されています。FSx for Windows File Server のファイルシステムは、10 TB のストレージで構成されています。

ソリューションアーキテクトは、ファイルシステムが最大キャパシティに達していることを発見しました。ソリューションアーキテクトは、ユーザーが再びアクセスできるようにする必要があります。解決策は、問題の再発を防ぐことも必要です。

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

■ 選択肢（編集せずそのまま）

A. 古いユーザープロファイルを削除してスペースを確保します。ユーザープロファイルを Amazon FSx for Lustre ファイルシステムに移行します。
B. update-file-system コマンドを使用して容量を増やします。空き容量を監視する Amazon CloudWatch メトリクスを実装します。Amazon EventBridge を使用して AWS Lambda 関数を呼び出し、必要に応じて容量を増やします。
C. Amazon CloudWatch の FreeStorageCapacity メトリクスを使用して、ファイルシステムを監視します。必要に応じて AWS Step Functions を使用して容量を増やします。
D. 古いユーザープロファイルを削除して容量を確保します。FSx for Windows File Server のファイルシステムを追加作成します。50% のユーザーが新しいファイルシステムを使用するようにユーザープロファイルのリダイレクトを更新します。

■ 問題文の要件の概要

  • WorkSpaces のセッションが失敗 → 原因は FSx for Windows File Server の容量不足
  • ユーザーが再びアクセスできるようにすること（＝即時性）
  • 将来的な容量不足の再発防止策が必要
  • 運用の複雑化を避ける必要あり

■ 正解の選択肢と解説

✅ 正解：B. update-file-system コマンドを使用して容量を増やします。空き容量を監視する Amazon CloudWatch メトリクスを実装します。Amazon EventBridge を使用して AWS Lambda 関数を呼び出し、必要に応じて容量を増やします。

解説：
Amazon FSx for Windows File Server では、ストレージ容量をオンラインで拡張可能です（縮小は不可）。以下の方法が推奨されます：

  1. update-file-system API または CLI を用いてストレージを即時増加（ユーザーアクセス回復）
  2. CloudWatch メトリクス（例: FreeStorageCapacity） で空き容量を継続監視
  3. 閾値を下回った場合、EventBridge ルール を用いて Lambda 関数 で自動スケーリング
    → これにより、将来的な容量逼迫を事前に防止でき、運用負荷を増やさず高可用性を維持できます。

■ 不正解の選択肢の理由

A. FSx for Lustre に移行

  • Lustre は Linux HPC向けファイルシステム
  • Windows環境・SMB対応なし
  • WorkSpacesのユーザープロファイルに非対応 → ✕

C. Step Functions を使用

  • Step Functions は CloudWatch から 直接起動不可
  • EventBridge → Lambda → Step Functions のような間接構成が必要で即時対応しづらい
  • 自動スケーリング目的なら Lambda を直接呼び出すべき → ✕

D. 追加ファイルシステムにリダイレクト

  • 手動でユーザーのプロファイルパスを分割管理 → 運用が煩雑
  • プロファイルの整合性・一貫性が失われる可能性
  • 構成がスケーラブルでなく、再発リスクは残る → ✕

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

  • Amazon FSx for Windows File Server はオンライン拡張可能（増加のみ）
  • 容量の継続監視には CloudWatch + EventBridge + Lambda がベストプラクティス
  • FSxファミリーの違い（Windows/Lustre/OpenZFS）を理解
  • 重要な共有ストレージには スケーラブルな構成と監視・自動化対応が必要

必要であれば、CloudWatch アラーム、EventBridge、Lambda の構成例や Terraform 例も提供可能です。お気軽にどうぞ！

以下に問題6を指定形式で整理・解説します。

■ 問題文（編集せずそのまま）

ある企業は、大都市全体の交通パターンを監視する IoT センサーを備えています。同社は、センサーからデータを読み取り、収集し、データの集計を実行したいと考えています。

ソリューションアーキテクトは、IoT デバイスが Amazon Kinesis Data Streams にストリーミングするソリューションを設計します。複数のアプリケーションがストリームからデータを読み込んでいます。しかし、一部のコンシューマでスロットリングが発生し、定期的に ReadProvisionedThroughputExceeded エラーが発生します。

この問題を解決する最適な方法を選択してください。（3つ選択）

■ 選択肢（編集せずそのまま）

A. ストリームを再シャードして、ストリーム内のシャード数を増やします。
B. Kinesis Producer Library (KPL) を使用します。ポーリング頻度を調整します。
C. 拡張ファンアウト機能を備えたコンシューマを使用します。
D. ストリームを再シャードして、ストリーム内のシャード数を減らします。
E. コンシューマロジックでエラーの再試行とエクスポネンシャルバックオフメカニズムを使用します。
F. 動的パーティショニングを使用するようにストリームを構成します。

■ 問題文の要件の概要

  • Kinesis Data Streams でスロットリング（ReadProvisionedThroughputExceeded）が発生
  • 原因は コンシューマ側の読み取りスループットの限界
  • 複数のアプリケーションがストリームを読み取り
  • 対策はスループット向上とリトライ設計の見直しが必要

■ 正解の選択肢と解説

✅ A. ストリームを再シャードしてシャード数を増やす

理由：
Kinesis のスループットは シャード数に比例します。
各シャードの上限は 5 GetRecords/sec または 2MB/sec。
→ シャードを増やすことで処理能力を拡張し、スロットリングを緩和できます。

✅ C. 拡張ファンアウト機能を備えたコンシューマを使用

理由：
Kinesis の拡張ファンアウトを使うと、**1つのコンシューマに専用スループット（2MB/sec）**が割り当てられ、他のコンシューマと競合しません。
→ 通常のポーリングベースより高パフォーマンス。スロットリングを回避できます。

✅ E. エラーの再試行＋エクスポネンシャルバックオフ

理由：
ReadProvisionedThroughputExceeded は一時的なスロットリング。
→ 指数的に間隔を空けて再試行すれば、再試行成功の可能性が高くなり、全体のリクエスト効率が向上します。

■ 不正解の選択肢の理由

❌ B. Kinesis Producer Library (KPL) の使用

  • KPLはプロデューサー（書き込み）側のツール。
  • 今回の問題は コンシューマ側の読み取りスループットであり、無関係。

❌ D. シャード数を減らす

  • シャード数を減らすと、スループットも下がりスロットリングが悪化。

❌ F. 動的パーティショニングを使用

  • 動的パーティショニングは Kinesis Data Firehose 専用の機能。
  • Kinesis Data Streams では使用できず、本問題とは無関係。

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

  • Kinesis Data Streams のシャードごとのスループット制限を理解（GetRecords: 5回/sec or 2MB/sec）
  • 複数のコンシューマで読み取り競合が発生する場合は：
    • シャード数の増加（水平スケーリング）
    • 拡張ファンアウト（専用帯域）
    • 再試行＋バックオフ（スロットリング時の定番対処）
  • KPL は Producer 専用ライブラリ、Firehose のパーティショニング機能とは非連携

必要であれば、シャードのスケーリング操作（CLIやAuto Scaling）や拡張ファンアウトの登録手順もご案内できます。お気軽にどうぞ！

以下に問題7を指定の形式でまとめて解説します。

■ 問題文（編集せずそのまま）

ある企業は AWS 上でイベントチケット発行プラットフォームを実行しており、プラットフォームの費用対効果を最適化したいと考えています。このプラットフォームは Amazon Elastic Kubernetes Service (Amazon EKS) と Amazon EC2 上にデプロイされ、Amazon RDS for MySQL DB インスタンスによってサポートされています。

同社は、AWS Fargate を使用して Amazon EKS 上で実行する新しいアプリケーション機能を開発しています。このプラットフォームでは、まれに需要のピークが発生します。需要の急増はイベントの日程によって異なります。

プラットフォームに最もコスト効率の高いセットアップを提供するソリューションを選択してください。

■ 選択肢（編集せずそのまま）

A.
EKS クラスターがベースライン負荷で使用する EC2 インスタンス用に、スタンダードリザーブドインスタンスを購入します。ピーク時に対応するため、スポットインスタンスを使用してクラスターをスケーリングします。年間の予測ピーク負荷に対応するために、データベース用に 1 年間の All Upfront (全前払い) のリザーブドインスタンスを購入します。

B.
EKS クラスターの中程度の負荷が予測される場合は、Compute Savings Plans を購入します。ピーク時のイベント日に基づいて、オンデマンドキャパシティー予約を使用してクラスターをスケーリングします。予測される基本負荷に対応するため、データベース用に 1 年間の No Upfront (前払い無し) のリザーブドインスタンスを購入します。ピーク時にデータベースのリードレプリカを一時的にスケールアウトします。

C.
EKS クラスターの予測ベース負荷に対応する EC2 Instance Savings Plans を購入します。ピーク時に対応するため、スポットインスタンスを使用してクラスターをスケーリングします。予測される基本負荷を満たすために、データベース用に 1 年間の All Upfront (全前払い) のリザーブドインスタンスを購入します。ピーク時に手動で DB インスタンスを一時的にスケールアップします。

D.
EKS クラスターの予測ベース負荷に対応する Compute Savings Plans を購入します。ピーク時に対応するため、スポットインスタンスを使用してクラスターをスケーリングします。予測される基本負荷に対応するために、データベース用に 1 年間の All Upfront (全前払い) のリザーブドインスタンスを購入します。ピーク時に手動で DB インスタンスを一時的にスケールアップします。

■ 問題文の要件の概要

  • イベントチケット発行プラットフォームのコスト最適化
  • EKS + EC2 + RDS 構成
  • 今後、Fargate も一部導入予定
  • イベント時など一時的なピーク負荷あり
  • 柔軟性・コスト効率・可用性のバランスを取る設計が必要

■ 正解の選択肢と解説

✅ B. Compute Savings Plans + オンデマンドキャパシティ予約 + No Upfront RI + リードレプリカ

理由：

  • Compute Savings PlansはEC2だけでなくFargateやLambdaにも適用可能で、EKSのような混在ワークロードに柔軟に対応できる。
  • オンデマンドキャパシティ予約により、イベント当日など確実なキャパシティ確保が可能。
  • データベースにはNo Upfront RIで柔軟性を保ちつつ割引を受け、初期費用を抑える。
  • ピーク時はリードレプリカで読み込みスケールアウトし、コスト効率よく性能を上げる。

■ 不正解の選択肢の理由

❌ A. スタンダードRI + スポット + All Upfront RI

  • スポットインスタンスは中断リスクあり → イベント日などの可用性が求められる時には不向き
  • スタンダードRIは柔軟性に欠ける（EKSに向いていない）
  • All Upfront RI は初期コストが大きく、柔軟性に欠ける

❌ C. EC2 Instance Savings Plans + スポット + All Upfront RI

  • EC2 Instance Savings PlansはFargateに適用されない → EKSにおけるFargate混在では不利
  • 手動スケールアップは自動化・即時性に欠け、運用負荷が高い
  • スポットも中断リスクがあり、信頼性に欠ける

❌ D. Compute Savings Plans + スポット + All Upfront RI + 手動スケールアップ

  • Compute Savings Plans の選択は良いが、スポットと手動スケールアップの組み合わせでは信頼性と迅速性に課題
  • 手動スケールは現代的なクラウド設計として不十分

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

  • Savings Plans の種類と適用範囲を明確に理解すること
    • Compute Savings Plans：最も柔軟。Fargate、Lambda も対象。複数サービスに跨る割引。
    • EC2 Instance Savings Plans：EC2 固定の割引で柔軟性はやや劣る。
  • スポットインスタンスは中断される可能性があるため、キャパシティ保証が必要な場面では避ける
  • オンデマンドキャパシティ予約は必要なときだけ使える即時・確実なリソース確保手段
  • RDSの読み込み性能向上にはリードレプリカが効果的。スケーラブルで自動化しやすい。

追加でSavings Plansやリードレプリカ、キャパシティ予約について図で整理することも可能です。必要であればお申し付けください。

RELATED POST