Uncategorized

#32

 

以下に、指定のフォーマットで整理して出力します。

■ 問題文（原文そのまま）

企業が、 Amazon EC2 インスタンスでデータ処理アプリケーションをホストしています。このアプリケーションは、Amazon Elastic File System (Amazon EFS) ファイルシステムをポーリングして、新しくアップロードされたファイルを探します。新しいファイルが検出されると、アプリケーションはファイルからデータを抽出し、ファイルを処理する Docker コンテナイメージを選択するロジックを実行します。アプリケーションは適切なコンテナイメージを起動し、ファイルの場所をパラメータとして渡します。

コンテナが実行するデータ処理には最大 2 時間かかります。処理が完了すると、コンテナ内で実行されるコードはファイルを Amazon EFS に書き戻して終了します。

同社は、コンテナを実行している EC2 インスタンスを削除するために、アプリケーションをリファクタリングする必要があります。

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

■ 選択肢（編集なし）

  • A. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。AWS Fargate タスクとして実行するように処理を構成します。適切な Fargate タスクを開始する Amazon EventBridge ルールとして実行するコンテナ選択ロジックを抽出します。EFS ファイルシステムにファイルが追加されたときに実行される EventBridge ルールを設定します。
  • B. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。AWS Fargate タスクとして実行するように処理を構成します。適切な Fargate タスクを起動する Fargate サービスとして実行するように、コンテナ選択ロジックを更新し、コンテナ化します。EFS ファイルシステムにファイルが追加されたときに Fargate サービスを呼び出すように、EFS イベント通知を設定します。
  • C. Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。AWS Fargate タスクとして実行するように処理を構成します。適切な Fargate タスクを開始する AWS Lambda 関数として実行するように、コンテナ選択ロジックを抽出します。ファイルのアップロードのストレージを Amazon S3 バケットに移行します。Amazon S3 を使用するように処理コードを更新します。オブジェクトが作成されたときに Lambda 関数を呼び出すように、S3 イベント通知を設定します。
  • D. 処理用の AWS Lambda コンテナイメージを作成します。コンテナイメージを使用するように Lambda 関数を設定します。コンテナ選択ロジックを抽出し、適切な Lambda 処理関数を呼び出す決定 Lambda 関数として実行します。ファイルアップロードのストレージを Amazon S3 バケットに移行します。Amazon S3 を使用するように処理コードを更新します。オブジェクトが作成されたときに決定 Lambda 関数を呼び出すように S3 イベント通知を構成します。

■ 問題文の要件の概要

  • 現状：EFSにファイルがアップロードされたら、EC2ホストのアプリがポーリングして、適切なDockerコンテナを起動し処理を実行。
  • 要件：
    • EC2を削除（≒サーバーレス移行）。
    • データ処理は最大2時間かかる。
    • 処理完了後、ファイルをEFSに戻す必要がある。
  • 目標：リファクタリングして、これらの要件を満たす最適なアーキテクチャを選択。

■ 正解の選択肢と解説

正解：C.
Amazon S3を使ってファイルアップロードのストレージを移行し、S3イベント通知でLambdaをトリガーしてFargateタスクを起動する構成が、サーバーレスでかつ2時間の長時間処理にも耐えられるソリューションです。

  • Amazon S3 はイベント通知機能があり、Lambdaをトリガー可能。
  • AWS Lambda はFargateのタスク起動ロジックのみ担当（長時間処理は不可のため）。
  • Amazon ECS on Fargate により、最大2時間までのデータ処理が実行できる（Fargateのtimeout上限は4時間）。
  • EC2を排除しつつ、柔軟なイベント駆動型アーキテクチャが実現できる。

