Uncategorized

#51

 

ありがとうございます！いただいた問題文を指定の形式で整理しました。

■問題文

ある企業は、チケット販売アプリケーションの信頼性を向上させる必要があります。このアプリケーションは、Amazon Elastic Container Service (Amazon ECS) クラスター上で実行されます。同社は、Amazon CloudFront を使用してアプリケーションを提供しています。ECS クラスターの単一の ECS サービスが、CloudFront ディストリビューションのオリジンです。

このアプリケーションでは、特定の数のアクティブユーザーのみがチケット購入フローに入ることができます。これらのユーザーは、JSON Web Token (JWT) の暗号化された属性によって識別されます。他のすべてのユーザーは、購入可能な容量ができるまで待合室モジュールにリダイレクトされます。

アプリケーションに高負荷が発生しています。待合室モジュールは設計どおりに動作していますが、待合室の負荷によりアプリケーションの可用性が損なわれています。この中断により、アプリケーションのチケット販売トランザクションに悪影響が出ています。

高負荷時にチケット販売トランザクションの信頼性が最も高くなるソリューションを選択してください。

■選択肢

A. 待合室用に ECS クラスター内に別のサービスを作成します。別のスケーリング設定を使用します。チケットサービスが JWT 情報を使用し、リクエストを待合室サービスに適切に転送することを確認します。

B. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移動します。待合室モジュールを、チケットポッドとは別のポッドに分割します。チケットポッドを StatefulSet の一部にします。チケットポッドが JWT 情報を使用し、リクエストを待合室ポッドに適切に転送することを確認します。

C. 待合室用に ECS クラスター内に別のサービスを作成します。別のスケーリング設定を使用します。JWT 情報を検査し、リクエストをチケットサービスまたは待合室サービスに適切に転送する CloudFront Functions を作成します。

D. アプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移動します。待合室モジュールを、チケットポッドとは別のポッドに分割します。Kubernetes 用の App Mesh コントローラーをプロビジョニングして、AWS App Mesh を使用します。チケットポッドと待合室ポッド間の通信に、mTLS 認証とサービス間認証を有効にします。チケットポッドが JWT 情報を使用し、リクエストを待合室ポッドに適切に転送することを確認します。

■問題文の要件の概要

  • アプリは ECS 上で稼働し、CloudFront がオリジン。
  • アクティブユーザーは JWT で識別され、それ以外は「待合室」にリダイレクトされる。
  • 高負荷時に待合室処理がオリジンに負担をかけ、チケット販売の可用性が低下。
  • 要件：高負荷時でも チケット販売処理の信頼性を維持する仕組み。

■正解の選択肢と解説

✅ C. CloudFront Functions を用いてエッジで JWT を検査し、待合室とチケットサービスにリクエストを振り分ける

  • CloudFront Functions を使うことで、オリジンに到達する前にリクエストを分類できる。
  • JWT 情報をエッジで判定 → 不要な待合室トラフィックを ECS に流さない。
  • ECS 内では待合室とチケット販売サービスを別サービスに分け、スケーリングを独立管理できる。
  • この設計により 販売トランザクションへの影響を最小化できる。

■不正解の選択肢の理由

A. ECS 内でサービス分離のみ

  • ECS に待合室を分離しても、判定がオリジンで行われるためトラフィック集中を防げない。
  • 高負荷時には待合室のスケーリングがチケットサービスに干渉し、可用性低下を招く。

B. EKS + StatefulSet

  • EKS への移行では本質的な問題解決にならない。
  • JWT 判定が依然としてオリジン側で行われるため待合室アクセスが殺到。
  • StatefulSet はスケーリング速度が遅く、高負荷への対応が不十分。

