Uncategorized

#41

 

以下は、あなたが提供してくださったHTML形式のSAP試験問題に対する整理・解説です。

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

ある企業が AWS でサーバーレス e コマースアプリケーションを実行しています。このアプリケーションは、Amazon API Gateway を使用して AWS Lambda の Java 関数を呼び出します。Lambda 関数は、Amazon RDS for MySQL データベースに接続してデータを保存します。
最近のセールイベント中、ウェブトラフィックの急激な増加により、API のパフォーマンスが低下し、データベース接続に失敗しました。同社は、Lambda 関数のレイテンシーを最小限に抑え、トラフィックのバーストに対応するためのソリューションを実装する必要があります。
アプリケーションへの変更を最小限に抑えて、これらの要件を満たすソリューションを選択してください。

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

A. Lambda 関数のコードを更新して、Lambda 関数が関数ハンドラーの外部でデータベース接続を開くようにします。Lambda 関数のプロビジョニング済み同時実行数を増やします。
B. データベースの RDS Proxy エンドポイントを作成します。AWS Secrets Manager にデータベースシークレットを保存します。必要な IAM アクセス許可を設定します。RDS Proxy エンドポイントに接続するように Lambda 関数を更新します。Lambda 関数のプロビジョニング済み同時実行数を増やします。
C. カスタムパラメータグループを作成します。max_connections パラメータの値を増やします。カスタムパラメータグループを RDS DB インスタンスに関連付け、再起動をスケジュールします。Lambda 関数の予約済み同時実行数を増やします。
D. データベースの RDS Proxy エンドポイントを作成します。AWS Secrets Manager にデータベースシークレットを保存します。必要な IAM アクセス許可を設定します。RDS Proxy エンドポイントに接続するように Lambda 関数を更新します。Lambda 関数の予約済み同時実行数を増やします。

■問題文の要件の概要

  • サーバーレス構成（API Gateway + Lambda）
  • Amazon RDS for MySQL に接続
  • セールによる急激なトラフィック増加でパフォーマンス低下
  • データベース接続エラー
  • レイテンシー最小化
  • トラフィックのバースト対応
  • アプリケーション変更は最小限に抑えたい

■正解の選択肢と解説

  • 正解: B

理由:

  • Amazon RDS Proxy を導入することで、Lambda のスケールアウトによる DB 接続数増加を抑制でき、接続プールにより効率的な接続管理が可能。
  • プロビジョニング済み同時実行 によって、関数が常時ウォーム状態となり、コールドスタートによるレイテンシーを回避。
  • Secrets Manager と連携させることで、認証情報の管理も自動化・安全に実施できる。
  • アプリケーション変更はRDS 接続先のエンドポイントを変更するだけで最小限に抑えられる。

■不正解の選択肢の理由

  • A:
    関数外での DB 接続保持は Lambda のスケールアウト時に意味をなさず、同時実行数が増えると DB への接続数も増加して max_connections を容易に超過するリスクがある。
  • C:
    max_connections を増やすことで接続数の制限は一時的に緩和されるが、DB のメモリ使用量が増加して不安定化するリスクあり。また 予約済み同時実行 はレイテンシー改善には寄与しない。
  • D:
    RDS Proxy の活用は正しいが、予約済み同時実行 では Lambda をウォームに保てず、トラフィック急増時にコールドスタートが発生してレイテンシーが悪化するため目的を満たせない。

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

  • RDS Proxy はサーバーレス（特に Lambda）と RDS の接続最適化において重要な役割を果たす。接続プールによって RDS の max_connections 制限を回避可能。
  • Secrets Manager と RDS Proxy の連携で 安全な認証情報管理を実現。
  • Lambda の同時実行オプションの違い：
    • 予約済み同時実行：他関数からのリソース保護。レイテンシー改善効果は限定的。
    • プロビジョニング済み同時実行：ウォーム状態を維持しコールドスタート防止。
  • 「レイテンシー対策」「バースト対応」には プロビジョニング済み同時実行 を選ぶ。
  • 設問の条件「アプリケーションへの変更を最小限に抑えたい」→構成変更の影響を少なくする設計が必要。