■ 不正解の選択肢の理由

  • A.
    • EventBridgeはEFSにファイルが追加されたイベントを直接トリガーできないため、構成が実現不能。
  • B.
    • EFSにはファイル作成トリガーでFargateサービスを起動するネイティブ通知機能がない。
  • D.
    • Lambdaでコンテナを実行する方法は、最大15分という制限があり、最大2時間かかる処理には不適。

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

  • EFSはイベント通知非対応：EFSはS3のように「ファイル追加で通知」機能がない。
  • S3イベント通知は強力なトリガー手段：SNS/SQS/Lambda/EventBridgeなどと連携可能。
  • Lambdaの制限：実行時間は最大15分 → 長時間バッチ処理にはFargateやEC2が必要。
  • Fargateのtimeoutは最大4時間：長時間の処理が可能で、EC2不要。
  • サーバーレス設計では「ファイルのアップロード先」や「処理トリガーの設計」が鍵。

次の問題があれば、引き続き貼り付けてください。分析・整理を続けます。

以下に問題2を指定のフォーマットで整理して出力します。

■ 問題文（原文そのまま）

ソリューションアーキテクトは、ある企業のオンプレミスのデータセンターを AWS クラウドに移行するためのビジネスケースを作成する必要があります。ソリューションアーキテクトは、ケースを作成するために、会社のすべてのサーバーの構成管理データベース (CMDB) のエクスポートを使用します。

これらの要件を最もコスト効率よく満たすソリューションを選択してください。

■ 選択肢（編集なし）

  • A. AWS Well-Architected Tool を使用して CMDB データをインポートし、分析を実行して推奨事項を生成します。
  • B. Migration Evaluator を使用して分析を実行します。データインポートテンプレートを使用して、CMDB エクスポートからデータをアップロードします。
  • C. リソースの一致ルールを実装します。CMDB エクスポートと AWS Price List Bulk API を使用して、AWS サービスに対して CMDB データを一括でクエリします。
  • D. AWS Application Discovery Service を使用して CMDB データをインポートし、分析を実行します。

■ 問題文の要件の概要

  • オンプレミスデータセンターの移行に関する ビジネスケース（移行コスト評価） を作成する必要がある。
  • 既存資産情報は CMDB（構成管理データベース）エクスポート にまとまっている。
  • 要件は「最もコスト効率のよい」分析ツールを選ぶこと。

■ 正解の選択肢と解説

正解：B. Migration Evaluator を使用して分析を実行します。

  • Migration Evaluator（旧 TSO Logic）は、オンプレミス環境のコスト情報やハードウェア構成などのデータ（CMDBエクスポート）をもとに、AWS移行後のコストを予測し、移行のビジネスケースを構築するための正式ツールです。
  • データインポートテンプレートを使って CMDB のエクスポートデータをアップロードすれば、自動的に分析・評価してくれます。
  • 最小限のコストでビジネス判断に必要な情報を取得できるため、本問において最も適切です。

■ 不正解の選択肢の理由

  • A. AWS Well-Architected Tool
    • 既存のAWSアーキテクチャに対して、ベストプラクティスに沿った設計レビューを行うツールであり、オンプレミス環境のCMDBをインポート・分析する機能は持っていません。
  • C. AWS Price List Bulk API
    • AWSサービスの価格情報を取得するためのAPI。CMDBデータとマッチさせる仕組みを手動で作る必要があり、自動でコスト評価やビジネスケースを生成できないため、非効率かつ不適切。
  • D. AWS Application Discovery Service
    • オンプレミスにDiscovery Agentをインストールし、アプリケーションの依存関係や実行プロセスを可視化するためのツール。CMDBの読み込みや直接的なコスト評価は不可。

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

  • Migration Evaluator：
    • AWSへの移行を検討する際のコスト評価・ビジネスケース作成専用ツール。
    • CMDBエクスポートなどの静的情報からでも対応可能。
    • 無料で利用可能（要申請）。
  • Application Discovery Service：依存関係の把握やアプリ構成の把握に特化。移行前の技術的調査用。
  • Well-Architected Tool：既存のAWS設計の改善に使うツール。移行元の分析には使えない。
  • Price List Bulk API：価格取得専用。自動分析は不可。

次の問題もあれば、同様に対応いたします。貼り付けをお願いします。

以下に、問題3 を指定のフォーマットで整理して出力します。

■ 問題文（原文そのまま）

