Uncategorized

#52

 

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

■問題文

ソフトウェア会社は、複数の AWS アカウントとリージョンにあるリソースを使用して AWS でアプリケーションをホストしています。アプリケーションは、us-east-1 リージョンにあるアプリケーション VPC 内の Amazon EC2 インスタンスのグループで実行され、IPv4 CIDR ブロックは 10.10.0.0/16 です。別の AWS アカウントでは、共有サービス VPC は us-east-2 リージョンにあり、IPv4 CIDR ブロックは 10.10.10.0/24 です。クラウドエンジニアが AWS CloudFormation を使用してアプリケーション VPC と共有サービス VPC をピアリングしようとすると、ピアリングの失敗を示すエラーメッセージが表示されます。

このエラーの原因となる可能性のある要因を選択してください。 (2 つ選択)

■選択肢

A. 2 つの VPC の IPv4 CIDR 範囲が重複しています。
B. VPC が同じリージョンにありません。
C. 一方または両方のアカウントがインターネットゲートウェイにアクセスできません。
D. VPC の 1 つが AWS Resource Access Manager を介して共有されていません。
E. ピアアクセプタのアカウントの IAM ロールに適切な権限がありません。

■問題文の要件の概要

  • us-east-1 と us-east-2 に存在する 別アカウントの VPC をピアリング しようとした。
  • CloudFormation 実行時に エラーで失敗。
  • 考えられる原因は CIDR 重複 or IAM 権限不足 のような設定上の問題。

■正解の選択肢と解説

✅ A. 2つの VPC の IPv4 CIDR 範囲が重複しています

  • 10.10.0.0/16 は 10.10.10.0/24 を内包しているため重複。
  • VPC ピアリングは CIDR が重複する場合は作成できない。

✅ E. ピアアクセプタのアカウントの IAM ロールに適切な権限がありません

  • CloudFormation でクロスアカウント VPC ピアリングを作成する場合、アクセプタ側には ec2:AcceptVpcPeeringConnection 権限などが必要。
  • 権限不足でリクエストが承諾されず、スタックは CREATE_FAILED になる。

■不正解の選択肢の理由

B. VPC が同じリージョンにありません

  • 誤り。VPC ピアリングは インターリージョンでも可能。
  • レイテンシーやデータ転送料金の考慮は必要だが、接続自体は可能。

C. インターネットゲートウェイがない

  • 誤り。ピアリングは プライベートルートでの通信であり、IGW の有無は関係ない。

D. AWS Resource Access Manager (RAM) を経由していない

  • 誤り。VPC ピアリングは クロスアカウントで直接リクエスト／承諾が可能であり、RAM は不要。

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

  • VPCピアリングの制約：
    • CIDR が重複している場合は作成できない。
    • セキュリティグループやルートテーブルの設定は後続作業として必要。
  • クロスアカウント VPC ピアリング：
    • IAM 権限不足が典型的な失敗要因。
  • 誤答になりやすいポイント：
    • 「リージョンが違うとダメ」→ 実際はOK（インターリージョンピアリング可能）。
    • 「IGW 必須」や「RAM 必須」→ 不要。

👉 この問題の本質は 「CIDR重複禁止」と「IAM権限不足が失敗原因になりうる」 という VPC ピアリングの制約理解です。

次は 問題2 を同じ形式でまとめましょうか？

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

■問題文

洪水監視機関は、1 万個以上の水位監視センサーを配備しています。センサーは継続的にデータ更新を送信し、各更新のサイズは 1 MB 未満です。この機関には、オンプレミスのアプリケーションサーバーがあります。これらのサーバーは、センサーからの更新を受信し、生データを人間が読める形式に変換し、その結果をオンプレミスのリレーショナルデータベースサーバーに書き込みます。次に、データアナリストは、単純な SQL クエリを使用してデータを監視します。