次の問題も準備できましたら、HTML形式でお送りください。丁寧に整理して解説いたします。

ご指摘ありがとうございます。以下、ご指定のフォーマットに正しく従って再出力いたします。

■問題文（文字列を編集せずに出力してください。）

ある企業は、オンプレミスのデータセンターで多くのサービスが実行されています。データセンターは、AWS Direct Connect (DX) と IPSec VPN を使用して AWS に接続されています。サービスデータは機密性が高く、インターネットを経由して接続することはできません。同社は、新しい市場セグメントに進出し、AWS を使用している他の企業にサービスを提供したいと考えています。

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

■選択肢（文字列を編集せずに出力してください。※正解がどれかわからないように）

A. TCP トラフィックを受け入れる VPC エンドポイントサービスを作成し、Network Load Balancer の背後でホストして、DX 経由でサービスを利用できるようにします。
B. HTTP または HTTPS トラフィックを受け入れる VPC エンドポイントサービスを作成し、Application Load Balancer の背後でホストして、DX 経由でサービスを利用できるようにします。
C. インターネットゲートウェイを VPC に接続し、ネットワークアクセスコントロールとセキュリティグループのルールが、関連するインバウンドとアウトバウンドのトラフィックを許可するようにします。
D. VPC に NAT ゲートウェイを接続し、ネットワークアクセスコントロールとセキュリティグループのルールが該当するインバウンドとアウトバウンドのトラフィックを許可するようにします。

■問題文の要件の概要

  • オンプレミスのサービスが AWS と DX + VPN で接続されている
  • サービスデータは インターネットを経由できない（機密性が高い）
  • 他の AWS 利用企業に セキュアにサービスを提供したい

■正解の選択肢と解説

  • 正解：A
  • 解説：
    VPCエンドポイントサービス（PrivateLink）を利用し、Network Load Balancer（NLB）の背後でサービスをホストすることで、他のVPC（他アカウント含む）からインターネットを経由せずにTCPでセキュアに接続できます。
    DX接続を通じてオンプレミスとも安全にやり取りでき、要件である「機密性の保持」「インターネット経由しない」「他社にサービス提供」がすべて満たされます。
    また、ALBはPrivateLinkと組み合わせられないため、TCPレベルを扱えるNLBが必須です。

■不正解の選択肢の理由

  • B：
    ALB は L7（HTTP/HTTPS）専用で、VPCエンドポイントサービスとは連携不可。また、サービスの通信プロトコルが HTTP とは限らないため適切ではありません。
  • C：
    インターネットゲートウェイを使用することで、機密データがインターネット経由になる。これは要件違反です。
  • D：
    NAT ゲートウェイは アウトバウンド通信（VPC → インターネット）に用いるものであり、他の企業からのインバウンド接続を受ける構成には不適切です。

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

  • VPCエンドポイントサービス（PrivateLink）は、他アカウント・他VPCへのプライベート接続提供手段。
  • PrivateLink は Network Load Balancer のみに対応。ALBは非対応。
  • Direct Connect + PrivateLinkの組み合わせで、オンプレミスからの安全な接続も可能。
  • NAT ゲートウェイはアウトバウンド用途。インバウンド接続用ではない。
  • 問題文に「インターネットは使えない」と明記されている場合、IGW や NAT は除外対象。

引き続き問題をお送りいただければ、この形式で解説いたします。

以下、ご指定のフォーマットに沿って、AWS SAP 試験「問題3」の整理を行います。

■問題文（文字列を編集せずに出力してください。）