D. EKS + App Mesh + mTLS

  • mTLS でセキュリティは向上するが、CPU 負荷・レイテンシが増大。
  • JWT をエッジで判定しないためトラフィック集中は解決できない。
  • 保守も複雑化し、信頼性向上よりもオーバーヘッド増大につながる。

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

  • CloudFront Functions / Lambda@Edge の使い分け
    • CloudFront Functions → 軽量・超低レイテンシ（JWT チェック・リダイレクトなどの軽処理向き）。
    • Lambda@Edge → より重い処理（DB 参照や大規模変換）が必要なとき。
  • エッジでの処理が有効なユースケース
    • 大量リクエストをオリジンに到達させない設計。
    • CDN 層での認証・承認・リダイレクト処理。
  • ECS/EKS の比較
    • 信頼性課題の多くは「コンテナオーケストレーション」ではなく「エッジでのトラフィック制御」で解決する。
    • EKS/ECS の違いに惑わされず、本質的な負荷分散の場所を見極める。

この問題は「ECS vs EKS の移行ではなく、エッジでのリクエスト制御が肝」という点を見抜くことが重要です。

次の問題もこの形式で整理していきますか？

ありがとうございます！いただいた 問題2 を整理しました。

■問題文

北米の金融サービス企業は、クライアント向けに AWS で新しいオンラインウェブアプリケーションを立ち上げる予定です。この企業は、us-east-1 リージョンの Amazon EC2 インスタンスにアプリケーションをデプロイする予定です。プログラムは、ユーザートラフィックの増加に対応するために、可用性が高く、動的スケーリングが可能である必要があります。さらに、組織は、us-west-1 リージョンでアクティブ-パッシブフェイルオーバーを利用するアプリケーションのディザスタリカバリ環境を構築したいと考えています。これらの条件を満たすソリューションを選択してください。

■選択肢

A. us-east-1 に VPC を作成し、us-west-1 に VPC を作成します。VPC ピアリングを設定します。us-east-1 VPC に、複数のアベイラビリティーゾーンにある両方の VPC にまたがる Application Load Balancer (ALB) を作成します。両方の VPC の複数のアベイラビリティーゾーンに EC2 インスタンスをデプロイする Auto Scaling グループを作成します。Auto Scaling グループを ALB の後ろに配置します。

B. us-east-1 に VPC を作成し、us-west-1 に VPC を作成します。us-east-1 VPC に、その VPC 内の複数のアベイラビリティーゾーンにまたがる Application Load Balancer (ALB) を作成します。us-east-1 VPC の複数のアベイラビリティーゾーンに EC2 インスタンスをデプロイする Auto Scaling グループを作成します。Auto Scaling グループを ALB の後ろに配置します。us-west-1 VPC で同じ設定をセットアップします。Amazon Route 53 ホストゾーンを作成します。ALB ごとに個別のレコードを作成します。ヘルスチェックを有効にして、リージョン間の高可用性を確保します。

C. us-east-1 に VPC を作成し、us-west-1 に VPC を作成します。us-east-1 VPC に、その VPC 内の複数のアベイラビリティーゾーンにまたがる Application Load Balancer (ALB) を作成します。us-east-1 VPC の複数のアベイラビリティーゾーンに EC2 インスタンスをデプロイする Auto Scaling グループを作成します。Auto Scaling グループを ALB の後ろに配置します。us-west-1 VPC で同じ設定をセットアップします。Amazon Route 53 ホストゾーンを作成します。ALB ごとに個別のレコードを作成します。ヘルスチェックを有効にし、各レコードのフェイルオーバールーティングポリシーを構成します。

D. us-east-1 に VPC を作成し、us-west-1 に VPC を作成します。VPC ピアリングを設定します。us-east-1 VPC に、複数のアベイラビリティーゾーンにある両方の VPC にまたがる Application Load Balancer (ALB) を作成します。両方の VPC の複数のアベイラビリティーゾーンに EC2 インスタンスをデプロイする Auto Scaling グループを作成します。Auto Scaling グループを ALB の後ろに配置します。Amazon Route 53 ホストゾーンを作成します。ALB のレコードを作成します。