機関は、アプリケーション全体の可用性を高め、メンテナンスタスクの実行に必要な労力を削減したいと考えています。アプリケーションサーバーの更新とパッチ適用を含むこれらのメンテナンスタスクは、ダウンタイムの原因となります。アプリケーションサーバーがダウンしている間、残りのサーバーがワークロード全体を処理できないため、センサーからデータが失われます。

機関は、運用のオーバーヘッドとコストを最適化するソリューションを求めています。ソリューションアーキテクトは、センサーデータを収集するために AWS IoT Core を使用することを推奨しています。

これらの要件を満たすために、ソリューションアーキテクトは他に何を推奨すべきでしょうか ?

■選択肢

A. センサーデータを Amazon Kinesis Data Firehose に送信します。AWS Lambda 関数を使用して Kinesis Data Firehose データを読み取り、.csv 形式に変換し、Amazon Aurora MySQL DB インスタンスに挿入します。データアナリストに、DB インスタンスから直接データをクエリするように指示します。

B. センサーデータを Amazon Kinesis Data Firehose に送信します。AWS Lambda 関数を使用して Kinesis Data Firehose データを読み取り、Apache Parquet 形式に変換し、Amazon S3 バケットに保存します。データアナリストに、Amazon Athena を使用してデータをクエリするように指示します。

C. センサーデータを Amazon Managed Service for Apache Flink アプリケーションに送信し、データを .csv 形式に変換して Amazon S3 バケットに保存します。Amazon Aurora MySQL DB インスタンスにデータをインポートします。データアナリストに、DB インスタンスから直接データをクエリするように指示します。

D. センサーデータを Amazon Managed Service for Apache Flink アプリケーションに送信し、データを Apache Parquet 形式に変換して Amazon S3 バケットに保存します。データアナリストに Amazon Athena を使用してデータをクエリするように指示します。

■問題文の要件の概要

  • センサー数：1 万台以上、連続的に小さいデータを送信
  • 現在：オンプレサーバー → DB に変換・保存 → SQL で監視
  • 課題：サーバーのパッチ適用や障害で ダウンタイム & データロス が発生
  • 目的：
    • 高可用性
    • 運用オーバーヘッド削減
    • コスト最適化

■正解の選択肢と解説

✅ B. Kinesis Data Firehose + Lambda(Parquet変換) + S3 + Athena

  • Kinesis Data Firehose：フルマネージドで自動スケーリングし、取り込みサーバー不要。
  • Lambda：Parquet 変換をサーバーレスで実施。
  • S3：データを高耐久・低コストで保存。
  • Athena：SQL で即時分析可能、サーバーレスで管理不要。

→ 列指向形式の Parquet を利用することで、スキャン量削減 → クエリコスト最適化。
→ サーバー不要で、パッチ適用やスケーリング対応も不要 → 可用性と運用負荷削減を両立。

■不正解の選択肢の理由

A. Aurora MySQL に直接書き込み

  • 高頻度のストリーム書き込みでは 接続制限・ロック競合 のリスク。
  • Aurora は高負荷ストリーミング処理には不向き。

C. Flink → S3 → Aurora

  • Flink 導入は複雑 & 運用コスト増。
  • Aurora で最終分析するためスケーラビリティ低下。
  • オーバーヘッド削減の要件に反する。

D. Flink → Parquet → S3 → Athena

  • 分析構成は正しいが、Flink は不要な複雑化。
  • Firehose + Lambda で十分対応可能。

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

  • IoT/センサーデータの取り込み設計
    • Firehose はバッファリング & 自動スケーリング → サーバーレスで高可用。
  • データフォーマット選択
    • Parquet/ORC など列指向フォーマットは大規模データ分析で必須。
  • サーバーレス分析基盤
    • S3 + Athena で SQL 分析 → 運用オーバーヘッド最小。
  • 誤答の落とし穴
    • 「Aurora に突っ込めばいい」→ スケールしない。
    • 「Flinkを入れれば高機能」→ 複雑性が増し試験要件に反する。