ある企業が AWS 上で IoT プラットフォームを実行しています。さまざまな場所に設置された IoT センサーは、Application Load Balancer の背後で動作する Amazon EC2 インスタンス上の Node.js API サーバーにデータを送信します。データは、4 TB の汎用 SSD ボリュームを使用する Amazon RDS for MySQL DB インスタンスに保存されます。同社が配備した IoT センサーの数は時間とともに増加しており、今後も大幅に増加することが予想されます。また、API サーバーは常に過負荷状態であり、RDS メトリクスは書き込みレイテンシーが高い状況です。

このプラットフォームの費用対効果を維持しながら、問題を恒久的に解決し、新しいセンサーがプロビジョニングされるにつれて成長を可能にする方法を選択してください。 (2 つ選択)

■選択肢（文字列を編集せずに出力してください。）

A. MySQL の汎用 SSD ストレージを 6 TB にサイズ変更し、ボリュームの IOPS を向上させます。
B. データベース層を再設計して、Amazon RDS for MySQL DB インスタンスの代わりに Amazon Aurora を使用し、リードレプリカを追加します。
C. Amazon Kinesis Data Streams と AWS Lambda を活用して、IoT から送信されたデータを取り込み、処理します。
D. AWS X-Ray を使用してアプリケーションの問題を分析およびデバッグし、負荷に合わせて API サーバーを追加します。
E. Amazon RDS for MySQL DB インスタンスの代わりに Amazon DynamoDB を使用するようにデータベース層を再設計します。

■問題文の要件の概要

  • IoTセンサーからのデータ送信先はNode.js APIサーバー（EC2 + ALB）
  • RDS（MySQL + gp2 4TB）が書き込みレイテンシーのボトルネック
  • APIサーバーは過負荷状態
  • センサー数は今後も急増
  • 成長に対応しつつ費用対効果を維持したい
  • 恒久的なソリューションが必要
  • 正解は 2つ

■正解の選択肢と解説

  • 正解：C, E

C. Amazon Kinesis Data Streams と AWS Lambda を活用して、IoT から送信されたデータを取り込み、処理します。

  • データの取り込み処理を非同期でスケーラブルに処理できる構成に変更。
  • Kinesis は高スループットで IoT からのデータをバッファリング可能。
  • Lambda はイベントドリブンで処理を並列にスケール、サーバーレスで費用対効果も高い。
  • 結果として API サーバーのボトルネックを解消できる。

E. Amazon RDS for MySQL DB インスタンスの代わりに Amazon DynamoDB を使用するようにデータベース層を再設計します。

  • DynamoDB は完全マネージドなNoSQLサービスで、高スループット・低レイテンシーな書き込みに最適。
  • センサー数の急増にもスケールアウトで対応可能。
  • オンデマンドモードで費用効率も良く、柔軟性が高い。

■不正解の選択肢の理由

A. MySQL の汎用 SSD ストレージを 6 TB にサイズ変更し、ボリュームの IOPS を向上させます。

  • gp2 のIOPSはサイズに比例するが、根本解決にはならない。
  • 単一DB構成ではスケール限界あり。センサー増加に対して非効率。

B. RDS for MySQL の代わりに Aurora + リードレプリカを使用

  • Aurora でも ライトノードは1つのみ → 書き込みレイテンシーは解決しない。
  • リードレプリカは読み取り性能の拡張に過ぎず、本問題とは無関係。

D. AWS X-Ray + API サーバー追加

  • X-Ray は分析・可視化ツールで、スケーラビリティやレイテンシーの恒久的対策にはならない。
  • APIサーバー増強はコスト増で、RDSのボトルネックは未解決。

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

  • Kinesis Data Streams + Lambda は大量データの取り込み処理における非同期スケーラブルアーキテクチャの代表。
  • DynamoDB は水平方向スケーリングに優れ、IoTや大量書き込み用途に適したコスト効率の高い選択肢。
  • RDS（Aurora含む）はスケールアップに限界があり、書き込みスループットの限界を理解することが重要。
  • ストレージ容量の増加＝性能向上ではなく、ボトルネックの種類（I/O、CPU、同時接続など）に応じたアーキテクチャ変更が必要。
  • **「恒久的かつ費用対効果の高い解決策」**という条件は、マネージドサービス＋サーバーレス構成が好まれる傾向あり。