企業は、新しく取得した AWS アカウントのセキュリティ体制を監査する必要があります。同社のデータセキュリティチームは、Amazon S3 バケットが一般に公開された場合にのみ通知を必要とします。同社はすでに Amazon Simple Notification Service (Amazon SNS) トピックを確立しており、データセキュリティチームのメールアドレスが登録されています。

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

■ 選択肢（編集なし）

  • A. すべての S3 バケットに isPublic イベント用の S3 イベント通知を作成します。イベント通知のターゲットとして SNS トピックを選択します。
  • B. AWS Identity and Access Management Access Analyzer でアナライザーを作成します。イベントタイプ “Access Analyzer Finding ” に対して、”isPublic: true ” のフィルターを持つ Amazon EventBridge ルールを作成します。EventBridge ルールのターゲットとして SNS トピックを選択します。
  • C. イベントタイプ “Bucket-Level API Call via CloudTrail ” に対して、”PutBucketPolicy ” のフィルターを持つ Amazon EventBridge ルールを作成します。EventBridge ルールのターゲットとして SNS トピックを選択します。
  • D. AWS Config を有効にし、cloudtrail-s3-dataevents-enabled ルールを追加します。”NON_COMPLIANT” のフィルターを使用して、イベントタイプ “Config Rules Re-evaluation Status” の Amazon EventBridge ルールを作成します。EventBridge ルールのターゲットとして SNS トピックを選択します。

■ 問題文の要件の概要

  • 新しく取得したAWSアカウントにおいて、S3バケットが一般公開された場合のみ通知が必要。
  • すでに SNSトピック があり、通知設定も済んでいる。
  • 要件は「S3バケットが**isPublic:true（公開）**になったときのみ通知」される仕組み。

■ 正解の選択肢と解説

正解：B. AWS Identity and Access Management Access Analyzer でアナライザーを作成します…

  • IAM Access Analyzer は、S3バケットやIAMロールなどのリソースが外部に公開されているかどうかを検出できるツール。
  • 特に "isPublic": true という属性が付いたファインディングを EventBridge で検出することで、バケットが公開状態になったときにのみ通知が可能。
  • SNSトピックをターゲットにすれば、既存の通知基盤と連携できる。
  • AWS公式でも推奨されている S3パブリックアクセス検出のベストプラクティス構成。

■ 不正解の選択肢の理由

  • A.
    • S3には "isPublic" というイベント通知タイプは存在しない。
    • S3イベント通知はオブジェクト作成や削除などに限定されており、パブリックアクセス設定の変更は対象外。
  • C.
    • PutBucketPolicy のAPI呼び出しだけでは、実際に公開状態かどうかは判断できない（ポリシーの内容に依存するため）。
    • バケットポリシーの更新は検出できるが、isPublic:true という状態検出には不十分。
  • D.
    • cloudtrail-s3-dataevents-enabled ルールは、CloudTrailがS3データイベントを記録しているかどうかの設定確認に用いるもの。
    • パブリックアクセスの監視には無関係。
    • Config Rules Re-evaluation Status も、再評価ステータスに関するものであり、公開状態の検出用途ではない。

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

  • IAM Access Analyzer は以下を監視可能：
    • S3バケットのパブリックアクセス
    • IAMロール・ポリシーの外部アクセス
    • KMS・SQS・Secrets Managerなど他リソースの外部公開状況
  • EventBridge を組み合わせて通知基盤と連携：
    • "Access Analyzer Finding" イベントをトリガーにSNSやLambdaを動かせる
  • S3のパブリックアクセス設定の監視には、ConfigやCloudTrailよりAccess Analyzerが適任。
    • 試験では、「何が目的か（設定の変更監視か、公開状態の検知か）」を見極めることが重要。

次の問題もあれば、引き続きお送りください。分析を続けます。

以下に 問題4 を指定フォーマットで整理して出力します。

■ 問題文（原文そのまま）