■問題文の要件の概要

  • 高可用性 + オートスケーリング（プライマリは us-east-1）
  • ディザスタリカバリ (DR) は us-west-1 を利用
  • アクティブ-パッシブフェイルオーバーを実現する必要がある
  • 適切な構成は「各リージョンに ALB + Auto Scaling」「Route 53 フェイルオーバーポリシーで制御」

■正解の選択肢と解説

✅ C. 各リージョンに ALB + Auto Scaling を配置し、Route 53 フェイルオーバールーティングを利用する

  • us-east-1：複数 AZ に ALB + Auto Scaling → 高可用性 + 動的スケーリング
  • us-west-1：同じ構成を DR 用に構築（スタンバイ）
  • Route 53：各 ALB をレコード登録し、フェイルオーバールーティングポリシーを設定
    • プライマリがダウンしたら自動的にセカンダリ（us-west-1）に切り替え
  • この設計により リージョン内冗長性 + リージョン間 DR を実現できる

■不正解の選択肢の理由

A. ALB を複数リージョンにまたがらせる構成

  • ALB は 単一リージョン・単一VPC 内でのみ利用可能。
  • VPC ピアリングをしても、us-west-1 のインスタンスを ALB のターゲットにはできない。

B. ALB レコードを作成してヘルスチェックのみ設定

  • ヘルスチェックだけでは アクティブ-パッシブが保証されない。
  • フェイルオーバーポリシーを明示しないと、トラフィックが両リージョンに分散する可能性がある。

D. VPC ピアリング + クロスリージョン ALB の前提

  • 技術的に ALB を クロスリージョンで構築することは不可能。
  • さらに Route 53 フェイルオーバーポリシーが設定されていないため DR 要件を満たさない。

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

  • ALB のスコープ → 単一リージョン・単一VPC内のみ。クロスリージョン不可。
  • Route 53 の役割 → リージョン間フェイルオーバーは DNS レイヤで制御。
  • フェイルオーバーポリシーを使わないとアクティブ-パッシブ構成にはならない。
  • DR 戦略の基本パターン（アクティブ-アクティブ vs アクティブ-パッシブ）を区別して理解。

👉 この問題は「リージョン内は ALB + Auto Scaling、リージョン間は Route 53 フェイルオーバー」という設計原則を理解しているかを試す典型問題です。

次の問題（問題3）もこの形式で整理していきますか？

ありがとうございます！いただいた 問題3 を整理しました。

■問題文

ある企業が、オンプレミス環境から AWS に多数の VM を移行することを計画しています。同社は、移行前のオンプレミス環境の初期評価、VM で実行されるアプリケーション間の依存関係の視覚化、オンプレミス環境の評価を提供するレポートが必要です。

これらの情報を得るために、同社は Migration Evaluator の評価リクエストを開始しました。同社は、オンプレミス環境に制約なくコレクターソフトウェアをインストールすることができます。

どのソリューションが、運用上のオーバーヘッドを最小限に抑えながら、必要な情報を提供できますか ?

■選択肢

A. 各オンプレミス VM に AWS Application Discovery Agent をインストールします。データ収集期間が終了したら、AWS Migration Hub を使用してアプリケーションの依存関係を表示します。Migration Hub から Quick insights 評価レポートをダウンロードします。

B. 各オンプレミス VM に Migration Evaluator Collector をインストールします。データ収集期間が終了したら、Migration Evaluator を使用してアプリケーションの依存関係を表示します。Migration Evaluator から検出されたサーバーリストをダウンロードしてエクスポートします。Amazon QuickSight にリストをアップロードします。QuickSight レポートが生成されたら、Quick Insights 評価レポートをダウンロードします。

C. オンプレミス環境で AWS Application Discovery Service Agentless Collector をセットアップします。データ収集期間が終了したら、AWS Migration Hub を使用してアプリケーションの依存関係を表示します。Application Discovery Service から検出されたサーバーリストをエクスポートします。Migration Evaluator にリストをアップロードします。Migration Evaluator レポートが生成されたら、Quick Insights 評価をダウンロードします。