次の問題も同様に送っていただければ、同形式で解説いたします。

以下は、AWS SAP 試験「問題4」に関する整理結果です。ご指定の形式に従って出力しています。

■問題文（文字列を編集せずに出力）

ソリューションアーキテクトは、オンプレミスのレガシーアプリケーションを AWS に移行する必要があります。このアプリケーションは、ロードバランサーの背後にある 2 台のサーバーで実行されます。アプリケーションは、サーバーのネットワークアダプターの MAC アドレスに関連付けられたライセンスファイルを必要とします。ソフトウェアベンダーが新しいライセンスファイルを送信するのに 12 時間かかります。また、アプリケーションは静的 IP アドレスを持つ構成ファイルを使用してデータベースサーバーにアクセスします。ホスト名はサポートされていません。

これらの要件を考慮した場合、AWS のアプリケーションサーバーに高可用性アーキテクチャを実装する最適な手順の組み合わせを選択してください。(2 つ選択)

■選択肢（文字列を編集せずに出力）

A. ENI のプールを作成します。プールのライセンスファイルをベンダーにリクエストし、ライセンスファイルを Amazon S3 に保存します。ライセンスファイルをダウンロードし、対応する ENI を Amazon EC2 インスタンスにアタッチするブートストラップ自動化スクリプトを作成します。
B. ENI のプールを作成します。プールのライセンスファイルをベンダーにリクエストし、ライセンスファイルを Amazon EC2 インスタンスに保存します。インスタンスから AMI を作成し、この AMI を将来のすべての EC2 インスタンスに使用します。
C. ベンダーに新しいライセンスファイルをリクエストするブートストラップ自動化スクリプトを作成します。応答を受信したら、ライセンスファイルを Amazon EC2 インスタンスに適用します。
D. ブートストラップ自動化スクリプトを編集して、AWS Systems Manager Parameter Store からデータベースサーバーの IP アドレスを読み取り、その値をローカル設定ファイルに挿入します。
E. Amazon EC2 インスタンスを編集して構成ファイルにデータベースサーバーの IP アドレスを含め、将来のすべての EC2 スタンスで使用する AMI を再作成します。

■問題文の要件の概要

  • アプリケーションは MAC アドレスに基づくライセンスを要求（再発行に12時間かかる）
  • データベースは 静的IPでのみ接続可能（ホスト名不可）
  • 高可用性が必要 → インスタンス再作成や切替が容易であるべき
  • インフラ変更時も MACアドレスとDB IPの管理が重要

■正解の選択肢と解説

  • 正解：A, D

A. ENI + ライセンスファイルをS3に保存し、対応するENIをEC2にアタッチするスクリプトを使用

  • ENI（Elastic Network Interface）は MACアドレスを保持して切り替えが可能なため、ハードウェア依存のライセンス対策に有効。
  • S3に保存したライセンスファイルを、ENIと紐付けて再利用できる構成をとることで、12時間のライセンス再発行を回避可能。
  • 高可用性＋迅速な再起動構成に最適。

D. DBの静的IPアドレスを Parameter Store に格納し、ブート時に読み込むようにスクリプト設定

  • DB接続先が静的IP必須だが、AMIに埋め込むと柔軟性がなくなる。
  • Parameter Store に格納してスクリプトで設定に挿入することで、動的なIP変更にも対応。
  • DBの再配置や障害復旧にも 設定変更最小で対応でき、高可用性を担保。

■不正解の選択肢の理由

B. AMIにライセンスファイルを保存して使用

  • インスタンスをAMIから再作成しても MACアドレスは変更される → ライセンス認証失敗。
  • 再起動やスケーリングがライセンス再発行待ち（12時間）になるため、可用性要件を満たせない。

C. ベンダーから毎回ライセンスをリクエスト

  • ベンダーの処理に12時間かかる → 障害時に 復旧までに大きな時間ロス。
  • 事前準備がないため、RTO要件を満たせない。