ソリューションアーキテクトは、AWS クラウドでホストされているアプリケーションを改善する必要があります。このアプリケーションは Amazon Aurora MySQL DB インスタンスを使用しており、接続に過負荷が発生しています。アプリケーションの操作のほとんどは、データベースにレコードを挿入します。アプリケーションは現在、テキストベースの設定ファイルに認証情報を保存しています。

ソリューションアーキテクトは、アプリケーションが現在の接続負荷を処理できるように、ソリューションを実装する必要があります。ソリューションでは、認証情報を安全に保管し、認証情報を定期的に自動的にローテーションする機能を提供する必要があります。

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

■ 選択肢（編集なし）

  • A. DB インスタンスの前に Amazon RDS Proxy レイヤーをデプロイします。接続認証情報を AWS Secrets Manager にシークレットとして保存します。
  • B. DB インスタンスの前に Amazon RDS Proxy レイヤーをデプロイします。接続認証情報を AWS Systems Manager Parameter Store に保存します。
  • C. Aurora レプリカを作成します。接続認証情報を AWS Secrets Manager にシークレットとして保存します。
  • D. Aurora レプリカを作成します。接続認証情報を AWS Systems Manager Parameter Store に保存します。

■ 問題文の要件の概要

  • Aurora MySQLに接続過多の問題がある（多数の挿入操作）。
  • 認証情報は現在設定ファイルに保存されており、安全性に欠ける。
  • 解決すべきことは次の2点：
    1. 接続の効率化（接続の負荷軽減）
    2. 認証情報の安全な保管と自動ローテーション

■ 正解の選択肢と解説

正解：A. DB インスタンスの前に Amazon RDS Proxy レイヤーをデプロイします。接続認証情報を AWS Secrets Manager にシークレットとして保存します。

  • Amazon RDS Proxy：接続プール機能を提供し、多数の同時接続がある環境で接続の効率化・リソース使用量の最適化が可能。
  • AWS Secrets Manager：DB認証情報などのシークレットを暗号化して安全に保管し、自動ローテーションが可能。
  • これらを組み合わせることで、接続の効率化とセキュアな認証情報管理の両方を実現できるベストプラクティス構成。

■ 不正解の選択肢の理由

  • B. RDS Proxy + Parameter Store
    • Parameter Store でも認証情報を保管可能だが、Secrets Managerのような自動ローテーション機能がないため不適切。
  • C. Aurora レプリカ + Secrets Manager
    • Aurora レプリカは読み込み専用であり、**「レコード挿入が大半」**という要件に適していない。
    • 書き込み負荷の軽減にはならないため、根本的な解決にならない。
  • D. Aurora レプリカ + Parameter Store
    • 書き込み処理にAuroraレプリカは使えず、Parameter Storeには自動ローテーション機能もない。
    • 要件である「接続負荷の軽減」「認証情報の安全管理と自動更新」のいずれにも合致しない。

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

  • Amazon RDS Proxy
    • 接続プールを行い、大量の同時接続によるDB負荷を軽減。
    • サーバーレスアプリケーションや接続のたびにコネクションを貼る環境で有効。
  • Secrets Manager
    • DBパスワードやAPIキーなどのシークレット情報を安全に管理。
    • 自動ローテーション、バージョン管理、IAMとの連携などが可能。
  • Systems Manager Parameter Store
    • セキュアにデータを格納可能だが、Secrets Managerほど高機能ではない。
    • 基本的に手動ローテーションが必要。
  • Aurora レプリカ
    • 読み取り専用の負荷分散用途。書き込み負荷の軽減には不向き。
    • 本問のように挿入処理が主の場合には効果がない。

次の問題も貼り付けてください。引き続き対応いたします。

以下に 問題5 を指定フォーマットで整理して出力します。

■ 問題文（原文そのまま）

ある企業が VPC で ウェブアプリケーションを運用しています。このウェブアプリケーションは、Application Load Balancer (ALB) の背後にある Amazon EC2 インスタンスのグループで実行されています。ALB は AWS WAF を使用しています。

外部のお客様がウェブアプリケーションに接続する必要があります。同社はすべての外部のお客様に IP アドレスを提供する必要があります。

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