D. オンプレミス環境で Migration Evaluator Collector をセットアップします。各 VM に AWS Application Discovery Agent をインストールします。データ収集期間が終了したら、AWS Migration Hub を使用してアプリケーションの依存関係を表示します。Migration Evaluator から Quick Insights 評価レポートをダウンロードします。

■問題文の要件の概要

  • オンプレミス環境から AWS 移行を検討中。
  • 必要な情報:
    1. 初期評価（環境の現状把握）
    2. アプリケーション依存関係の可視化
    3. 評価レポートの自動提供
  • 条件: 運用オーバーヘッドを最小化

■正解の選択肢と解説

✅ A. AWS Application Discovery Agent を各 VM にインストールし、Migration Hub で依存関係を可視化、Quick Insights レポートを取得

  • Application Discovery Agent を各 VM に導入すると、
    • CPU / メモリ / ネットワーク使用率
    • プロセス間通信フロー
    • 実行アプリケーション
      が自動収集される。
  • Migration Hub と統合されており、依存関係マップや移行可否の可視化が可能。
  • Quick Insights レポート を自動生成できるため、追加ツールや手作業が不要。
  • 要件（初期評価・依存関係可視化・レポート出力・低オーバーヘッド）を最も効率的に満たす。

■不正解の選択肢の理由

B. Migration Evaluator Collector + QuickSight

  • Migration Evaluator は主に コスト見積もりが目的。
  • 依存関係は可視化できず、QuickSight への手動アップロードが必要でオーバーヘッド大。

C. Application Discovery Service Agentless Collector

  • vCenter 経由でVM情報を収集するが、プロセス通信やアプリ依存関係を取得できない。
  • さらに、Migration Evaluator へのデータ移行が必要 → 工数増。

D. Migration Evaluator Collector + Application Discovery Agent

  • 両方を同時導入するとデータが重複し、設定や管理が複雑化。
  • 運用オーバーヘッドが増えるため要件（最小限の負荷）に反する。

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

  • Migration Evaluator → コスト見積もり・キャパシティプランニングに強い。依存関係可視化はできない。
  • Application Discovery Service (ADS)
    • Agentless Collector → vCenter 経由のメタデータ収集（依存関係は取れない）。
    • Discovery Agent → VM/サーバーに直接導入、プロセス通信・依存関係まで可視化可能。
  • Migration Hub と統合し、依存関係マップ & Quick Insights レポートを生成できるのは Application Discovery Agent。
  • 試験では「依存関係を取るには Agent 必須」を覚えておくこと。

👉 この問題のキーポイントは 「Migration Evaluator はコスト見積もり用、依存関係可視化は Application Discovery Agent」 です。

次の問題（問題4）も同じ形式で整理しましょうか？

ありがとうございます！いただいた 問題4 を整理しました。

■問題文

ある企業が AWS に移行し、AWS ビジネスサポートを使用しています。同社は、AWS アカウント全体の Amazon EC2 インスタンスの費用対効果を監視したいと考えています。EC2 インスタンスには、部門、事業部、環境のタグが付いています。開発用の EC2 インスタンスはコストが高いですが、使用率は低いです。

同社は、利用率の低い開発用 EC2 インスタンスを検出し、停止する必要があります。過去 14 日間のうち少なくとも 4 日間、1 日あたりの平均 CPU 使用率が 10% 以下で、ネットワーク I/O が 5 MB 以下のインスタンスは十分に活用されていません。

運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。

■選択肢

A. Amazon CloudWatch ダッシュボードを構成して、部門、事業部、および環境のタグに基づいて EC2 インスタンス使用率を監視します。使用率の低い開発用 EC2 インスタンスを停止する AWS Lambda 関数を呼び出す Amazon EventBridge ルールを作成します。

B. EC2 インスタンスの使用率を追跡し、十分に活用されていないインスタンスを Amazon CloudWatch に報告するように AWS Systems Manager を設定します。CloudWatch データを、部門、事業部、環境のタグでフィルタリングします。使用率の低い開発用 EC2 インスタンスを停止する AWS Lambda 関数を呼び出す Amazon EventBridge ルールを作成します。