E. IPを設定ファイルに書いてAMI再作成

  • DBのIP変更が発生した場合、全インスタンスを再作成する必要がある。
  • 柔軟性がなく運用負荷が大きいため、可用性とスケーラビリティに不向き。

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

  • ENI（Elastic Network Interface）を使うことでMACアドレスを固定化できる点は、ライセンス依存システムの高可用性構成で非常に重要。
  • AWS Systems Manager Parameter Storeは、設定情報（IPアドレスやパスワードなど）の動的・安全な注入先として非常に有用。
  • AMIに設定やライセンスを焼き込む設計は変更耐性に乏しく、柔軟性の欠如につながる。
  • 再起動・再配置が想定される環境では、外部依存情報（ライセンス・設定）は動的に取得する設計がベストプラクティス。
  • SAPでは、アーキテクチャ全体としての回復性・自動化・運用性をどう担保するかが問われる。

次の問題も準備でき次第、お送りください。継続して対応可能です。

以下は、AWS SAP試験「問題5」の整理です。ご指定のフォーマットに従って出力します。

■問題文（文字列を編集せずに出力）

ある企業は、AWS 上でデータ集約型のアプリケーションを実行しています。このアプリケーションは、数百の Amazon EC2 インスタンスのクラスター上で実行されています。また、200 TB のデータを保存する共有ファイルシステムも、いくつかの EC2 インスタンス上で実行されています。アプリケーションは、共有ファイルシステム上のデータを読み込んで変更し、レポートを生成します。このジョブは毎月 1 回実行され、共有ファイルシステムからファイルのサブセットを読み取り、完了するまでに約 72 時間かかります。コンピューティングインスタンスは Auto Scaling グループでスケーリングされますが、共有ファイルシステムをホストするインスタンスは継続的に実行されます。コンピューティングインスタンスとストレージインスタンスは、すべて同じ AWS リージョンにあります。

ソリューションアーキテクトは、共有ファイルシステムのインスタンスを置き換えることによってコストを削減する必要があります。ファイルシステムは、72 時間の実行中に、必要なデータへの高性能アクセスを提供する必要があります。

これらの要件を満たしながら、全体的なコストを最大に削減できるソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A. 既存の共有ファイルシステムから、S3 Intelligent-Tiering ストレージクラスを使用する Amazon S3 バケットにデータを移行します。毎月のジョブが実行される前に、Amazon FSx for Lustre を使用して、遅延ロードを使用して Amazon S3 からのデータで新しいファイルシステムを作成します。ジョブの実行期間中は、新しいファイルシステムを共有ストレージとして使用します。ジョブが完了したら、ファイルシステムを削除します。
B. 既存の共有ファイルシステムから、マルチアタッチを有効にした大きな Amazon Elastic Block Store (Amazon EBS) ボリュームにデータを移行します。Auto Scaling グループの起動テンプレートのユーザーデータスクリプトを使用して、EBS ボリュームを各インスタンスにアタッチします。ジョブの実行期間中、EBS ボリュームを共有ストレージとして使用します。ジョブが完了したら、EBS ボリュームをデタッチします。
C. 既存の共有ファイルシステムから、S3 標準ストレージクラスを使用する Amazon S3 バケットにデータを移行します。毎月のジョブを実行する前に、Amazon FSx for Lustre を使用して、バッチによる読み込みを使用して Amazon S3 からのデータで新しいファイルシステムを作成します。ジョブの実行期間中は、新しいファイルシステムを共有ストレージとして使用します。ジョブが完了したら、ファイルシステムを削除します。
D. 既存の共有ファイルシステムから Amazon S3 バケットにデータを移行します。毎月のジョブを実行する前に、AWS Storage Gateway を使用して、Amazon S3 からのデータでファイルゲートウェイを作成します。ジョブ用の共有ストレージとしてファイルゲートウェイを使用します。ジョブが完了したら、ファイルゲートウェイを削除します。