👉 この問題の本質は 「IoT データをサーバーレスかつ高可用に収集・変換・分析する最適解」 を選べるかどうかです。

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

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

■問題文

ある企業には、親会社に統合される複数の事業部門 (LOB) があります。同社は、ソリューションアーキテクトに次の要件を満たすソリューションの開発を依頼しました。

  • LOB が使用するすべての AWS アカウントに対して、単一の AWS 請求書を作成します。
  • LOB アカウントごとのコストは、請求書で内訳を記載する必要があります。
  • 会社のガバナンスポリシーで定義されているように、LOB アカウントでサービスと機能を制限する機能を提供します。
  • ガバナンスポリシーに関係なく、各 LOB アカウントに完全な管理者権限を委任する必要があります。

これらの要件を満たすために、ソリューションアーキテクトが実行する必要がある手順の組み合わせを選択してください。 (2 つ選択)

■選択肢

A. AWS Organizations を使用して、各 LOB の親アカウントに組織を作成します。次に、各 LOB アカウントを適切な組織に招待します。

B. AWS Organizations を使用して、親アカウントに単一の組織を作成します。次に、各 LOB の AWS アカウントを組織に参加するよう招待します。

C. サービスクォータを実装して、許可されるサービスと機能を定義し、必要に応じて各 LOB にクォータを適用します。

D. 承認されたサービスと機能のみを許可する SCP を作成し、そのポリシーを LOB アカウントに適用します。

E. 親アカウントの課金コンソールで一括請求を有効にし、LOB アカウントをリンクします。

■問題文の要件の概要

  • 単一請求書：全アカウントをまとめた Consolidated Billing が必要。
  • 内訳表示：アカウント別コストを可視化する必要あり。
  • ガバナンス：特定サービス・機能の利用制限。
  • 管理権限：各アカウントには Admin 権限をフルに委任する必要がある。

■正解の選択肢と解説

✅ B. AWS Organizations を使用して単一の組織を作成する

  • AWS Organizations で単一の組織を作成 → 一括請求が自動で有効化。
  • 請求書は 1 枚になり、各アカウントごとの明細を含む。
  • OU を利用して部門ごとに構造化も可能。

✅ D. 承認されたサービスと機能のみを許可する SCP を作成し、LOB アカウントに適用する

  • サービスコントロールポリシー (SCP) は OU やアカウントに適用可能。
  • Admin 権限を各アカウントに委任しても、SCP が「利用可能な範囲の上限」を定義する。
  • これによりガバナンスポリシーを一元的に実現できる。

■不正解の選択肢の理由

A. 各 LOB ごとに別組織を作成

  • 複数組織に分けると Consolidated Billing が分断される。
  • 単一請求書が実現できず不適切。

C. サービスクォータで制御

  • サービスクォータは利用上限の設定であり、未承認サービスを禁止する仕組みではない。
  • ガバナンスポリシー実装には不十分。

E. 一括請求のみ有効化

  • 請求統合はできるが、ガバナンス制御 (SCP) を適用できない。
  • Organizations を使わない方式は非推奨。

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

  • AWS Organizations の役割
    • 一括請求 (Consolidated Billing) を提供。
    • OU 単位で SCP を適用可能。
    • マルチアカウント戦略のベストプラクティスの中核サービス。
  • SCP の特徴
    • IAM 権限の「上限」を設定するガードレール。
    • AdminAccess を持つユーザーでも SCP で制限された操作は不可。
    • ガバナンスと権限委任を両立可能。
  • 誤答の典型パターン
    • サービスクォータを権限制御と誤解する。
    • Consolidated Billing と Organizations の違いを混同する。
    • 部門ごとに別 Organizations を作成してしまう。

👉 この問題の本質は 「Organizations + SCP による一元的な請求統合とガバナンス」 を理解しているかどうかです。

次は 問題4 も同じフォーマットで整理していきますか？

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