C. AWS Trusted Advisor によって報告された EC2 インスタンスの低い使用率を検出する Amazon EventBridge ルールを作成します。部署、事業部、環境のタグでデータをフィルタリングし、使用率の低い開発 EC2 インスタンスを停止する AWS Lambda 関数を呼び出すように、ルールを構成します。

D. すべての EC2 インスタンスの使用率データを取得するために、毎日実行する AWS Lambda 関数を作成します。データを Amazon DynamoDB のテーブルに保存します。使用率の低い開発用 EC2 インスタンスを識別して停止するために、DynamoDB テーブルをデータソースとして使用する Amazon QuickSight ダッシュボードを作成します。

■問題文の要件の概要

  • AWS 環境に移行済み、AWS ビジネスサポートを利用中
  • 低使用率の開発用 EC2 インスタンスを自動的に検出・停止したい
  • 判定条件：
    • 過去14日間で4日以上、
    • 1日平均CPU使用率 ≤10%、ネットワークI/O ≤5MB
  • 目的：コスト最適化
  • 制約：運用オーバーヘッドを最小化

■正解の選択肢と解説

✅ C. AWS Trusted Advisor + EventBridge + Lambda

  • Trusted Advisor (ビジネスサポート以上で利用可能)
    • 「低使用率のEC2インスタンス」チェックがあり、過去14日間のCPUとネットワークI/Oを自動評価。
    • 追加のメトリクス収集やスクリプト開発は不要。
  • EventBridge
    • Trusted Advisor レポート更新時のイベントをトリガーに利用可能。
    • 部門・事業部・環境タグでフィルタリングし、開発環境のみを対象にできる。
  • Lambda
    • StopInstances APIを実行し、対象インスタンスを自動停止。

➡️ Trusted Advisor が低利用インスタンスをネイティブに検出 → EventBridge & Lambdaで自動化 → 運用負荷を最小化し要件を満たす。

■不正解の選択肢の理由

A. CloudWatch ダッシュボード

  • 可視化はできるが、14日間の複合条件チェックは自動化されない。
  • CloudWatchだけでは停止判定ロジックを作り込む必要があり、オーバーヘッドが大きい。

B. Systems Manager + CloudWatch

  • Systems Managerはインベントリ・パッチ管理用途であり、低使用率判定機能は持たない。
  • カスタムスクリプトとCloudWatch連携が必要で、運用負荷が高い。

D. Lambda + DynamoDB + QuickSight

  • QuickSightは可視化のみで、自動停止アクションを実行できない。
  • データ収集・保存・可視化を自前で構築する必要があり、オーバーヘッドが大きすぎる。

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

  • Trusted Advisor (Business Support以上必須)
    • コスト最適化チェックに「低使用率EC2インスタンス」がある。
    • CPU ≤10% & ネットワークI/O ≤5MB が4日以上で検出。
  • EventBridge → Trusted Advisor の更新イベントをトリガーに利用可能。
  • Lambda → EC2停止処理などを自動実行できる。
  • CloudWatchやQuickSightは可視化専用で、自動アクションは不可。
  • SAP試験では「最小オーバーヘッド = 既存のマネージド機能を使う」が重要。

👉 この問題のキーポイントは 「Trusted Advisor の低利用チェックを活用して自動化する」 です。

次の問題（問題5）も同じ形式でまとめますか？

ありがとうございます！いただいた 問題5 を整理しました。

■問題文

会社は、Amazon CloudFront、Amazon API Gateway、AWS Lambda 関数で構成されたサーバーレスアプリケーションを導入しています。現在のアプリケーションコードのデプロイは、Lambda 関数の新しいバージョン番号を作成し、AWS CLI スクリプトを実行して更新します。新しい関数のバージョンにエラーが発生した場合は、別の CLI スクリプトを用いて、以前の関数のバージョンをデプロイすることによって元に戻します。同社は、Lambda 関数が提供するアプリケーションロジックの新しいバージョンをデプロイする時間を短縮し、エラーが識別されたときに検出して元に戻す時間も短縮したいと考えています。これを達成する最適な方法を選択してください。