■問題文の要件の概要

  • 毎月1回、72時間実行されるジョブで200TBのデータを読み込み・変更してレポート生成。
  • EC2クラスターからの高スループットアクセスが必要。
  • 共有ファイルシステムは現在常時起動中。
  • ストレージコスト削減が目的。
  • 実行中のみ高性能、非稼働時は低コストが理想。

■正解の選択肢と解説

  • 正解：A

A. S3 Intelligent-Tiering + FSx for Lustre（遅延ロード）

  • 遅延ロード機能付きの FSx for Lustre を使用することで、必要なデータだけをアクセス時に読み込む。
  • バックエンドにある S3 Intelligent-Tiering はアクセス頻度に応じて自動階層化、コスト削減。
  • ジョブ期間中のみ FSx を稼働し、終了後削除できるため、ストレージコストが最小に。
  • FSx for Lustre は HPC 向け並列I/Oに特化しており、大規模な読み書きに最適。

■不正解の選択肢の理由

B. マルチアタッチEBS

  • EBSのマルチアタッチは 最大16台のインスタンスまでしか共有不可 → 数百台のクラスタ要件を満たせない。
  • EBS 1ボリュームの最大サイズは64TiB → 200TB構成には多数のボリューム分割・RAIDが必要で管理・コスト増。
  • 常時プロビジョンI/O課金が発生し、非稼働時でもコスト削減不可。

C. S3 Standard + FSx（バッチ読み込み）

  • バッチインポートは 全データをジョブ前にFSxへコピーするため、200TBの複製コスト・時間が発生。
  • データ重複（S3とFSx両方）によるコスト増。
  • 非効率かつ準備時間もかかり、S3 Intelligent-Tiering + 遅延ロードと比べて非最適。

D. AWS Storage Gateway（ファイルゲートウェイ）

  • Gatewayはオンプレ環境向け。HPCクラスタ向けの高スループット/並列I/Oには不向き。
  • ゲートウェイインスタンス・キャッシュEBSの維持コストが常時発生し、削減効果は限定的。

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

  • Amazon FSx for Lustre：高性能な並列I/OとPOSIX互換のHPC向けファイルシステム。S3との連携で一時的な処理に最適。
  • 遅延読み込み（lazy load）：FSxとS3連携時に、実データをアクセス時に取り込む機能。初期ロードやコストを抑制可能。
  • S3 Intelligent-Tiering：アクセスパターンに応じてストレージ階層を自動で最適化。低頻度アクセス期間のコストを大幅削減。
  • HPCワークロードでは Storage Gateway や EBS はパフォーマンス的に非推奨。
  • 設問キーワード「高性能アクセス + 一時利用 + コスト最小化」＝ Lustre + S3連携の典型問題。

次の問題も準備でき次第、お送りください。引き続き対応いたします。

以下は、AWS SAP試験「問題6」の整理です。指定のフォーマットに従って出力します。

■問題文（文字列を編集せずに出力）

ある企業が AWS Organizations に組織を持ち、多数の AWS アカウントを持っています。そのうちの 1 つの AWS アカウントはトランジットアカウントとして指定されており、他のすべての AWS アカウントと共有される Transit Gateway を持っています。同社のグローバルオフィスとトランジットアカウントの間には、AWS Site-to-Site VPN 接続が構成されています。同社は、すべてのアカウントで AWS Config を有効にしています。

同社のネットワークチームは、グローバルオフィスに属する内部 IP アドレス範囲のリストを集中管理する必要があります。開発者は、アプリケーションに安全にアクセスするために、このリストを参照します。

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

■選択肢（文字列を編集せずに出力）

A. Amazon S3 にホストされている、すべての内部 IP アドレス範囲をリストする JSON ファイルを作成します。JSON ファイルが更新されたときに呼び出すことができる、各アカウントの Amazon Simple Notification Service (AmazonSNS) トピックを設定します。SNS トピックに AWS Lambda 関数をサブスクライブして、更新された IP アドレス範囲ですべての関連するセキュリティグループのルールを更新します。