■問題文

ある企業では、イベント駆動型アーキテクチャを用いて注文システムを導入しました。初期テスト中に、システムが注文を処理できなくなりました。さらにログを分析したところ、Amazon Simple Queue Service (Amazon SQS) の標準キューにある 1 つの注文メッセージがバックエンドでエラーを引き起こし、後続のすべての注文メッセージをブロックしていることがわかりました。キューの可視性タイムアウトは 30 秒に設定されており、バックエンドの処理タイムアウトは 10 秒に設定されています。ソリューションアーキテクトは、欠陥のある注文メッセージを分析し、システムが後続のメッセージを処理し続けることを確認する必要があります。

これらの要件を満たすための最適な方法を選択してください。

■選択肢

A. 可視性タイムアウトと一致するように、バックエンド処理タイムアウトを 30 秒に増やします。

B. キューの可視性タイムアウトを減らして、欠陥のあるメッセージを自動的に削除します。

C. 新しい SQS FIFO キューをデッドレターキューとして設定し、欠陥のあるメッセージを分離します。

D. 新しい SQS 標準キューをデッドレターキューとして設定し、欠陥のあるメッセージを分離します。

■問題文の要件の概要

  • SQS 標準キューに 処理できない欠陥メッセージ が存在。
  • そのメッセージが再試行され続け、後続の正常メッセージが処理できない。
  • 欠陥メッセージを 隔離（分析可能にする） しつつ、システムは後続処理を継続する必要がある。

■正解の選択肢と解説

✅ D. 新しい SQS 標準キューをデッドレターキューとして設定する

  • DLQ (Dead Letter Queue) を設定することで、処理に失敗したメッセージは一定回数（maxReceiveCount）再試行後、自動的に DLQ に送られる。
  • 欠陥メッセージが本番キューから分離され、後続メッセージの処理が継続可能になる。
  • DLQ 内のメッセージは別途分析して根本原因を特定できる。
  • 標準キューの DLQ は必ず 標準キュー でなければならない（FIFO ↔ 標準は不可）。

■不正解の選択肢の理由

A. バックエンド処理タイムアウトを 30 秒にする

  • 可視性タイムアウトと揃えても、欠陥メッセージは繰り返し処理失敗を起こし、後続が詰まる。
  • 根本的な解決にならない。

B. 可視性タイムアウトを減らす

  • タイムアウトを短くしてもメッセージは削除されず、再配信が加速するだけ。
  • 欠陥メッセージを隔離できない。

C. FIFO キューを DLQ にする

  • DLQ はソースキューと同じタイプでなければならない。
  • 標準キュー → FIFO キューの組み合わせはサポートされない。

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

  • SQS Dead Letter Queue (DLQ)
    • 失敗メッセージを分離して後続処理を継続可能にする仕組み。
    • maxReceiveCount を超えると自動的に DLQ に移動する。
    • DLQ のタイプはソースキューと同じである必要あり（標準↔標準、FIFO↔FIFO）。
  • 可視性タイムアウトの誤解を避ける
    • 可視性タイムアウトは「処理中に同じメッセージが他のコンシューマーに見えないようにする時間」。
    • 削除は自動で行われず、必ず DeleteMessage API か DLQ 移動が必要。
  • イベント駆動アーキテクチャ設計の鉄則
    • 欠陥データや一部の失敗が全体をブロックしないように フォールトアイソレーション を設計する。
    • DLQ はその代表的手段。

👉 この問題の本質は 「SQS の DLQ によって欠陥メッセージを隔離し、後続処理を継続させる」 です。

次の 問題5 も同じ形式で整理しますか？

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

■問題文

ある金融会社は、Amazon S3 にデータレイクをホストしています。同社は毎晩、複数のサードパーティから SFTP を介して財務データのレコードを受信します。同社は、VPC のパブリックサブネット内の Amazon EC2 インスタンスで独自の SFTP サーバーを実行しています。ファイルはアップロードされた後、同じインスタンス上で実行される cron ジョブによってデータレイクに移動されます。SFTP サーバーは、Amazon Route 53 を使用して DNS sftp.example.com に到達できます。