■ 選択肢（編集なし）

  • A. ALB を Network Load Balancer (NLB) に置き換えます。NLB に Elastic IP アドレスを割り当てます。
  • B. Elastic IP アドレスを割り当てます。ALB に Elastic IP アドレスを割り当てます。Elastic IP アドレスをお客様に提供します。
  • C. AWS Global Accelerator の標準アクセラレータを作成します。アクセラレータのエンドポイントとして ALB を指定します。アクセラレータの IP アドレスをお客様に提供します。
  • D. Amazon CloudFront ディストリビューションを設定します。ALB をオリジンに設定します。ディストリビューションの DNS 名を Ping して、ディストリビューションのパブリック IP アドレスを決定します。お客様に IP アドレスを提供します。

■ 問題文の要件の概要

  • アプリケーションは ALB + EC2 構成で稼働中。
  • ALBにはAWS WAFが適用されている。
  • 外部顧客に対して IPアドレスを提供する必要がある。
  • 運用オーバーヘッドは最小限にしたい。

■ 正解の選択肢と解説

正解：C. AWS Global Accelerator の標準アクセラレータを作成します。アクセラレータのエンドポイントとして ALB を指定します。アクセラレータの IP アドレスをお客様に提供します。

  • Global Accelerator は、静的なAnycast IPアドレスを提供し、ALBやNLBをエンドポイントに指定可能。
  • これにより、固定IPアドレスでALBへアクセス可能になり、IPベースでの接続制御やファイアウォール登録が容易。
  • ALBやWAFの機能を維持したままIPを提供可能という点で、最も効率的かつ保守性の高い選択肢。

■ 不正解の選択肢の理由

  • A.
    • NLBにはElastic IPを付与可能だが、WAFが適用できないという致命的な欠点がある。
    • 問題文に「ALBはWAFを使用している」とあるため、ALB→NLBへの変更は要件を満たさない。
  • B.
    • ALBにElastic IPを直接割り当てることは不可能（2025年現在の仕様）。
    • Elastic IPはEC2インスタンスやNLBにしか割り当てられない。
  • D.
    • CloudFrontのIPは動的に変わるため、DNS名ベースのアクセスが前提。
    • Pingで得たIPを顧客に配布するような運用は非推奨かつ不安定。
    • そもそもCloudFrontの目的（キャッシュ・CDN）とはズレる。

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

  • ALBに直接Elastic IPは割り当てられない → 固定IPが必要な場合は別手段が必要。
  • Global Accelerator は：
    • グローバルなAnycast静的IPを提供し、
    • 背後に ALB/NLB/EC2 を配置可能。
    • WAFやALBの機能を保持しつつ、静的IPが必要なシナリオで有効。
  • NLBはElastic IPを持てるがWAF非対応 → セキュリティ機能の有無に注意。
  • CloudFrontはDNSでの利用が前提。IPベースでのアクセス制御には不向き。

次の問題も引き続きどうぞ。すべてこの形式で対応いたします。

以下に 問題6 を指定フォーマットで整理して出力します。

■ 問題文（原文そのまま）

ある企業が、ドキュメント処理のワークロードを AWS に移行しようとしています。同社は、処理サーバーが毎秒約 5 ドキュメントの割合で生成するドキュメントを保存、取得、変更するために、Amazon S3 API をネイティブに使用するように多くのアプリケーションを更新しました。ドキュメントの処理が完了すると、お客様は Amazon S3 からドキュメントを直接ダウンロードできます。

移行中に、同社は、S3 API をサポートするために多くのドキュメントを生成する処理サーバーをすぐに更新できないことに気づきました。このサーバーは Linux 上で動作しており、サーバーが生成・変更するファイルへの高速なローカルアクセスが必要です。サーバーが処理を完了すると、ファイルは 30 分以内にダウンロードできるように一般に公開される必要があります。

これらの要件を最も少ない労力で満たすソリューションを選択してください。