■選択肢

A. AWS CloudFront ディストリビューションと API Gateway で構成される親スタックと、Lambda 関数を含む子スタックを使用して、ネストされた AWS CloudFormation スタックを作成してデプロイします。Lambda を変更するために、AWS CloudFormation 変更セットを作成してデプロイします。エラーがトリガーされた場合は、AWS CloudFormation の変更セットを以前のバージョンに戻します。

B. AWS SAM と組み込みの AWS CodeDeploy を使用して新しいバージョンの Lambda 関数をデプロイします。徐々にトラフィックを新しいバージョンにシフトし、トラフィック前とトラフィック後のテスト関数を使用してコードを検証します。Amazon CloudWatch アラームがトリガーされた場合はロールバックします。

C. AWS CLI スクリプトをリファクタリングして、新しいバージョンの Lambda 関数をデプロイする単一のスクリプトにします。デプロイが完了すると、スクリプトのテストが実行されます。エラーが検出された場合は、以前のバージョンの Lambda 関数に戻します。

D. 新しいバージョンの Lambda 関数を参照する新しい API Gateway エンドポイントで構成される AWS CloudFormation スタックを作成してデプロイします。 CloudFront オリジンを新しい API Gateway エンドポイントに変更し、エラーを監視し、エラーが検出された場合は AWS CloudFront オリジンを以前の API Gateway エンドポイントに変更します。

■問題文の要件の概要

  • サーバーレスアプリ（CloudFront + API Gateway + Lambda）を利用
  • 現在は CLIスクリプト手動デプロイ & ロールバック → 運用負荷大
  • 要件：
    • 新バージョンのデプロイを迅速化
    • エラー検出とロールバックを自動化し短縮化

■正解の選択肢と解説

✅ B. AWS SAM + AWS CodeDeploy（組み込み機能）

  • AWS SAM
    • サーバーレスアプリの定義とデプロイを自動化。
    • Lambda 関数に対して CodeDeploy リソースを自動作成可能。
  • AWS CodeDeploy（Lambda専用機能）
    • Canary/Linear デプロイでトラフィックを徐々に新バージョンに移行。
    • Pre/PostTraffic テストフックで正常性確認。
    • CloudWatch アラーム連携により異常検知時は自動ロールバック。

➡️ 手動スクリプト不要、迅速かつ安全にデプロイとロールバックができ、要件を完全に満たす。

■不正解の選択肢の理由

A. CloudFormation 変更セット

  • スタック単位の更新のみで 段階的トラフィック移行は不可。
  • ロールバックは全体復元で時間がかかり、要件の「迅速性」を満たせない。

C. CLI スクリプト統合

  • 手動スクリプト依存のまま。
  • 自動トラフィックシフトや即時ロールバックができず、要件を解決しない。

D. API Gateway + CloudFront オリジン切替

  • ネットワークルーティング変更にすぎず、Lambda のバージョン管理を解決できない。
  • キャッシュ無効化も必要でロールバックが遅れる。

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

  • Lambda の安全なデプロイには CodeDeploy を使用するのがベストプラクティス。
  • デプロイ戦略：Canary, Linear, All-at-once。
  • SAM と CodeDeploy の組み合わせで、最小設定で自動ロールバック機能を利用可能。
  • CloudFormation 変更セットや CLI スクリプトはロールバックに不向き。
  • CloudFront や API Gateway はルーティング制御であり、Lambda デプロイの問題は解決できない。

👉 この問題のキーポイントは 「SAM + CodeDeploy を使った段階的デプロイと自動ロールバック」 です。

次の問題（問題6）も同じ形式でまとめますか？

了解しました！いただいた 問題6 を整理しました。

■問題文

ソフトウェア事業者は、Amazon API Gateway、AWS Lambda 関数、および Amazon DynamoDB のテーブルを使用して、REST API を使用するアプリケーションを作成しました。このアプリケーションでは、PUT 要求の失敗の数が増加しています。PUT リクエストの大部分は、一意の API キーを使用して認証された限られた数のお客様から発信されます。