SFTP ソリューションの信頼性とスケーラビリティを向上させる最適な方法を選択してください。

■選択肢

A. EC2 インスタンスを Auto Scaling グループに移動します。Application Load Balancer （ALB）の背後に EC2 インスタンスを配置します。ALB を指すように Route 53 の DNS レコード sftp.example.com を更新します。

B. SFTP サーバーを AWS Transfer for SFTP に移行します。サーバーエンドポイントのホスト名を指すように、Route 53 の DNS レコード sftp.example.com を更新します。

C. SFTP サーバーを AWS Storage Gateway のファイルゲートウェイに移行します。ファイルゲートウェイのエンドポイントを指すように Route 53 の DNS レコード sftp.example.com を更新します。

D. Network Load Balancer (NLB) の背後に EC2 インスタンスを配置します。NLB を指すようにRoute 53 の DNS レコード sftp.example.com を更新します。

■問題文の要件の概要

  • サードパーティから毎晩 SFTP 経由でデータを受け取る必要がある。
  • 現状は EC2 1 台で稼働 → 単一障害点（SPOF）、スケール不可。
  • データは最終的に Amazon S3 データレイク に保存する。
  • 求められるのは 高可用性 + スケーラビリティ + 運用負荷低減。

■正解の選択肢と解説

✅ B. AWS Transfer for SFTP に移行する

  • AWS Transfer Family (SFTP) はマネージドサービスで、SFTP エンドポイントをフルマネージドで提供。
  • マルチ AZ 冗長化済み → EC2 サーバーの SPOF を排除。
  • 自動スケーリングでセッション数や転送量に応じて拡張。
  • Amazon S3 とのネイティブ連携 により、アップロード後の cron ジョブ不要（直接 S3 に保存）。
  • Route 53 で CNAME を Transfer サーバーに向けるだけで移行可能。

■不正解の選択肢の理由

A. EC2 + Auto Scaling + ALB

  • ALB は HTTP/HTTPS 向け (L7) であり、SFTP のような長時間 TCP セッションは扱いに不向き。
  • Auto Scaling しても各 EC2 がローカル保存 → データ同期が必要になり複雑化。

C. Storage Gateway ファイルゲートウェイ

  • File Gateway は NFS / SMB プロトコル に対応するが、SFTP プロトコルは非対応。
  • そのためクライアントは接続できない。

D. NLB + EC2

  • NLB は TCP レベル (L4) の負荷分散は可能だが、複数インスタンス間のファイル共有が問題。
  • 各 EC2 に保存 → 同期や重複排除の仕組みが必要となり、管理が煩雑。

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

  • AWS Transfer Family
    • マネージド SFTP/FTPS/FTP/AS2 を提供。
    • バックエンドは Amazon S3 または Amazon EFS。
    • 高可用性・スケーラブル・サーバーレス。
    • Route 53 CNAME を使えば既存 DNS 名を維持可能。
  • 誤答パターンの注意点
    • 「EC2 + LB」で SFTP を HA 化しようとするのは誤り（セッション持続・ストレージ同期問題）。
    • 「Storage Gateway」は別ユースケース向け（オンプレ ↔ S3/NFS/SMB）。
    • SFTP 要件には Transfer Family が最適解。

👉 この問題の本質は 「SFTP サーバーを EC2 からマネージドサービス (AWS Transfer for SFTP) に移行することで信頼性・スケーラビリティを確保する」 ことです。

次の 問題6 も同じフォーマットで整理していきましょうか？

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

■問題文