■ 選択肢（編集なし）

  • A. アプリケーションを AWS Lambda 関数に移行します。AWS SDK for Java を使用して、企業が Amazon S3 に直接保存するファイルを生成、変更、アクセスします。
  • B. Amazon S3 ファイルゲートウェイをセットアップし、ドキュメントストアにリンクされたファイル共有を設定します。NFS を使用して、ファイル共有を Amazon EC2 インスタンスにマウントします。Amazon S3 で変更が発生した場合、RefreshCache API 呼び出しを開始して S3 ファイルゲートウェイを更新します。
  • C. インポートおよびエクスポートポリシーを使用して Amazon FSx for Lustre を設定します。新しいファイルシステムを S3 バケットにリンクします。Lustre クライアントをインストールし、NFS を使用してドキュメントストアを Amazon EC2 インスタンスにマウントします。
  • D. AWS DataSync を構成して Amazon EC2 インスタンスに接続します。生成されたファイルを Amazon S3 との間で同期するタスクを設定します。

■ 問題文の要件の概要

  • 現在のアプリの一部はすでに S3 API を使用しているが、一部の処理サーバーは更新できない。
  • それらは Linux 上で動作しており、高速なローカルアクセスを要求。
  • 最終的に S3 にアップロードされ、30分以内に公開される必要がある。
  • できるだけ少ない労力でこれらの要件を満たす必要がある。

■ 正解の選択肢と解説

正解：B. Amazon S3 ファイルゲートウェイをセットアップし、ドキュメントストアにリンクされたファイル共有を設定します。NFS を使用して、ファイル共有を Amazon EC2 インスタンスにマウントします。Amazon S3 で変更が発生した場合、RefreshCache API 呼び出しを開始して S3 ファイルゲートウェイを更新します。

  • S3 File Gateway は、S3 バケットをローカルファイルシステムとしてマウント可能にするサービス。
  • NFS や SMB を通して ローカルのようにファイルへアクセス可能。
  • アプリ側のコード変更が不要なため、既存アプリをすぐに動かせる。
  • S3 との同期も自動で行われ、アップロードしたファイルを即座にS3で公開可能。

■ 不正解の選択肢の理由

  • A. AWS Lambda + SDK for Java
    • Lambda 関数でファイル生成/変更するには、大幅なアーキテクチャ変更が必要。
    • 既存の Linux サーバーで動作する処理サーバーに比べて、高速なローカルアクセスが困難。
  • C. FSx for Lustre
    • 高性能用途には適しているが、設定が複雑かつオーバースペック。
    • また、S3連携においてはバッチ的な連携が主で、毎秒処理に対してはオーバーヘッドが大きい。
  • D. AWS DataSync
    • データ同期には使用できるが、リアルタイム性がない。
    • 「生成後30分以内に公開」には対応しづらく、更新の検知や反映にタイムラグが発生する。

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

  • Amazon S3 File Gateway
    • **S3 バケットをローカルにマウント（NFS/SMB）**できる最もシンプルな手段。
    • アプリ改修が不要で、レガシーシステムにも対応可能。
    • RefreshCache API で変更を即時反映させることも可能。
  • FSx for Lustre
    • S3連携できるが、高スループットが必要なHPC向け。
    • 小規模なドキュメント処理用途には不向き。
  • DataSync
    • 非同期・バッチ的なファイル転送向けであり、即時反映が必要なシナリオには不適切。
  • Lambda + SDK
    • サーバーレスで新規構築時には有効だが、レガシーからの移行ではコスト高・改修多。

次の問題もどうぞ。すべてこの形式で引き続き対応します。

以下に 問題7 を指定フォーマットで整理して出力します。

■ 問題文（原文そのまま）

ある企業が AWS 上でアプリケーションをホストしています。アプリケーションは、単一の Amazon S3 バケットに保存されているオブジェクトの読み取りと書き込みを行います。企業は、アプリケーションを 2 つの AWS リージョンにデプロイするようにアプリケーションを変更する必要があります。

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