B. すべての内部 IP アドレス範囲を含む新しい AWS Config マネージドルールを作成します。ルールを使用して、各アカウントのセキュリティグループをチェックし、IP アドレス範囲のリストに準拠していることを確認します。検出された非準拠のセキュリティグループを自動的に修復するルールを設定します。

C. トランジットアカウントで、すべての内部 IP アドレス範囲を含む VPC プレフィックスリストを作成します。AWS Resource Access Manager を使用して、プレフィックスリストを他のすべてのアカウントと共有します。共有プレフィックスリストを使用して、他のアカウントでセキュリティグループのルールを設定します。

D. トランジットアカウントで、すべての内部 IP アドレス範囲を含むセキュリティグループを作成します。”/sg-1234abcd” のネストされたセキュリティグループ参照を使用して、トランジットアカウントのセキュリティグループを参照するように他のアカウントのセキュリティグループを構成します。

■問題文の要件の概要

  • IP アドレス範囲リストを中央管理したい。
  • 全アカウントで開発者がそのリストを参照し、安全にアプリへアクセスできる必要がある。
  • 運用負荷は最小限にしたい。
  • Transit Gateway や AWS Organizations を活用中。
  • AWS Config は有効化済み。

■正解の選択肢と解説

  • 正解：C

C. プレフィックスリスト + AWS RAM共有

  • VPCプレフィックスリストを使えば、IPアドレス範囲の中央管理が可能。
  • トランジットアカウントで作成したプレフィックスリストを、**AWS Resource Access Manager（RAM）**を使って他アカウントに共有可能。
  • 各アカウントでは、共有されたプレフィックスリストを直接参照してセキュリティグループを定義できる。
  • 一元管理されているため、リスト更新は1か所で済み、自動的に全アカウントに反映される。
  • Lambdaや通知のような追加システムは不要で、最小限の運用負荷。

■不正解の選択肢の理由

A. S3 + SNS + Lambda連携でセキュリティグループ更新

  • JSONファイルをS3に置き、更新をSNS通知、Lambdaで各セキュリティグループ更新という複雑な構成。
  • アカウントごとのLambda・SNS設定、IAM権限管理など手間が多くスケーラブルでない。
  • エラー時の挙動や通知遅延リスクもあり、ネイティブな一元管理に劣る。

B. AWS ConfigルールでIP範囲監査と修復

  • AWS Configは構成監査用のサービスであり、IPリストをセキュリティグループに直接提供できない。
  • 各アカウントにルールと自動修復アクションの展開・管理コストがかかる。
  • 中央から直接IPリスト参照できないため要件に合致しない。

D. SGをアカウント間でネスト参照

  • セキュリティグループIDを別アカウントで参照することは非サポート（同一VPC内でしか参照できない）。
  • クロスアカウントSG参照は技術的に不可であり、構想自体が誤り。

■SAP試験で押さえるべきポイント

  • VPCプレフィックスリスト + AWS RAM＝複数アカウントでのIP範囲集中管理のベストプラクティス。
  • クロスアカウント環境では、**ネイティブ共有可能リソース（例：Prefix List）**を活用。
  • AWS Configは「監査・検出」であり「配布・参照」には不向き。
  • セキュリティグループはクロスアカウント参照できない → ネスト参照は同一VPC/アカウントのみ。

次の問題も準備でき次第、お送りください。引き続き対応します。

以下は、AWS SAP試験「問題7」の整理です。指定のフォーマットに従って出力します。

■問題文（文字列を編集せずに出力）

ある企業が、自社のウェブサイトを AWS に移行したいと考えています。このウェブサイトは、オンプレミスの自己管理型 Kubernetes クラスターにデプロイされたコンテナを使用しています。ウェブサイトのデータはすべてオンプレミスの PostgreSQL データベースに保存されています。