ロードバランサーは、単一のアベイラビリティーゾーンに含まれる Amazon EC2 インスタンスにトラフィックを分散するために使用されます。この組織ではセキュリティが問題になっており、ソリューションアーキテクトが以下の要件を満たすようにシステムを再構築してくれることを望んでいます。

  • 一般的な脆弱性攻撃に対して、インバウンドリクエストをフィルタリングする必要があります。
  • 拒否されたリクエストは、サードパーティの監査アプリケーションに送信する必要があります。
  • すべてのリソースが高可用性である必要があります。

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

■選択肢

A. アプリケーションの AMI を使用して マルチ AZ 構成の Auto Scaling グループを設定します。ALB を作成し、ターゲットとして Auto Scaling グループを選択します。Amazon Inspector を使用してトラフィックを監視。WAF で Web ACL を作成。AWS Lambda で Inspector レポートをサードパーティに送信。

B. ALB を設定し、EC2 インスタンスをターゲットに追加。WAF で Web ACL を作成。CloudWatch Logs でログ記録を有効化。AWS Lambda でログをサードパーティに送信。

C. ALB とターゲットグループを設定し、EC2 を追加。Kinesis Data Firehose を作成し、サードパーティ宛に設定。WAF で Web ACL を作成し、Kinesis Firehose にログを送信。AWS マネージドルールをサブスクライブ。

D. アプリケーションの AMI を使用して マルチ AZ 構成の Auto Scaling グループを設定。ALB を作成し、ターゲットに Auto Scaling グループを追加。Kinesis Data Firehose を作成しサードパーティ宛に設定。WAF で Web ACL を作成し、ログ送信先を Firehose に設定。AWS マネージドルールをサブスクライブ。

■問題文の要件の概要

  • セキュリティ：一般的な脆弱性（SQLインジェクション、XSS など）をフィルタリングする必要がある → AWS WAF + マネージドルール。
  • 監査要件：拒否リクエストをサードパーティに送信 → WAF ログを Kinesis Data Firehose で転送。
  • 高可用性：EC2 が単一 AZ → Auto Scaling マルチ AZ + ALB で冗長化。

■正解の選択肢と解説

✅ D. Auto Scaling (マルチ AZ) + ALB + AWS WAF + Kinesis Data Firehose

  • Auto Scaling マルチ AZ → コンピュートリソースの冗長化で高可用性を実現。
  • Application Load Balancer → 複数 AZ にまたがるトラフィック分散。
  • AWS WAF → SQLi や XSS などの一般的な脆弱性攻撃をフィルタリング可能。
  • AWS マネージドルール → セキュリティ運用の効率化。
  • Kinesis Data Firehose → 拒否リクエストログをサードパーティにリアルタイム転送可能。

この構成で セキュリティ、監査要件、高可用性 のすべてを満たす。

■不正解の選択肢の理由

A. Inspector を利用

  • Amazon Inspector は 脆弱性診断（パッチ不足など） のサービスであり、リアルタイムでリクエストをブロックできない。要件の「フィルタリング」に不適。

B. CloudWatch Logs + Lambda 転送

  • WAF + CloudWatch でログ転送は可能だが、EC2 が単一 AZ → 高可用性を満たさない。

C. Firehose でログ転送は正しいが Auto Scaling がない

  • 拒否リクエスト送信は実現できるが、EC2 が単一 AZ → 高可用性の要件を満たさない。

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

  • AWS WAF：ALB / CloudFront / API Gateway にアタッチ可能。マネージドルールで一般的な攻撃を自動検知。
  • WAF ログの外部転送：CloudWatch Logs または Kinesis Data Firehose 経由でサードパーティへ送信可能。
  • Inspector の役割：インフラの脆弱性スキャンであり、リクエストフィルタリングはできない。
  • 高可用性設計：必ず「Auto Scaling + マルチ AZ + ALB」で冗長化。

👉 この問題の本質は
「AWS WAF で攻撃をフィルタし、拒否ログを Firehose 経由で外部転送しつつ、Auto Scaling + ALB で高可用性を担保する」 です。

