ありがとうございます！いただいたHTMLを整理して、指定のフォーマットで出力しました。
■問題文
ある企業は、AWS Lambda 関数上で実行されるアプリケーションを構築しています。数百人のお客様がこのアプリケーションを利用します。同社は、各お客様に特定の期間のリクエストのクォータを与えたいと考えています。クォータはお客様の使用パターンと一致する必要があります。一部のお客様は、より高いクォータをより短い期間で受け取る必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢
A：Lambda 関数を呼び出すプロキシ統合を使用して Amazon API Gateway REST API を作成します。お客様ごとに、適切なリクエストのクォータを含む API Gateway 使用量プランを設定します。お客様が必要とする各ユーザーの使用量プランから API キーを作成します。
B：VPC に Application Load Balancer (ALB) を作成します。ALB のターゲットとして Lambda 関数を構成します。ALB に対して AWS WAF を使用して、ウェブ ACL を構成します。お客様ごとに、適切なリクエストクォータを含むレートベースのルールを構成します。
C：お客様ごとに Lambda 関数のエイリアスを作成します。適切なリクエストクォータに同時実行のクォータを含めます。関数エイリアスごとに Lambda 関数 URL を作成します。各エイリアスの Lambda 関数 URL を関連するお客様と共有します。
D：Lambda 関数を呼び出すプロキシ統合を使用して Amazon API Gateway HTTP API を作成します。お客様ごとに、適切なリクエストのクォータを含む API Gateway 使用量プランを設定します。使用量プランごとにルートレベルのスロットリングを設定します。お客様が必要とするユーザーごとに、使用量プランから API キーを作成します。
■問題文の要件の概要
- 数百人の顧客がLambda関数を利用するアプリケーション
- 各顧客に対して「期間内リクエスト数のクォータ」を付与したい
- クォータは顧客の利用パターンに応じて異なる
- 一部顧客には短期間に高いクォータが必要
- 顧客ごとに柔軟にクォータ制御可能な仕組みが必要
■正解の選択肢と解説
正解：A
- Amazon API Gateway REST API は「使用量プラン (Usage Plan)」と「APIキー」を組み合わせて顧客ごとのクォータやスロットリングを設定できる。
- 各顧客に異なる使用量プランを割り当て、APIキーで制御することで利用パターンに応じた制御が可能。
- REST API では「期間単位のクォータ」「秒/分単位のスロットリング」を細かく調整可能。
👉 これにより「顧客ごとの異なる期間・クォータ」に完全対応できる。
■不正解の選択肢の理由
- B（ALB + AWS WAF レートベースルール）
- WAF のレートベースルールは「IPアドレス単位」でのリクエスト制御であり、顧客ごとの柔軟なクォータ設定は不可。
- 主目的はセキュリティ対策であり、クォータ管理には不適。
- C（Lambda エイリアス + 関数URL + 同時実行クォータ）
- Lambda の同時実行数は「リクエスト数の総量」管理に向いていない。
- 顧客ごとの柔軟なクォータ制御はできず、ユーザーごとの利用制限を細かく反映できない。
- D（API Gateway HTTP API + 使用量プラン）
- HTTP API では REST API と異なり「ルートレベルのスロットリング」がサポートされていない。
- 使用量プランは設定できるが細かい制御ができないため、顧客ごとのクォータ要件を満たせない。
■SAP試験で押さえておくべきポイント
- API Gateway REST API → 使用量プラン（Usage Plan）+ APIキーで「顧客ごとに柔軟なクォータ制御」が可能。
- HTTP API はコスト効率が良いが、一部の機能（ルートレベルスロットリング等）がREST APIに比べ制限される。
- AWS WAF は「クォータ管理」ではなく「セキュリティ対策（攻撃防御・IP制御）」が主用途。
- Lambda の同時実行数制御は全体的なリソース制御であり、「顧客ごとの利用制御」には向かない。
👉 「顧客ごとの利用量管理」＝ API Gateway REST API + Usage Plan + APIキー が定石。
次の問題も同じ形式で整理しますか？
了解しました！いただいた問題2を指定フォーマットで整理しました。
■問題文
ある企業が、本番環境とテスト環境など、さまざまな AWS 環境にアプリケーションをデプロイしています。組織は、本番環境とテスト環境用に個別のアカウントを維持しており、ユーザーは、チームメンバーやサービスに応じて、追加のアプリケーションユーザーを設定することができます。セキュリティチームは、運用チームから、本番環境とテスト環境間の分離の強化、セキュリティ認証情報の集中管理、および環境間の権限管理の改善を要求しました。最も安全にこの目的を達成できる方法を選択してください。
■選択肢
A：本番アカウントとテストアカウントのアクセス許可を変更して、新しい IAM ユーザーの作成を運用チームのメンバーに制限します。各アカウントに強力な IAM パスワードポリシーを設定します。各アカウントに新しい IAM ユーザーとグループを作成し、開発者のアクセスを職務を完了するために必要なサービスのみに制限します。
B：各アカウントで実行されるスクリプトを作成し、ユーザーアカウントがセキュリティポリシーを遵守しているかどうかを確認します。準拠していないユーザーまたはサービスアカウントを無効にします。
C：ID アカウントのような、ユーザーアカウントとサービスアカウントを保持するために、新しい AWS アカウントを作成します。ID アカウントにユーザーとグループを作成します。本番アカウントとテストアカウントに適切な権限を持つロールを作成します。ロールの信頼ポリシーに ID アカウントを追加します。
D：本番アカウントにすべてのユーザーアカウントを作成します。本番アカウントとテストアカウントでアクセスするためのロールを作成します。本番アカウントからテストアカウントへのクロスアカウントアクセスを許可します。
■問題文の要件の概要
- 本番環境とテスト環境を別アカウントで運用中。
- セキュリティチームからの要請：
- 環境間の分離を強化したい。
- 認証情報を集中管理したい。
- 環境間の権限管理を改善したい。
- 最もセキュアかつ効率的にユーザーと権限を管理する仕組みが必要。
■正解の選択肢と解説
正解：C
- ID管理専用の「中央IDアカウント（Identity account）」を作成し、すべてのユーザーとサービスアカウントをそこに集約する。
- 本番・テストの各アカウントにはロールを作成し、信頼ポリシーでIDアカウントを信頼する構成にする。
- ユーザーはIDアカウントにサインインし、STS AssumeRole を利用して必要な環境のロールに切り替える。
👉 これにより「環境間の分離」「認証情報の集中管理」「権限管理の改善」のすべてを実現できる。
👉 実際のAWSベストプラクティスでも AWS Organizations + IAM Identity Center (旧SSO) を用いた集中管理が推奨されている。
■不正解の選択肢の理由
- A
- 各アカウントごとにIAMユーザーを管理しているため「分散管理」になり、認証情報の集中管理が実現できない。
- 環境間の分離や運用効率の改善には不十分。
- B
- 各アカウントに既存ユーザーを作った上で監視・無効化する方式であり、根本的な集中管理や分離強化にはならない。
- 対症療法的でセキュリティベストプラクティスから外れる。
- D
- 本番アカウントに全ユーザーを集中させる方式は、本番環境に依存してしまい「分離の強化」という要件を満たさない。
- そもそも本番アカウントがID管理の役割を担うのはリスクが高い。
■SAP試験で押さえておくべきポイント
- 複数アカウント環境でのIAM管理のベストプラクティス
- ID専用アカウントを作成し、全ユーザーを集約する。
- 各アカウントには「ロール」を作成し、信頼ポリシーでIDアカウントからのAssumeRoleを許可する。
- AWS OrganizationsやIAM Identity Centerを用いた統合管理が推奨される。
- 避けるべきパターン
- 各アカウントにバラバラにIAMユーザーを作成する（管理の煩雑化）。
- 本番アカウントをID管理のハブとして流用する（分離性欠如）。
- スクリプトでポリシー遵守をチェックするだけの後追い対応。
👉 SAP試験では「マルチアカウント戦略」「セキュリティと分離」「集中管理」がキーワード。
次の問題も整理していきますか？
了解しました！問題3を整理してフォーマットに沿って出力します。
■問題文
ある企業が AWS 上のモバイルアプリを使用してオンラインコンテストを実施しています。各コンテスト終了時に、会社はランダムに優勝者を選びます。コンテストは様々な期間実施されます。コンテスト終了後、会社はコンテストのデータを保持する必要はありません。
同社は、Amazon EC2 インスタンスでホストされているカスタムコードを使用して、コンテストデータを処理し、優勝者を選びます。EC2 インスタンスは Application Load Balancer の背後で実行され、コンテストのエントリーは Amazon RDS DB インスタンスに保存されます。同社は、コンテストの運営コストを削減するために、新しいアーキテクチャを設計する必要があります。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■選択肢
A：コンテストのエントリーのストレージを Amazon DynamoDB に移行します。コードを AWS Lambda 関数として書き直します。各エントリーの DynamoDB TTL 属性を設定して、コンテスト終了時に各エントリーの有効期限が切れるようにします。
B：コンテストのエントリーのストレージを Amazon DynamoDB に移行します。DynamoDB Accelerator (DAX) クラスターを作成します。Fargate 起動タイプを使用する Amazon Elastic Container Service (Amazon ECS) コンテナとして実行するようにコードを書き換えます。コンテスト終了時に、DynamoDB テーブルを削除します。
C：コンテストのエントリーをキャッシュするために、RDS DB インスタンスの前に Amazon ElastiCache for Redis クラスターを追加します。Fargate 起動タイプを使用する Amazon Elastic Container Service (Amazon ECS) コンテナとして実行するようにコードを書き換えます。各エントリに ElastiCache TTL 属性を設定し、コンテストの終了時に各エントリの有効期限が切れるようにします。
D：コンテストのエントリーのストレージを Amazon Redshift に移行します。コードを AWS Lambda 関数として書き直します。コンテスト終了時に、Redshift クラスターを削除します。
■問題文の要件の概要
- オンラインコンテストのエントリーを短期間保存する必要がある。
- コンテスト終了後はデータ保持不要。
- 現在はEC2＋RDS構成だが、コスト削減が求められている。
- 新アーキテクチャは スケーラブルかつコスト効率的 である必要がある。
■正解の選択肢と解説
正解：A
- Amazon DynamoDB を利用することでフルマネージドなNoSQLデータベースを利用可能。
- TTL（Time to Live）属性を設定すれば、コンテスト終了後にデータを自動的に削除可能 → ストレージコストを削減。
- AWS Lambda に処理を移行することで、必要時のみ実行される「サーバーレス」な構成を実現でき、EC2の常時稼働コストを削減。
👉 DynamoDB + TTL + Lambda の組み合わせで 低コスト・スケーラブル・短期保存 の要件を完全に満たす。
■不正解の選択肢の理由
- B（DynamoDB + DAX + ECS/Fargate）
- DAX は読み取りキャッシュ最適化用で今回の要件（短期保存＋削除）とは無関係。
- ECS/Fargate運用は Lambda よりコスト効率が悪く、不要に複雑。
- C（ElastiCache + ECS/Fargate）
- Redisはキャッシュ用途であり、永続データストアとして利用するのは不適切。
- バックエンドRDSを削除できず、コスト削減にならない。
- D（Redshift + Lambda）
- RedshiftはDWH用途であり、分析向き。
- 短期保存や即時削除には不向きで、コスト効率が悪い。
■SAP試験で押さえておくべきポイント
- 短期保存・不要データ削除 → DynamoDB TTL が最適解。
- サーバーレス化（EC2 → Lambda） によるコスト削減は頻出テーマ。
- ElastiCacheはキャッシュ用途、Redshiftは分析用途、DAXは高速化用途 → 問題要件と適合しない。
- 試験で問われる「コスト効率化」＝ 不要リソースを持たない/自動削除/サーバーレス。
次も同じ形式で整理しましょうか？
はい！問題4を指定のフォーマットで整理しました。
■問題文
金融サービス会社は、クレジットカードサービスパートナーから定期的にデータフィードを受け取ります。約 5,000 件のレコードが 15 分ごとにプレーンテキストで送信され、HTTPS を介してサーバー側の暗号化を使用して Amazon S3 バケットに直接配信されます。このフィードには、クレジットカードのプライマリアカウント番号 (PAN) の機密データが含まれています。会社は、追加の内部処理のために、データを別の S3 バケットに送信する前に、自動的に PAN をマスクする必要があります。また、特定のフィールドを削除してマージし、レコードを JSON 形式に変換する必要があります。さらに、将来的にフィードが追加される可能性があるため、どのデザインも簡単に拡張できる必要があります。これらの要件を満たすソリューションを選択してください。
■選択肢
A：データフィード形式に基づいて AWS Glue クローラーとカスタム分類子を作成し、一致するテーブル定義を構築します。ファイル配信時に Amazon Athena クエリを実行して、Amazon EMR ETL ジョブを開始し、処理と変換の要件に従ってレコード全体を変換します。出力形式を JSON として定義します。完了したら、内部処理のために結果を別の S3 バケットに送信し、EMR クラスターをスケールダウンします。
B：ファイル配信時に AWS Lambda 関数をトリガーし、各レコードを抽出して Amazon SQS キューに書き込みます。SQS キューにメッセージが含まれている場合に、自動的に単一のインスタンスにスケーリングするように AWS Fargate コンテナアプリケーションを設定します。アプリケーションに各レコードを処理させ、レコードを JSON 形式に変換します。キューが空になったら、結果を別の S3 バケットに送って内部処理を行い、AWS Fargate インスタンスをスケールダウンします。
C：データフィード形式に基づいて AWS Glue クローラーとカスタム分類子を作成し、それに合わせたテーブル定義を構築します。ファイル配信時に AWS Lambda 関数をトリガーして、AWS Glue ETL ジョブを開始し、処理と変換の要件に従ってレコード全体を変換します。出力形式を JSON として定義します。完了したら、ETL ジョブに結果を別の S3 バケットに送信して、内部処理を行います。
D：ファイル配信時に AWS Lambda 関数をトリガーし、各レコードを抽出して Amazon SQS キューに書き込みます。新しいメッセージが SQS キューに到着したときに、別の Lambda 関数をトリガーしてレコードを処理し、結果を Amazon S3 の一時的な場所に書き込みます。SQS キューが空になったら、最後の Lambda 関数をトリガーして、レコードを JSON 形式に変換し、結果を別の S3 バケットに送信して内部処理します。
■問題文の要件の概要
- 入力データ：15分ごとに5,000件、S3に配信。PAN（機密データ）を含む。
- 要件：
- PANをマスク（個人情報保護）
- 特定フィールドの削除・マージ
- JSON形式に変換
- 将来的に新しいフィードが追加されても拡張しやすいアーキテクチャ
- 制約：金融系のためセキュリティ・スケーラビリティ・拡張性重視
■正解の選択肢と解説
正解：C
- AWS Glue はマネージドETLサービスで、データ変換・マスキング・フィールド削除/マージ・形式変換を簡単に実装できる。
- Glue クローラーとカスタム分類子を使えば、新しいデータフィードにも柔軟に対応可能。
- S3にデータ配信 → Lambdaトリガー → Glueジョブ実行 → JSON形式で出力 → 別のS3へ格納 という拡張性の高いパターン。
- GlueはSparkベースで並列処理可能なため、5,000件/15分程度の処理は余裕で対応でき、将来的な増加にも耐えられる。
👉 要件（セキュリティ・マスク処理・変換・拡張性）をバランス良く満たすのがGlue ETL。
■不正解の選択肢の理由
- A（Athena + EMR）
- EMRは大規模データ処理向けであり、今回のようなバッチ小規模処理にはコスト効率が悪い。
- 拡張性や運用負荷の観点で不適切。
- B（Lambda + SQS + Fargate）
- カスタムアプリ開発が必要となり運用負荷が増える。
- FargateはGlueに比べてスケーラビリティはあるが、ETL要件に対する効率や拡張性で劣る。
- D（Lambda + SQS + 複数Lambda）
- 複雑なLambdaチェーンは開発・保守が大変。
- 大量データ処理には同時実行制限の影響を受ける可能性があり不向き。
■SAP試験で押さえておくべきポイント
- AWS Glueの特徴
- マネージドETLサービス、組み込み変換（マスキング、削除、JSON変換など）が容易。
- クローラー＋カスタム分類子でスキーマ検出・新規データ対応が可能。
- EMRとGlueの使い分け
- EMR＝大規模・複雑な処理に最適。
- Glue＝サーバーレス・中規模ETL・簡易変換に最適。
- LambdaチェーンやFargateによる独自実装はコスト効率や拡張性で不利。
- 金融や機密データ系の要件では「セキュリティ＋拡張性＋スケーラブルなETL基盤」としてGlueが頻出解答。
👉 つまり「S3に届く → Glueで変換・マスク → JSON化 → S3に出力」というのが模範的なアーキテクチャです。
次の問題（問題5）も同じ形式で整理しますか？
了解です！問題5を指定フォーマットで整理しました。
■問題文（文字列を編集せずに出力してください。）
ある企業は、オンプレミスで Microsoft SQL Serverデータベースを使用しており、毎晩 200 GB のエクスポートをローカルドライブに書き込んでいます。同社は、バックアップを Amazon S3 上のより堅牢なクラウドストレージに移行したいと考えています。同社は、オンプレミスのデータセンターと AWS の間に 10 Gbps の AWS Direct Connect 接続を設定しました。
これらの要件を最も費用対効果の高い方法で満たすソリューションを選択してください。
■選択肢（文字列を編集せずに出力してください。※正解がどれかわからないように）
A：Direct Connect 接続に接続されている VPC 内に、Amazon FSx for Windows File Server マルチ AZ ファイルシステムを作成します。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートを Amazon FSx ファイルシステムの SMB ファイル共有に書き込みます。夜間のバックアップを有効にします。
B：新しい S3 バケットを作成します。Direct Connect 接続に接続されている VPC 内に AWS Storage Gateway ファイルゲートウェイをデプロイします。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートを新しい SMB ファイル共有に書き込みます。
C：Direct Connect 接続に接続されている VPC 内に、Amazon FSx for Windows File Server シングル AZ ファイルシステムを作成します。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートを Amazon FSx ファイルシステムの SMB ファイル共有に書き込みます。夜間のバックアップを有効にします。
D：新しい S3 バケットを作成します。Direct Connect 接続に接続されている VPC 内に AWS Storage Gateway ボリュームゲートウェイをデプロイします。新しい SMB ファイル共有を作成します。夜間のデータベースエクスポートをボリュームゲートウェイの新しい SMB ファイル共有に書き込み、このデータの S3 バケットへのコピーを自動化します。
■問題文の要件の概要
- 毎晩 200 GB をS3へバックアップしたい
- 10 Gbps Direct Connect は既にあり
- 目的は堅牢なクラウド保存を費用対効果高く実現すること
- 既存の SQL Server の夜間エクスポートフローを大きく変えない（SMB共有に書けると良い）
■正解の選択肢と解説
正解：B
理由
- AWS Storage Gateway（File Gateway） はオンプレ/ネットワーク越しに SMB/NFS 共有を提供し、書き込まれたファイルを非同期に Amazon S3 へオブジェクトとして保存します。
- 既存の夜間エクスポートをそのままSMB共有に書くだけでクラウド側はS3耐久性（11ナイン）を享受でき、運用も簡素。
- 料金は主に S3のストレージ＋リクエストで済み、FSxの容量/バックアップコストより安価。
- すでにある Direct Connect(10Gbps) を経路に使えるため、転送の安定性・スループットも確保できる。
■不正解の選択肢の理由
- A（FSx for Windows File Server：マルチAZ）
- FSx はマネージドWindowsファイルサーバで高可用だが、容量・バックアップの料金が高め。単なるバックアップ保管先としてはS3直行の方が安価。
- C（FSx：シングルAZ）
- Aよりは安価だが、依然としてFSxの容量/バックアップ費が発生。オブジェクトストレージへダイレクトに置ける File Gateway + S3 に費用対効果で劣る。
- D（Storage Gateway：ボリュームゲートウェイ）
- ボリュームゲートウェイは iSCSI ブロックを提供するモデルでSMB共有を提供しない。問題文の手順（SMB共有に書く）と機能不一致。S3へのコピーも追加の仕組みが必要になり複雑。
■SAP試験で押さえておくべきポイント
- オンプレ → S3 へ“ファイルとして”送りたい：まずStorage Gateway File Gatewayを想起（SMB/NFS→S3オブジェクト化）。
- FSx for Windows はSMBが必要で“クラウド上のWindows共有”を常用したいケース向け。バックアップ置場にはS3直行が安い。
- ボリュームゲートウェイはiSCSIブロック（スナップショットはS3）で、ファイル共有（SMB/NFS）は提供しない。
- Direct Connect は大容量夜間転送の安定性向上に有効だが、設計の肝はストレージ選定（S3直行できるか）。
次の問題があれば、同じ形式でどんどん整理します！
了解です！問題6を指定フォーマットで整理しました。
■問題文（文字列を編集せずに出力してください。）
ある企業が、オンプレミスのファイルストレージシステムのバックアップを目的として、Amazon S3 を使用したいと考えています。この企業のオンプレミスファイルストレージソリューションは NFS をサポートしており、新しいソリューションも同様にサポートする必要があります。5 日後、バックアップファイルをアーカイブしたいと考えています。企業が災害復旧のためにアーカイブされたデータを必要とする場合、それらの取得を数日待つことを許可します。費用対効果の観点から、これらの基準に最も適した方法を選択してください。
■選択肢（文字列を編集せずに出力してください。※正解がどれかわからないように）
A：S3 バケットに関連付けられた AWS Storage Gateway ファイルゲートウェイをデプロイします。オンプレミスのファイルストレージソリューションからテープゲートウェイにファイルを移動します。S3 ライフサイクルルールを作成して、5 日後にファイルを Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) に移動します。
B：S3 バケットに関連付けられた AWS Storage Gateway ファイルゲートウェイをデプロイします。オンプレミスのファイルストレージソリューションからファイルゲートウェイにファイルを移動します。S3 ライフサイクルルールを作成して、5 日後にファイルを Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) に移動します。
C：S3 バケットに関連付けられた AWS Storage Gateway テープゲートウェイをデプロイします。オンプレミスのファイルストレージソリューションからテープゲートウェイにファイルを移動します。S3 ライフサイクルルールを作成して、5 日後にファイルを Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) に移動します。
D：S3 バケットに関連付けられた AWS Storage Gateway ボリュームゲートウェイをデプロイします。オンプレミスのファイルストレージソリューションからボリュームゲートウェイにファイルを移動します。S3 ライフサイクルルールを作成して、5 日後にファイルを S3 Glacier Deep Archive に移動します。
E：S3 バケットに関連付けられた AWS Storage Gateway ファイルゲートウェイをデプロイします。オンプレミスのファイルストレージソリューションからファイルゲートウェイにファイルを移動します。S3 ライフサイクルルールを作成して、5 日後にファイルを S3 Glacier Deep Archive に移動します。
■問題文の要件の概要
- オンプレ側は NFS をサポート → 新ソリューションも NFS 対応が必須
- バックアップを S3 に保存
- 5日後にアーカイブへ移行したい
- 災害復旧時は 取得に数日待てる → 取り出しが遅くても可
- 目的：費用対効果が最も高い構成
■正解の選択肢と解説
正解：E
- File Gateway は NFS/SMB を提供し、書き込まれたファイルを S3 オブジェクトとして保存できるため、オンプレNFSワークロードをそのままクラウドへバックアップ可能。
- S3 ライフサイクルで 5日後に S3 Glacier Deep Archive へ自動遷移させれば、取り出しに時間はかかるが、最安の長期保管クラスで大幅なコスト最適化。
- 「数日待てる」という要件と Deep Archive の前提（取り出しが遅い代わりに非常に安い） が一致。
■不正解の選択肢の理由
- A：記述が不整合（File Gateway をデプロイと言いつつ「テープゲートウェイに移動」）。さらに Standard-IA への移行は「すぐ取り出せる」用途向けで、Deep Archive ほど安くない。
- B：NFS要件は満たすが、Standard-IA は取り出し即時性が必要なデータ向け。数日待てる要件なら Deep Archive がより費用対効果高い。
- C：Tape Gateway は iSCSI/VTL ベース。NFS 要件を満たさず、さらに Standard-IA への移行もコスト最適ではない。
- D：Volume Gateway は iSCSI ブロック提供で NFS 非対応。要件不一致。Deep Archive への移行自体はコスト面で良いが、プロトコル要件を満たさない。
■SAP試験で押さえておくべきポイント
- Storage Gateway の使い分け
- File Gateway＝NFS/SMB で S3 へ（ファイル→オブジェクト）。
- Volume Gateway＝iSCSI ブロック（NFS/SMBなし）。
- Tape Gateway＝仮想テープ（VTL/iSCSI）。
- ストレージクラス選択の指針
- Standard-IA：低頻度アクセスだが即時取り出しが必要なとき。
- Glacier / Glacier Deep Archive：取り出しに時間がかかって良い長期保管。特に Deep Archive は最安。
- ライフサイクルポリシーで「ホット→コールド」へ自動遷移させて運用をシンプルにコスト最適化。
- 文章内のキーワード（NFS, 待てる, アーカイブ, 費用対効果）から File Gateway + Deep Archive を素早く導く訓練を。
次の問題もこの形式でどうぞ！
了解しました！問題7を指定フォーマットで整理しました。
■問題文
ある企業では、Amazon API Gateway、AWS Lambda、および Amazon DynamoDB を使用するウェブアプリケーションがあります。最近のマーケティングキャンペーンにより、需要が高まっています。監視ソフトウェアは、多くのリクエストの応答時間がマーケティングキャンペーン前よりも大幅に長くなっていることを報告しています。
ソリューションアーキテクトは、API Gateway の Amazon CloudWatch Logs を有効にし、リクエストの 20% でエラーが発生していることに気付きました。CloudWatch では、Lambda 関数の Throttles メトリクスがリクエストの 1% を、Errors メトリクスがリクエストの 10% を表しています。アプリケーションログによると、エラーが発生する際には DynamoDB への呼び出しを伴っていることがわかります。
ウェブアプリケーションの人気が高まるにつれて、ソリューションアーキテクトは現在の応答時間を改善するためにどのような変更を行う必要がありますか ?
■選択肢
A：テーブルに DynamoDB Auto Scaling を実装します。
B：API Gateway のスロットリング制限を増やします。
C：より適切にパーティション化されたプライマリインデックスを使用して DynamoDB テーブルを再作成します。
D：Lambda 関数の同時実行数の制限を増やします。
■問題文の要件の概要
- API Gateway + Lambda + DynamoDB 構成
- 負荷増加により レスポンス遅延とエラー増加
- CloudWatch で確認：
- Lambda スロットリング：1% → 軽微
- Lambda Errors：10%（DynamoDB 呼び出し時に発生）
- 主因は DynamoDB キャパシティ不足
- 解決策は スループット自動拡張による可用性向上
■正解の選択肢と解説
正解：A（テーブルに DynamoDB Auto Scaling を実装します。）
- DynamoDB Auto Scaling は、CloudWatch メトリクスを監視し、トラフィックに応じて 読み取り/書き込み容量を自動調整する仕組み。
- マーケティングキャンペーンでの急増アクセスに対応し、スロットリングやエラーを防止できる。
- 他のサービス(API Gateway, Lambda)は主因でなく、DynamoDB がボトルネック。
■不正解の選択肢の理由
- B：API Gateway のスロットリング制限を増やします。
→ API Gateway 側は問題なく、制限を緩和しても DynamoDB 負荷が増えるだけで改善しない。 - C：より適切にパーティション化されたプライマリインデックスを使用して DynamoDB テーブルを再作成します。
→ パーティション設計見直しは抜本的で即効性がなく、Auto Scaling に比べて過剰対応。 - D：Lambda 関数の同時実行数の制限を増やします。
→ Lambda 側のスロットリングは1%と軽微で、主因は DynamoDB。実行数を増やしてもDynamoDBエラーは解消しない。
■SAP試験で押さえておくべきポイント
- DynamoDB Auto Scaling は、トラフィックに応じた自動的な容量調整でスロットリング防止。
- CloudWatch メトリクス分析でボトルネックを見極める（Throttles, Errors, ConsumedCapacity 等）。
- API Gateway, Lambda, DynamoDB の責務を区別し、ボトルネックを正確に特定。
- DynamoDB のスループット問題に対しては、Auto Scaling or On-Demand モードが即効性のある解決策。
この問題は「どこがボトルネックか」を CloudWatch メトリクスから読み解く力を問う典型パターンですね。
次の問題も整理しますか？
