以下は、問題1の内容に基づいた整理・解説です。
■問題文（編集せずにそのまま）
ある企業は、eu-north-1 リージョンの Amazon EC2 で可用性の高いデータ収集アプリケーションを実行しています。このアプリケーションは、エンドユーザーのデバイスからデータを収集し、Amazon Kinesis Data Streams とレコードを処理する一連の AWS Lambda 関数にレコードを書き込みます。同社は、レコード処理の出力を eu-north-1 の Amazon S3 バケットに保存します。同社は S3 バケット内のデータを Amazon Athena のデータソースとして使用しています。
同社は、グローバルなプレゼンスを高めたいと考えています。ソリューションアーキテクトは、sa-east-1 と ap-northeast-1 リージョンでデータ収集機能を起動する必要があります。ソリューションアーキテクトは、アプリケーション、Kinesis Data Streams、Lambda 関数を 2 つの新しいリージョンにデプロイします。ソリューションアーキテクトは、データ分析を一元化する要件を満たすために、S3 バケットを eu-north-1 に保持します。
新しいセットアップのテスト中に、ソリューションアーキテクトは、新しいリージョンから S3 バケットへのデータの到着に大幅な遅延があることに気付きました。
この遅延時間を最も改善するソリューションを選択してください。
■選択肢（編集せずにそのまま）
A. 2 つの新しいリージョンそれぞれで、VPC で実行するように Lambda 関数を設定します。その VPC に S3 ゲートウェイエンドポイントを設定します。
B. eu-north-1 の S3 バケットで S3 Transfer Acceleration を有効にします。アプリケーションが S3 バケットにデータをアップロードする際に、新しい S3 アクセラレーションエンドポイントを使用するようにアプリケーションを変更します。
C. 2 つの新しいリージョンそれぞれに S3 バケットを作成します。それぞれの新しいリージョンのアプリケーションを、それぞれの S3 バケットにアップロードするように設定します。eu-north-1 の S3 バケットにデータを複製するように、S3 クロスリージョンレプリケーションを設定します。
D. Lambda 関数のメモリ要件を増やして、複数のコアが利用できるようにします。アプリケーションが Lambda から Amazon S3 にデータをアップロードするときに、マルチパートアップロード機能を使用します。
■問題文の要件の概要
- グローバル展開により新しいリージョン（sa-east-1、ap-northeast-1）でデータ収集を開始。
- データ分析は eu-north-1のS3バケットで一元管理。
- 新リージョンからeu-north-1へのS3転送で大きな遅延が発生。
- 遅延を改善する最適なソリューションが問われている。
■正解の選択肢と解説
✅ C. 各リージョンでS3に保存し、CRRで複製
- 新しいリージョンでそれぞれのローカルS3バケットにアップロード → 高速かつレイテンシ最小化。
- eu-north-1の中央S3バケットへは、**クロスリージョンレプリケーション（CRR）**を利用して非同期に自動転送。
- こうすることで、アプリケーションは近距離リージョンにだけ書き込み、後の分析用にデータは自動集約される。
■不正解の選択肢の理由
❌ A. LambdaをVPC内で実行＋S3エンドポイント
- エンドポイントはVPC内通信の最適化には有効だが、リージョン間の距離によるネットワーク遅延には無関係。
- この遅延はインフラ物理距離の問題なので、根本的な改善にはならない。
❌ B. S3 Transfer Acceleration
- CloudFrontを介した高速転送が可能になるが、距離やデータ規模によって効果に限界がある。
- バケットがeu-north-1に1つのみなので帯域集中の懸念が残り、最も効果的ではない。
❌ D. Lambdaのメモリ増加とマルチパートアップロード
- Lambdaの性能を上げても、リージョン間のネットワーク遅延は改善できない。
- マルチパートアップロードは大容量ファイル向けの高速化策であり、今回の小さなデータ収集では効果が薄い。
■SAP試験で押さえておくべきポイント
- クロスリージョンレプリケーション（CRR）は、分析やアーカイブ目的でデータを一元集約したいときに有効。
- S3 Transfer Accelerationは転送高速化オプションだが、万能ではない。地理的な距離の問題は別対策が必要。
- リージョンを跨ぐ設計では、書き込みはローカル → 分析用に集約がベストプラクティス。
- LambdaのVPC配置・リソース増加は計算リソースには有効でも、ネットワーク遅延には効果なし。
次の問題もお送りいただければ、引き続きこの形式で解説いたします。SAP試験ではグローバル設計と最適なデータ転送戦略が頻出テーマですので、この問題は特に重要です。
以下は、問題2の要件と解説を整理したものです：
■問題文（原文）
ある企業は、Amazon Elastic File System (Amazon EFS) ファイルシステムにドキュメントを保存し、管理しています。ファイルシステムは、AWS Key Management Service (AWS KMS) キーで暗号化されています。ファイルシステムは、独自のソフトウェアを実行する Amazon EC2 インスタンスにマウントされています。
同社は、ファイルシステムの自動バックアップを有効にしています。自動バックアップは、AWS Backup のデフォルトのバックアッププランを使用しています。
ソリューションアーキテクトは、削除されたドキュメントを 100 分の RPO 内で回復できるようにする必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢（原文）
A. 新しい IAM ロールを作成します。新しいバックアッププランを作成します。新しい IAM ロールを使用してバックアップを作成します。KMS キーポリシーを更新して、新しい IAM ロールがキーを使用できるようにします。ファイルシステムに 1 時間ごとのバックアップスケジュールを実装します。
B. 新しいバックアッププランを作成します。KMS キーポリシーを更新して、AWSServiceRoleForBackup IAM ロールがキーを使用できるようにします。カスタム cron 式を実装して、ファイルシステムのバックアップを 30 分ごとに実行します。
C. 新しい IAM ロールを作成します。既存のバックアッププランを使用します。KMS キーポリシーを更新して、新しい IAM ロールがキーを使用できるようにします。ポイントインタイムリカバリ (PITR) のために継続的バックアップを有効にします。
D. 既存のバックアッププランを使用します。AWSServiceRoleForBackup IAM ロールがキーを使用できるように、KMS キーポリシーを更新します。ファイルシステムのクロスリージョンレプリケーションを有効にします。
■問題文の要件の概要
- Amazon EFS を KMS 暗号化付きで利用
- AWS Backup で自動バックアップ運用中
- RPO（目標復旧時点）100分以内の要件あり
→ 1時間毎（60分）以上の頻度でのバックアップが必要
■正解の選択肢と解説
✅ 正解：A
- IAMロールとKMSポリシーの調整により、新しいバックアッププランに権限を付与。
- AWS Backup の最小バックアップ間隔は「1時間ごと」。
- 100分以内のRPO要件をクリアできるスケジュールで実現。
■不正解の選択肢の理由
❌ B：
cron式で30分ごとにバックアップという点が実現不可。- AWS Backup のバックアップスケジュールは最短 1時間ごと。
❌ C：
- Amazon EFS は 継続的バックアップ（PITR） をサポートしていない。
- PITRはEFSでは利用できない（RDSやDynamoDBなど一部サービスのみ）。
❌ D：
- クロスリージョンレプリケーションは 耐障害性向上が目的。
- RPO短縮には貢献しない。
■SAP試験で押さえておくべきポイント
- AWS Backup によるバックアップ頻度の最小単位は 1時間。
- EFS は PITR をサポートしない。
- RPO を短縮したい場合、スケジュール設定でカバーする必要がある。
- KMS 暗号化リソースをバックアップ対象に含める場合、KMS キーポリシーで IAM ロールの許可設定が必須。
- クロスリージョンレプリケーションは DR 対策（耐障害性）であり、RPO/RTO要件には直接貢献しないことが多い。
この設問は、EFS × AWS Backup の特性を把握し、実装可能な手法と制限を見極める力が問われます。SAP試験では頻出の「復旧目標時間（RTO）と復旧目標時点（RPO）」の違いも併せて理解しておくと良いでしょう。
以下に、いただいた問題を指定フォーマットで整理して解説します。
■問題文（文字列を編集せずに出力）
ある会社では、AWS Organizations を使用して開発環境を管理しています。会社の各開発チームは、独自の AWS アカウントがあります。各アカウントには、重複しない単一の VPC と CIDR ブロックがあります。
同社は、共有サービスアカウントに Amazon Aurora DB クラスターがあります。すべての開発チームは、DB クラスターからのライブデータを操作する必要があります。
最も少ない運用オーバーヘッドで DB クラスターへの必要な接続を提供するソリューションを選択してください。
■選択肢（正解がどれかは伏せて出力）
A.
DB クラスター用に AWS Resource Access Manager (AWS RAM) リソース共有を作成します。すべての開発アカウントで DB クラスターを共有します。
B.
共有サービスアカウントに Transit Gateway を作成します。Transit Gateway 用に AWS Resource Access Manager (AWS RAM) リソース共有を作成します。Transit Gateway をすべての開発アカウントと共有します。開発者にリソース共有を受け入れるように指示します。ネットワークを構成します。
C.
DB クラスターの IP アドレスを指す Application Load Balancer (ALB) を作成します。ALB を使用する AWS PrivateLink エンドポイントサービスを作成します。各開発アカウントがエンドポイントサービスに接続できるようにアクセス許可を追加します。
D.
共有サービスアカウントで AWS Site-to-Site VPN 接続を作成します。ネットワークを構成します。各開発アカウントで AWS Marketplace VPN ソフトウェアを使用して、Site-to-Site VPN 接続に接続します。
■問題文の要件の概要
- 複数の AWS アカウント（開発チーム）があり、個別の VPC を持っている。
- 共有アカウントにある Aurora DB に対し、すべての開発チームがライブデータ操作を必要とする。
- 要件は「運用オーバーヘッドを最小化しつつ接続を提供すること」。
■正解の選択肢と解説
正解：B
Transit Gateway（TGW）を中心としたハブアンドスポーク型接続を構成し、それを AWS RAM で共有する。
- Transit Gateway は複数のVPCを一括で接続・管理できる中心的なハブ。
- AWS RAM によって複数アカウント間での共有設定が簡素化される。
- ピアリングのような1対1接続ではなく、一括管理・拡張性がある構成で、運用効率が非常に高い。
- アカウント数が増えても設定変更は最小で済み、**「最も少ない運用オーバーヘッド」**という条件に最適。
■不正解の選択肢の理由
A. RAM による DB クラスター共有のみ
- Aurora DB 自体の「リソース共有」ではネットワーク接続は構成されない。
- VPC をまたぐアクセスを可能にするためには、VPC ピアリングや TGW 等のネットワーク構成が必須。
C. ALB 経由での PrivateLink 接続
- ALB を PrivateLink の エンドポイントとして使うのは非対応（通常は NLB に限る）。
- DB クラスター自体を NLB 経由で提供するのも現実的ではなく、設定が冗長・複雑。
D. Site-to-Site VPN の使用
- VPN はオンプレ⇔AWS向けのソリューションで、AWS アカウント間の接続に使うのは過剰。
- かつ、Marketplace VPN 製品の利用は構築・保守の手間が大きいため、「運用オーバーヘッド最小」とは矛盾する。
■SAP試験で押さえておくべきポイント
| ポイント | 内容 |
|---|---|
| AWS Transit Gateway | 複数のアカウント・VPCの一元管理・接続に最適。スケーラビリティ・メンテ性に優れる。 |
| AWS Resource Access Manager (RAM) | 組織内のリソース（TGWなど）を複数アカウントに共有する手段。Organizationsと連携。 |
| Aurora DB はVPC内リソース | 他アカウント・他VPCからアクセスするにはネットワーク接続（TGW, VPCピアリング等）が必要。 |
| PrivateLink の制限 | エンドポイントサービスは通常 NLB に限られ、ALB や DB には直接使えない。 |
| Site-to-Site VPN の用途 | 基本はオンプレミスとの接続向け。AWS内アカウント間用途には非推奨。 |
次の問題もお送りいただければ、同様の形式で解説いたします。
以下に、問題4の内容を指定フォーマットに沿って整理・解説します。
■問題文（文字列を編集せずに出力）
ある企業が、オンプレミスのデータセンターで 3 層のウェブアプリケーションを運用しています。フロントエンドは Apache ウェブサーバー、ミドル層はモノリシック Java アプリケーション、ストレージ層は PostgreSQL データベースです。
最近のマーケティングプロモーション中に、アプリケーションがクラッシュしたため、お客様はアプリケーションを通じて注文を行うことができませんでした。分析の結果、3 つの層すべてが過負荷状態であることがわかりました。アプリケーションは応答しなくなり、データベースは読み取り操作のために容量制限に達しました。同社では、近い将来に同様のプロモーションをいくつか予定しています。
ソリューションアーキテクトは、これらの問題を解決するために AWS への移行計画を立てる必要があります。ソリューションは、スケーラビリティを最大化し、運用上の労力を最小限に抑える必要があります。
これらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)
■選択肢（正解がどれかは伏せて出力）
A.
フロントエンドをリファクタリングして、静的アセットを Amazon S3 でホストできるようにします。Amazon CloudFront を使用して、お客様にフロントエンドを提供します。フロントエンドを Java アプリケーションに接続します。
B.
フロントエンドの Apache ウェブサーバーを、Auto Scaling グループに属する Amazon EC2 インスタンスに再ホストします。Auto Scaling グループの前にロードバランサーを使用します。Amazon Elastic File System (Amazon EFS) を使用して、Apache ウェブサーバーが必要とする静的アセットをホストします。
C.
Auto Scaling を含む AWS Elastic Beanstalk 環境で Java アプリケーションを再ホストします。
D.
Java アプリケーションをリファクタリングし、Java アプリケーションを実行する Docker コンテナを開発します。AWS Fargate を使用してコンテナをホストします。
E.
AWS Database Migration Service (AWS DMS) を使用して、PostgreSQL データベースを Amazon Aurora PostgreSQL データベースに再プラットフォームします。リードレプリカには Aurora Auto Scaling を使用します。
F.
オンプレミスサーバーの 2 倍のメモリを持つ Amazon EC2 インスタンスで PostgreSQL データベースを再ホストします。
■問題文の要件の概要
- 現在：3層構成（Apache／Javaアプリ／PostgreSQL）をオンプレで運用。
- 問題：全層が高負荷でクラッシュ。今後も同様のトラフィックが見込まれる。
- 要件：スケーラビリティ最大化・運用負荷最小化を実現するAWS移行戦略。
- 回答形式：3つの正しいステップを選択する
■正解の選択肢と解説
正解：A, C, E
✅ A. S3 + CloudFront によるフロントエンドの静的ホスティング
- 静的アセット（HTML/JS/CSSなど）を S3に配置しCloudFrontで配信する構成は、高可用かつスケーラブルなベストプラクティス。
- EC2やApacheのスケーリングを不要にし、運用負荷が大幅に削減される。
✅ C. Elastic Beanstalk による Java アプリの再ホスト
- Beanstalk は Javaアプリのマネージド環境を提供し、Auto Scaling やモニタリングが自動。
- 運用負荷が低く、モノリシックな構成でも柔軟なスケーリングが可能。
✅ E. Aurora + DMS + Auto Scaling
- Aurora PostgreSQL はマネージドサービスで、スケーラブルな読み取りレプリカを備える。
- DMSを使うことで ダウンタイムを抑えた移行が可能。
- Aurora Auto Scaling を使うと、トラフィックに応じたリードレプリカの追加・削除が自動。
■不正解の選択肢の理由
❌ B. EC2 + Apache + EFS
- スケーラビリティは確保できるが、ApacheやEC2の管理が必要になり運用負荷が高い。
- 静的ファイルに EFS を使うのはコスト・性能面で効率が悪い。
❌ D. コンテナ化 + Fargate
- Fargate の利用自体は良案だが、Javaアプリをコンテナ化するためのリファクタが必要で、短期的には運用負荷が大きい。
- 現在の要件は「迅速な移行と簡便なスケーリング」なので Beanstalk の方が現実的。
❌ F. EC2 に大容量メモリで再ホスト
- スペックアップは根本的なスケーラビリティ解決にはならず、水平方向のスケーリングや運用効率も考慮されていない。
- DBのスケーリング・可用性確保を目的とするなら Aurora + Auto Scaling の方が適切。
■SAP試験で押さえておくべきポイント
| 観点 | 要点 |
|---|---|
| フロントエンド移行 | 静的アセットは S3 + CloudFront にホスティングするのが最もスケーラブルで運用が軽い。 |
| Javaアプリケーションのホスティング | マネージドサービス（Elastic Beanstalk）が最優先。Auto Scaling も簡単に導入できる。 |
| データベース移行とスケーリング | Aurora PostgreSQL + Aurora Auto Scaling により読み取りスケーラビリティを確保。DMS でスムーズな移行。 |
| コンテナ vs Beanstalk | モノリシックJavaなら、まずは Beanstalk が無難。Fargate は将来のリファクタ時に検討。 |
| EC2 直接移行は最終手段 | 管理負担・スケーリング限界の観点から極力避ける（メモリ増強などは一時しのぎ）。 |
次の問題も続けて送っていただければ、同様に分析いたします。
以下に、問題5の内容をSAP試験向けに指定フォーマットで整理・解説します。
■問題文（文字列を編集せずに出力）
ある会社が、AWS Organizations の組織を使用して、複数の AWS アカウントを管理しています。この会社は、会社の共有サービスアカウントの VPC でいくつかのアプリケーションをホストしています。
同社は、共有サービスアカウントの VPC に Transit Gateway をアタッチしています。
同社は新しい機能を開発しており、共有サービスアカウントにあるアプリケーションへのアクセスを必要とする開発環境を作成しました。同社は、開発アカウントでリソースを頻繁に削除して再作成する予定です。また、必要に応じて、開発チームが共有サービスアカウントへのチーム接続を再作成できるようにしたいと考えています。
これらの要件を満たすソリューションを選択してください。
■選択肢（正解がどれかは伏せて出力）
A.
開発アカウントに Transit Gateway を作成します。共有サービスアカウントに Transit Gateway のピアリングリクエストを作成します。共有サービスの Transit Gateway が自動的にピアリング接続を受け入れるように構成します。
B.
共有サービスアカウントで Transit Gateway の自動受け入れを有効にします。AWS Resource Access Manager (AWS RAM) を使用して、共有サービスアカウントの Transit Gateway リソースを開発アカウントと共有します。開発アカウントでリソースを受け入れます。開発アカウントで Transit Gateway アタッチメントを作成します。
C.
共有サービスアカウントで Transit Gateway の自動受け入れを有効にします。VPC エンドポイントを作成します。エンドポイントポリシーを使用して、開発アカウントの VPC エンドポイントに対するアクセス許可を付与します。接続リクエストを自動的に受け入れるようにエンドポイントサービスを構成します。エンドポイントの詳細を開発チームに提供します。
D.
Amazon EventBridge ルールを作成して、開発アカウントがアタッチメントリクエストを行ったときに Transit Gateway アタッチメントを受け入れる AWS Lambda 関数を呼び出します。AWS Network Manager を使用して、共有サービスアカウントの Transit Gateway を開発アカウントと共有します。開発アカウントで Transit Gateway を受け入れます。
■問題文の要件の概要
- 複数アカウント管理 → Organizationsを利用
- 共有サービスアカウント → Transit Gateway保持中
- 開発アカウントでは → リソースの「頻繁な削除・再作成」が発生
- 要件：
- 接続を 開発チーム自身が再作成できる
- 接続の管理負荷を最小化
- 再現性のある スケーラブルなネットワーク接続
■正解の選択肢と解説
正解：B
✅ B. Transit Gateway を AWS RAM で共有し、自動受け入れを有効化
- Transit Gateway を共有サービスアカウントで一元管理しつつ、Resource Access Manager (RAM) で 開発アカウントと共有。
- 自動受け入れを有効にしておけば、開発チームは 自身でアタッチメント作成可能。
- この方法は運用負荷が非常に低く、Organizationsベースでのベストプラクティス。
■不正解の選択肢の理由
❌ A. 開発アカウントに Transit Gateway を新規作成
- Transit Gateway の重複作成は非効率。管理やルート制御が複雑化。
- 共有側ですでにTGWが存在しているなら、それを RAMで共有すべき。
❌ C. VPCエンドポイントの利用
- VPCエンドポイント（Interface/Gateway） は、AWSサービスへの接続用途であり、VPC-to-VPC通信には不適。
- この構成では Transit Gateway を活用しきれていない。
❌ D. EventBridge + Lambda による自動化
- 技術的には可能だが、過剰設計であり本問の目的（効率・再現性）に反する。
- RAMと自動受け入れで シンプルに解決できる内容に対し、Lambda・EventBridgeは冗長。
■SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| Transit Gateway 管理 | 一元管理された TGW を RAMで共有するのが基本戦略。複数アカウントで使い回せる。 |
| RAM (Resource Access Manager) | TGWやRoute 53 Resolverなどの共有に使われる。Organizations単位での共有も可能。 |
| 自動接続の実現 | Transit Gatewayの自動受け入れ設定を行えば、毎回マニュアル承認不要でアタッチ可能。 |
| 開発環境の可変性対応 | 頻繁に再作成される環境でも、RAM共有 + 自動受け入れで運用がスムーズ。 |
| NG構成 | VPCエンドポイントはサービス接続向け。TGW間接続には TGWアタッチ or ピアリング を使う。 |
次の問題も送っていただければ、引き続きこの形式で対応いたします。
以下に、問題6の内容を指定のSAP試験用フォーマットで整理・解説します。
■問題文（文字列を編集せずに出力）
ヨーロッパとアジアにオフィスを構え、家電製品を開発している企業は、ヨーロッパに 60 TB のソフトウェアイメージを保管しています。同社は、このイメージを ap-northeast-1 リージョンの Amazon S3 バケットに転送したいと考えています。新しいソフトウェアイメージは毎日作成されるため、転送中は暗号化する必要があります。同社は、カスタム開発を必要とせず、既存のソフトウェアイメージと新しいソフトウェアイメージをすべて Amazon S3 に自動的に転送できるソリューションが必要です。
転送プロセスの次の最適な手順を選択してください。
■選択肢（正解がどれかは伏せて出力）
A.
AWS DataSync エージェントをデプロイし、イメージを S3 バケットに転送するタスクを設定します。
B.
Amazon Kinesis Data Firehose を設定して、S3 Transfer Acceleration を使用してイメージを転送します。
C.
AWS Snowball デバイスを使用して、S3 バケットをターゲットとしてイメージを転送します。
D.
マルチパートアップロードで S3 API を使用して、Site-to-Site VPN 接続を介してイメージを転送します。
■問題文の要件の概要
- ヨーロッパに保管されている 60TB のソフトウェアイメージ
- 転送先は ap-northeast-1（東京）S3バケット
- 毎日新しいイメージが生成される
- 転送は暗号化が必要
- カスタム開発不要
- 既存・新規データを自動で転送可能な仕組みが必要
■正解の選択肢と解説
正解：A
✅ A. AWS DataSync エージェントを使用してタスクを構成
- AWS DataSync は、オンプレミスからS3への暗号化された自動転送をサポート。
- GUIベースで構成可能なため、カスタム開発不要。
- タスクをスケジュール化できるため、毎日更新されるデータの自動処理が可能。
- 60TB規模の大量データにも対応しており、高速かつセキュア。
■不正解の選択肢の理由
❌ B. Kinesis Data Firehose + S3 Transfer Acceleration
- Kinesis Firehose は ストリーミングデータ向けでファイル転送用途に不適。
- Transfer Acceleration は速度改善には役立つが、自動・バッチファイル転送機能を持たない。
❌ C. AWS Snowball
- 物理デバイスを用いた一時的なバルク転送には適するが、継続的な毎日の転送には不向き。
- 毎日更新されるデータに対応できない。
❌ D. マルチパートアップロード + Site-to-Site VPN
- セキュアだが、運用・構築が複雑であり、カスタム実装が必要。
- 毎日のファイルを確実に自動送信できる保証がなく、60TBの規模にも非効率。
■SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| 大容量の継続データ転送 | 定期的・自動的に更新されるデータ → AWS DataSync 一択。 |
| 暗号化要件 | DataSync はデータ転送中の TLS暗号化 と S3側の サーバー側暗号化の両方をサポート。 |
| 物理 vs 論理転送 | Snowball は一時的な物理移送に特化。継続的な同期用途には不適切。 |
| 転送プロトコルの自動化 | 手動やVPNベースのアップロードは、自動化・信頼性の観点でマイナス評価。 |
| Transfer Accelerationの誤解 | S3 Transfer Acceleration は「速度向上手段」であり、「自動同期機能」は持たない。 |
次の問題も同様の形式で対応可能ですので、続けてお送りください。
以下に、問題7の内容を AWS Certified Solutions Architect – Professional (SAP) 試験向けに整理・解説します。
■問題文（文字列を編集せずに出力）
ある会社が、AWS 上で e コマースのウェブアプリケーションを運営しています。このウェブアプリケーションは、Amazon S3 上の静的なウェブサイトとしてホストされており、コンテンツ配信には Amazon CloudFront を使用しています。Amazon API Gateway API は、ウェブアプリケーションのユーザーリクエストと注文処理を処理するために AWS Lambda 関数を呼び出します。Lambda 関数は、オンデマンドインスタンスを使用する Amazon RDS for MySQL DB クラスターにデータを保存します。DB クラスターの使用量は過去 12 ヶ月間一貫しています。
最近、ウェブサイトで SQL インジェクションとウェブエクスプロイトの試みが発生しています。また、お客様からは、使用量のピーク時に注文処理時間が長くなったという報告もあります。これらの期間中、Lambda 関数はしばしばコールドスタートします。会社の成長に伴い、会社はトラフィックのピーク時にスケーラビリティと低レイテンシーのアクセスを確保する必要があります。また、データベースのコストを最適化し、SQL インジェクションやウェブエクスプロイトの試みに対する保護を追加する必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢（正解がどれかは伏せて出力）
A.
Lambda 関数を設定して、ピーク時にタイムアウト値を増やします。データベースに RDS リザーブドインスタンスを使用します。CloudFront を使用して、SQL インジェクションとウェブエクスプロイトの試みから保護するために AWS Shield Advanced にサブスクライブします。
B.
Lambda 関数のメモリを増やし、データベースを Amazon Redshift に移行します。Amazon Inspector を CloudFront と統合して、SQL インジェクションやウェブエクスプロイトの試みから保護します。
C.
ピーク時のコンピューティングには、プロビジョニング済み同時実行性を備えた Lambda 関数を使用し、データベースを Amazon Aurora Serverless に移行します。CloudFront を使用して、SQL インジェクションとウェブエクスプロイトの試みから保護するために AWS Shield Advanced にサブスクライブします。
D.
ピーク時のコンピューティングには、プロビジョニング済み同時実行性を備えた Lambda 関数を使用します。データベースには RDS リザーブドインスタンスを使用します。AWS WAF を CloudFront と統合して、SQL インジェクションとウェブエクスプロイトの試みから保護します。
■問題文の要件の概要
- 現在の構成：
- 静的ウェブ → S3 + CloudFront
- バックエンド → API Gateway → Lambda → RDS for MySQL
- 問題点：
- SQLインジェクション・Webエクスプロイトが発生
- ピーク時に注文処理遅延（Lambdaのコールドスタート）
- 要件：
- スケーラビリティと低レイテンシー（Lambdaの最適化）
- データベースコストの最適化（安定した負荷）
- セキュリティ強化（Web脅威対策）
■正解の選択肢と解説
正解：D
✅ 解説
- プロビジョニング済み同時実行性を設定したLambdaにより、コールドスタートを防止 → 低レイテンシー実現。
- データベースには使用量が一定なので、RDSリザーブドインスタンスがコスト最適化に最適。
- AWS WAFをCloudFrontに統合 → SQLインジェクションやXSSなどWebエクスプロイトをブロック可能。
- WAFはWebレイヤーの保護
- Shield AdvancedはDDoS対策であり、本件の攻撃種別には効果が薄い
■不正解の選択肢の理由
❌ A
- Shield AdvancedはDDoS対策であり、SQLインジェクションやWeb攻撃に対処できない。
- Lambdaのタイムアウト延長はコールドスタート対策にならない。
- RDSリザーブドは適しているが、他が不適。
❌ B
- Amazon Redshiftは分析用のDWH。トランザクション処理（注文データなど）には不向き。
- Inspectorは脆弱性スキャンツールで、CloudFrontとの統合もできず、攻撃検知には使用できない。
❌ C
- Aurora Serverlessはスケーラビリティに優れるが、安定した使用量にはコストが高くなる可能性あり。
- WAFではなく Shield Advancedの使用はWeb脅威対策として不適切（DDoS用）。
■SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| Lambdaパフォーマンス | コールドスタート防止には「プロビジョニング済み同時実行性」。タイムアウトやメモリ増加では解決できない。 |
| DBコスト最適化 | 安定した使用量 → RDSリザーブドインスタンスが有効。Aurora Serverlessは変動トラフィック向き。 |
| セキュリティ対策 | WAF → Webアプリ攻撃（SQLi・XSS）に対応Shield Advanced → DDoS対策のみ。 |
| RedshiftとRDSの違い | Redshift → 分析用途、RDS → トランザクション用途。 |
| Inspectorの用途 | インスタンスやLambdaコードの脆弱性スキャン。攻撃のブロックや監視はできない。 |
次の問題も続けていただければ、同様に解説いたします。