■ 選択肢（編集なし）

  • A.
    S3 バケットをオリジンとして Amazon CloudFront ディストリビューションを設定します。アプリケーションを 2 つ目のリージョンにデプロイします。CloudFront ディストリビューションを使用するようにアプリケーションを変更します。AWS Global Accelerator を使用して、S3 バケット内のデータにアクセスします。
  • B.
    2 つ目のリージョンに新しい S3 バケットを作成します。元の S3 バケットと新しい S3 バケットの間で双方向の S3 クロスリージョンレプリケーション (CRR) を設定します。両方の S3 バケットを使用する S3 マルチリージョンアクセスポイントを構成します。変更したアプリケーションを両方のリージョンにデプロイします。
  • C.
    2 つ目のリージョンに新しい S3 バケットを作成します。2 つ目のリージョンにアプリケーションをデプロイします。新しい S3 バケットを使用するようにアプリケーションを構成します。元の S3 バケットから新しい S3 バケットに S3 クロスリージョンレプリケーション (CRR) を設定します。
  • D.
    S3 バケットをオリジンとして S3 ゲートウェイエンドポイントを設定します。アプリケーションを 2 つ目のリージョンにデプロイします。新しい S3 ゲートウェイエンドポイントを使用するようにアプリケーションを変更します。S3 バケットで S3 Intelligent-Tiering を使用します。

■ 問題文の要件の概要

  • アプリケーションが 単一のS3バケットに対して読み書きを行う構成。
  • 今後、アプリケーションを 2リージョンにデプロイする必要がある。
  • 運用上のオーバーヘッドは最小限にしたい。

■ 正解の選択肢と解説

正解：B.
2 つ目のリージョンに新しい S3 バケットを作成します。元の S3 バケットと新しい S3 バケットの間で双方向の S3 クロスリージョンレプリケーション (CRR) を設定します。両方の S3 バケットを使用する S3 マルチリージョンアクセスポイントを構成します。変更したアプリケーションを両方のリージョンにデプロイします。

解説:

  • 双方向CRR：両方のバケットで発生した変更をそれぞれ同期することでデータ整合性を確保。
  • S3マルチリージョンアクセスポイント：単一のエンドポイントで最寄りのリージョンへ自動ルーティング可能。これによりアプリケーションの実装も簡素化できる。
  • 運用オーバーヘッド最小化：ルーティングや同期はAWSがマネージドで処理。

■ 不正解の選択肢の理由

  • A.
    • CloudFrontは主に読み取り用のCDNであり、書き込みには非対応。
    • Global Acceleratorを加えてもS3間の同期は実現しない。
    • 書き込み処理が発生するアプリケーション要件には合わない。
  • C.
    • 片方向のCRRでは不十分：片方のリージョンで書き込んだデータがもう一方に反映されない。
    • また、マルチリージョンアクセスポイントも使用していないため、アプリケーション側に複雑なロジックが必要になる。
  • D.
    • S3 Gateway Endpointはリージョン内専用のVPCエンドポイント。
    • 別リージョンのアプリケーションからはアクセスが困難。
    • Intelligent-Tieringはストレージ最適化機能であり、可用性やマルチリージョン構成とは無関係。

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

  • S3 クロスリージョンレプリケーション (CRR)：
    • 一方向構成がデフォルト。双方向同期をしたい場合は手動で双方向に設定する必要あり。
    • 非同期レプリケーションである点も意識。
  • S3 マルチリージョンアクセスポイント：
    • 単一のグローバルエンドポイントを提供し、リクエストを最適なリージョンのバケットに自動ルーティング。
    • 複数リージョンの高可用構成時に、アプリケーション側の変更を最小限にできる強力な機能。
  • CloudFrontとGlobal Acceleratorの違い：
    • CloudFrontは静的コンテンツ配信用CDN（主にGET対応）。
    • Global AcceleratorはTCP/UDPレベルのルーティング制御。
    • どちらもS3間の同期や書き込み要件には適さない。
  • ゲートウェイエンドポイントのスコープはリージョン限定。マルチリージョン用途には使用不可。

この形式で次の問題も引き続き対応可能です。続けて貼り付けてください。

RELATED POST