次は 問題7 を整理していきますか？

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

■問題文

ソリューションアーキテクトは、Amazon API Gateway リージョンエンドポイントと AWS Lambda 関数を使用するウェブアプリケーションを開発しました。ウェブアプリケーションの消費者は、アプリケーションがデプロイされる AWS リージョンと同じ地域に住んでいます。Lambda 関数は、Amazon Aurora MySQL データベースにのみクエリを実行します。ソリューションアーキテクトは、3 つのリードレプリカを持つようにデータベースを構成しています。

テストしたところ、アプリケーションはパフォーマンス要件を満たすことができません。負荷が高い場合、アプリケーションは多数のデータベース接続を開きます。

これらの要件を満たすために、最適な方法を選択してください。（2つ選択）

■選択肢

A. Aurora データベースのクラスターエンドポイントを使用します。

B. RDS Proxy を使用して、Aurora データベースのリーダーエンドポイントへの接続プールを設定します。

C. Lambda プロビジョニング済み同時実行の機能を使用します。

D. Lambda 関数内のデータベース接続を開くためのコードを、イベントハンドラの外に移動します。

E. API Gateway エンドポイントをエッジ最適化エンドポイントに変更します。

■問題文の要件の概要

  • 課題：負荷が高いときに Lambda が大量の DB 接続を生成 → Aurora の接続数上限・レイテンシー悪化。
  • 要件：DB 接続数を抑制しつつ、Lambda のパフォーマンスを改善する。
  • 前提条件：ユーザーは同一リージョン内にいるため、API Gateway の最適化は不要。

■正解の選択肢と解説

✅ B. RDS Proxy を使用して接続プールを設定

  • Lambda の呼び出しごとに新規接続を作らず、RDS Proxy が接続をプール・再利用。
  • Aurora の接続制御を効率化し、スパイク時でも接続数が爆発しない。
  • マルチ AZ 構成で可用性も確保。

✅ D. Lambda コードで接続をイベントハンドラ外に移動

  • Lambda はコンテナ再利用時に既存の接続を保持できる。
  • ハンドラー外で接続確立すると、同じコンテナでは再利用されるため、新規接続オーバーヘッドを削減。
  • Aurora への負荷が減り、応答時間も短縮。

■不正解の選択肢の理由

❌ A. Aurora クラスターエンドポイント

  • 単にプライマリノードへルーティングするだけ。
  • 接続プールや接続削減の機能はないため、根本的な課題（接続数爆発）を解決できない。

❌ C. Lambda プロビジョニング済み同時実行

  • コールドスタート回避が目的。
  • DB 接続数削減とは無関係。むしろ固定数の Lambda がそれぞれ接続を持ち続け、Aurora 接続上限に達するリスクあり。

❌ E. API Gateway エッジ最適化エンドポイント

  • リージョン外の利用者に有効（CloudFront 経由で低遅延化）。
  • 今回の利用者は同一リージョンにいるため効果なし。
  • DB 接続数問題にも無関係。

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

  • Lambda + RDS/Aurora ベストプラクティス
    • RDS Proxy を利用して DB 接続を効率的にプーリング。
    • Lambda 初期化コードを活用し、接続をハンドラー外で確立 → コネクション再利用。
  • Aurora エンドポイントの違い
    • Cluster Endpoint：プライマリインスタンス（書き込み用）。
    • Reader Endpoint：リードレプリカに分散。
    • Instance Endpoint：特定インスタンスを直接指定。
  • 間違いやすいポイント
    • Provisioned Concurrency = コールドスタート対策であり、接続数制御とは無関係。
    • Edge Optimized API = グローバルユーザー向け、同一リージョンでは不要。

👉 この問題の本質は
「Lambda の大量同時接続を Aurora に直接作らせず、RDS Proxy で接続プールを利用し、さらに Lambda のコネクション再利用を徹底する」 です。

次は 問題8 を整理していきますか？

RELATED POST