同社は、オンプレミスの Kubernetes クラスターを Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行することを決定しました。EKS クラスターは、ノード数が固定された EKS マネージド型ノードグループを使用します。また、オンプレミスのデータベースを Amazon RDS for PostgreSQL データベースに移行する予定です。

ソリューションアーキテクトは、移行前にこのワークロードの総所有コスト (TCO) を見積もる必要があります。

必要な TCO 情報を提供するソリューションを選択してください。

■選択肢（文字列を編集せずに出力）

A. Migration Evaluator へのアクセスをリクエストします。Migration Evaluator Collector を実行してデータをインポートします。シナリオを設定します。Migration Evaluator から Quick Insights レポートをエクスポートします。

B. オンプレミスデータベース用に AWS Database Migration Service (AWS DMS) を起動します。評価レポートを生成します。AWS Pricing Calculator で EKS 移行のコストの見積もりを作成します。

C. AWS Application Migration Service を初期化します。オンプレミスサーバーを移行元サーバーとして追加します。テストインスタンスを起動します。Application Migration Service から TCO レポートを出力します。

D. AWS クラウドエコノミクスセンターのウェブページにアクセスして、AWS クラウドバリューフレームワークを評価します。Cloud Value Framework から AWS コストと使用状況レポートを作成します。

■問題文の要件の概要

  • オンプレミスから Amazon EKS + Amazon RDS for PostgreSQL への移行予定。
  • コンテナは Kubernetes（自己管理） → EKS に移行。
  • データベースはオンプレミス PostgreSQL → RDS に移行。
  • 移行前に TCO（総所有コスト）の見積もりが必要。

■正解の選択肢と解説

  • 正解：A

A. Migration Evaluator を使った TCO 評価

  • Migration Evaluator は、オンプレミス環境の詳細（CPU, メモリ, ストレージ, ライセンスなど）を収集し、AWS 移行後の TCO を算出できるサービス。
  • Quick Insights レポートとして、AWS でのコスト（Savings Plans や Reserved Instances 適用後も含む）を含んだ包括的な移行前後比較を自動作成可能。
  • Kubernetes → EKS、オンプレ PostgreSQL → RDS といった構成にも対応しており、シナリオに基づいた具体的なコストが得られる。
  • 単一ツールで済み、手動見積もり不要・最も包括的な選択肢。

■不正解の選択肢の理由

B. DMS + Pricing Calculator

  • DMS は移行ツールであり、TCO 見積もりツールではない。
  • AWS Pricing Calculator は試算可能だが、EKS や RDS などを正確に見積もるには手動設定が必要で網羅性に欠ける。
  • 2つのツールの組み合わせでも、Savings Plans やライセンスの割引効果まで含めたTCOの自動比較はできない。

C. Application Migration Service を使った評価

  • このサービスはVMベースのリフト＆シフト向けであり、Kubernetes や RDS への移行には対応しない。
  • TCOレポート機能も存在せず、テストインスタンス起動＝TCO評価ではない。
  • コンテナベースのアーキテクチャには適合しない誤選択。

D. Cloud Economics Center の Cloud Value Framework

  • 定性的な価値分析ツール（例：生産性向上、可用性向上）であり、定量的なコスト試算ツールではない。
  • 実データに基づく月額コストやライセンス費、ディスカウントプランを含む評価は提供されない。
  • あくまで経営層向けの概念整理ツールであり、TCOの正確な数値比較には不適。

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

  • Migration Evaluator：オンプレの実利用データから TCO を算出する代表的サービス。Collector と Quick Insights レポートを使う。
  • DMS＝データ移行、Application Migration Service＝VM移行、Cloud Economics Center＝定性的分析。
  • EKS や RDS の TCO 試算を自動的に実行できるサービスは Migration Evaluator のみ。
  • SAP試験では、「目的（TCO見積もり）に対して最も自動的かつ包括的なツールは何か」を判断できるようにしておくこと。

次の問題もお送りいただければ、同様に整理いたします。

RELATED POST