ソリューションアーキテクトは、PUT リクエストの大部分が単一のお客様からのものであると判断しました。API はミッションクリティカルではないので、お客様は失敗した呼び出しの再試行を受け入れる可能性があります。しかし、この失敗はクライアントに表示されるため、API の評判に悪影響があります。

カスタマーエクスペリエンスを向上させるために必要な推奨事項を選択してください。

■選択肢

A. クライアントアプリケーションにエクスポネンシャルバックオフと不規則な変動で再試行ロジックを実装します。エラーが捕捉され、説明的なエラーメッセージで処理されることを確認します。

B. API Gateway レベルで、使用量プランによる API スロットリングを実装します。クライアントアプリケーションが、コード 429 のエラーレスポンスなしで処理することを確認します。

C. API キャッシュを有効にして、本番環境の応答性を向上させます。10 分間の負荷テストを実行します。キャッシュ容量がワークロードに適していることを確認します。

D. Lambda 関数レベルで予約済同時実行数を実装して、トラフィックの急激な増加時に必要なリソースを提供します。

■問題文の要件の概要

  • API Gateway + Lambda + DynamoDB の 書き込み系 API（PUT） が失敗増加
  • リクエストの大半が 特定顧客の集中アクセス によるもの
  • API はミッションクリティカルではないが、失敗が見えるのは UX/評判に悪影響
  • 要件：
    • クライアント側の見える失敗を減らす
    • 再試行を自動化して体験を改善する

■正解の選択肢と解説

✅ A. クライアントにエクスポネンシャルバックオフ + ジッター再試行を実装

  • AWS推奨の再試行パターン：
    • API Gateway / Lambda はバースト時に 429 (Too Many Requests) や 5XX を返すことがある
    • クライアント側で Exponential Backoff + Jitter（指数的待機 + ランダム性） を組み合わせることで、リクエスト集中を平準化可能
  • 効果：
    • 一時的なスロットリングや DynamoDB のキャパシティ制限による失敗を吸収
    • ユーザーには再試行が透過的に行われるため失敗が目立たない
    • 説明的なエラーメッセージと組み合わせることでユーザー体験を改善

➡️ AWS ベストプラクティスに沿ったクライアント制御による解決策。

■不正解の選択肢の理由

B. API Gateway スロットリング

  • スロットリングは即座に 429 エラーを返す。
  • 顧客側からは失敗が可視化され、評判悪化を避けられない。

C. API キャッシュ

  • GET系のみ有効。PUT や書き込み操作には無意味。
  • DynamoDB 書き込みの失敗削減には効果なし。

D. Lambda 予約済同時実行

  • 実行枠を保証するだけで、特定顧客のバースト抑制にはならない。
  • リクエスト過剰時には結局 スロットリングや 5XX が返るため、失敗が見える。

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

  • 再試行戦略 (Exponential Backoff + Jitter) は AWS の基本パターン。
  • 書き込みリクエストの失敗はキャッシュでは解決できない。
  • スロットリングや予約済み同時実行は制御・保証レベルの話で、UX改善にはならない。
  • SAP試験では「顧客体験の改善」や「失敗が露出するかどうか」を問う問題が多い。

👉 この問題のキーポイントは 「失敗を見せないようにするにはクライアント側でリトライ制御を実装する」 です。

次の 問題7 も同じ形式でまとめますか？

はい！いただいた 問題7 を整理しました。

■問題文

ある企業が、オンプレミスのレガシーアプリケーションを AWS に移行する計画を立てています。このアプリケーションは、Apache Tomcat 上で動作する Java の Web アプリケーションで、PostgreSQL データベースを使用しています。

企業はソースコードにアクセスすることはできませんが、Java アーカイブ (JAR) ファイルをデプロイすることは可能です。このアプリケーションは毎月末にトラフィックが増加します。

以下のうち、最小の運用負担でこれらの要件を満たすソリューションを選択してください。

■選択肢

A. 複数のアベイラビリティーゾーンで Amazon EC2 インスタンスを起動します。Amazon Elastic File System (Amazon EFS) マウントポイントを使用して、すべてのインスタンスに Tomcat と PostgreSQL をデプロイします。AWS Step Functions を使用して追加の EC2 インスタンスをデプロイし、トラフィックの増加に合わせて拡張します。

B. Amazon Elastic Kubernetes Service (Amazon EKS) を複数の AWS リージョンにまたがる Auto Scaling グループでプロビジョニングします。Tomcat と PostgreSQL をコンテナイメージにデプロイします。Network Load Balancer を使用して、トラフィックの増加に合わせて拡張します。

C. Java アプリケーションを Python ベースのコンテナにリファクタリングします。アプリケーションロジックに AWS Lambda 関数を使用します。アプリケーションデータを Amazon DynamoDB グローバルテーブルに保存します。AWS Storage Gateway と Lambda の同時実行を使用して、トラフィックの増加に合わせてスケーリングします。

D. AWS Elastic Beanstalk を使用して、複数のアベイラビリティーゾーンで Auto Scaling が可能な Tomcat サーバーをデプロイします。アプリケーションデータを Amazon RDS for PostgreSQL データベースに保存します。Amazon CloudFront と Application Load Balancer をデプロイして、トラフィックの増加に合わせてスケーリングします。

■問題文の要件の概要

  • レガシー Java アプリ（Tomcat） + PostgreSQL
  • ソースコードなし → 再開発やリファクタリング不可
  • 毎月末にトラフィック増加 → 自動スケーリングが必要
  • 要件：
    • コード改修せずに移行できる
    • 運用負担を最小化できる
    • 可用性・スケーラビリティ確保

■正解の選択肢と解説

✅ D. AWS Elastic Beanstalk + Amazon RDS for PostgreSQL + CloudFront/ALB

  • Elastic Beanstalk
    • Tomcat プラットフォームが標準提供されており、JAR ファイルをそのままデプロイ可能。
    • Auto Scaling やマルチ AZ 配置、ALB などを自動的に構築。
  • Amazon RDS for PostgreSQL
    • 既存の PostgreSQL データベースをそのままマネージド化できる。
    • バックアップ・パッチ適用・スケーリングを AWS が管理。
  • CloudFront + ALB
    • グローバル配信 & レイテンシ改善。
    • ALB がスケールアウトした Tomcat 環境に振り分け。

➡️ ソースコード不要、フルマネージド利用で「最小の運用負担」を実現。

■不正解の選択肢の理由

A. EC2 + EFS + Step Functions

  • すべて手動構築・管理が必要。
  • DB を EC2 にデプロイするのは可用性・スケーラビリティに弱い。
  • Step Functions は Auto Scaling の代替にならず「運用負担大」。

B. EKS + コンテナ PostgreSQL

  • EKS 運用（ノード管理・CNI・アップグレード等）で工数大。
  • PostgreSQL をコンテナで動かすのは状態管理が難しく、RDS の方が適切。
  • 「最小の運用負担」を満たさない。

C. Python 化 + Lambda + DynamoDB

  • ソースコード改修不可の要件を満たさない。
  • Java JAR を Python や Lambda に置き換えるのは非現実的。
  • DB もリレーショナルから DynamoDB に移行できず要件外。

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

  • 移行要件で「コード改修不可」なら Elastic Beanstalk + RDS が鉄板。
  • EKS や EC2 手動構築は「運用負担が大きい」として除外される。
  • CloudFront + ALB の組み合わせはスケーラブルなアーキテクチャの基本。
  • 試験では「最小運用負担」「マネージドサービス利用」が最重要キーワード。

👉 この問題の本質は 「コード変更なしで移行」＋「最小運用負担」＝ Elastic Beanstalk + RDS の組み合わせ です。

次の 問題8 も同じ形式でまとめますか？

RELATED POST