演習１

Android

Last updated at 2026-03-14Posted at 2026-02-17

問題1:

ある企業は、オンプレミス環境においてWindowsサーバーを用いたバッチジョブを運用しています。このバッチジョブは、日次で最大1時間実行されます。ソリューションアーキテクトは、このバッチジョブプロセスをAWSに移行し、最適化する必要があります。

運用上のオーバーヘッドを抑えつつ、これらの要件を満たすソリューションはどれでしょうか。

回答は正解です
A.AWS Batch上でEC2インスタンス・Windowsサーバーを起動し、Amazon EventBridgeを利用した日次スケジュールを設定したバッチジョブ処理を実施する。

B.Auto Scalingグループを構成したAmazon EC2インスタンスのフリートに、Amazon EventBridgeを利用した日次スケジュールを設定したバッチジョブ処理を実施する。

C.Amazon EventBridgeルールによって日次スケジュールを設定して、バッチジョブを処理するAWS Lambda関数を呼び出す。

D.StepFunctionsのステートマシン上で日次スケジュールを設定して、バッチジョブ処理を実施する。

全体的な説明
オプション１が正解となります。AWS Batchを利用してEC2インスタンスのWindowsサーバーを起動して、日次スケジュールを設定することで、Windowsバッチジョブ処理を構成できます。加えて、Amazon EventBridgeを設定してバッチジョブをスケジューリングすることができます。

AWS Batchは、AWS上でバッチ処理を効率的に実行するためのバッチ処理サービスです。Amazon EC2インスタンスをバッチジョブのコンピューティングリソースとして設定できるため、Windowsバッチジョブ処理のためにEC2インスタンスのWindowsサーバーを起動して、バッチジョブを構成することができます。ユーザーはジョブ定義とジョブキューを設定するだけで、インフラ管理やスケーリングが自動的に実行されます。

AWS Batchのような環境では、「稼働中のサーバーを直す」のではなく、「新しいサーバーの元となるイメージ（AMI）を更新する」というイミュータブル（不変）インフラストラクチャのアプローチが運用オーバーヘッド削減の鍵となります。

AWS Batchのコンピューティング環境は、ジョブの実行が必要なときだけEC2インスタンスを起動し、完了すると終了します。ユーザー様のご指摘通り、業務ジョブの実行中にパッチを当てても、そのインスタンスは終了時に破棄されるため、次回起動時にはまた古い状態に戻ってしまいます。

したがって、正解の選択肢が意図しているプロセスは以下のような流れになります：

メンテナンス用ジョブの起動: 日次などのスケジュールで、パッチ適用専用の「メンテナンス用ジョブ（またはパイプライン）」をAWS Batch（あるいはEC2 Image Builder等と連携）で起動します。
パッチ適用とAMI作成: このジョブ内でWindowsサーバーを起動し、最新のWindowsパッチを適用します。その後、その状態を保存した**新しいAmazon マシンイメージ (AMI)**を作成します。
環境の更新: 翌日の業務バッチジョブが実行される際には、この「更新されたAMI」を使用してインスタンスが起動するようにAWS Batchのコンピューティング環境設定を更新します。

このアプローチが「運用上のオーバーヘッドを抑える」とされる理由は以下の通りです。

• 起動時間の短縮: 業務バッチの実行時に毎回パッチを当てると、Windows Updateの処理に時間がかかり、1時間という実行時間の制約を圧迫します。事前にパッチ適用済みのAMIを用意しておくことで、業務ジョブは起動直後から処理を開始できます。

• 一貫性の保証: AMI（Amazon マシンイメージ）には、OS、アプリケーション、パッチ状態などがすべて含まれています。一度AMIを作成してしまえば、何度インスタンスを起動しても常に同じパッチ適用状態が保証されるため、環境差異によるトラブル（ドリフト）を防げます。

• 管理の自動化: パッチ適用プロセス自体を「ジョブ」としてスケジュール化・自動化することで、管理者が手動でサーバーにログインして更新作業を行う手間（オーバーヘッド）を排除できます。

オプション２は不正解です。Auto Scalingグループを構成したAmazon EC2インスタンスのフリート上で日次スケジュールを設定し、Windowsバッチジョブ処理を実施することは可能ですが、バッチジョブの管理と運用はユーザー側で実施する必要があります。したがって、運用上のオーバーヘッドを抑えつつという要件には合致しません。

オプション３は不正解です。サーバレスコンピューティングリソースであるLambda関数は、Windowsサーバーによるバッチジョブを構成することができません。

オプション４は不正解です。StepFunctionsのステートマシンに連動させて、AWS BatchやAmazon EC2インスタンスをワークフロー上に構成することは可能です。しかしながら、バッチジョブを運用管理するだけであればAWS Batchを利用すれば十分であり、StepFunctionsのステートマシンに連動させる必要はありません。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

詳細情報は追加の学習内容です。より詳しく学習したい場合や、サービス内容がよくわからなかった場合などにオプションで参照してください。

１．回答に関連する知識をしっかりと学習をされたい方→【詳細情報】を含めて学習してください。

２．効率的に学習されたい方や試験問題のみに特化して学習したい方→【詳細情報】は省略して学習してください。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

【AWS Batchの詳細情報】

1．主な特徴とメリット

• フルマネージド: サーバーのプロビジョニングや管理、ソフトウェアのインストールが不要で、インフラストラクチャの管理負担を排除します。

• 柔軟なコンピューティング環境: Amazon ECS、Amazon EKS、AWS Fargateなどのコンテナサービスや、Amazon EC2（スポットインスタンスまたはオンデマンドインスタンス）など、幅広いAWSコンピューティングリソース上でジョブを実行・スケジュールします。

• 自動スケーリングとコスト最適化: ジョブのボリュームやリソース要件に基づいてコンピューティングリソースを自動的にスケーリングし、ジョブの配信を最適化することでコストを削減します。

• AWSサービスとの統合: ストレージやネットワークなどのAWS機能とネイティブに統合されており、スケーリングや管理が容易です。

2．具体的なユースケース

AWS Batchは様々な業界で利用されています。

• 自動運転機能（AV/ADAS）の開発: 車両センサーや3D環境などのシミュレーション要素をコンテナ化し、大規模なテストや開発を効率化します。

• 金融サービス: 料金設定、市場分析、リスク管理などのハイパフォーマンスコンピューティング（HPC）ワークロードや、取引後のデータ処理、不正検知などに利用され、自動化とコスト削減を実現します。

• ライフサイエンス（創薬・ゲノム解析）: 低分子ライブラリの検索（薬剤スクリーニング）や、DNAシーケンシングの二次分析などを自動化し、研究開発を加速させます。

• メディアとエンターテインメント: コンテンツのレンダリング、ファイルベースのトランスコーディング、メディアサプライチェーンのワークフローを自動化し、手作業を減らして処理を高速化します。

3．技術的な構成要素の例

• コンピューティング環境: デフォルトではAmazon ECSに最適化されたAMI（Amazon Linux 2など）を使用しますが、将来的にはAmazon Linux 2023がデフォルトになる予定です。

• ストレージ連携: 高性能なストレージが必要な場合、Amazon FSx for Lustreなどのファイルシステムと統合して利用することができます。

• サーバーレス処理: AWS Fargateと統合することで、タスクあたり最大16 vCPUまでスケールアップ可能なサーバーレスの並列処理を実現できます。

4．スケジューリング機能

AWS Batchにおけるスケジューリングは、主に「ジョブの実行順序やリソース配分の管理」を指し、サービス自体がフルマネージドなバッチスケジューラとして機能します。

AWS Batchのスケジューリング機能 (ジョブ実行管理)

AWS Batchは、従来のオンプレミスにあるバッチスケジューラと同様の役割をクラウド上で果たします。

• ジョブキューと優先順位: ユーザーは「ジョブキュー」にジョブを送信します。AWS Batchは、設定された優先順位やリソースの可用性に基づいて、これらのジョブをスケジュールし、実行します。

• リソースの自動管理: AWS Batchは、投入されたジョブの量やリソース要件（CPU、メモリなど）を評価し、最適なコンピューティングリソース（Amazon EC2、AWS Fargate、スポットインスタンスなど）を自動的にプロビジョニングしてジョブをスケジュールします。

• 最適化: ワークロードの規模に応じてコンピューティングリソースを自動的にスケーリングし、ジョブの配信を最適化することで、手動での調整を不要にし、コストを削減します。

定期的な実行 (日時指定など)

「毎日〇時に実行する」といった時間ベースのスケジューリングを行いたい場合は、外部のトリガーサービスと組み合わせます。

• Amazon EventBridgeとの連携: 特定の日時やスケジュールに基づいてAWS Batchのジョブをトリガーするには、Amazon EventBridge を使用します。EventBridgeでルールを作成し、ターゲットとしてAWS Batchを指定することで、自動化された定期実行が可能になります。

【詳細情報】

全体構成の概要

実行環境 (AWS Batch): Windowsコンテナを実行するためのコンピューティング環境とジョブ定義を作成します。
トリガー (Amazon EventBridge): 日次スケジュール（Cron式など）を定義し、ターゲットとしてAWS Batchのジョブを指定します。

ステップ 1: コンテナイメージの準備

Windowsバッチ処理を実行するためのアプリケーションをコンテナ化し、Amazon Elastic Container Registry (Amazon ECR) などのレジストリに保存します。

• ポイント: Windowsコンテナを実行するため、DockerイメージはWindowsベースである必要があります（例: windowsservercoreなど）。

ステップ 2: AWS Batch コンピューティング環境の作成

Windowsコンテナを実行するためのインフラストラクチャ（EC2）を定義します。

• コンピューティング環境の設定: マネージド型コンピューティング環境を選択し、プロビジョニングモデルとして「EC2」または「Spot」を選択します。

• オペレーティングシステム: WindowsをサポートするAMI（Amazon Machine Image）またはインスタンスファミリーを選択する必要があります。AWS BatchはEC2起動テンプレートと統合されているため、必要に応じて起動テンプレートでWindows固有の設定を行うことも可能です。

ステップ 3: ジョブ定義 (Job Definition) の作成

実行するバッチジョブの「設計図」を作成します。ここでWindowsコンテナを使用することを指定します。

• プラットフォーム設定: ECSのタスク定義と同様に、runtimePlatform の operatingSystemFamily に WINDOWS_SERVER_2019_CORE (または適切なバージョン) を指定し、互換性に EC2 を指定します。

• コンテナプロパティ: ステップ1で作成したECRのイメージURIを指定し、vCPUやメモリ要件を定義します。

ステップ 4: ジョブキュー (Job Queue) の作成

ジョブ定義とコンピューティング環境を紐付けるキューを作成します。

• 作成したコンピューティング環境をこのキューに接続します。

ステップ 5: スケジュールの設定 (Amazon EventBridge)

日次でジョブを自動実行するために、Amazon EventBridgeを使用します。

• ルールの作成: EventBridgeコンソールまたはCLIでルールを作成します。

• スケジュールパターン: Cron式を使用して「毎日〇時」というスケジュールを定義します。

◦ 例: 毎日午前9時 (JST) の場合、UTCでは0時なので cron(0 0 * * ? *) のように設定します (EventBridgeの最小粒度は1分です)。

• ターゲットの選択:

◦ ターゲットタイプとして「AWS Batch job queue」 (または Batch PutJob) を選択します。

◦ ステップ3で作成した「ジョブ定義」と、ステップ4の「ジョブキュー」を指定します。

構成のメリット

• フルマネージド: AWS Batchは、ジョブの量やリソース要件に基づいて、EC2インスタンスのプロビジョニング、スケーリング、終了を自動的に行います。

• コスト最適化: ジョブが実行されていないときはインスタンスを停止（0にスケーリング）することで、WindowsライセンスやEC2のコストを削減できます。

• 柔軟性: スポットインスタンスを利用して、耐障害性のあるバッチ処理を割引価格で実行する構成も可能です。

この構成により、指定した時間に自動的にWindows EC2インスタンスが立ち上がり、バッチ処理を実行した後、不要になればインスタンスが終了するというサイクルを実現できます。

問題2:

ある金融機関は、銀行業務においてハイパフォーマンスコンピューティングと機械学習を活用した不正検出システムを開発しています。この金融機関は、ワークロードを迅速に処理するための分散処理を求めています。

運用上のオーバーヘッドを抑制しつつ、これらの要件を満たすソリューションはどれでしょうか。

回答は不正解です
A.Amazon EKSと複数のコンテナを利用して、ハイパフォーマンスコンピューティング (HPC) クラスターをデプロイする。

正解
B,AWS ParallelClusterとEFAを利用したMessage Passing Interface（MPI）ライブラリを使用して、ハイパフォーマンスコンピューティング (HPC) クラスターをデプロイする。

C.Amazon EC2インスタンスにAmazon SQSを連携して、分散並列処理を構成し、ハイパフォーマンスコンピューティング (HPC) クラスターをデプロイする。

D.Amazon ECSと複数のコンテナを利用して、ハイパフォーマンスコンピューティング (HPC) クラスターをデプロイする。

全体的な説明
このシナリオでは、ハイパフォーマンスコンピューティングと機械学習を活用した不正検知のワークロードを、できる限り短時間で完了させるための分散処理構成が求められています。

オプション２が正解となります。AWS ParallelClusterは、ハイパフォーマンスコンピューティング（HPC）クラスターをデプロイおよび管理するためのオープンソースのクラスター管理ツールです。AWS ParallelClusterを利用することで、EC2インスタンスベースのHPCコンピューティング環境を迅速に構築し、デプロイして管理することができます。

Elastic Fabric Adapter (EFA) はAI、機械学習 (ML) およびハイパフォーマンスコンピューティング (HPC) のアプリケーションを高速化するために Amazon EC2 インスタンスにアタッチできるネットワークデバイスです。EFAを活用することで、Message Passing Interface (MPI) を用いる高性能計算 (HPC) アプリケーションや、NVIDIA Collective Communications Library (NCCL) を利用する機械学習 (ML) アプリケーションを、数千のCPUやGPUにスケールさせることができます。

また、Message Passing Interface（MPI）は、並列計算におけるプロセス間通信のための標準規格であり、分散メモリ環境での効率的なデータ交換を実現します。

オプション１は不正解です。Amazon EKSにより複数コンテナ上にハイパフォーマンスコンピューティング（HPC）クラスターを展開して、分散処理構成を実現することが可能となります。しかしながら、この構成を実現するにはAmazon EKSコンテナクラスター内のHPC設定をユーザー側が行う必要があるため手間がかかります。したがって、AWS ParallelClusterを利用した場合と比較して運用効率が劣るため要件に合致しません。

オプション３は不正解です。Amazon EC2インスタンスとAmazon SQSを組み合わせた分散並列処理の構成は、ハイパフォーマンスコンピューティングと機械学習を活用したワークロードを実行するのにはHPCの設定をユーザー側が行う必要があります。したがって、AWS ParallelClusterを利用した場合と比較して運用効率が劣るため要件に合致しません。

オプション４は不正解です。Amazon ECSと複数のコンテナを用いた分散並列処理の構成は、ハイパフォーマンスコンピューティングと機械学習を活用したワークロードを実行するのにはHPCの設定をユーザー側が行う必要があります。したがって、AWS ParallelClusterを利用した場合と比較して運用効率が劣るため要件に合致しません。

【AWS ParallelClusterの詳細情報】

AWS ParallelClusterは、AWSクラウド上でハイパフォーマンスコンピューティング (HPC) クラスターのデプロイと管理を支援する、AWSがサポートするオープンソースのクラスター管理ツールです。

主な機能と特徴

• 自動設定: 必要なコンピューティングリソース、スケジューラ、共有ファイルシステムを自動的に設定します。

• スケジューラのサポート: AWS BatchおよびSlurmスケジューラを使用できます。

• 迅速な環境構築: 概念実証（PoC）環境から本番稼働用のHPCコンピューティング環境まで、素早く構築してデプロイすることが可能です。

• ワークフローの構築: ゲノミクスポータルなど、高レベルなワークフロー（例：DNAシーケンスワークフローの自動化）をクラスター上に構築してデプロイすることもできます。

AWSサービスとの統合

• Amazon FSx for Lustre: クラスター作成プロセス中に、FSx for Lustreファイルシステムを自動的に作成したり、既存のファイルシステムを使用したりすることができます。

• Elastic Fabric Adapter (EFA): HPCクラスターでノード間の通信を高速化するためにEFAを利用する構成も可能です（HPCクラスターのコンテキストにおいて）。

利用方法と料金

• アクセス方法: コマンドラインインターフェイス (CLI)、API、PCUI、PythonライブラリAPI、またはAWS CloudFormationカスタムリソースとして利用できます。

• 料金: AWS ParallelCluster自体に追加料金はかかりません。クラスターを作成または更新した際に使用されたAWSリソース（EC2インスタンスなど）に対してのみ料金が発生します。

【HPCクラスターの構築に関する詳細情報】

概要とツールの役割

HPCクラスターの構築には、AWS ParallelClusterを管理ツールとして使用し、ノード間の通信高速化のためにEFAを有効化したEC2インスタンスを利用します。

• AWS ParallelCluster: HPCクラスターのデプロイと管理を支援するオープンソースツールです。コンピューティングリソース、スケジューラ（Slurmなど）、共有ファイルシステムを自動的に設定します。

• Elastic Fabric Adapter (EFA): Amazon EC2インスタンス向けのネットワークインターフェイスです。OSバイパス機能により、インスタンス間通信のレイテンシーとジッターを低減し、MPIなどの密結合HPCアプリケーションのパフォーマンスを向上させます。

デプロイに必要な構成と手順

EFAを利用したクラスターを構成するには以下の要素を組み合わせる必要があります。

A. インスタンスとネットワークの設定

• 対応インスタンスの選択: EFAはオプションのネットワーク機能であり、サポートされているEC2インスタンスで有効化する必要があります。

• クラスタープレイスメントグループの使用: ノード間の通信レイテンシーを最小限に抑えるため、EFA対応インスタンスは「クラスタープレイスメントグループ」内に起動する構成とします。

• セキュリティグループ: EFAトラフィックを許可する適切なセキュリティグループを作成・設定する必要があります。

B. ソフトウェア環境 (AMIとMPI)

• EFA対応AMI: EFAドライバーやライブラリが含まれた「EFA対応AMI（Amazon Machine Image）」を使用します。

• MPIライブラリ: EFAはlibfabricインターフェイスを使用するため、OpenMPIなどの一般的なMPIライブラリをほとんど変更なしで利用可能です。これにより、既存のHPCアプリケーションをAWSへスムーズに移行できます。

C. ストレージの統合 (オプション)

• Amazon FSx for Lustre: ParallelClusterはFSx for Lustreと統合可能です。FSx for LustreもEFAを活用できるため、コンピューティング集約型のワークロードに対して高いストレージパフォーマンスを提供できます。

デプロイの実行手段

AWS ParallelClusterを使用したデプロイは、主に以下のインターフェイスを通じて行います。

• AWS ParallelCluster コマンドラインインターフェイス (CLI)

• AWS ParallelCluster API

これらを使用することで、EFAやMPI環境が整ったHPCクラスター（計算ノード、スケジューラ、ストレージを含む）を迅速に構築・デプロイすることが可能です。

問題3:

ある企業は、AWS上でアプリケーションを開発しています。このアプリケーションはAWS Lambda関数を用いて実行されるサーバーレスアプリケーションです。データベース層にはAmazon RDS for MySQL DBインスタンスを使用し、Lambda関数によって多くのデータ処理を行う必要があります。その際の接続構成を最適化することが求められます。

運用上のオーバーヘッドを抑えつつ、これらの要件を満たすソリューションはどれでしょうか。

A.RDSエンドポイントを利用して、Amazon RDS DBインスタンスに接続する。

正解
B.RDS Proxyを構成して、Amazon RDS DBインスタンスへの接続にRDS Proxyを使用する。

C.RDSライターエンドポイントを利用して、Amazon RDS DBインスタンスに接続する。

回答は不正解です
D.RDSリーダーエンドポイントを利用して、Amazon RDS DBインスタンスに接続する。

全体的な説明
オプション２が正解となります。Amazon RDS DBインスタンスへの接続にRDS Proxyを利用することで、Lambda関数からのDB接続を効率的に管理できます。

AWS Lambda関数がRDS DBインスタンスに対してエンドポイント経由で接続する際は、AWS Lambdaは継続的なLambda関数の呼び出しを考慮するため、DBインスタンスに対して一時的にコネクションを保持しつづけます。この結果、Lambda関数が実行されるたびにDBコネクション数が増加してしまい、大量のコネクションによるDB接続エラーが発生する可能性があります。

この問題を回避するためには、RDS Proxyを活用してLambda関数との接続を行うことが重要です。

オプション１は不正解です。Lambda関数がRDSエンドポイントを介してAmazon RDS DBインスタンスに接続する場合、実行回数が増加するにつれてコネクション数も増加するため、大量のコネクションによるDB接続エラーが発生する可能性があります。これは、Lambda関数の実行後に次のLambda関数の呼び出しを考慮して、一時的にコネクションを保持するためです。

オプション３は不正解です。Amazon RDSにはライターエンドポイントと呼ばれる接続ポイントは存在しません。ライターエンドポイントはAuroraクラスターで使用される書き込み専用のエンドポイントです。

オプション４は不正解です。Amazon RDSにはリーダーエンドポイントと呼ばれる接続ポイントは存在しません。リーダーエンドポイントはAuroraクラスターで使用される読み込み専用のエンドポイントです。

【RDS Proxyの詳細情報】

主な役割と仕組み

RDS Proxyはアプリケーションとデータベースの「仲介役」として機能します。

• コネクションプーリング: RDS Proxyは、データベースへの接続プール（接続の集まり）を確立・管理します。アプリケーションからのデータベース接続リクエストに対して、新しい接続を都度作成するのではなく、プール内にある既存の接続を再利用（多重化）させます。

• トラフィックの処理: アプリケーション（特にAWS Lambdaなど）からのすべてのデータベーストラフィックは、データベースインスタンスに直接流れるのではなく、RDS Proxyを経由して処理されます。

利用するメリット

特にAWS Lambdaなどのサーバーレスアーキテクチャにおいて、以下の課題を解決します。

• データベース負荷の軽減: Lambda関数などは数万件の同時接続リクエストが発生する可能性があり、データベースのメモリやCPUリソースを圧迫してしまいます。RDS Proxyが接続を集約することで、データベースへの接続数を少なく抑え、負荷を軽減します。

• スケーラビリティの向上: 接続管理に必要なリソース消費が抑えられるため、データベースの効率が上がり、アプリケーションのスケーラビリティが向上します。

• 可用性の向上（フェイルオーバーの高速化）: マルチAZ構成のDBクラスターにおいて、RDS Proxyを使用することで、マイナーバージョンアップグレードや障害時のフェイルオーバーに伴うダウンタイムを短縮（場合によっては1秒以下に）できることがあります。

• セキュリティの強化: データベースの認証情報をコードに埋め込む必要がなくなり、AWS Secrets Managerを使用して管理できます。また、IAM認証を使用してデータベースへの接続を制御することも可能です。

サポートされているデータベース

以下のデータベースエンジンでサポートされています（更新時点の情報を含む）。

• Amazon RDS MySQL または Aurora MySQL

• Amazon RDS PostgreSQL または Aurora PostgreSQL

アプリケーションコードへの影響

アプリケーション側では、接続先のエンドポイントをデータベースインスタンスから「RDS Proxyのエンドポイント」に変更するだけで利用でき、通常はアプリケーションロジックの大幅な変更は不要です。

【詳細情報】

AWS LambdaでAmazon RDS Proxyを使用する手順は以下の通りです。RDS Proxyを利用することで、Lambda関数のスケーリングに伴うデータベースへの接続負荷を軽減し、効率的な接続プール管理が可能になります。

前提条件の準備

まず、以下の準備が必要です。

• データベース: Amazon RDS MySQL または Aurora MySQL などのサポートされているデータベースインスタンスが必要です。

• 認証情報の保存: データベースのユーザー名とパスワードを AWS Secrets Manager にシークレットとして保存します。

• IAMロールの作成: RDS ProxyがSecrets Managerのシークレットを読み取り、データベースに接続できるようにするためのIAMロールを作成します。このロールには、シークレットへのアクセス許可と、RDSサービスがロールを引き受けるための信頼ポリシーが必要です。

プロキシの作成とLambda関数への追加

AWS Lambdaコンソールを使用して、関数にデータベースプロキシを設定します。

Lambdaコンソールで対象の関数を開きます。
設定ページから「データベースプロキシの追加 (Add Database Proxy)」を選択します。
ウィザードに従い、以下を指定します。

◦ プロキシ識別子

◦ 対象のRDSデータベース

◦ 作成したSecrets Managerのシークレット

◦ 作成したIAMロール

設定完了後、プロキシがプロビジョニングされステータスが「利用可能 (Available)」になるのを待ちます。この際、生成された Proxyエンドポイントを控えておきます。
Lambdaコードからの接続

Lambda関数のコード内で、データベースへの接続先をRDSインスタンスのエンドポイントから RDS Proxyのエンドポイントに変更します。

• 標準的なデータベースクライアントライブラリ（例: Node.jsのmysqlモジュールなど）をそのまま使用できます。

• 接続情報（ホスト名、ユーザー名など）は、コードに直接記述せず、Lambdaの環境変数を使用して管理することが推奨されます。

認証方法の選択

プロキシへの接続には、以下の2つの認証オプションがあります。

• IAM認証（推奨）: コード内に認証情報を埋め込む必要がなく、セキュリティが向上します。Lambdaの実行ロールに rds-db:connect 権限を付与することで、IAM認証トークンを使用してデータベースに接続できます。

• ネイティブ認証情報: Secrets Managerに保存されたユーザー名とパスワードを使用する方法です。

問題4:

ある企業は、3TBのボリュームデータをオンプレミスのリポジトリに保有し、大量の印刷ファイルを保存しています。このリポジトリは年間500GBの容量が増加しているものの、ローカル環境の制約により、単一の論理ボリュームとして運用する必要があります。あなたはソリューションアーキテクトとして、ローカルストレージの制約を回避するために、このリポジトリをAmazon S3バケットに拡張することが求められています。その際、ローカルストレージをメインストレージとして利用して、S3バケットをバックアップとして利用します。

この要件を満たすために、AWS Storage Gatewayの構成をどのように設定すればよいでしょうか。

A.Amazon S3への移転スケジュールが設定されたスナップショットを利用するキャッシュ型ボリュームをAWS上に構成して、キャッシュを取得する仕組みをオンプレミス環境に設定する。

正解
B.Amazon S3への移転スケジュールが設定されたスナップショットを利用する保管型ボリュームをAWS上に構成して、保管ボリュームをオンプレミス環境に設定する。

回答は不正解です
C.Amazon S3 Glacier（迅速アクセス）への移転スケジュールが設定されたスナップショットを利用するキャッシュ型ボリュームをAWS上に構成して、スナップショットをAWSの別リージョンに保管する。

D.Amazon S3への移転スケジュールが設定されたスナップショットを利用する仮想テープライブラリーをAWS上に構成して、仮想テープをAmazon S3バケットに保存する。

全体的な説明
このシナリオでは、AWS Storage Gatewayを活用して、オンプレミス環境のストレージとAmazon S3バケットを連携し、ストレージ領域を拡張する方法が求められています。

AWS Storage Gatewayは、Amazon S3バケットとオンプレミスのストレージを接続し、バックアップの取得やストレージ容量の拡張を可能にするハイブリッドクラウド機能を提供します。

AWS Storage Gatewayには、主に3種類のゲートウェイタイプが存在します。それぞれのゲートウェイタイプは異なる用途に対応しているため、要件に基づいて最適なタイプを選択することが重要です。さらにボリュームゲートウェイは保管型とキャッシュ型の２つに分かれるため、それぞれの違いを理解する必要があります。

オプション２が正解となります。AWS Storage Gatewayの保管型ボリュームを利用することで、ローカルストレージをメインストレージとして使用し、そのデータを非同期的にS3バケットにバックアップすることが可能です。その際、Amazon S3への移転スケジュールが設定されたスナップショットを用いて保管型ボリュームを構成し、ローカルストレージをS3バケットに拡張します。保管型ボリュームは 1 日に 1 回というデフォルトのスナップショットスケジュールを設定したAWS Storage Gateway を作成できます。また、必要に応じてスナップショットの移転スケジュールをユーザー側で設定することも可能です。

オプション１は不正解です。AWS Storage Gatewayのキャッシュ型ボリュームを活用することで、頻繁にアクセスされるデータをローカル環境にキャッシュとして保持しつつ、S3バケットを主要なデータストレージとして利用したハイブリッドストレージ構成を実現できます。これはローカルをメインとする要件に合致しません。

オプション３は不正解です。AWS Storage Gatewayのハイブリッド構成にはS3 Standardを使用することが最も適しており、Glacierは適切ではありません。Glacierは中長期的に使用頻度が低いファイルの保存に用いられます。

オプション４も不正解です。AWS Storage Gatewayの仮想テープライブラリーはテープ形式のバックアップに特化しており、今回の要件には関連性がありません。

【AWS Storage Gateway 保管型ボリュームの詳細情報】

AWS Storage Gateway の保管型ボリューム (Stored Volume) は、Volume Gateway で選択できる動作モードの一つです。

主な特徴と仕組みは以下の通りです。

• データの保存場所とアクセスプライマリデータ（メインのデータ）をオンプレミス（ローカル）に保存します。データセット全体がローカル環境にあるため、オンプレミスのアプリケーションは低レイテンシーでデータにアクセスできます。iSCSI プロトコルを使用して、ブロックストレージボリュームとしてアプリケーションに提示されます。

• クラウドへのバックアップローカルに保存されたデータは、非同期的に Amazon S3 へバックアップされます。

• データ保護（スナップショット） AWS Backup などを使用してボリュームの特定時点のコピー（ポイントインタイムコピー）を取得することができ、これらは Amazon EBS スナップショットとして AWS クラウド上に保存されます,。これらのスナップショットは増分バックアップであり、変更されたブロックのみが圧縮されて保存されるため、ストレージコストを最小限に抑えられます。

• 運用の仕様保管型ボリュームには、デフォルトで「1日1回」のスナップショットスケジュールが作成されます。このデフォルトスケジュール自体を削除することはできませんが、実行時間や頻度（1、2、4、8、12、24時間ごと）の変更は可能です。

対照的なモードとして、プライマリデータを S3 に置き、頻繁に使用するデータのみをローカルにキャッシュする「キャッシュ型ボリューム（Cached Volume）」があります。保管型ボリュームは、全データをローカルに持ちつつ、クラウドをバックアップ先として利用したい場合に適しています。

【構成方法の詳細情報】

AWS Storage Gatewayの「保管型ボリューム（Stored Volume）」を使用して、オンプレミスにデータを保持しつつ、スケジュールに基づいてAmazon S3へスナップショット（バックアップ）を転送・管理する構成手順は以下の通りです。

保管型ボリューム（Stored Volume）の構成概要

保管型ボリュームは、プライマリデータをオンプレミス（ローカル）に保存し、そのデータセット全体に対する低レイテンシーなアクセスを維持しながら、非同期的にAWS（Amazon S3）へバックアップを取る方式です。バックアップはAmazon EBSスナップショットとしてS3に保存されます。

AWS上でのスナップショットスケジュールの設定

保管型ボリュームを作成すると、AWSはデフォルトで1日1回のスナップショットスケジュールを自動的に作成します。このスケジュールに従って、オンプレミスのデータ差分が圧縮され、S3上のEBSスナップショットとして保存されます。

このスケジュールは以下の手順でカスタマイズ可能です（デフォルト設定自体を削除することはできませんが、編集は可能です）。

Storage Gatewayコンソールを開く: AWSマネジメントコンソールでStorage Gatewayのページに移動します。
ボリュームの選択: ナビゲーションペインで「ボリューム (Volumes)」を選択し、対象の保管型ボリュームを選びます。
スケジュールの編集: 「アクション (Actions)」メニューから「スナップショットスケジュールの編集 (Edit snapshot schedule)」を選択します。
頻度と時間の指定: スナップショットを取得する頻度（1、2、4、8、12、または24時間ごと）と開始時間を指定し、「保存 (Save)」をクリックします。

これにより、指定したスケジュールでデータがAWS（S3）へ転送・保存されるようになります。

オンプレミス環境への保管型ボリュームの設定

オンプレミス側では、ゲートウェイアプライアンスを介してボリュームをマウントし、利用します。

ゲートウェイのデプロイ: オンプレミス環境（VMware ESXi、Microsoft Hyper-V、Linux KVM）またはハードウェアアプライアンスとしてStorage Gatewayをデプロイします。
iSCSIによる接続: 保管型ボリュームは、業界標準のiSCSIプロトコルを使用して、オンプレミスのアプリケーションサーバーにブロックストレージボリュームとして提示されます。

◦ オンプレミスのサーバー（iSCSIイニシエータ）から、ゲートウェイのIPアドレスをターゲットとして接続設定を行います。

ディスクの割り当て: 保管型ボリュームモードでは、以下のディスク構成が必要です。

◦ データストレージ: データセット全体を保存するためのローカルディスク。

◦ アップロードバッファ: S3へのアップロード待ちデータを一時的に保持するためのディスク。

高度なバックアップ管理（AWS Backupの利用）

単なる定期スナップショットだけでなく、より詳細なスケジュール管理や保持期間（リテンション）の設定を行いたい場合は、AWS Backupとの統合を利用します。

• 一元管理: AWS Backupを使用することで、バックアッププランを作成し、スナップショットの作成頻度や保持期間（いつ期限切れにするか）を詳細に定義できます。

• コンプライアンス: 保持ルールや有効期限ルールを含むポリシーを適用し、コンプライアンス要件を満たすことができます。

• 復元: 取得したEBSスナップショットは、オンプレミスのゲートウェイに復元したり、クラウド上のAmazon EC2インスタンスとして復元したりすることが可能です。

まとめ

AWS側: Storage Gatewayコンソールで保管型ボリュームを作成し、デフォルトまたはカスタムの「スナップショットスケジュール」を設定してS3への転送頻度を定義します。より高度な管理にはAWS Backupを使用します。
オンプレミス側: iSCSIを使用してゲートウェイに接続し、ローカルディスクを全データの保存領域として使用します。データはローカルで処理されつつ、設定したスケジュールに従って非同期にAWSへバックアップされます。

問題5:

ある企業がAWS上で3層アプリケーションを開発しています。あなたはソリューションアーキテクトとして、このアプリケーションを複数のマイクロサービスに分割し、疎結合化することが求められています。その際、マイクロサービスの構築にはコンテナを利用します。また、運用要件として、AWS上でのコンテナ用コンピュートリソースの構成管理を不要にすることが求められています。

この要件を満たすために、どのようなアプローチを取るべきでしょうか。

A.Amazon ECSクラスターをEC2起動モードでプロビジョニングする。ECSクラスターのEC2ノードにAmazon EC2 Auto Scalingグループをアタッチし、コンテナにタスクを定義する。

B.AWS Lambda関数を作成して、マイクロサービスのコンポーネントを構成する。これらの関数をAmazon API Gatewayと統合して、スケーリングとトラフィック制御を実施する。

C.Amazon ECSクラスターをEC2起動モードでプロビジョニングする。コンテナにEC2タスクをデプロイする。

回答は正解です
D.Amazon ECSクラスターをFargate起動モードでプロビジョニングする。コンテナにFargateタスクをデプロイする。

全体的な説明
このシナリオでは、Amazon ECSというDocker形式のコンテナ構成を実現するサービスの設定方法について問われています。Dockerは、コンテナ仮想化技術を利用してアプリケーションの開発環境を提供するソフトウェアです。OSレベルの仮想化を用いてアプリケーションを開発・実行環境から分離し、迅速なアプリケーションの提供を実現します。また、その環境自体もアプリケーションと同様に、イメージと呼ばれるコードを用いてコンテナ環境を管理することが可能です。

AWSでコンテナー環境を構成する際は、Docker形式のアプリケーション開発環境を提供するAmazon ECSと、Kubernetesを用いたコンテナ仮想化を実現するAmazon EKSの2つのサービスが利用可能です。これらのサービスにおいては、サーバータイプのEC2起動タイプとサーバーレスタイプのFargate起動タイプの2種類のコンピューティングエンジンを選択できます。要件に応じて、適切な組み合わせを選ぶことが重要です。

本シナリオでは、「コンテナを用いてマイクロサービスを構築すること」と「AWS上でコンテナ用のコンピュートリソースを構成管理しないこと」という2つの要件が設定されています。

オプション４が正解となります。Amazon ECSは、Dockerを活用してコンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易に行えるフルマネージドのコンテナオーケストレーションサービスです。Amazon ECSでコンピューティングリソースとしてFargateを利用すれば、「AWS上でコンテナ用のコンピュートリソースを構成管理しないこと」という要件に合致します。

AWS Fargateは、インスタンスのタイプやサイズなどのプロビジョニング設定を自動的に行うため、Dockerコンテナのコンピューティング設定や運用管理が自動化されます。Fargateを利用することで、コンテナを実行するための仮想マシンのクラスターをプロビジョニング、設定、スケーリングする必要がなくなります。これにより、ユーザーはサーバータイプの選択やクラスターのスケーリングタイミング、クラスターのパッキング最適化を行う必要がなくなります。

Reference: https://aws.amazon.com/jp/blogs/containers/developers-guide-to-using-amazon-efs-with-amazon-ecs-and-aws-fargate-part-1/

オプション１と３は不正解です。Amazon ECSでは、コンテナを構成する際にEC2インスタンスを利用するEC2起動モードを選択することが可能です。この場合、一般的なEC2インスタンスと同様にインスタンス選定などをユーザーが行う必要があります。そのため、柔軟な構成が可能である一方で、Fargateと比較すると手間がかかるというデメリットがあります。したがって、このEC2起動タイプでは「AWS上でコンテナ用のコンピュートリソースを構成管理しないこと」という要件に合致しません。

オプション２は不正解です。AWS Lambda関数を作成して、マイクロサービスのコンポーネントを構成しても、コンテナ構成は実現できません。

【コンテナ管理の詳細情報】

コンテナ管理とは、アプリケーションの実行に必要なコード、ライブラリ、設定などをまとめた「コンテナ」の作成、デプロイ、スケーリング、および運用保守を効率的に行うプロセスや技術のことです。

コンテナ技術（Dockerなど）を利用することで、アプリケーションを環境に依存せずどこでも実行できるようになりますが、多数のコンテナを連携させて大規模なシステムを運用するには、それらを統合的に管理する仕組みが必要となります。

１．主な要素とAWSのサービス

AWSなどのクラウド環境におけるコンテナ管理は、主に以下の役割を持つサービス群によって実現されています。

• コンテナオーケストレーション（配置・実行管理）多数のコンテナの起動、停止、スケジューリング、スケーリング（数の増減）を自動化する仕組みです。

◦ Amazon Elastic Container Service (Amazon ECS): スケーラビリティとパフォーマンスに優れたフルマネージド型のコンテナ管理サービスです。Dockerコンテナに対応しており、クラスター上でアプリケーションを簡単に実行・管理できます。

◦ Amazon Elastic Kubernetes Service (Amazon EKS): オープンソースのコンテナオーケストレーションツールであるKubernetesをマネージドサービスとして提供するものです。

• コンピューティングエンジン（実行環境）コンテナを実際に動かすためのインフラストラクチャです。

◦ AWS Fargate: サーバーのプロビジョニングや管理をすることなくコンテナを実行できる、サーバーレスのコンピューティングエンジンです。Amazon ECSやAmazon EKSと組み合わせて使用し、インフラ管理の負担を軽減します。

◦ Amazon EC2: 仮想サーバーとして自身で管理するクラスター上でコンテナを実行するオプションもあります。

• コンテナレジストリ（イメージの保存・共有）コンテナの設計図となる「コンテナイメージ」を保存・管理する場所です。

◦ Amazon Elastic Container Registry (Amazon ECR): フルマネージド型のDockerコンテナレジストリです。コンテナイメージを安全に保存、共有、デプロイすることができます。

２．コンテナ管理のメリット

• ポータビリティと一貫性: 開発環境から本番環境まで、環境の差異をなくし一貫した動作を保証します。

• スケーラビリティ: 需要に応じてコンテナの数を自動的に増減（オートスケーリング）させることが容易です。

• 運用負荷の軽減: マネージドサービスを利用することで、サーバーのパッチ適用やスケーリングといったインフラ管理の作業（差別化につながらない重労働）を削減し、アプリケーション開発に集中できます。

３．関連機能

• ロードバランシング: Application Load Balancer (ALB) などを使用して、トラフィックを複数のコンテナに分散させます。

• モニタリング: Amazon CloudWatch Container Insightsなどを使用して、コンテナ化されたアプリケーションやクラスターのメトリクスやログを収集・分析します。

【AWS Fargateの詳細情報】

AWS Fargateは、Amazon ECS（Elastic Container Service）やAmazon EKS（Elastic Kubernetes Service）でコンテナを実行するためのサーバーレスコンピューティングエンジンです。「Fargate起動モード」を選択することは、コンテナを実行するホストサーバー（EC2インスタンス）のプロビジョニングや管理をユーザー自身が行わず、AWSに任せることを意味します。

１．主な特徴とメリット

• サーバー管理が不要: 従来の「EC2起動タイプ」ではユーザーがEC2インスタンスのOS管理、パッチ適用、スケーリングを行う必要がありましたが、Fargateではこれらが不要になります。インフラストラクチャではなく、アプリケーションの構築に集中できます。

• 強力な分離（セキュリティ）: 各タスク（ECS）やポッド（EKS）は、それぞれ専用のランタイム環境で実行されます。設計レベルでワークロードが分離されているため、セキュリティが向上します。

• コスト効率: 実際に使用したコンピューティングリソース（vCPUやメモリ）に対してのみ料金が発生し、初期費用はかかりません。また、Fargate SpotやSavings Plansを利用してコストをさらに最適化することも可能です。

２．EC2起動タイプとの違い

• インフラへのアクセス: Fargateでは基盤となるインフラストラクチャへのアクセス権がないため、OSレベルの設定（ドライバーのインストールなど）は行えません。

• ストレージ: Fargateタスクのローカルストレージは、実行中の仮想マシンに紐付いているため、タスクが停止・再起動するとデータは失われます（エフェメラル）。ただし、Amazon EFSと統合することで、Fargateタスクから永続的な共有ストレージをマウントして利用することが可能です。

３．ユースケース

Fargateは以下のようなワークロードに適しています。

• ウェブアプリケーション、API、マイクロサービス

• レガシーアプリケーションのモダナイゼーション（リファクタリングなしでの移行）

• AIおよび機械学習アプリケーション

• AWS Batchと統合したデータ処理ワークロード

問題６

ある企業は、AWSを利用してアプリケーションを運用しています。このアプリケーションのデータレイヤーにはAmazon DynamoDBテーブルを使用しています。同社ではこのアプリケーションのパフォーマンスを向上させるため、Amazon DynamoDB Accelerator（DAX）クラスターを追加したキャッシュ処理を実装しました。ソリューションアーキテクトは、このDAXクラスターが保管データを暗号化する必要があると考えていますが、現在は実施できていません。

この要件を満たすソリューションはどれでしょうか。

A.既存のDAXクラスターを停止してから既存のDAXクラスター設定を編集して、AWS KMSカスタマーマネージドキーを使用して、暗号化を有効化する。

回答は正解です
B.DAXクラスターを作成し直して、暗号化を有効化する。

C.既存のDAXクラスター設定を編集して、AWS KMSカスタマーマネージドキーを使用して、保管データを暗号化する。

D.事前にAWS KMSカスタマーマネージドキーを作成する。このAWS KMSカスタマーマネージドキーを使用して、DAXクラスターを暗号化する。

全体的な説明
オプション２が正解となります。DAXクラスターはクラスター作成時に保管時および転送中の暗号化を有効化する必要があります。DAXクラスターの暗号化はデフォルトで有効になっているため、テーブル作成時に無効に変更しない限り暗号化が適用されます。しかしながら、手動で暗号化を無効にした上でDAXクラスターを作成した場合は、後から暗号化を有効にすることはできません。そのため、暗号化されていないDAXクラスターを後から暗号化したい場合は、新たにDAXクラスターを作成し、保管時のデータを暗号化する必要があります。

また、Amazon DynamoDBテーブルの暗号化も、同様に原則としてテーブル作成時のみ設定可能であり、既存テーブルに対して後から有効にすることはできません。暗号化を後付けしたい場合は、データをエクスポートして新しい暗号化テーブルに移行する必要があります。

オプション１は不正解です。既存のDAXクラスターを停止しても暗号化はできません。その場合、DAXクラスターを再作成し、保管時のデータを暗号化する必要があります。

オプション３は不正解です。既存のDAXクラスターの編集画面で後から暗号化を有効にすることはできません。そのため、DAXクラスターを再作成し、保管時のデータを暗号化する必要があります。

オプション４は不正解です。DAXクラスターを暗号化する際にサービスデフォルトキーが存在しない場合、AWS KMSは自動的に新しいAWSマネージドキーを生成します。これを使用して暗号化が可能であるため、事前にAWS KMSカスタマーマネージドキーを作成する必要はありません。AWS KMSカスタマーマネージドキーを利用しても暗号化は可能ですが、DAXクラスターを作成しなおす必要があります。

【DAXの詳細情報】

１．主な特徴とメリット

• 極めて高いパフォーマンス: 読み取り負荷の高いワークロードにおいて、マイクロ秒単位の応答時間を実現します。イベントなどでリクエストが急増した場合でも、アプリケーションの高速性と応答性を維持します。

• DynamoDB との API 互換性: DAX は既存の DynamoDB API 呼び出しと互換性があります。そのため、開発者はキャッシュの無効化やデータの入力ロジックを自分で実装する必要がなく、アプリケーションコードを大きく変更せずに導入できます。

• フルマネージド: ハードウェアやソフトウェアのプロビジョニング、パッチ適用、障害の検出と復旧といった管理タスクを AWS が自動で行うため、運用負荷が軽減されます。

• 高いスケーラビリティ: パフォーマンスを犠牲にすることなくオンデマンドでスケール可能です。3 ノードのクラスターから開始し、最大 10 ノードまで拡張して容量を増やすことができます。

２．仕組みとアーキテクチャ

• クラスターとノード: DAX は「クラスター」として構成され、その最小単位が「ノード」です。クラスター内の 1 つのノードがプライマリノードとして機能し、その他はリードレプリカとなります。

◦ プライマリノード: キャッシュ済みデータへのリクエスト対応に加え、DynamoDB への書き込み操作やキャッシュデータの削除（エビクション）を担当します。

◦ リードレプリカ: キャッシュ済みデータへの読み取りリクエストに対応します。DynamoDB への書き込みは行いません。

• VPC 内での動作: DAX は Amazon Virtual Private Cloud (Amazon VPC) 環境内で実行されるように設計されており、セキュリティグループを使用してアクセスを制御します。

• 耐障害性: 本番環境では、耐障害性を確保するために、少なくとも 3 つのノードをそれぞれ異なるアベイラビリティーゾーン (AZ) に配置することが推奨されます。

３．セキュリティ

• 暗号化: 保管時の暗号化（AWS KMS と統合）および転送中の暗号化をサポートしており、データを保護します。

• アクセス制御: AWS Identity and Access Management (IAM) と統合されており、ユーザーアクセスを制御できます。

DAX は、読み取り頻度が高く、かつ極めて低いレイテンシーが求められるアプリケーション（例：ゲームのリーダーボード、リアルタイム入札、ソーシャルメディアのフィードなど）に最適なソリューションです。

【DAXの暗号化の詳細情報】

DAX（Amazon DynamoDB Accelerator）で保管時の暗号化を有効にする際の主な注意点は以下の通りです。

作成後の変更不可

DAX クラスターを作成した後に、保管時の暗号化設定を有効または無効に変更することはできません。作成時に有効にしなかった場合、暗号化を適用するにはクラスターを再作成する必要があります。

使用できる KMS キーの制限

DAX の保管時の暗号化では、顧客管理キー（Customer Managed Keys）を指定することはできません。

• DAX クラスターの暗号化には、単一のサービスデフォルトキー（AWS マネージドキー）が使用されます。

• サービスデフォルトキーが存在しない場合、AWS KMS が自動的に新しい AWS マネージドキーを作成します。

サポートされていないノードタイプ

すべてのノードタイプが保管時の暗号化に対応しているわけではありません。

• dax.r3.* ノードタイプでは、保管時の暗号化はサポートされていません。

• サポートされているのは、R4、R5、R7、T2、T3 ファミリーなどのノードタイプです。

キーの無効化とアクセスの挙動

DAX はすべての操作ごとに AWS KMS を呼び出すわけではなく、クラスターの起動時にのみキーを使用します。そのため、キーのアクセス権限を取り消したりキーを無効化したりしても、実行中のクラスターがシャットダウンされるまでは、DAX は引き続き暗号化されたデータにアクセスできます。

アプリケーションへの影響（参考）

• データが暗号化されても、DAX は透過的に復号処理を行うため、アプリケーションのコードを変更する必要はありません。

• 暗号化はパフォーマンスへの影響を最小限に抑えながら処理されます。

問題7:

あなたはソリューションアーキテクトとして、AWSを活用してEC2インスタンス上にデータベースサーバーを設定する役割を担っています。このデータベースには非常に重要な情報を保存するため、必要なパッチをダウンロードする場合を除き、インターネットから直接にデータベースサーバーに接続されないようにする必要があります。

この要件を満たすためのAWSネットワーク設定はどれでしょうか。

A.データベースをパブリックサブネット内に構築して、このプライベートサブネットのルートテーブルにインターネットゲートウェイへのルートを設定する。

B.データベースをパブリックサブネット内に構築して、このプライベートサブネットのルートテーブルにNATゲートウェイへのルートを設定する。

回答は不正解です
C.データベースをプライベートサブネット内に構築して、このプライベートサブネットのルートテーブルにインターネットゲートウェイへのルートを設定する。

正解
D.データベースをプライベートサブネット内に構築して、このプライベートサブネットのルートテーブルにNATゲートウェイへのルートを設定する。

全体的な説明
このシナリオでは、AWSのプライベートサブネットとパブリックサブネットを利用したアーキテクチャ構成が問われています。サーバーをインターネットから直接接続できないようにする場合は、プライベートサブネットを利用します。

オプション４が正解となります。データベースへのインターネットアクセスを制限するためには、プライベートサブネット内にデータベース用のEC2インスタンスを設置します。プライベートサブネットはインターネットからアクセスできないネットワーク空間であるため、要件を満たすことができます。

しかしながら、このままではプライベートサブネットにあるEC2インスタンスにはパッチ適用などの更新ができない状態となります。そのため、プライベートサブネットのルートテーブルにNATゲートウェイへのルートを追加することで、インターネットからのパッチ更新データなどが返送されるのを、NATゲートウェイ経由で許可する設定を行います。これにより、プライベートサブネット内のデータベースインスタンスに対してパッチ適用や更新作業が可能となります。

プライベートサブネットにインスタンスを配置することで、インターネットからの直接的なアクセスが遮断され、セキュリティが向上します。しかし、ソフトウェアの更新が必要な場合、インターネットからパッチファイルをダウンロードできないため、運用上の問題が生じることがあります。このような場合に役立つのがネットワークアドレス変換（NAT）ゲートウェイです。NATゲートウェイはプライベートサブネット内のEC2インスタンスにあるプライベートIPアドレスをNATゲートウェイに付与されている静的IPアドレスに変換して、対象インスタンスの代わりに外部のインターネットとの通信を行うゲートウェイです。これを利用することで、外部からの返信をNATゲートウェイが代わりに受け取ってくれるようになります。

プライベートサブネットに配置されたEC2インスタンスは、パブリックサブネットに設置されたNATゲートウェイを利用することで、インターネットへのトラフィックを送信することができます。この仕組みにより、プライベートサブネット内のデータベースインスタンスは、NATを介してインターネットにアクセスし、パッチやその他のソフトウェアアップデートを行うことが可能となります。

オプション１と２は不正解です。データベースをパブリックサブネットに配置すると、インターネットからの直接アクセスが可能になり、セキュリティ要件を満たすことができません。そのため、プライベートサブネットに設置する必要があります。

オプション３は不正解です。データベースをプライベートサブネットに設置した場合でも、そのプライベートサブネットのルートテーブルにインターネットゲートウェイへのルートを設定すると、パブリックインターネットとの相互アクセスが可能になってしまいます。したがって、要件に適合しません。

上記は構成の一例です。アベイラビリティーゾーン A には、パブリックサブネットに NAT ゲートウェイが設置されています。一方、アベイラビリティーゾーン B のプライベートサブネットには、インスタンスが配置されています。ルーターは、プライベートサブネット内のインスタンスから NAT ゲートウェイへインターネット向けのトラフィックを転送します。NAT ゲートウェイは、送信元 IP アドレスとして NAT ゲートウェイのエラスティック IP アドレスを使用し、インターネットゲートウェイにトラフィックを送信します。

【NATゲートウェイの詳細情報】

１．主な役割と特徴

• アウトバウンド接続の許可: プライベートサブネット内のインスタンスから、インターネットや VPC 外のサービスへの接続を可能にします。

• インバウンド接続のブロック: 外部（インターネットなど）から開始される、インスタンスへの未承諾の接続は受信しません。これによりセキュリティを維持します。

• アドレス変換: インスタンスのプライベート IP アドレスを NAT ゲートウェイの IP アドレスに変換して通信を行います。応答トラフィックを受信すると、宛先を元のインスタンスのプライベート IP アドレスに再変換して配信します。

２．接続タイプ

NAT ゲートウェイには以下の 2 つの接続タイプがあります。

パブリック (デフォルト)

◦ 用途: プライベートサブネットからインターネットへの接続に使用します。

◦ 要件: パブリックサブネット内に作成し、Elastic IP アドレス (固定パブリック IP) を関連付ける必要があります。

◦ 経路: NAT ゲートウェイへのトラフィックは、VPC のインターネットゲートウェイにルーティングされます。

プライベート

◦ 用途: プライベートサブネットから他の VPC やオンプレミスネットワークへの接続に使用します。インターネット接続は提供しません。

◦ 要件: Elastic IP アドレスは関連付けられません。

◦ 経路: トラフィックは Transit Gateway または仮想プライベートゲートウェイ経由でルーティングされます。

３．その他の機能と考慮事項

• IPv6 サポート: DNS64 と NAT64 を使用して、IPv6 トラフィックにも対応しています。

• 開始点: 接続は常に NAT ゲートウェイを含む VPC 内から開始する必要があります。

• 料金: NAT ゲートウェイの時間単位の利用料金に加え、処理されたデータ量（GB 単位）に応じたデータ処理料金が発生します,。

• 代替手段: メンテナンス（SSH 接続など）のためだけに NAT ゲートウェイを使用している場合は、コスト削減のために EC2 Instance Connect Endpoint の使用が検討されることがあります。

問題8:

ある企業では、AWSを利用して多くのウェブサイトとアプリケーションを運営しています。これらのウェブアプリケーションからは、毎日1TBを超えるクリックストリームデータが収集されており、ユーザーの行動データ解析に活用されています。現在、ソリューションアーキテクトは、これらの大量のデータを保存して、効果的に分析するためのプラットフォームを構築中です。

このデータ分析のために、ソリューションアーキテクトが採用すべきアプローチは何でしょうか。

回答は不正解です
A.AWS Data Pipelineを構成して、Amazon S3バケットにデータを保存し、そのデータをAmazon EMRクラスターで分析する。

B.AWS Data Pipelineを構成して、Amazon S3バケットにデータを保存する。Amazon Redshift Spectrumでバケット内のデータを分析する。

C.Amazon Kinesis Data Streamsでデータを収集して、Amazon Data Firehoseを介して、S3バケットにデータを保存する。オブジェクトがS3バケットに格納された際にS3イベント通知を実行してAWS Lambda関数を起動してデータ分析を行う。

正解
D.Amazon Kinesis Data Streamsでデータを収集して、Amazon Data Firehoseを介して、S3バケットにデータを保存する。Amazon Redshift Spectrumでバケット内のデータを分析する。

全体的な説明
オプション４が正解となります。このシナリオでは、毎日1TBを超えるクリックストリームデータを収集し、データ分析用のワークロードを構築する必要があります。ストリームデータの処理にはAmazon Kinesisを活用することが最適です。Amazon Kinesis Data Streamsは、ストリームデータの処理に特化したサービスです。このサービスを利用することで、クリックストリームデータをリアルタイムで取得し、処理するアプリケーションを開発することが可能です。

Amazon Data Firehoseは、ストリームデータを変換して、ストレージやデータベースに配信するためのサービスです。これを用いることで、データをAmazon S3バケットに送信することができます。ストリームデータは非常に大量になるため、S3バケットにデータを保存する仕組みが必要です。

【具体的な構成】

Amazon Kinesis Data Streamsによるストリーミングデータ処理→Amazon Data Firehoseによるデータ変換と配信→S3バケットでのストリーミングデータ保存

Amazon Redshift SpectrumはS3バケットを直接のデータリソースとして、ビッグデータ解析を行うことができる高性能なデータウェアハウス機能です。Amazon Redshift Spectrumを利用することで、S3バケットに保存された大量のストリーミングデータに対して直接、高度なクエリ処理を行うことができます。Spectrumは数千台のインスタンスにスケール可能であり、データセットがエクサバイトを超える場合でも、高速なデータ取得と安定したパフォーマンスを提供します。

オプション１と２は不正解です。AWS Data Pipelineは、AWSサービス間のデータ転送やデータ変換処理を行うためのサービスであり、ストリームデータの取得や変換には利用できません。AWS Data Pipelineはは、保存されたデータに定期的にアクセスし、データの変換および処理を実施し、その結果をAmazon S3、Amazon RDS、Amazon DynamoDB、Amazon EMRなどに転送することに利用します。

オプション３は不正解です。AWS Lambda関数を使用してAmazon S3内のデータを処理し、分析を行うコーディングは可能ですが、Amazon Redshift Spectrumなどの専用サービスを利用する方がはるかに効率的です。また、AWS Lambda関数は、今回のような大量のストリーミングデータを処理するには適していません。

【Amazon Kinesis Data Streamsの詳細情報】

１．主な特徴とメリット

• リアルタイム処理: ストリーミングデータをリアルタイムで取り込み、バッファリングし、処理することができます。これにより、データの分析結果（インサイト）を得るまでの時間を、数日から数分へと大幅に短縮できます。

• 高速で継続的なデータ取り込み: ITインフラストラクチャのログデータ、アプリケーションログ、ソーシャルメディア、マーケットデータフィード、ウェブのクリックストリームデータなどを、高速かつ継続的に取り込み、集約するために使用されます。

• スケーラビリティ: 数千ものソースから発生する任意の量のストリーミングデータを処理でき、低レイテンシーでの処理が可能です。

• 高可用性: デフォルトでデータを複数のアベイラビリティーゾーン（AZ）にレプリケートするため、AZの障害に対して堅牢な設計となっています。

２．主なユースケース

• アプリケーションのモニタリングと分析: アプリケーションのモニタリング、不正検知、ライブリーダーボードなどのアプリ構築に利用され、分析結果を任意のデータストアやアプリケーションに送信できます。

• ログ分析: 従来はバッチ処理で分析されていたデータに対してリアルタイム分析を実行し、最新情報をいち早く入手するログ分析ソリューションの構築に役立ちます。

• IoTデータ分析: IoTデバイスからのストリーミングデータを処理し、リアルタイムアラートの送信や、センサーが特定のしきい値を超えた際の応答などに利用できます。

• 動画ストリーミング: カメラ搭載デバイスからの動画を安全にストリーミングし、動画再生、セキュリティモニタリング、顔検出、機械学習（ML）などに活用できます。

また、Kinesis Data Streamsはイベント駆動型アーキテクチャにおいて、システム間の依存関係を疎結合にするためのストリーミングデータプラットフォームとしても機能します。

【構成の詳細情報】

Amazon Kinesis Data Streams（KDS）で収集したデータを、Amazon Data Firehose（旧 Kinesis Data Firehose）を経由して Amazon S3 バケットに保存する構成は、一般的なストリーミングデータ処理のパターンです。

全体的なデータフロー

データプロデューサー: アプリケーション、サーバー、IoTデバイスなどが「データプロデューサー」となり、レコード（データ）を Amazon Kinesis Data Streams に送信します。
データ収集 (Kinesis Data Streams): Kinesis Data Streams はデータをリアルタイムで取り込み、一時的に保持します。
データ配信 (Amazon Data Firehose): Firehose は Kinesis Data Streams から自動的にデータを読み取り、バッファリングした後、指定された Amazon S3 バケットへ配信します。

構成ステップと主要な機能

Kinesis Data Streams の用意

まず、データの受け口となる Kinesis Data Stream（ストリーム）を作成します。データプロデューサーはこのストリームに対してレコードを送信します。

Amazon Data Firehose ストリーム（配信ストリーム）の作成

Firehose ストリームを作成し、以下の設定を行います。

• ソース（Source）の設定: データソースとして、既存の Kinesis Data Streams を選択します。これにより、Firehose は自動的にストリームからデータを読み取るようになります。

• 宛先（Destination）の設定: 配信先として Amazon S3 を選択し、データを保存する S3 バケットを指定します。

• バッファリングの設定（バッファサイズとバッファ間隔）: Firehose はデータを S3 に配信する前に、特定のサイズまたは期間、データをバッファリング（一時保存）します。

◦ バッファサイズ: MB単位で指定します（最大128MBなど）。

◦ バッファ間隔: 秒単位で指定します（例: 60秒）。

◦ どちらかの条件が満たされた時点で、データが S3 に書き込まれます。

データ変換（オプション）

S3 に保存する前にデータの形式を変更したい場合（例：ログ形式の変換、JSON への変換など）、AWS Lambda 関数を呼び出してデータを変換するように Firehose を設定できます。

• データ変換を有効にした場合、変換後のデータが宛先の S3 バケットに配信されます。

• オプションで、変換前の「ソースデータ」を別の S3 バケット（または同じバケットの別のプレフィックス）にバックアップとして保存することも可能です。

S3 への保存形式

Firehose によって S3 に配信されるデータは、設定したバッファリング条件に基づいて生成されたオブジェクト（ファイル）として保存されます。特に設定しない場合、データレコードは連結されて保存されますが、Parquet や ORC などの列指向フォーマットに変換して保存する機能（データ変換）を利用することも可能です。

【Amazon Redshift Spectrumの詳細情報】

Amazon Redshift Spectrumは、Amazon Redshiftの機能の一つで、Amazon S3に保存されているデータに対して、Redshiftのテーブルにロードすることなく直接SQLクエリを実行できるサービスです。

１．主な特徴と利点は以下の通りです。

• データのロードが不要: 通常、データウェアハウスで分析を行うにはデータをロード（ETL処理など）する必要がありますが、Spectrumを使用すると、S3上のファイルをそのままのフォーマットでクエリできます。これにより、データを移動する手間や時間を削減できます。

• 大規模なスケーラビリティ: クエリの実行時には、背後で数千台規模までスケールするSpectrumインスタンス（ワーカー）が使用されます。これにより、データセットがエクサバイト規模になっても、高速なデータ取り出しと一貫したパフォーマンスを実現します。

• ハイブリッドなクエリが可能: Redshiftのローカルストレージに保存されたデータと、S3上にあるデータを、1つのクエリ内で自由に組み合わせて（JOINして）参照することができます。

◦ 例：頻繁にアクセスする「直近のデータ」はRedshiftに置き、アクセ頻度の低い「古いデータ」はS3に置いてコストを抑えるといったハイブリッド構成が可能です。

• オープンフォーマットのサポート: CSV、TSV、Parquet、SequenceFile、RCFileといったオープンなフォーマットをサポートしています。また、GzipやSnappyなどの圧縮ファイルも扱えます。

• 他のAWSサービスとの連携: S3上のデータに直接アクセスするため、Amazon EMRやAmazon Athenaといった他のサービスで処理されたデータと同じデータを参照・共有することが容易です。

２．仕組みと利用方法

利用者は、外部スキーマ（External Schema）と外部テーブル（External Table）を定義するだけで、通常のRedshiftテーブルと同じようにSQLを投入できます,。Redshiftはクエリプランを作成し、Spectrumワーカーに指示を出してS3上のファイルに対しスキャン、フィルタリング、集計などを実行させます。最終的な結果の統合はRedshift内で行われます。

３．料金

Redshiftクラスターの費用とは別に、クエリによってS3からスキャンされたデータ量（例：1TBあたり5ドル）に基づいて課金されます。データを圧縮したり、列指向フォーマット（Parquetなど）を使用したりすることで、スキャン量を減らしコストを節約できます。

問題9:

ある企業では、AWSの東京リージョンにおいてEC2インスタンスにホストされたWEBアプリケーションを運営しています。あなたはソリューションアーキテクトとして、これらのWEBアプリケーションをシンガポールリージョンおよびシドニーリージョンに複製し、アプリケーションを拡張しようとしています。このプロセスにおいては、地理的に近いユーザーに対する最適な言語選択とルーティング制御が求められます。

ユーザーに対して最適な言語選択とルーティング制御を実現するためには、どのようなソリューションが必要でしょうか。

正解
A.Route53において位置情報ルーティングを設定して、ユーザーの位置情報に応じた言語表示を自動で実施する。

B.NLBを利用して全リージョンのロードバランシングを実施して、ロードバランサーのトラフィック分散地域に応じて言語表示を自動で実施する。

回答は不正解です
C.Route53で地理的近接性ルーティングを設定して、ユーザーの位置情報に応じた言語表示を自動で実施する。

D.ALBを利用して全リージョンのロードバランシングを実施して、ロードバランサーのトラフィック分散地域に応じて言語表示を自動で実施する。

全体的な説明
このシナリオでは、要件に応じたRoute53のルーティングポリシーの選択方法が問われています。Route53ではIPアドレスとドメイン（URL）を紐づけて、名前解決をしてくれるDNSサーバーを提供しています。そして、Route53はドメイン名に基づいて最適なリソースに対してルーティングを行ってくれています。その際のルーティング方法を定めるのがルーティングポリシーです。

オプション１が正解となります。ユーザーの地理的位置情報に基づいてトラフィックを処理するリソースを選択するためには位置情報ルーティングを利用します。この機能により、ユーザーの位置情報に応じて表示言語やトラフィック処理の方法を調整することが可能です。例えば、東京にいるユーザーには日本語を、ソウルにいるユーザーには韓国語を表示することができます。

Route53でレコードを作成する際には、以下のルーティングポリシーから選択する必要があります。

■シンプルルーティングポリシー
特定の機能を実行する単一のリソースがドメイン内に存在する場合に適用されます。例えば、example.comのウェブサイトにコンテンツを提供する単一のウェブサーバーが該当します。このシンプルルーティングは、プライベートホストゾーンにレコードを作成する際に利用可能です。

■フェイルオーバールーティングポリシー
アクティブ/パッシブのフェイルオーバーを設定する際に使用されます。このポリシーも、プライベートホストゾーンにレコードを作成するために利用できます。

■位置情報ルーティングポリシー
ユーザーの地理的位置に基づいてトラフィックをルーティングする場合に適用されます。このポリシーは、プライベートホストゾーンにレコードを作成するために使用されます。

■地理的近接性ルーティングポリシー
リソースの物理的な位置に基づいてトラフィックをルーティングし、必要に応じてトラフィックを異なる場所のリソース間で移動させる場合に使用されます。このポリシーも、プライベートホストゾーンにレコードを作成するために利用可能です。

■レイテンシールーティングポリシー
複数のAWSリージョンにリソースが存在する場合に、最もレイテンシーが低いリージョンにトラフィックをルーティングするために使用されます。このポリシーは、プライベートホストゾーンにレコードを作成する際に利用できます。

■IPベースのルーティングポリシー
トラフィックを特定のIPアドレスに基づいてルーティングする場合に使用されます。

■複数値回答ルーティングポリシー
Route 53がDNSクエリに対して応答する際、最大8つの正常なレコードをランダムに選択して使用します。このルーティング方式は、プライベートホストゾーンにレコードを作成する際にも利用可能です。

■加重ルーティングポリシー
特定の比率に基づいて、複数のリソースにトラフィックを分配するために用いられます。このポリシーも、プライベートホストゾーンにレコードを作成する際に使用できます。

オプション３は不正解です。地理的近接性ルーティングは、ユーザーの位置情報とリソースの位置情報に基づいて、配信リソースの地理的範囲を調整する手法です。例えば、同じ米国内であっても、西部地域のリソースにトラフィックを集中させたい場合などにバイアスの設定して、ユーザーの地理的範囲を柔軟に変更する際に活用されます。このポリシーはリージョンに応じた言語表示設定には利用できません。

オプション２と４は不正解です。ELBには、位置情報に基づくルーティングやトラフィック分散を実施する機能はありません。

【構成の詳細情報】

位置情報ルーティングポリシーは、DNS クエリの送信元であるユーザーの物理的な位置に基づいて、トラフィックを特定のリソース（ウェブサーバー、S3バケット、ロードバランサーなど）にルーティングする機能です。これを利用することで、例えば日本からのアクセスには日本語版のウェブサイトを、アメリカからのアクセスには英語版のウェブサイトを表示するといった制御が可能になります。

設定のステップ

Route 53 で位置情報に基づいた言語表示の切り替えを自動化するには、以下のプロセスで構成します。

各言語向けのリソース（エンドポイント）の準備

まず、言語ごとに異なるコンテンツを提供するサーバーやリソースを用意します。

• 日本語用リソース: 日本語コンテンツをホストするサーバー（例: IPアドレス 192.0.2.1 または S3バケット）

• 英語（その他）用リソース: 英語コンテンツをホストするサーバー（例: IPアドレス 192.0.2.2）

Route 53 でのレコード作成とポリシー設定

Route 53 のホストゾーン内で、ドメイン名（例: example.com）に対してレコードを作成します。その際、ルーティングポリシーとして「位置情報 (Geolocation)」を選択します。

具体的な設定イメージは以下の通りです。

• レコードセット A（日本語用）:

◦ ルーティングポリシー: 位置情報 (Geolocation)

◦ 場所 (Location): アジア > 日本 (Japan)

◦ 値/ルーティング先: 日本語用リソースの IP アドレスや DNS 名

◦ 動作: 日本国内からのアクセスは、このリソースにルーティングされます。

• レコードセット B（デフォルト/英語用）:

◦ ルーティングポリシー: 位置情報 (Geolocation)

◦ 場所 (Location): デフォルト (Default)

◦ 値/ルーティング先: 英語用リソースの IP アドレスや DNS 名

◦ 動作: 日本以外の場所、または位置が特定できないIPアドレスからのアクセスは、すべてこのリソースにルーティングされます。

重要な考慮事項

• デフォルトレコードの作成: 位置情報ルーティングを使用する場合、どの場所にも一致しないリクエストや、IP アドレスから位置が特定できないリクエストを処理するために、デフォルトのレコードを作成することが推奨されます（上記レコードセット B に相当）。これにより、予期しない場所からのアクセスでもエラーにならず、標準的な言語ページ（英語など）を表示できます。

• 精度の範囲: 大陸単位、国単位、あるいはアメリカ合衆国であれば州単位での指定が可能です。

この構成により、ユーザーがブラウザでドメインにアクセスした際、Route 53 がユーザーの DNS リゾルバの位置を判別し、適切な言語バージョンのサーバーの IP アドレスを自動的に返します。

問題10:

ある企業が、パブリックドメインの画像データを提供するアプリケーションを開発しています。このアプリケーションはAmazon EC2インスタンス上で運用されており、画像コンテンツはAmazon S3バケットの標準ストレージクラスに保存されています。S3バケットにはパブリックアクセスブロックを有効にしてバケットポリシーによる制御が設定されています。アプリケーションは、AWS外部のユーザーのリクエストに応じて特定の画像を一時的に表示する必要があり、その際には特定のユーザーに対してのみ一時的な画像の利用許可を設定することが求められます。

この要件に応じて、どのようなソリューションを導入する必要がありますか。

回答は正解です
A.Amazon S3の期限付きの事前署名付きURLを利用して、画像コンテンツをユーザーに配信する。

B.CloudFrontディストリビューションによって画像配信を実施することで、画像コンテンツを利用できるユーザー範囲を限定する。

C.Amazon S3にAWS KMSの暗号化キーを適用して期限付きで、画像コンテンツを暗号化する。ユーザーは復号キーを利用して、画像にアクセスする。

D.画像保存先をEFSによるファイル共有に切り替えることで、期限付きで画像コンテンツを共有する仕組みを構成する。

全体的な説明
このシナリオでは、Amazon S3バケットの標準ストレージクラスに保存された画像コンテンツに対して、特定のユーザーに一時的な画像オブジェクトへのアクセス権を付与する方法が求められています。Amazon S3バケットはパブリックアクセスブロックが無効になっている場合、インターネットから誰でも保存されているオブジェクトデータにアクセスできるストレージです。

パブリックアクセスブロックを有効にしてバケットポリシーによってアクセス制御設定をしている場合は、その制御範囲でしかオブジェクトデータにアクセスできなくなります。その際に、特定の外部ユーザーにS3バケット内の画像コンテンツを配信する方法が問われています。

オプション１が正解となります。Amazon S3は、事前署名付きURLを使用して特定のオブジェクトに一時的にアクセスできる特別なURLを生成することができます。特定のユーザーに特定のオブジェクトへの一時的なアクセスを許可する場合は事前署名付きURL経由で、対象オブジェクトにアクセスを許可することができます。パブリックアクセスブロックやバケットポリシーの制御に影響されずに、外部ユーザーは事前署名付きURL経由で特定のオブジェクトに一定期間アクセスすることが可能となります。

オプション２は不正解です。Amazon CloudFrontディストリビューションの配信設定のみでは、画像コンテンツへの一時的なアクセス許可をユーザーに付与することができません。CloudFrontディストリビューション設定において署名付きURLや署名付きCookiesを発行することで、特定のユーザーに対して一時アクセスを許可することができます。これにより、Amazon S3の事前署名付きURLと同じ結果が得られます。

オプション３は不正解です。AWS KMSによる暗号化は、特定のユーザーに画像を共有するための仕組みではありません。暗号化キーはデータを暗号化する手段であり、S3バケット内のデータを保護するための機能です。

オプション４は不正解です。EFSではインスタンス間でのデータ共有が可能ですが、インターネットを介して第三者がアクセスすることはできません。そのため、外部にデータを公開するためのストレージサービスとしては、Amazon S3を利用する方が適切です。

【事前署名付きURLの詳細情報】

主な特徴と仕組みは以下の通りです。

仕組みと権限

• 権限の委任: 署名付きURLは、それを作成したユーザーのアクセス許可によって制限されます。つまり、URLを作成したユーザーが対象オブジェクトへのアクセス権（アップロードやダウンロードの権限）を持っている場合のみ、そのURLを受け取った第三者も操作が可能になります。

• 認証情報の不要化: URLを受け取ったユーザーは、AWSの認証情報を持っていなくても、HTTPリクエスト（curlコマンドなど）を通じてS3バケットへの操作が可能になります。

有効期限（Expiration）

署名付きURLには有効期間が設定されており、期間が過ぎるとアクセスできなくなります。

• コンソールでの挙動: Amazon S3コンソールでオブジェクトに対して「開く」や「名前を付けてダウンロード」を選択した際も、裏側では有効期限が5分間の署名付きURLが生成されています。

• 最大有効期限: AWS CLI（コマンドラインインターフェイス）やAWS SDKを使用して生成する場合、有効期限は最大7日間まで設定可能です。

主な利用用途

• オブジェクトのアップロード: ユーザーにファイルをアップロードさせたい場合、署名付きURLを発行することで、特定のバケットやキー（ファイル名）に対して直接アップロードを許可できます。この際、URL生成時に指定したファイル名と正確に一致する必要があります。

• オブジェクトのダウンロード: デフォルトで非公開（プライベート）なオブジェクトに対して、特定のユーザーに期間限定でアクセスさせたい場合などに利用されます。

作成方法

署名付きURLは、コードを記述せずに「AWS Explorer for Visual Studio」を使用したり、AWS SDKやAWS CLIを使用してプログラムで生成したりすることができます。

問題11:

あなたはソリューションアーキテクトとして、AWS上でアプリケーションの開発およびテストを行っています。その際は、作業効率を高めるために、AWS環境のインフラ構成を一括にデプロイするような方法が求められています。それによって、開発環境やテスト環境を迅速にプロビジョニングしたり、容易に削除したりできるようにすることを目指しています。

この要件を満たす最も適切なAWSサービスの設定はどれでしょうか。

AWS CodePipelineを設定して、コードを展開するパイプラインを構成することで迅速な環境設定と削除を可能にする。

回答は正解です
CloudFormationによりテスト環境用のテンプレートを作成する。このテンプレートを利用してテスト環境をデプロイできるようにする。

EC2インスタンスのAMIとBashスクリプトを利用して、テスト環境構築を設定する。スクリプトを実行することで、テスト環境をデプロイできるようにする。

Amazon ECRにイメージを作成して、テスト環境構築を設定する。このイメージを利用して、テスト環境をデプロイできるようにする。

全体的な説明
オプション２が正解となります。AWS CloudFormationテンプレートを使用することで、AWSリソースの設定を定義したJSONまたはYAMLファイルからAWS環境を一括でプロビジョニングすることが可能となります。この機能により、開発環境やテスト環境などのAWSリソース構成をテンプレート化して何度も展開したり削除したりすることが容易になります。

AWS CloudFormationは、AWSリソースを用いたアーキテクチャの構成をコードとして表現し、テンプレートとして利用できるサービスです。コードを用いて、Amazon EC2インスタンスやAmazon RDS DBインスタンスなどのAWSリソースを記述するテンプレートを作成することで、リソースのプロビジョニングや設定を実行することができます。

オプション１は不正解です。AWS CodePipelineは、CodeDeployやAmazon ECSなどのサービスを利用してアプリケーションデプロイ時のパイプラインを構築する機能です。これを利用して、コードの開発からデプロイまでのプロセスを自動化し、効率的に管理することができます。しかしながら、CodePipelineはコードデプロイ用であって、インフラ構成のデプロイには適用できません。インフラのデプロイにはCloudFormationなどのツールを使用する必要があります。

オプション３は不正解です。AMIとBashスクリプトはEC2インスタンスの起動時にソフトウェア設定を自動化するために使用されますが、これはEC2インスタンス特有の機能であり、AWSインフラ構成のデプロイには利用できません。

オプション４は不正解です。Amazon ECRはDockerイメージを保存するためのサービスであり、これによりDockerコンテナの構成を保存して、再利用することができます。しかしながら、このサービスはAWS上のインフラストラクチャのデプロイ設定を自動化するためのものではなく、あくまでDockerアプリケーションの構成イメージを管理するためのものです。

【CloudFormationテンプレートの詳細情報】

CloudFormationのテンプレートでは、次のような記述方法が規定されています。ResourcesセクションにVPCやEC2などのリソースを指定し、それぞれのリソースの設定をプロパティとして記述することで、構成や設定を表現することができます。

形式と構造

• ファイル形式: JSON または YAML 形式で記述します。

• 必須セクション: テンプレートには複数のセクションを含めることができますが、必須なのは Resources セクションのみです。ここでは少なくとも1つのリソースを宣言する必要があります。

• 作成方法: テキストエディタで直接記述するほか、ビジュアルインターフェイスである「AWS Infrastructure Composer」や、既存のリソースからテンプレートを生成する「IaCジェネレーター」を使用して作成することも可能です。

主な機能と記述内容

テンプレート内では、静的なリソース定義だけでなく、動的な処理や制御も記述できます。

• 組み込み関数: 実行時まで値が決まらないプロパティを割り当てるために使用します。

◦ Ref: パラメータの値やリソースの物理IDを取得します。

◦ Fn::GetAtt: リソースから特定の属性値を取得します。

◦ Fn::Sub: 文字列内の変数を実際の値に置き換えます。

◦ Fn::Join: 複数の値を結合して1つの文字列にします。

• リソース属性: リソースの動作を制御します。

◦ DependsOn: リソースの作成順序を指定します（あるリソースが作成されてから別のリソースを作成するなど）。

◦ DeletionPolicy: スタック削除時のリソースの扱い（保持するか削除するかなど）を指定します。

管理と運用のメリット

• Infrastructure as Code (IaC): インフラストラクチャをコードとして定義することで、バージョン管理システム（Gitなど）を用いた変更履歴の追跡や管理が可能になります。

• 再現性と一貫性: テンプレートを再利用することで、複数のAWSアカウントやリージョンにわたって、同じ構成のリソースを一貫して繰り返しセットアップできます。

• 保存場所: テンプレートはAmazon S3バケットに保存したり、Git同期機能を使用してGitリポジトリで管理したりすることができます。

なお、AWS Cloud Development Kit (AWS CDK) を使用してプログラミング言語（TypeScriptやPythonなど）でインフラを定義する場合も、バックグラウンドではCloudFormationテンプレートが生成され、リソースのプロビジョニングに使用されます。

問題12:

ある企業がAWSを活用してデータベースを構築するための要件を検討しています。あなたはソリューションアーキテクトとして、データベース要件に基づいて最適なAWSサービスを選定し、データベースを設定する役割を担っています。同社は、データベースに使用するサーバーのOS設定を自社で管理する考えです。

この要件に適合するデータベース構築の方法を選択してください。

Amazon RDSを利用してデータベースを構築する。

Amazon DynamoDBを利用してデータベースを構築する。

Amazon Auroraを選択してデータベースを構築する。

回答は正解です
Amazon EC2インスタンスを利用してデータベースを構築する。

全体的な説明
オプション４が正解となります。自社でOS設定などのデータベースインフラを管理するためには、EC2インスタンスを用いてデータベースを構築することが不可欠です。EC2インスタンスを活用することで、ゲストサーバーのOSやデータベースソフトウェアをユーザーが完全に制御できるようになります。

AWSが提供するサービスは、Amazon RDSなどのAWS側が運用管理を行うマネージド型サービスと、Amazon EC2のように物理サーバーはAWSが管理するものの、ソフトウェアの設定以降はユーザーに運用が委ねられるアンマネージド型に分類されます。AWSの大半のサービスはマネージド型となるため、ユーザーはインフラやOSなどの運用管理が直接できません。

マネージド型サービスは運用が容易である一方、ユーザーが設定や管理できる範囲が制限されるという欠点があります。対照的に、アンマネージド型サービスはユーザーが設定や管理を行う柔軟性が高いという利点があります。したがって、このシナリオにおいて「データベースに使用するサーバーのOS設定を自社で管理する」という要件を満たすためには、アンマネージド型のEC2インスタンスを利用し、ユーザー側でDBソフトウェアをインストールする必要があります。

オプション１と２と３は不正解です。RDS／DynamoDB／Auroraはマネージド型サービスのため、データベースを構成するOS設定などを自社で管理できません。

【構成の詳細情報】

Amazon EC2インスタンスを利用してデータベースを構築する方法には、主に以下の3つのアプローチがあります。

手動またはスクリプトによるインストール（セルフマネージド）

EC2インスタンスを仮想サーバーとして立ち上げ、そのOS上にデータベースソフトウェア（MySQL、PostgreSQL、SQL Server、Oracleなど）を直接インストールして設定する方法です。

• ユーザーデータの活用: インスタンスの起動時に「ユーザーデータ」スクリプトを指定することで、セットアップを自動化できます。例えば、Amazon Linux上でLAMPサーバーを構築する際、ユーザーデータを使用してパッケージの更新、mariadb-serverのインストール、サービスの開始などを自動的に実行させることが可能です。

• 構成の自由度: OSやデータベースの設定、パッチ適用、バックアップなどをユーザー自身が完全に管理（IaaS型）するため、自由なカスタマイズが可能です。

AWS Launch Wizardを利用したデプロイ

サードパーティー製の特定のアプリケーションやデータベースについては、AWS Launch Wizardを利用することで構築を自動化・簡素化できます。

• 機能: Microsoft SQL ServerやSAPなどの要件（パフォーマンス、ノード数、接続性など）を入力すると、Launch Wizardが適切なAWSリソース（EC2インスタンスタイプやEBSボリュームなど）を特定し、プロビジョニングと設定を自動で行います。

• メリット: 個々のリソースを手動で識別・プロビジョニングする必要がなく、AWSのベストプラクティスに基づいた構成が可能です。

クラスター構成による構築（高可用性）

ミッションクリティカルなシステムなどでは、複数のEC2インスタンスを使用してクラスターを構成し、可用性を高める方法があります。

• 構成例: EC2インスタンスを複数の拠点（アベイラビリティーゾーンなど）に配置し、OSレベルのフェールオーバークラスター（Windows Server Failover ClusteringやPacemakerなど）を構成します。

• 共有ストレージ: Amazon EBSのマルチアタッチ機能を利用すると、1つのプロビジョンドIOPS SSDボリュームを同じアベイラビリティーゾーン内の複数のインスタンス（LinuxまたはWindows）にアタッチでき、クラスター化されたデータベースやファイルシステムの構築が容易になります。

データベース構築時の重要な要素

EC2でデータベースを構築する際は、以下のリソース選定が重要となります。

• インスタンスタイプ: ワークロードに応じて、メモリ最適化インスタンス（R5など）や、高いコンピューティング性能を持つベアメタルインスタンスなどを選択します。

• ストレージ: データベースのデータ保存には、永続的なブロックストレージであるAmazon EBSが推奨されます。データの耐久性を確保するため、定期的にEBSスナップショットを作成してバックアップを行う責任はユーザーにあります。

【参照】

AWS Managed Services (お客様に代わりAWSを運用) | AWS (amazon.com)

問題13:

ある企業がAWS上でウェブアプリケーションを開発しています。このアプリケーションは複数のEC2インスタンスにホストされており、Amazon SQSキューからメッセージを取得して、EC2インスタンスがそのメッセージを処理し、処理結果をAmazon RDS DBインスタンスに書き込む仕組みです。処理完了後、メッセージはキューから削除されます。Amazon SQSキュー内のメッセージは重複しないものの、RDS DBインスタンスに保存されたデータには時折重複レコードが見受けられます。

重複メッセージの発生を防ぐために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

正解
ChangeMessageVisibility をAPI使用して、適切な可視性タイムアウト値を設定する。

回答は不正解です
AddPermission APIを使用して、適切な権限を付与する。

CreateQueue APIを使用して、新しいキューを作成する。

ReceiveMessage APIを使用して、適切な待機時間を設定する。

全体的な説明
Amazon SQSは、マネージド型のメッセージキューイング機能です。SQSキューを利用することで、分散型のコンポーネント間を分離し、トランザクションの並行処理などが可能となります。

キューとは、受信したデータやメッセージを順番に格納し、最初に入れたメッセージから順に取り出す仕組みです。これは、レジ待ちの際に「先に並んでいた人が先に呼ばれ、後から来た人は列の後ろに並ぶ」という状況に似ています。したがって、キューは順番通りにトランザクション処理を実行させたい場合などに利用します。

今回のケースでは、Amazon SQSキュー内のメッセージには重複が見られない一方で、RDS DBインスタンス内の保存データには重複レコードが存在するという問題が発生しています。この原因として、コンシューマーがキューからメッセージを二重に取得している可能性が考えられます。コンシューマーとはキューを処理するLambda関数やEC2インスタンスなどのコンピューティングリソースのことです。

オプション１が正解となります。Amazon SQSキューでは、コンシューマーによってキュー内のメッセージが取得されても、対象メッセージが削除されない限り、キュー内には同じメッセージが残り続けます。そのため、複数の受信先が同じメッセージを受け取ることで、メッセージ配信が重複するリスクが生じます。他のコンシューマーによるメッセージの再処理を防ぐためには、Amazon SQSの可視性タイムアウトを設定することが重要です。可視性タイムアウト期間は、最初にメッセージを受信したコンシューマー以外のコンシューマーからはメッセージが見えなくなります。

可視性タイムアウトを設定するには、ChangeMessageVisibility APIを利用し、適切なタイムアウト値を指定します。これにより、他のコンシューマーがメッセージを重複して取得することを防ぎます。

オプション２は不正解です。AddPermission APIは、適切な権限を付与するための権限設定です。このAPIを使用しても、可視性タイムアウトを設定したり、メッセージの重複を防ぐことはできません。

オプション３は不正解です。CreateQueue APIは新しいキューを作成するためのAPI設定であり、これを使用しても可視性タイムアウトを設定したり、メッセージの重複を防ぐことはできません。

オプション４は不正解です。ReceiveMessage APIは、適切な待機時間を設定するための機能です。待機時間を設定すると、すべてのコンシューマーがメッセージの取得を待つことになり、処理が遅延します。これは可視性タイムアウトとは異なり、メッセージの重複処理を防ぐ機能ではありません。

【可視性タイムアウトの詳細情報】

Amazon SQS キューからコンシューマーがメッセージを受信した際、そのメッセージはキューに残ったままですが、他のコンシューマーからは一時的に見えなくなる（受信できなくなる）期間のことです。

この機能により、あるコンシューマーがメッセージを処理している間、他のコンシューマーが同じメッセージを同時に取得して重複処理してしまうことを防ぎます。

主な挙動と仕組み

不可視化: メッセージが配信されると、可視性タイムアウトの期間が開始され、その間メッセージは他のコンシューマーから隠されます。
処理と削除: コンシューマーはこの期間内にメッセージの処理を完了し、キューからメッセージを削除する必要があります。
再表示: タイムアウト期間内にメッセージが削除されなかった場合（処理の失敗やタイムアウトなど）、そのメッセージは再びキューに表示され、別のコンシューマーが受信して処理できるようになります。

例えば、インスタンスAとインスタンスBの2つのインスタンスがキュー内のメッセージを処理している場合、以下のように動作します。

キュー内のメッセージAがスポットインスタンスAによって最初にポーリングされると、その後、他のインスタンスからは一定の期間（可視性タイムアウトで設定された時間）そのメッセージAは見えなくなります。
もしスポットインスタンスAがメッセージ処理を完了する前に削除された場合、可視性タイムアウトの間はメッセージAの処理が中断されることになります。
可視性タイムアウトの期間が終了すると、別のインスタンスBからメッセージAが再び見えるようになるため、インスタンスBによってメッセージAの処理が再開されます。

設定と制限

• デフォルト設定: デフォルトの可視性タイムアウトは 30 秒です。

• 設定可能範囲: 最小 0 秒から最大 12 時間の間で設定可能です。

• 動的な変更: ChangeMessageVisibility アクションを使用することで、個別のメッセージに対してタイムアウトをプログラムで延長または短縮できます。

◦ 処理に時間がかかる場合に時間を延長する（ハートビートのような仕組み）。

◦ 処理を中止してすぐに他のコンシューマーに任せるために、タイムアウトを 0 秒にして終了する。

• 最大制限: メッセージを最初に受信してから最大 12 時間までしか延長できません。

キュータイプによる挙動の違い

• 標準キュー: 可視性タイムアウトにより、複数のコンシューマーが同じメッセージを同時に処理することを防ぎます（ただし、標準キューの特性上、まれに複数回配信される可能性はあります）。

• FIFO キュー: あるメッセージグループ ID を持つメッセージが処理中（可視性タイムアウト中）の場合、同じグループ内の後続のメッセージは、その処理中のメッセージが削除されるかタイムアウトするまで配信されません。これにより順序が守られます。

問題14:

ある企業はEC2インスタンス上に「イベントドリブンアプリケーション」を構築しました。アプリケーションのトラフィック急増時にも円滑に処理を続けられるよう、これらのインスタンスにはAuto Scalingグループが設定されています。しかし、最近、毎日17時から17時半の間にアプリケーションのパフォーマンスが急激に低下する問題が発生しています。この負荷増加が短時間であるため、Auto Scalingによるインスタンスの追加が間に合っていないようです。

ソリューションアーキテクトとして、どのようにこの問題を改善するべきでしょうか。

Auto Scalingが起動するインスタンス数の最大数を増加する。

ELBによるロードバランシングを設定する。

回答は不正解です
Route53によるトラフィックルーティングを設定する。

正解
Auto Scalingに対して、スケジュールされたスケーリングポリシーを追加する。

全体的な説明
このシナリオでは、短期間だけEC2インスタンスへのトラフィック負荷が増加することで、Auto Scalingによる新たなインスタンスの起動が間に合わないという問題が発生しています。Auto Scalingグループが新しいインスタンスを起動する際には、アプリケーション向けのソフトウェアインストールなどの準備に時間を要します。そのため、Auto Scalingによるインスタンス増加が実行されてから実際に負荷が軽減されるまでには、数分から数十分のタイムラグが生じることが一般的です。

オプション４が正解となります。このシナリオでは、毎日17時から17時半の間だけアプリケーションのパフォーマンスが低下するため、迅速なスケーリングが求められています。スケーリングが必要な時間帯や期間が特定されている場合、Auto Scalingにはスケジュールされたスケーリングポリシーの設定が必要です。この設定によって、17時前にスケーリングを実施することができるため、ピーク時間前に稼働可能なEC2インスタンスの数を増やすことができます。

スケジュールされたスケーリングポリシーは、特定期間に予測された負荷上昇を自動的にスケーリングするための設定です。これにより、特定期間内にインスタンスを増減させるスケジュールされたアクションを作成できます。例えば、週の半ばに負荷が増加し、週末に向かって減少するパターンに合わせてスケーリングを設定することが可能です。これにより、コストとパフォーマンスを最適化し、アプリケーションは必要なキャパシティを保持しつつ、不要なリソースを減らすことができます。

【Auto scalingのスケーリングタイプ】

オプション１は不正解です。Auto Scalingグループによってスケールアウトされるインスタンス最大数の設定を増やしても、スケーリング感知時に起動される最大インスタンス数が増えるだけです。このシナリオでは、そもそもスケーリング実施時にインスタンス起動準備が間に合っていないことが原因のため、その数を増やしても問題の解消には役に立ちません。

オプション２は不正解です。ELBによるロードバランシングは、EC2インスタンス間のトラフィックを分散することができますが、インスタンス数が不足している場合、負荷分散だけではトラフィック急増には耐えられません。今回のケースでは、スケーリングタイミングが問題であるため、適切ではありません。

オプション３は不正解です。Route53を用いたトラフィックルーティングの冗長構成をしても、1つのインスタンスが停止した場合に別のインスタンスにトラフィックを振り分けるだけです。インスタンス間のルーティングが適切に行われたとしても、そもそものインスタンス数が不足している場合は負荷増加には耐えられません。今回のケースでは、スケーリングタイミングが問題であるため、適切ではありません。

【スケジュールされたスケーリングの詳細情報】

主な仕組みと機能

スケジュールされたスケーリングを使用するには、「スケジュールされたアクション」を作成します。

• 動作: 指定された日時に、Auto Scaling グループの希望するキャパシティ（Desired Capacity）、最小キャパシティ、最大キャパシティの設定値を変更します。

◦ 現在のキャパシティが新しい設定値より少ない場合、スケールアウト（インスタンス追加）します。

◦ 現在のキャパシティが新しい設定値より多い場合、スケールイン（インスタンス削除）します。

• スケジュールの種類:

◦ 一度だけの実行: 特定の日時に1回だけ実行するアクションを作成できます。

◦ 定期的な実行: Cron式（Linuxのcrontab形式）を使用して、繰り返しのスケジュール（例：毎週月曜日の午前9時など）を設定できます。

• タイムゾーン: デフォルトは協定世界時 (UTC) ですが、ローカルタイムゾーン（例：Asia/Tokyoなど）を指定することも可能です。サマータイムがある地域を指定した場合、自動的に調整されます。

動的なスケーリングポリシーとの併用

スケジュールされたスケーリングは、ターゲット追跡スケーリングなどの動的なスケーリングポリシーと併用することができます。

• 併用のメリット: スケジュールされたアクションでベースとなるキャパシティ（最小・最大）を確保しつつ、その範囲内で突発的な負荷変動に対しては動的なポリシーで対応するといった構成が可能です。

• 例えば、イベント開始時にスケジュールアクションで最小キャパシティを引き上げ、イベント終了後に元に戻すといった使い方ができます。これにより、イベント中の負荷を処理するための十分なベースラインを確保できます。

制限事項

• 1つのAuto Scalingグループにつき、最大125個のスケジュールされたアクションを作成できます。

• アクションの名前はグループ内で一意である必要があります。

問題15:

ある企業はAWS上で基幹システムを運用しており、このシステムはAmazon Aurora MySQLデータベースを用いてデータを管理しています。保存データは業務において極めて重要であるため、データセンター障害に備えた構成が求められます。要件としては、データセンター障害が発生した際には、数分以内にデータベースを再稼働させることができるようにして、ダウンタイムを最小限に抑える必要があります。

この要件を満たすために、コスト効率の良いソリューションを選定してください。

Amazon Aurora Global Databaseによる高速フェールオーバーを有効化する。これによって、プライマリDBに障害が発生した場合でも、スタンバイDBが処理を継続する。

Amazon Aurora Global Databaseを有効化する。プライマリDBに障害が発生した場合は、スタンバイDBインスタンスをプライマリDBインスタンスに昇格させる。

正解
Aurora DBクラスターのレプリカを複数アベイラビリティゾーンに展開する。プライマリDBに障害が発生した場合は、レプリカの１つをプライマリDBに昇格させる。

回答は不正解です
AuroraDBクラスターのスナップショットを作成して、Amazon Data Lifecycle Managerを設定する。プライマリDBに障害が発生した場合は、Amazon DLMによってスナップショットから迅速にDBが復元される。

全体的な説明
このシナリオでは、特定のデータセンターに障害が発生した場合でも、別のデータベースを活用することで、Amazon Aurora MySQLデータベースのダウンタイムを最小限に抑えることが求められています。データセンターは1つのアベイラビリティゾーンを形成しているため、データセンターが停止すると、そのアベイラビリティゾーンそのものが影響を受ける可能性があります。したがって、単一のアベイラビリティゾーンに依存しないデータベースの冗長性が必要です。

オプション３が正解となります。Amazon Aurora MySQLデータベースはクラスター構成により複数のアベイラビリティゾーンにまたがってボリュームを構成しているため、Amazon RDS MySQLデータベースと比較してアベイラビリティゾーンの障害に対してより強固な構成となっています。

しかしながら、Auroraデータベースは、展開時にマルチAZ配置を有効にすることで、複数のアベイラビリティゾーンにAuroraレプリカを配置することができます。この機能により、プライマリDBが存在するアベイラビリティゾーンに障害が発生した際には、レプリカの一つをプライマリDBとして昇格させることで、ダウンタイムを最小限に抑えつつデータベースの処理を継続することが可能です。

Aurora DBクラスターは、最大15個のAuroraレプリカを配置でき、これらのレプリカはAWSリージョン内のDBクラスターが利用する複数のアベイラビリティゾーンに分散して配置されます。プライマリDBに障害が発生した場合には、任意のAuroraレプリカをプライマリインスタンスに昇格させることができます。

プライマリDBインスタンスに障害が生じると、１つのAuroraレプリカがプライマリに昇格し、フェイルオーバーが行われます。フェイルオーバーにかかる時間は通常60秒未満とされており、要件内の数分程度で問題なく対応可能です。

オプション１と２は不正解です。Amazon Auroraは、Amazon Aurora Global Databaseを活用することで、複数のAWSリージョンにまたがって、複数のAurora DBクラスターを構築することが可能です。Auroraは、プライマリDBクラスターでのすべての変更を1つ以上のセカンダリクラスターに自動的に同期させます。これにより、Aurora DBクラスターは高い冗長性が確保されますが、マルチAZのレプリカ配置と比較するとコスト効率が悪いため、本件ではレプリカを利用する方が最適です。

オプション４は不正解です。Auroraデータベースのバックアップやスナップショットを作成し、別のリージョンで復元することは可能ですが、この復元方法は時間がかかるため、迅速な処理を継続するという要件には適していません。また、Amazon Data Lifecycle ManagerはAuroraに設定することができません。

【Auroraレプリカの詳細情報】

主な役割と特徴

読み取りのスケールアウト（負荷分散）

◦ Aurora レプリカに対してクエリを発行することで、アプリケーションの読み取り作業の負荷を分散させることができます。通常、クラスターの「リーダーエンドポイント」に接続することで、Aurora は読み取り専用接続の負荷をクラスター内の複数のレプリカに分散します。

◦ 1 つの Aurora DB クラスターには、最大で 15 個の Aurora レプリカを含めることができます。

高可用性の確保（フェイルオーバーターゲット）

◦ クラスター内のライター（書き込み用）インスタンスが使用できなくなった場合、Aurora は自動的にレプリカの 1 つを新しいライターとして昇格させます。

◦ レプリカを昇格させるフェイルオーバーは、プライマリインスタンスを再作成するよりも短時間で完了します。高可用性を確保するためには、異なるアベイラビリティーゾーン（AZ）に 1 つ以上の Aurora レプリカを作成することが推奨されます。

共有ストレージによる高速化

◦ Aurora レプリカは、プライマリインスタンスと同じ「クラスターボリューム（ストレージ）」を共有します。データは物理的にコピーされるわけではなく、すべてのインスタンスが単一の論理ボリュームを参照します。

◦ このアーキテクチャにより、通常のデータベースレプリケーションのようにデータをコピーする必要がなく、コストが抑えられます。

◦ プライマリインスタンスが更新を書き込んだ後のレプリカラグ（遅延）は、通常 100 ミリ秒未満と非常に小さく、すべてのレプリカがほぼ同じデータを返すことができます。

従来の RDS リードレプリカとの違い

通常の Amazon RDS のリードレプリカは、ソースインスタンスのスナップショットから作成され、データの変更があるたびに非同期レプリケーションでデータをコピーします。一方、Aurora レプリカは前述の通り、基盤となるストレージレイヤーをソースインスタンスと共有するため、データをレプリカノードにコピーする必要がなく、より高いパフォーマンスと効率性を提供します。

その他のレプリケーションオプション

Aurora レプリカ（同一リージョン内）以外にも、ユースケースに応じて以下のレプリケーションオプションがあります。

• Aurora Global Database: 複数の AWS リージョンにまたがってデータをレプリケートし、地理的な災害対策や、世界規模での読み取り高速化を実現します。

• 従来のレプリケーション: MySQL のバイナリログ (binlog) や PostgreSQL の論理レプリケーション機能を使用して、他のリージョンや環境とレプリケーションを行うことも可能です。

問題16:

あなたはソリューションアーキテクトとしてAmazon DynamoDBテーブルにデータを書き込むためのAWS Lambda関数を作成しました。このLambda関数がDynamoDBテーブルを操作できるように権限を設定する必要があります。

どのように権限を設定すればよいでしょうか。

Lambda関数に適切な権限を付与したIAMユーザーを設定してDynamoDBへのアクセスを許可する。

正解
Lambda関数に適切な権限を付与したIAMロールを設定してDynamoDBへのアクセスを許可する。

Lambda関数に適切な権限を付与したIAMポリシーを設定してDynamoDBへのアクセスを許可する。

回答は不正解です
Lambda関数に適切な権限を付与したリソースポリシーを設定してDynamoDBへのアクセスを許可する。

全体的な説明
オプション２が正解となります。他のAWSリソースと連携するLambda関数を作成する場合、該当リソースへのアクセス権限が設定されたIAMロールをLambda関数に設定して、適切なアクセス権限を付与することが求められます。このIAMロールに与えられたアクセス権限により、Lambda関数が操作可能なAWSリソースの範囲が定まります。

オプション１は不正解です。Lambda関数に関連付けるのはIAMユーザーではなく、IAMロールです。IAMユーザーは特定のユーザーに対してAWSリソースへのアクションを許可するために設定されるエンティティであり、リソースに対する権限を付与する際には使用できません。

オプション３は不正解です。Lambda関数に関連付けるのはIAMポリシーではなく、IAMロールです。IAMポリシーは、IAMユーザーやIAMロールに対する権限の範囲を定義する文書です。この文書を用いることで、権限の詳細な設定が可能となります。しかし、IAMポリシーで定義された権限をリソースに適用するためには、IAMロールが必要です。IAMポリシーは、以下のような形式で許可権限を設定します。

オプション４は不正解です。Lambda関数に設定するのはリソースポリシーではなく、IAMロールです。リソースポリシーはリソース側でアクセス制御をする際に設定するポリシーであり、バケットポリシーが代表的です。

【構成の詳細情報】

Lambda関数からDynamoDBへアクセスするためには、Lambda関数に関連付ける「実行ロール」に適切なIAMポリシーを設定する必要があります。手順と重要なポイントは以下の通りです。

１．IAMコンソールを使用した実行ロールの作成手順

最も一般的な方法は、IAMコンソールを使用して必要な権限（マネージドポリシー）を持つロールを作成することです。

IAMコンソールの「ロール」ページを開き、「ロールの作成」を選択します。
「信頼されたエンティティタイプ」で「AWSのサービス」を選択し、ユースケースとして「Lambda」を選択します。
ポリシーの選択画面で、DynamoDBへのアクセス許可を提供するAWSマネージドポリシーである AWSLambdaDynamoDBExecutionRole を選択します。
ロール名を入力し、ロールを作成します。

ロールの信頼ポリシーの設定

Lambdaが作成したロールを適切に引き受ける（Assume Role）ことができるように、ロールの「信頼ポリシー」には、Lambdaサービスプリンシパル（lambda.amazonaws.com）が信頼できるサービスとして指定されている必要があります。IAMコンソールでLambda用のロールを作成する場合、通常これは自動的に設定されますが、CLIなどで作成する場合は明示的に定義する必要があります。

２．関数へのロールの適用

実行ロールを作成したら、それをLambda関数にアタッチする必要があります。

• 新規作成時: Lambdaコンソールで関数を作成する際、作成済みの実行ロールを選択してアタッチできます。

• 既存の関数: 既存の関数の設定から「実行ロールの更新」を行うことで、新しいロールをアタッチできます。

３．権限の最適化（最小権限の原則）

初期設定ではマネージドポリシーを使用することが便利ですが、本番環境へ公開する前には、必要なアクションのみを許可する「最小権限」の状態にポリシーを調整することが推奨されます。IAM Access Analyzerを使用すると、実際に使用されたアクセス許可に基づいてポリシーテンプレートを生成し、権限をきめ細かく調整することができます。

問題17:

ある企業が、オンプレミス環境にある静的ウェブサイトをAWSに移行することを決定しました。このウェブサイトは、世界中のユーザーにアクセスされるグローバルなサイトであり、迅速に全てのユーザーが利用できることが求められています。また、その際は、コスト効率の良いアーキテクチャであることも要件となっています。

これらの要件を満たすために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

静的ウェブホスティングをS3バケットに構成する。S3バケットを複数のAWSリージョンにレプリケートして、各リージョンに配信する。

正解
静的ウェブホスティングをS3バケットに構成する。Amazon CloudFrontディストリビューションを構成し、S3バケットをオリジンとして設定する。

回答は不正解です
静的ウェブホスティングをS3バケットに構成する。Route53を利用して、各リージョンにルーティングするように構成する。

静的ウェブホスティングをS3バケットに構成する。S3バケットを複数のAWSリージョンにレプリケートして、Route53を利用して、各リージョンにルーティングするように構成する。

全体的な説明
Amazon S3バケットを使用した静的ウェブホスティングを設定することが可能です。S3バケットにおいて静的ウェブホスティング機能を有効にして、Index.htmlを指定することで、そのファイルを簡易的な静的ウェブサイトとして公開できます。

静的ウェブサイトとは、HTML、CSS、JavaScriptで構成され、動的な処理を必要としないシンプルなウェブサイトを指します。ウェブアプリケーションには適していませんが、企業情報を掲載するようなシンプルなコーポレートサイトを作成することができます。

このような静的ウェブサイトはEC2インスタンスを用いて展開することも可能ですが、常時稼働するEC2インスタンスよりも、Amazon S3バケットの静的ウェブホスティングを利用する方が低コストでウェブサイトを運用できます。このシナリオでは、Amazon S3バケットの静的ウェブホスティングを用いた最適なアーキテクチャの設定方法が求められています。

オプション２が正解となります。静的ウェブサイトを迅速に世界中のユーザーに提供するためには、Amazon S3バケットをオリジンサーバーとしてCloudFrontディストリビューションを構成することが最も効果的です。静的ウェブサイトへのインターネットアクセスを許可するために、S3バケットに対して以下のアクセス設定が必要です。

・パブリックアクセスブロックを無効にして、パブリックアクセスが可能なS3バケットとします。

・バケットポリシーが設定されている場合は、インターネットからのs3:GetObjectアクセスを許可します。

このようにして、静的ウェブホスティングが有効化されたS3バケットをCloudFrontディストリビューションのオリジンサーバーとして設定することで、エッジロケーションを通じて静的ウェブサイトのコンテンツを迅速にグローバルに配信することが可能となります。

オプション１は不正解です。S3バケットを複数のAWSリージョンにレプリケートすることで、各リージョンに近いユーザーがそれぞれのバケットにアクセスできるようになりますが、各リージョンに多数の静的ウェブサイトが存在することになり、コスト効率が低下するため、要件に合致しません。

オプション３と４は不正解です。静的ウェブホスティングを設定したS3バケットに対してRoute53を構成し、ドメインを設定することが可能です。しかしながら、グローバルにコンテンツ配信を最適化するためにはCloudFrontを利用することが必要です。

【S3静的ウェブホスティングの詳細情報】

静的ウェブホスティングとは、個々のウェブページの内容が「静的コンテンツ」であるウェブサイトをホストすることを指します。サーバー側でページを動的に生成するのではなく、ストレージに保存されたファイル（HTML、画像、CSSなど）をそのままユーザーに配信する仕組みです。

主な特徴とAWSでの実装方法は以下の通りです。

主な特徴

• コンテンツ: ページの内容は固定ですが、クライアント側（ブラウザ）で実行されるスクリプト（JavaScriptなど）を含めることができ、これにより動的な動作を実現することも可能です。

• S3の機能: Amazon S3の静的ウェブサイトホスティング機能を使用すると、インデックスドキュメント（トップページ）、カスタムエラードキュメント、ウェブページのリダイレクトなどを設定できます。

AWSにおける構成パターン AWSで静的ウェブサイトを公開する場合、主に以下の方法があります。

S3 ウェブサイトエンドポイント（HTTPのみ） S3バケットの「静的ウェブサイトホスティング」機能を有効にして公開する方法です。http://DOC-EXAMPLE-BUCKET.s3-website-region.amazonaws.com のようなエンドポイントが生成されますが、通信はHTTPのみとなります。
CloudFront + S3（推奨・HTTPS対応） S3をオリジンとしてAmazon CloudFrontを使用する方法です。SSL/TLS証明書を使用したHTTPS通信が可能になり、セキュリティとパフォーマンスが向上します。

◦ S3バケットがSSE-KMS（AWS Key Management Service）で暗号化されている場合、S3のウェブサイトエンドポイント機能は使用できないため、CloudFrontとオリジンアクセスコントロール（OAC）を組み合わせて配信する必要があります。

AWS Amplify ホスティング（推奨） AWSでは、S3に保存されている静的コンテンツをホストするために、AWS Amplify ホスティングの使用も推奨しています。これはCloudFrontを利用したフルマネージドサービスで、S3からのデプロイやHTTPS化を簡単に行うことができます。

【Amazon CloudFront ディストリビューションの詳細情報】

Amazon CloudFront ディストリビューション（Distribution）とは、CloudFrontがコンテンツをどのように配信するかを定義する「設定の単位（構成体）」のことです。S3上の静的ウェブサイトを世界中に配信するための「窓口」や「パイプ役」として機能するリソースです。具体的には以下の役割や設定を含みます。

オリジン（情報の取得元）との接続設定

ディストリビューションには、コンテンツの実体が存在する場所（オリジン）を指定します。これまでの文脈であるS3静的ホスティングの場合、以下の2種類のいずれかをオリジンとして設定します。

• S3 REST API エンドポイント: S3バケットそのものを指定する方法。現在推奨されている構成で、バケットを非公開にしたままCloudFront経由でのみアクセスさせることが可能です。

• S3 ウェブサイトエンドポイント: S3の静的ウェブサイトホスティング機能を有効にした際のURL（例: http://...s3-website...）を指定する方法。この場合、S3バケット自体もパブリックアクセスを許可する必要があります。

セキュリティとアクセス制御

ディストリビューションは、オリジン（S3）を保護するための重要なセキュリティ機能を提供します。

• HTTPS (SSL/TLS) の提供: S3のウェブサイトエンドポイント単体ではHTTPしか利用できませんが、CloudFrontディストリビューションを通すことで、HTTPSによる安全な通信が可能になります。

• アクセス制限 (OAC/OAI): オリジンへのアクセスをCloudFront経由のみに制限する設定です。特に「オリジンアクセスコントロール (OAC)」を使用することで、S3バケットを直接公開せずに安全にコンテンツを配信できます。

• KMS暗号化への対応: S3バケットがSSE-KMSで暗号化されている場合、直接のウェブサイト公開はできませんが、OACを設定したCloudFrontディストリビューションを使用することで配信が可能になります。

ドメインとURLの管理

ディストリビューションを作成すると、固有のドメイン名（例: d1234abcd.cloudfront.net）が発行されます。また、独自のドメイン（カスタムドメイン）を使用したい場合は、DNSレコード（CNAME）を設定し、そのドメインをディストリビューションに関連付けることで、ユーザーは独自ドメイン経由でサイトにアクセスできるようになります。

問題18:

ある企業では、AWSを活用した発注管理アプリケーションの設計を行っています。このアプリケーションを通じてユーザーが発注を行うと、12時間以内にその処理が完了する必要があります。発注内容は多様であるため、注文を分類し、適切に管理することも求められています。

費用対効果と運用効率を最大限に高めながら、これらの要件を満たすための最適なソリューションはどれでしょうか。

注文内容に応じて、複数のAmazon Kinesis Data Streamsシャードを作成する。適切なシャードにメッセージを送信するように、Amazon SNSトピックを作成する。データストリームに関連するSNSトピックにサブスクライブするようにアプリケーションを設定する。

注文内容に応じて、複数のAWS Lambda関数とAmazon SNSトピックを作成する。Lambda関数を関連するSNSトピックにサブスクライブして、注文に応じたSNSトピックにメッセージを発行するように設定する。

回答は正解です
Amazon SNSトピックを１つ作成して、このSNSトピックに複数のAmazon SQSキューをサブスクライブする。SNSトピックにフィルターを設定して注文内容に応じて適切なSQSキューに適切なメッセージを送信するようにメッセージをフィルタリングする。注文に応じたSQSキューからメッセージを受信するようにバックエンドサーバーを設定する。

注文内容に応じて、複数のAmazon Kinesis Data Streamsのシャードを作成する。適切なシャードにメッセージを送信するように、ウェブアプリケーションを設定する。アプリケーションサーバーの各バックエンドグループを設定して、Kinesis Client Libraryを使用してそれぞれのデータストリームからのメッセージをプールする。

全体的な説明
このシナリオでは、AWS上の発注アプリケーション開発において、その注文処理が12時間以内に完了されること。注文内容に応じて分類して管理すること。費用対効果と運用効率を最大限にすることが求められています。

オプション３が正解となります。注文内容に応じて処理を分けるには、Amazon SNSとAmazon SQSを活用した並列分散処理を実現し、コスト効果と運用効率を最大化します。

具体的には以下のように構成します。

１．１つのAmazon SNSトピックと、注文の種類に応じた複数のAmazon SQSキューを作成します。

２．このSNSトピックに、複数のAmazon SQSキューをサブスクライブします。これにより、Amazon SNSの注文メッセージに応じてそれぞれのSQSキューで処理を分けることができます。

３．SNSトピックにフィルターを設定することで、注文内容に基づいてメッセージをフィルタリングして、適したSQSキューにメッセージを振り分けます。

Amazon SNSは、サブスクリプションに設定されたフィルターポリシーに従い、メッセージ属性やメッセージ本文に適用されるポリシーに対応します。フィルターポリシーを設定してトピックにメッセージを発行すると、Amazon SNSはメッセージ属性や本文を各サブスクリプションのフィルターポリシー内のプロパティと比較します。一致するプロパティが存在する場合、Amazon SNSはそのメッセージを受信者に送信します。

４．各SQSキューの先では注文に応じて異なる処理をするバックエンドサーバーを設定することで、異なる注文に応じた処理が可能となります。

オプション１と４は不正解です。Amazon Kinesis Data Streamsは、大量のデータをリアルタイムで取り込み、永続的に保存することで、データの消費を可能にします。これはリアルタイムデータ処理に利用される仕組みであって、注文メッセージを処理するフローには不適切な構成となります。

オプション２は不正解です。複数のAWS Lambda関数とAmazon SNSトピックを作成して処理する場合、Amazon SNSとLambda関数の組み合わせを多数管理する必要が生じるため、コスト効率と運用の効率が低下します。

【構成の詳細情報】

Amazon SNS トピックから Amazon SQS キューへメッセージを送信（サブスクライブ）させるには、主に以下の手順が必要です。特に重要なのは、SQS キュー側で SNS からの書き込み権限を許可するという設定です。詳細な手順は以下の通りです。

必要な情報の準備 (ARNの取得)

設定を行うために、まず対象となる「SNS トピック」と「SQS キュー」それぞれの Amazon リソースネーム (ARN) を取得します。

• SQS キューの ARN: SQS コンソールの詳細タブからコピーします。

• SNS トピックの ARN: SNS コンソールの詳細セクションからコピーします。

SQS キューのアクセスポリシー設定（重要）

サブスクリプションを作成する前に、SNS トピックが SQS キューに対してメッセージを送信 (sqs:SendMessage) できるように、SQS 側のアクセスポリシーを編集して権限を付与する必要があります。

SQS コンソールの「アクセスポリシー」タブで以下の条件を含むステートメントを追加します。

• Principal: SNS サービスプリンシパル (sns.amazonaws.com) を指定します。

• Action: sqs:SendMessage を許可します。

• Resource: SQS キューの ARN を指定します。

• Condition: セキュリティ対策（混乱した代理問題の防止）として、aws:SourceArn キーを使用し、特定の SNS トピックの ARN からのリクエストのみを許可するように制限します。

ポリシーの例:

{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:region:account-id:MyQueue",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:region:account-id:MyTopic"
}
}
}
]
}

サブスクリプションの作成

権限設定が完了したら、SNS トピックに対してキューをサブスクライブさせます。これは SNS コンソールから行うのが一般的です。

SNS コンソールで対象のトピックを選択します。
「サブスクリプションの作成」を選択します。
プロトコルで「Amazon SQS」を選択します。
エンドポイントに、先ほど取得した SQS キューの ARN を入力します。
「サブスクリプションの作成」を実行します。

自身の AWS アカウント内のリソース同士であれば、サブスクリプションは自動的に確認され、即座にアクティブになります。

補足：メッセージのフィルタリング

特定の条件（属性など）に合致するメッセージのみをキューに送信したい場合は、サブスクリプション作成時または作成後に「フィルターポリシー」を設定することで、受信するメッセージを制御できます。

問題19:

ある企業は、社内のストレージをAWSにホストすることを検討しています。このストレージは、オンプレミスのアプリケーションサーバーにiSCSIデバイスを介して接続される必要があります。さらに、移行後はAWS上のストレージをプライマリーストレージとして使用する方針です。

この要件を満たすための適切な設定方法はどれでしょうか。

S3バケットを作成して、S3コネクターをiSCSIデバイスとして利用する。

回答は不正解です
EBSを作成して、EBSコネクターをiSCSIデバイスとして利用する。

Glacierを作成して、GlacierコネクターをiSCSIデバイスとして利用する。

正解
AWS Storage GatewayをISCSIデバイスとして利用する。

全体的な説明
このシナリオでは、Amazon S3バケットをオンプレミスのアプリケーションサーバーにiSCSIデバイスを通じて接続することが求められています。そのためにはAWS Storage Gatewayを利用することが基本です。AWS Storage Gatewayは、Amazon S3バケットとオンプレミスのストレージを接続し、バックアップの取得やストレージ容量の拡張を可能にするハイブリッドストレージの構成機能を提供します。

オプション４が正解となります。AWS Storage GatewayをiSCSIデバイスとして使用することで、オンプレミスのストレージをAmazon S3バケットに接続できます。この際、ストレージゲートウェイのキャッシュ型ボリュームを利用することで、頻繁にアクセスされるデータをローカルに保持しつつ、Amazon S3を主要なデータストレージとして活用できます。ローカル環境でキャッシュされたボリュームは、頻繁にアクセスされるデータに対して低レイテンシーでのアクセスを提供します。キャッシュ型ボリュームでは、最大32TiBのストレージボリュームを作成し、iSCSIデバイスを介してオンプレミスのストレージに接続することが可能です。

AWS Storage Gateway のiSCSI イニシエータは iSCSI ターゲットとしてボリュームに接続します。 Storage Gateway は、チャレンジハンドシェイク認証プロトコル (CHAP) によってiSCSI とイニシエータの接続を認証します。

オプション１と２と３は不正解です。これらのサービスはAWS Storage Gatewayとは異なり、ISCSIデバイスによってオンプレミス側と接続する機能はありません。

【iSCSI イニシエータの詳細情報】

１．iSCSI イニシエータとは、iSCSI ネットワークにおけるクライアントコンポーネントのことです。

主な役割と特徴は以下の通りです。

• 機能: iSCSI ネットワーク上のサーバーコンポーネントである「iSCSI ターゲット」（AWS Storage Gateway においてはボリュームや VTL デバイスがこれに該当します）に対して、接続やデータのリクエストを送信します。

• 実装形態: ソフトウェアまたはハードウェアで実装することが可能ですが、AWS Storage Gateway ではソフトウェアイニシエータのみがサポートされています。

代表的なソフトウェアイニシエータとして以下の2つが挙げられています。

Microsoft iSCSI イニシエータ: Windows オペレーティングシステムに組み込まれているソフトウェアプログラムで、Windows クライアントをゲートウェイに接続するために使用されます。
Red Hat iSCSI イニシエータ: Red Hat Linux 用に iscsi-initiator-utils パッケージとして提供されているもので、iSCSI プロトコル用のサーバーデーモンが含まれています。

２．AWS Storage Gatewayの「ボリュームゲートウェイ」機能を使用し、オンプレミス環境からiSCSIブロックストレージとしてAmazon S3に接続・データを保存できます。これにより、既存のアプリやOS（Windows/Linux）から直接S3をローカルディスクのように扱えます。

主な特徴とメリット

iSCSI接続: ゲートウェイが仮想マシンとしてオンプレミスに設置され、iSCSIイニシエータを使用してS3上のボリュームをローカルにマウント可能。

用途: 主にバックアップ、災害復旧（DR）、高速アクセスが必要なデータの一時保存。

ストレージタイプ:

キャッシュ型: データはS3に保存し、頻繁にアクセスするデータのみをローカルにキャッシュして高速化。

保管型: すべてのデータをローカルに保存し、バックアップをS3へ非同期に保存。

この機能により、既存のバックアップワークフローを変更せずに、事実上無制限のクラウドストレージへ移行できます。

問題20:

ある企業では、EC2インスタンス上でバッチ処理ワークロードを運用しています。このワークロードは複数のAmazon EC2インスタンスを活用しており、ステートレスな特性を持っています。そのため、インスタンス処理を途中で停止したり再開したりすることが容易です。全体の処理時間は約1時間を要します。あなたはソリューションアーキテクトとして、コストの最適化を求められています。

コスト最適化を実現するために、ソリューションアーキテクトはどのインスタンスタイプを選択すべきでしょうか。

正解
スポットインスタンスを利用する。

リザーブドインスタンスを利用する。

オンデマンドインスタンスを利用する。

回答は不正解です
ベアメタルインスタンスを利用する。

全体的な説明
このシナリオでは、要件に基づいて最適なインスタンスの購入方法を選定する必要があります。AWSでは、以下のように複数の購入オプションからインスタンスを選ぶことが可能です。各購入オプションは利用期間や割引率が異なるため、提示された要件に適した方法を選ぶことが重要です。

オプション１が正解となります。このシナリオにおいて必要とされるインスタンス処理は、ステートレスであり、途中での停止や再開が可能で、完了までに約1時間程度の短時間で行われます。このような短時間で中断可能なワークロード処理には、スポットインスタンスを利用することが適しています。

スポットインスタンスは、AWSが管理する未使用のEC2インスタンスリソースをユーザーに提供することで、オンデマンド価格よりも低価格で利用できるインスタンスの購入方法です。最大で90％の割引が適用されるため、Amazon EC2のコストを大幅に削減することが可能です。ただし、スポットインスタンスはAWSから一時的に借りているため、突然停止するリスクがありますが、今回のケースでは中断が許容される処理となっています。

オプション２は不正解です。リザーブドインスタンスは、EC2インスタンスを「1年間」または「3年間」といった期間を事前予約することにより、通常のEC2インスタンスを利用するよりも低コストでインスタンスを使用できる購入方法です。しかし、今回の処理が約1時間程度であるため、リザーブドインスタンスを購入すると逆にコストが高くなってしまいます。

オプション３は不正解です。オンデマンドインスタンスは、従量課金で使用時間に応じて定められた料金を支払う一般的なインスタンス利用形態であり、コスト最適化にはつながりません。

オプション４も不正解です。Amazon EC2ベアメタルインスタンスでは、ユーザーは基盤となるサーバーのIntel® Xeon® スケーラブルプロセッサおよびメモリリソースに直接アクセスできます。このインスタンスタイプは、物理インフラの操作をクラウド上で行う特別な要件に対応しているため、物理インフラを占有することになり、通常のインスタンスよりも高額になります。

問題21:

ある会社は、AWSマーケティングプレイスから提供されているサードパーティ製のWEBアプリケーションの利用を検討しています。このアプリケーションを活用するためには、同社のAWSアカウント内で稼働しているEC2インスタンスへのAPI経由のアクセスが必要です。そのため、EC2インスタンスベースのサードパーティのWEBアプリケーションが同社のAWSアカウントのEC2インスタンスと連携できるようなアクセス設定が必要です。同社のセキュリティポリシーに基づき、WEBアプリケーションのアクセス権限は、その業者のみが利用できるように制限する必要があります。したがって、第三者による不正利用を防ぐために、適切な権限の付与が求められます。

これらの要件をすべて満たすソリューションはどれでしょうか。

正解
サードパーティ製のWEBアプリケーションが必要とする権限のみに限定したIAMポリシーを設定したクロスアカウントアクセス用のIAMロールを作成する。そのIAMロールを外部WEBアプリケーションに設定する。

回答は不正解です
サードパーティ製のWEBアプリケーションのAPIへのアクセス権限を有したIAMロールをEC2インスタンスに割り当てて、EC2インスタンスと外部WEBアプリケーションを連携する。

サードパーティ製のWEBアプリケーションが必要とする権限のみに限定したIAMロールをAPI Gatewayに設定して、API経由でEC2インスタンスと外部WEBアプリケーションを連携する。

サードパーティ製のWEBアプリケーションが必要とする権限のみに限定したIAMユーザーを設定して、ベンターに提供する。そのIAMユーザーに対してAWS Organizationsによるクロスアカウント連携を実施する。

全体的な説明
このシナリオでは、ある会社のAWSアカウントにあるEC2インスタンスとサードパーティのWebアプリケーションとの連携を実現するためのアクセス権限設定が求められています。具体的には、クロスアカウントアクセスを通じてサードパーティ製のWEBアプリケーションに必要な権限を委譲します。

オプション１が正解となります。サードパーティ製のWEBアプリケーションに必要なアクセス権限を付与するIAMポリシーを設定して、IAMロールに付与します。そして、このIAMロールをサードパーティ製のWEBアプリケーションに適用します。これにより、第三者に対する資格情報の漏洩を防ぎつつ、IAMロールの管理を通じて、サードパーティーアプリケーションのアクセス権限を制御できるようになります。

異なるAWSアカウントに存在するリソースにアクセスを委任するために、クロスアカウントアクセス許可とIAMロールを設定します。これにより、特定のアカウント内の特定のリソースを他のアカウントのユーザーと共有することが可能になります。クロスアカウントアクセスを設定することで、各アカウントごとにIAMユーザーを作成する必要がなくなります。

オプション２は不正解です。サードパーティ製のWEBアプリケーションに対してアクセス権限を付与する必要があるため、逆の権限設定となってしまっています。アクセスされる側のEC2インスタンスにはIAMロールによる権限移譲は必要ありません。

オプション３は不正解です。API Gateway APIを通じてWEBアプリケーションがEC2インスタンスと連携する場合、IAMロールなどの権限を持たない外部システムやユーザーからもAPI GatewayへのAPIリクエストは実行可能です。

オプション４も不正解です。AWSリソース間の権限付与となるため、外部WEBアプリケーションが必要とする権限のみに限定したIAMユーザーをベンターに提供するのではなく、WEBアプリケーションが利用するリソースに対してIAMロールを設定することが必要です。また、AWS Organizationsは、複数のAWSアカウントの利用可能な権限範囲を管理するためのツールであり、外部へのアクセス権限移譲を実施する機能は有していません。

【構成の詳細情報】

IAMロールをサードパーティに適用（信頼関係を設定）することで、資格情報の漏洩リスクを防ぎつつ、IAMロールの管理を通じてアクセス権限を適切に制御することができます。

仕組みと重要なセキュリティ対策について解説します。

IAMロールによるアクセス委任の仕組み

この構成は「クロスアカウントアクセス」または「アクセスの委任」と呼ばれます。

• 長期的な認証情報の排除: IAMユーザーの長期的な認証情報を使用するのではなく、IAMロールを使用して一時的な認証情報を発行することが推奨されています。これにより、万が一の漏洩リスクを低減できます。

• 信頼関係の構築: お客様のAWSアカウント（ターゲットアカウント）にIAMロールを作成し、信頼ポリシー（Trust Policy）でサードパーティのAWSアカウント（ソースアカウント）を「信頼されたエンティティ」として指定します。

• 権限の制御: 作成したIAMロールに対して、必要なアクション（例: S3バケットへの読み書きなど）のみを許可するIAMポリシーを付与することで、サードパーティが実行できる操作を厳密に制御できます。

アクセスの流れ

サードパーティのアプリケーションは、以下の手順で権限を行使します。

AssumeRole: サードパーティは、AWS CLIやAPIを使用して sts:AssumeRole を呼び出し、お客様が作成したIAMロールを引き受けます,。
一時的な認証情報の取得: AssumeRole の応答として、アクセスキー、シークレットキー、セッショントークンを含む「一時的なセキュリティ認証情報」が発行されます。
リソースへのアクセス: サードパーティは、この一時的な認証情報を使用して、許可された範囲内でリソース（S3など）への操作を行います。
第三者利用における重要なセキュリティ対策（ExternalId）

サードパーティへアクセス権限を付与する場合、セキュリティ上の理由から ExternalId（外部ID）の使用が強く推奨されます。

• なりすましの防止: 第三者が所有するAWSアカウントへのアクセスを許可する場合、アクセス許可ポリシーの Condition 要素で ExternalId を要求する必要があります。

• 混乱した代理問題の対策: これは「混乱した代理（confused deputy）」問題を防ぐためのもので、サードパーティが他人のリソースへ不正にアクセスしようとする試みをブロックする役割を果たします。

問題22:

ある企業は、静的コンテンツをAmazon S3バケットに保存するWebアプリケーションを開発しています。このアプリケーションの非機能要件として、S3バケットは1秒間に3500件を超えるPUTリクエストを迅速に処理するパフォーマンスを有している必要があります。

最適なパフォーマンスを確保するためには、どのような対策を講じるべきでしょうか。

オブジェクトキー名にランダムPrefixを利用する。

正解
オブジェクトキー名に日付などのPrefixを利用する。

回答は不正解です
マルチパートアップロードを利用する。

S3のライフサイクル管理を有効化する。

全体的な説明
バージョニングされたAmazon S3バケットは、プレフィックスを活用してファイル日付に基づいてアップロードを分散させることで、毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。バケット内のプレフィックスの数に制限はありません。

さらに並列化を使用することによって、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化すると、読み取りパフォーマンスを 1 秒あたり 55,000 回の読み取りリクエストにスケールできます。

プレフィックスとは、ファイル構成を分割するために単語の先頭に接頭語を追加する方法です。例えば、画像データには「image」というプレフィックスを付けて、他のドキュメントと区別することが可能です。また、日付をプレフィックスとして「20230405~」のように設定することで、ドキュメントを効果的に管理できます。このように、ファイル名の前に日付を設定することは、一般的なファイル構成管理の手法と考えられます。

オプション１は不正解です。以前は、Amazon S3バケットのパフォーマンスを向上せるには、日付などのプレフィックスではなく、オブジェクトキー名にランダムプレフィックスを使用することが必要でしたが、S3のリクエストレート処理のパフォーマンスが向上したことにより、オブジェクトプレフィックスをランダム化する必要はなくなりました。

オプション３は不正解です。マルチパートアップロードは、S3に大きなファイルをアップロードする際に使用される機能であり、今回の要件には適していません。

オプション４も不正解です。S3のライフサイクル管理は、一定の期間が経過した後にオブジェクトの保存先を移動したり、削除したりする機能です。S3バケットの処理性能の向上には関連していません。

【詳細情報】

S3バケットで1秒間に3,500件を超えるPUTリクエストを処理するには、リクエストを並列化し、複数の「プレフィックス」に分散して書き込みを行う必要があります。

具体的な方法は以下の通りです。

プレフィックスによる分散（パーティショニング） Amazon S3のリクエストレート制限は、バケット全体ではなく、プレフィックス（オブジェクトキー名の先頭部分）ごとに適用されます。現在の仕様では、パーティショニングされたAmazon S3プレフィックスごとに、以下のパフォーマンスが期待できます。

• PUT/COPY/POST/DELETE: 毎秒 3,500 リクエスト以上

• GET/HEAD: 毎秒 5,500 リクエスト以上

したがって、3,500件/秒を超える書き込みを行いたい場合は、単一のプレフィックス（フォルダのような階層）に集中させるのではなく、複数のプレフィックス（例: /date/users/A, /date/users/B など）を使用するように設計します。バケット内のプレフィックスの数に制限はありません。

処理の並列化アプリケーション側で書き込み処理を並列化し、異なるプレフィックスに対して同時にアクセスすることで、スループットを集約できます。例えば、10個の異なるプレフィックスに対して書き込みを分散させれば、理論上は1秒あたり数万件単位の書き込みリクエストにスケールさせることが可能です。

重要な注意点：スケーリングと503エラー Amazon S3は高いリクエストレートに合わせて自動的にスケールしますが、このスケーリングは瞬時ではなく徐々に行われます。そのため、急激にリクエストレートが上昇し、S3が新しいレートに合わせて内部的にスケーリングを行っている間は、503 (Slow Down) エラーが返される場合があります。このエラーが発生した場合に備え、アプリケーション側にはエクスポネンシャルバックオフ（指数関数的バックオフ）などを用いた再試行（リトライ）ロジックを実装することが推奨されます。スケーリングが完了すれば、これらのエラーは解消されます。

問題23:

ある企業が自社の文書管理システムとしてAmazon S3バケットを導入しようとしています。初期段階では、保存される文書が頻繁に利用される可能性がありますが、4か月後にはその利用頻度が大幅に減少し、ほとんどアクセスされなくなる見込みです。したがって、これらの文書をアーカイブする必要があります。その際、コストを最適化することが求められます。

この要件を満たすためには、どのようなS3バケット設定が必要でしょうか。

S3 Standard IAにデータを蓄積して、4カ月後にGlacier Instant Retrievalに移行するライフサイクルルールを設定する。

正解
S3 Standardにデータを蓄積して、4カ月後にGlacier Deep Archiveに移行するライフサイクルルールを設定する。

S3 Standardにデータを蓄積して、4カ月後にGlacier Instant Retrievalに移行するライフサイクルルールを設定する。

回答は不正解です
S3 Standard IAにデータを蓄積して、4カ月後にGlacier Deep Archiveに移行するライフサイクルルールを設定する。

全体的な説明
このシナリオでは、S3バケットの最適なストレージクラスの選定方法とライフサイクルルール設定について問われています。この種の質問は、01版の試験形式において一般的なものであり、出題された場合には確実に正解するべき基本的な問題です。要件に基づき、Glacierを含むAmazon S3の最適なストレージタイプを選定する知識が必要とされます。今回の要件は、「会社が保存する文書は初期段階では頻繁に使用される可能性がある。」「4か月後には利用頻度が大幅に減少し、ほとんどアクセスされなくなるためアーカイブする。」「その際には、できる限りコストを最適化する」という3つのポイントを押さえる必要があります。

オプション２が正解となります。文書管理システムのデータをS3バケットのStandardストレージクラスに保存し、4カ月後にGlacier Deep Archiveに移行するライフサイクルルールを設定することで、要件を満たすことが可能です。S3バケットにデータが保存された直後は、このデータは頻繁にアクセスされるため、アクセスしやすいS3 Standardストレージクラスを使用します。

4カ月後にはデータアクセスがほとんどなくなるため、最もコスト効率の良いアーカイブ用ストレージであるGlacier Deep Archiveにデータを移動することで、コスト最適化を図ることができます。

S3ライフサイクル設定とはAmazon S3 がオブジェクトに適用するアクションを定義するルールのセットです。ここでライフサイクルルールを設定することで、S3バケットに保存されたオブジェクトがライフサイクルを通じてコスト効率よく保存されるように管理することができます。

オプション１と４は不正解です。S3 Standard IAはアクセス頻度が低いデータをStandardクラスよりも安い価格で保存できるストレージクラスです。今回はデータ保存後の4か月間はアクセス頻度が高いため、 S3 Standard IAクラスを利用するのは適切ではありません。

オプション３は不正解です。Amazon S3 Glacier Instant Retrievalは、滅多にアクセスされないアーカイブ用データに対して即時にアクセス可能な特殊なストレージです。これはアーカイブされていたとしても、アクセス時には迅速なアクセスが必要な医療データなどに利用します。Glacier Deep Archiveよりも価格が高くなるため、コスト最適ではありません。

【S3 ライフサイクル設定の詳細情報】

S3 ライフサイクル設定とは、Amazon S3 バケット内のオブジェクトをコスト効率よく管理するために、Amazon S3 がオブジェクトのグループに対して適用する「一連のルール（規則）」のことです。主な機能と役割を解説します。

主な目的とアクション

ライフサイクル設定を使用する主な目的は、ストレージコストの削減とデータ管理の自動化です。以下の2種類のアクションを定義できます。

• 移行アクション (Transition actions): オブジェクトを、より低コストなストレージクラス（S3 Standard-IA、S3 Glacier Flexible Retrieval など）へ自動的に移動させます。

◦ 例: 作成から30日後に S3 Standard-IA へ、1年後に S3 Glacier へアーカイブする。

• 有効期限切れアクション (Expiration actions): オブジェクトの有効期限を定義し、Amazon S3 に自動的に削除させます。

◦ 例: ログファイルを1週間後に削除する、あるいは保存義務期間が過ぎた文書を削除する。

ルールの適用範囲（フィルター）

ライフサイクルルールは、バケット全体に適用することも、特定のオブジェクトのみに絞り込んで適用することも可能です。

• プレフィックス (Prefix): オブジェクトキー名の先頭文字列（フォルダのような階層）を指定して適用します（例: logs/ や tax/ など）。

• タグ (Tag): 特定のオブジェクトタグが付与されたオブジェクトにのみ適用します。

• オブジェクトサイズ: オブジェクトのサイズ（最小または最大バイト数）に基づいて適用対象をフィルタリングできます。

• AND条件: プレフィックス、タグ、サイズなどの条件を組み合わせて対象を絞り込むことができます。

具体的なユースケースと機能

• バージョニングされたバケットの管理: S3 バージョニングが有効なバケットでは、「現在のバージョン (Current version)」と「最新ではないバージョン (Noncurrent version)」を区別してルールを設定できます。

◦ 非現行バージョンの移行・削除: 新しいバージョンで上書きされ、古くなったバージョンだけを Glacier に送ったり、削除したりすることでコストを節約できます。

◦ 期限切れ削除マーカーのクリーンアップ: データの実体がない「削除マーカー」だけが残っている場合、これを削除するルールを設定できます。

• 不完全なマルチパートアップロードの停止: 大容量ファイルのアップロード（マルチパートアップロード）が完了せずに中断された場合、その断片データ（パート）がストレージに残って課金されることがあります。ライフサイクル設定で「開始からX日後に停止」するよう設定することで、不完全なデータを自動削除できます。

重要な考慮事項

• コスト: ライフサイクルによる移行リクエスト自体に料金が発生する場合があるため、頻繁な移動には注意が必要です。

• ルールの優先順位: 同じオブジェクトに対して複数のルールが重複して適用される場合、「完全な削除は移行より優先される」などの一般的なルールに従って処理されます。

• 反映タイミング: 新しいルールを追加すると、既存のオブジェクトと新規オブジェクトの両方に適用されます。また、ルールを一時的に無効化（Disabled）してテストすることも可能です。

• 小さいオブジェクトの制限: 以前は128KB未満のオブジェクトは特定のストレージクラスへの移行が制限されていましたが、2024年9月以降のデフォルト動作ではこの挙動が変更されており、設定により移行を許可または回避できます。

問題24:

ある企業は、AWS上でホストされている一連のアプリケーションの運用を行っています。この企業では、アプリケーション間の連携を実現するためにAmazon API Gatewayを導入することに決定しました。そのため、Amazon API Gateway API に対する権限管理を行い、API呼び出し時にAPIコール元に対して適切なアクセス権限を設定する必要があります。

この要件を満たすためのAPI Gatewayの最も適切な設定方法はどれでしょうか。

回答は不正解です
AWS STSを利用して、API コールの呼び出し元に対して権限を付与する。

正解
IAMポリシーを利用して、API コールの呼び出し元に対して権限を付与する。

AWS Configを利用して、API コールの呼び出し元に対して権限を付与する。

IAMアクセスキーを利用して、API コールの呼び出し元に対して権限を付与する。

全体的な説明
このシナリオでは、開発者、IT管理者、ユーザーそれぞれに適したAPIへのアクセス権を付与する必要があり、そのためのAPI Gatewayが管理するAPIに対する権限設定方法が問われています。APIは「Application Programming Interface」の略称であり、アプリケーションやそのデータにアクセスするための入り口となる機能です。したがって、APIへのアクセスを許可することにより、アプリケーションの特定の機能やデータへのアクセスが可能となります。AWSでは、Amazon API Gatewayというサービスを使用して、APIの作成と管理を行うことができます。

オプション２が正解となります。Amazon API Gatewayは、APIへのアクセスをIAM権限によって管理することが可能です。APIの呼び出しやキャッシュの更新を許可するためには、IAMポリシーを作成し、それをユーザー、グループ、またはロールにアタッチして権限を与える必要があります。

オプション１は不正解です。STSはユーザーに一時的な認証を提供する機能であり、API GatewayのAPIに対する中長期的なアクセス権限を付与するには適していません。

オプション３は不正解です。AWS Configはアクセス権限を付与する機能を持っていません。AWS Configは、AWSリソースの変更を管理するための構成管理ツールであり、設定内容や相互の関連性、時間の経過に伴う設定の変化など、AWSアカウントに関連するリソースの詳細情報を提供します。

オプション４は不正解です。Amazon API GatewayのAPIへのアクセス権限設定には、IAMアクセスキーではなく、IAMユーザーやIAMロールを利用します。IAMアクセスキーはAWSユーザーのプログラム認証に使用される認証方式であり、CLIツールなどを利用する際に設定されます。

【Amazon API Gatewayの詳細情報】

主な役割と特徴は以下の通りです。

アプリケーションの「フロントドア（玄関口）」

API Gateway は、アプリケーションがバックエンドサービス（AWS Lambda、Amazon EC2、その他のウェブアプリケーションなど）にあるデータやビジネスロジックにアクセスするための入り口として機能します。開発者はバックエンドの複雑なインフラを意識することなく、API を通じて機能を利用できるようになります。

サポートする API の種類

API Gateway は、用途に合わせて以下の種類の API を作成できます。

• REST API および HTTP API:

◦ 標準的な HTTP メソッド（GET、POST、PUT、DELETE など）を使用します。

◦ ステートレス（状態を保持しない）なクライアント/サーバー通信を可能にします。

• WebSocket API:

◦ クライアントとサーバー間のステートフル（状態を保持する）な全二重通信を実現します。

◦ チャットアプリやリアルタイムダッシュボードなど、双方向のやり取りが必要なアプリケーションに適しています。

主な機能とメリット

• トラフィック管理とスケーラビリティ: 最大で数十万個の同時 API コールの受け入れ処理が可能で、トラフィック管理やスロットリング（流量制限）を自動的に処理します。

• セキュリティと認証: IAM 権限による管理に加え、Amazon Cognito ユーザープールや Lambda オーソライザーを使用した強力で柔軟な認証メカニズムを提供します。また、AWS WAF（ウェブアプリケーションファイアウォール）と統合して、一般的なウェブの脆弱性から API を保護できます。

• モニタリングと可観測性: Amazon CloudWatch と統合されており、API の実行ログやメトリクスを記録・監視できます。また、AWS X-Ray と統合することで、パフォーマンスのレイテンシー（遅延）を分析し、ボトルネックを特定することができます。

• バージョニングとデプロイ: API のバージョン管理をサポートしており、「Canary リリース（カナリアリリース）」機能を使用して、変更を段階的かつ安全にデプロイすることが可能です。

サーバーレスアーキテクチャとの連携

API Gateway は AWS サーバーレスインフラストラクチャの重要な一部です。AWS Lambda と組み合わせることで、サーバーの管理をすることなく、可用性の高いウェブ API を構築・実行することができます。

【Amazon API Gateway のAPI権限に関する詳細情報】

Amazon API Gateway で API へのアクセスを IAM 権限によって管理するには、API Gateway 側での「IAM 認証の有効化」と、呼び出し元（クライアント）への「IAM ポリシーの付与」という2つの設定が必要です。

具体的な手順と仕組みを解説します。

API Gateway 側での設定（IAM 認証の有効化）

まず、API Gateway のメソッドに対して、IAM 認証を使用するように設定を変更します。

メソッドの選択: API Gateway コンソールで対象の API を開き、IAM 認証を有効にしたいメソッド（GET、POST など）を選択します。
認証設定の変更: 「メソッドリクエスト」を選択し、設定内の「認可 (Authorization)」の項目を編集して、ドロップダウンリストから AWS_IAM を選択し保存します。
デプロイ: 設定変更を反映させるために、API をデプロイします。
呼び出し元への権限付与（IAM ポリシーの設定）

API を呼び出すユーザー（IAM ユーザー、グループ、またはロール）に対して、その API を実行するための権限を付与する必要があります。

IAM ポリシーの作成: API 実行のアクセス許可を定義した IAM ポリシーを作成します。ポリシーの Action 要素で許可する操作を指定し、Resource 要素で対象の API の ARN を指定します。
ポリシーのアタッチ: 作成したポリシーを、API を呼び出す IAM ユーザー、グループ、またはロールにアタッチします。

また、これとは別に API Gateway リソースポリシーを使用することも可能です。これは API 側に直接アタッチするポリシーで、特定の IAM プリンシパルからのアクセスを許可したり、特定の IP アドレスからのアクセスを制限したりする場合に使用されます。

クライアントからの呼び出し（署名プロセス）

IAM 認証が有効化された API にリクエストを送信する際、クライアントはリクエストに対して署名 (Signature Version 4) を行う必要があります。

• 署名の必要性: 単なる HTTP リクエストでは「認証トークンが見つかりません」というエラー (403 Forbidden) が返されます。アクセスキー ID とシークレットアクセスキーを使用してリクエストに署名することで、IAM 認証を通過できます。

• ツールの利用: Postman などのツールを使用する場合、「Authorization」タブでタイプとして「AWS Signature」を選択し、IAM ユーザーの認証情報を入力することで、簡単にテストを行うことができます。

補足：権限の競合について

IAM ポリシー（アイデンティティベース）と API Gateway リソースポリシー（リソースベース）の両方を使用する場合、どちらか一方で「拒否 (Deny)」が設定されていると、アクセスは拒否されます。

問題25:

ある企業がAWSを活用してアプリケーションを開発しています。このアプリケーションのデータレイヤーには、Amazon DynamoDBテーブルを使用する予定です。データ処理は午前中はほとんど行われませんが、午後からは増加し、夕方には予測できない読み書きのトラフィックが発生する可能性があります。その際、短時間でトラフィックの急増が起こることも考えられます。

コストを最適化しつつ要件を満たすために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

オンデマンドモードのDynamoDBテーブルを作成する。さらに、このテーブルをグローバルテーブルとして設定する。

正解
オンデマンドモードのDynamoDBテーブルを作成する。

プロビジョンドスループットモードのDynamoDBテーブルを作成する。さらに、このテーブルのオートスケーリングを有効化する。

回答は不正解です
プロビジョンドスループットモードのDynamoDBテーブルを作成する。さらに、このテーブルをグローバルテーブルとして設定する。

全体的な説明
このシナリオでは、要件に基づいて適切なDynamoDBテーブルのキャパシティモードを選択する方法について問われています。DynamoDBテーブルは、利用負荷が予測可能な場合と予測不可能な場合に応じて、オンデマンドモードとプロビジョニングモードの2種類のキャパシティモードから選択することができます。それぞれのモードの特徴は以下の通りです。

オプション２が正解となります。このシナリオでは、DynamoDBテーブルのデータ処理能力が大きく変動するため、その予測が非常に困難です。予測不可能な負荷に対しては、オンデマンドモードのDynamoDBテーブルを作成し、必要に応じてキャパシティを自動的に調整できるようにします。

DynamoDBテーブルの利用負荷が予測可能な場合は、プロビジョンドスループットモードを選択します。一方で、予測が難しい場合にはオンデマンドモードを設定することが推奨されます。

オプション１は不正解です。オンデマンドモードのDynamoDBテーブルを作成することで、DynamoDBは過去のトラフィックレベルに応じて自動的に拡張または縮小し、ワークロードの処理能力を調整します。グローバルテーブルは、複数の地域にわたってテーブルを作成し、データをレプリケートする機能を提供します。この機能は、データの冗長性を確保し、異なるリージョンでのデータアクセスの速度を向上させるために使用されるため、本件には必要ありません。

オプション３と４は不正解です。利用負荷があらかじめ予測できる場合に、プロビジョンドスループットモードを選択します。

【DynamoDB テーブルのキャパシティモードの詳細情報】

DynamoDB テーブルのキャパシティモードとは、テーブルの読み込みおよび書き込みスループット（処理能力）をどのように管理し、課金するかを決定する設定のことです。

ワークロードの要件に応じて、以下の2つのモードから選択できます。

オンデマンドモード (On-Demand Mode)

データベース管理を簡素化するサーバーレスのスループットオプションです。

• 特徴: キャパシティプランニングやスケーリングポリシーの設定が不要です。アプリケーションのトラフィックに合わせて、DynamoDB が自動的にスループットをスケールさせます。

• 課金体系: 実際に実行した読み込みおよび書き込みリクエスト数に基づく従量課金制です。使用した分だけ支払うため、事前にスループットを指定する必要はありません。

• 推奨されるケース: ほとんどの DynamoDB ワークロードで推奨されるデフォルトのオプションであり、トラフィックの予測が難しい場合や、管理の手間を省きたい場合に適しています。

プロビジョニングモード (Provisioned Mode)

アプリケーションに必要な1秒あたりの読み込み回数と書き込み回数を、ユーザーが事前に指定するモードです。

• 特徴: 定義されたリクエストレート（スループット）を維持するように DynamoDB を制御します。

• 課金体系: 実際に消費した量ではなく、プロビジョニング（確保）した時間単位のキャパシティ量に基づいて課金されます。

• 推奨されるケース: トラフィックの増加が安定的で予測可能である場合や、コストの予測可能性（毎月の支払額の固定化など）を重視する場合に適しています。

問題26:

ある企業は、単一リージョン内の2つのアベイラビリティゾーン（AZ）に配置されたAmazon EC2インスタンスに対してALBおよびAuto Scalingが設定されたWebアプリケーションを運営しています。運用要件として、1つのAZがダウンし、かつAuto Scalingが残るAZで新たなインスタンスを起動できていない期間においても、アプリケーションが常に100％のピークロードが処理できるパフォーマンスを維持する必要があります。

この要件を満たすために必要なアーキテクチャの構成はどれでしょうか。

回答は正解です
3つのAZに対して、AZ毎に50％のピークロードを処理できるAuto Scaling設定を行ったEC2インスタンスを展開する。

3つのAZに対して、AZ毎に30％のピークロードを処理できるAuto Scaling設定を行ったEC2インスタンスを展開する。

２つのAZに対して、リージョン毎に50％のピークロードを処理できるAuto Scaling設定を行ったEC2インスタンスを展開する。

２つのAZに対して、AZ毎に50％のピークロードを処理できるAuto Scaling設定を行ったEC2インスタンスを展開する。

全体的な説明
このシナリオでは、1つのアベイラビリティゾーン（AZ）がダウンしてもアプリケーションが一定の処理能力を維持することが求められています。具体的には、AZが1つ停止した直後でも、Auto Scalingが実行される前の段階において、100％の可用性を確保する必要があります。つまり、1つのAZが利用できなくなった場合でも、EC2インスタンスがピークロードを100％処理できるパフォーマンス構成を選択することが求められます。

オプション１が正解となります。Auto Scalingグループによって新たにインスタンスが起動される際には、ソフトウェアのセットアップなど、サーバーの準備に時間がかかります。そのため、通常はAuto Scalingが実行されてから、実際に負荷が軽減されるまでに数分から数十分のタイムラグが生じます。このため、1つのAZが利用できなくなり、Auto Scalingが残りのAZに新しいインスタンスを起動できない期間においても100％の可用性を維持するためには、残りのAZ内で十分なEC2インスタンス数を展開することが必要です。今回のケースでは、3つのAZごとに50％のピークロードを処理できるようにEC2インスタンスを展開すれば、1つのAZが停止しても100％の可用性を維持することが可能です。

オプション２は不正解です。このAZの配置では、1つのAZがダウンした際の可用性が100％ではなく60％となるため、適切ではありません。100％のピークロードを維持するためには、1つのAZが失われても、残りのEC2インスタンスだけで処理能力が100％を超えるような構成が必要です。

オプション３と４は不正解です。この２つの構成では、１つのAZがダウンした場合に、残った2つのAZでは100％の可用性を達成できません。

【構成の詳細情報】

ご質問のシナリオ（1つのAZがダウンし、Auto Scalingによる復旧が間に合っていない期間中も、100%のピークロード処理能力を維持する）に対応するための唯一の解決策は、アーキテクチャ設計において**「静的安定性 (Static Stability)」**という考え方を採用することです。

具体的には、障害発生後にリソースを追加する（スケーリングする）のではなく、障害が発生しても残りのAZだけでピーク負荷を処理できるだけのリソースを、最初から過剰に配置しておく必要があります。

具体的な設計方針は以下の通りです。

静的安定性に基づく過剰プロビジョニング

Auto Scalingによる新規インスタンスの起動（リアクティブな対応）を待っていては、そのタイムラグの間にパフォーマンスが低下します。これを防ぐために以下の計算でインスタンス数を確保します。

• 前提: アプリケーションのピークロード（最大負荷）を処理するために、合計で N 台のインスタンスが必要であるとします。

• 設計: 2つのアベイラビリティーゾーン（AZ-A, AZ-B）を使用する場合、それぞれのAZに N 台ずつ、合計で 2N 台のインスタンスを常時稼働させます。

• 効果: 仮にAZ-Aがダウンして全滅しても、AZ-Bに既に N 台のインスタンスが存在するため、Auto Scalingが動くのを待つことなく、即座に100%のピークロードを処理し続けることができます。

Auto Scaling グループの設定

Auto Scalingは「障害時の復旧用」としてではなく、平常時の構成維持のために設定します。

• 希望容量 (Desired Capacity): 1つのAZが失われてもシステムが耐えられるよう、常にピークロードを処理可能な台数（上記の例では 2N 台）を維持するように設定します。

ロードバランサー (ELB) の最適化

残った健全なインスタンスにトラフィックを適切に振り分けるための設定が必要です。

• ヘルスチェック: ダウンしたAZのインスタンスを即座に切り離すため、適切なヘルスチェックを設定します。

• クロスゾーン負荷分散: ELBの「クロスゾーン負荷分散」を有効にし、生き残ったAZのリソースへトラフィックが効率的に分散されるようにします。

結論

この要件を満たすためには、**「障害発生から新インスタンス起動までのタイムラグ（デッドタイム）には機能しないリソースを期待せず、その期間も機能するリソースだけを事前に配置する」**というコストをかけた設計が不可欠です。

問題27:

ある企業は、Amazon EC2インスタンスをウェブサーバーとして利用し、ELBおよびAuto Scalingグループを設定したアプリケーションを運営しています。このアプリケーションのデータベース層には、Amazon RDS MySQLデータベースが利用されています。最近、RDSインスタンスへの読み取り要求が増加しており、その結果、データベース処理のパフォーマンスが低下しています。

コスト最適にDBインスタンスのパフォーマンスを向上させるソリューションはどれでしょうか。

Amazon CloudFrontディストリビューションをデータベース構成の前面に設置する。

Amazon RDS DBインスタンスをマルチAZ構成に変更する。

正解
Amazon RDS DBインスタンスに対してリードレプリカを増加させる。

回答は不正解です
DynamoDBテーブルをAmazon RDS DBインスタンスのキャッシュレイヤーとして設置する。

全体的な説明
このシナリオでは、Amazon RDS DBインスタンスに対する読取負荷が増加しており、読み取りパフォーマンスを向上させる手段が求められています。RDS DBインスタンスの読取負荷のパフォーマンスを向上させるためには、リードレプリカを活用するか、キャッシュレイヤーを追加してクエリをキャッシュ処理する方法があります。キャッシュ活用の場合は読み取り処理が特定のクエリに集中しているという条件が必要ですが、今回はそのような条件は存在しません。

また、インスタンスタイプの性能を向上させることによっても読み取りパフォーマンスを改善することが可能ですが、その場合は書き込み性能も含めてDBインスタンス全体の性能を向上させつつ、コストが増加します。読み取りパフォーマンスの改善方法としては推奨されません。

オプション３が正解となります。リードレプリカは、読み込み専用の複製データベースとして機能します。Amazon RDSでは、マスターDBインスタンスのデータを非同期的にレプリケーションし、リードレプリカを生成します。この機能により、1つのDBインスタンスのキャパシティをレプリカの数に応じて柔軟に拡張でき、読み取りが頻繁に行われるデータベースのワークロードの負荷を軽減することが可能です。RDSは最大15台のレプリカを作成でき、アプリケーションの大規模な読み取りトラフィックを処理し、全体の読み込みスループットを向上させることができます。

オプション１は不正解です。Amazon CloudFrontは、グローバルなコンテンツ配信を迅速化するためのコンテンツ配信ネットワーク機能です。これはデータベースの読み取り処理の向上には寄与しないため、誤りです。

オプション２は不正解です。Amazon RDS DBインスタンスをマルチAZ構成にすることで、データベースインスタンスの可用性は向上しますが、読み取り性能の向上にはつながりません。

オプション４も不正解です。DynamoDBではなく、ElastiCacheをRDS DBインスタンスの前に配置することで、キャッシュ処理を通じてクエリ処理を高速化させることが可能です。ただし、キャッシュを利用する場合には、読み取り処理が特定のクエリに集中しているという条件が必要ですが、今回はそのような条件は提示されていません。読み取り処理全般のリクエストが増加している場合は、まずはリードレプリカを利用することがコスト最適でかつ、最良の対応となります。

【RDSのリードレプリカの詳細情報】

その仕組みと特徴を解説します。

主な役割と目的

• 読み取りスケーラビリティ: 単一のDBインスタンスのキャパシティ制約を超えて、読み取り処理を伸縮自在にスケールアウトできます。アプリケーションからの「読み取りクエリ（Read）」をリードレプリカにルーティングすることで、ソースDBインスタンスの負荷を軽減し、全体のスループットを向上させます。

• 非同期レプリケーション: ソースDBインスタンスが変更されるたびに、データベースエンジンのネイティブな非同期レプリケーション機能を使用して、データのコピー（レプリカ）を更新します。

仕組みと動作

• 作成プロセス: ソースDBインスタンスのスナップショットを使用して2番目のDBインスタンス（レプリカ）を作成します。

• 接続: リードレプリカは「読み取り専用接続」のみを許可するDBインスタンスとして動作し、アプリケーションは通常のDBインスタンスと同様の方法で接続できます。

• Amazon Auroraの場合: AuroraはSSDベースの仮想化ストレージレイヤーを共有するため、データをレプリカノードにコピーする必要がなく、コストを抑えられます。

主な機能とメリット

• 昇格（プロモーション）: 必要に応じて、リードレプリカをスタンドアロンのDBインスタンス（書き込み可能）に昇格させることができます。これにより、ソースインスタンスに障害が発生した場合の復旧や、シャーディングの実装に役立ちます。

• 構成の柔軟性:

◦ 異なるストレージタイプ: レプリカにはソースとは異なるストレージタイプ（汎用SSDやプロビジョンドIOPSなど）を選択でき、コストやパフォーマンスを最適化できます。

◦ クロスリージョン: 異なるAWSリージョンにリードレプリカを作成し、災害対策（DR）やローカルパフォーマンスの向上に利用できます。

• セキュリティ: ソースとレプリカ間の通信はパブリックキー暗号化を使用して安全に行われ、KMSを使用した暗号化もサポートされます。

マルチAZ配置との違い

高可用性を目的とする「マルチAZ配置」と、スケーラビリティを目的とする「リードレプリカ」の違いが以下のように定義されています。

サポートされるエンジンと制限

• 対応エンジン: Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Db2。

• 作成数の上限: MySQL, PostgreSQL, MariaDB, SQL Serverは1つのインスタンスにつき最大15個、Oracleは最大5個まで作成可能です。

問題28:

ある企業がオンプレミス環境からAWSへの移行を決定しました。この移行を円滑に進めるため、同社はコンサルティング会社と契約しました。移行作業においては、同社のAWSアカウントにあるAmazon EC2インスタンスのAmazon マシンイメージ (AMI) をコンサルティング会社のAWSアカウントと共有する必要があります。このAMIはAmazon S3バケットにバックアップされており、AWS KMSのカスタマー管理キーを用いてスナップショットの暗号化も行われています。あなたはソリューションアーキテクトとして、このAMIの共有設定を行う役割を担っています。

この要件を満たすために、ソリューションアーキテクトはどのような手順を踏むべきでしょうか。

暗号化されたAMIを公開して、コンサルティング会社のAWSアカウントがアクセスできるようにする。AWS KMSのキーポリシーを変更して、コンサルティング会社のAWSアカウントが暗号化に使用されたKMSキーを使用できるようにする。

回答は正解です
AMIをコンサルティング会社のAWSアカウントのみと共有できるようにAMIのLaunchPermissionプロパティを変更する。AWS KMSのキーポリシーを変更して、コンサルティング会社のAWSアカウントが暗号化に使用されたKMSキーを使用できるようにする。

AMIをコンサルティング会社のAWSアカウントのみと共有できるようにAMIのLaunchPermissionプロパティを変更する。AWS KMSのキーポリシーを変更して、コンサルティング会社の所有する新しいKMSキーを許可して、このAMIに適用する。

暗号化されたAMIを公開して、コンサルティング会社のAWSアカウントがアクセスできるようにする。AWS KMSのキーポリシーを変更して、コンサルティング会社の所有する新しいKMSキーを許可して、このAMIに適用する。

全体的な説明
このシナリオでは、暗号化されたAMIを他のAWSアカウントと共有する方法が問われています。Amazon マシンイメージ（AMI）は、インスタンスの初期起動に必要な設定情報を含むイメージです。EC2で新たにインスタンスを立ち上げる際には、特定のOS設定がされているAMIを選択し、そのイメージに基づいてインスタンスを起動します。同一の設定を持つ複数のインスタンスが必要な場合、1つのAMIから複数のインスタンスを起動することが可能です。また、異なる設定のインスタンスが必要な場合は、それぞれ異なるAMIを使用してインスタンスを起動することができます。

オプション２が正解となります。複数のアカウント間でAMIを共有するには、他のアカウントとAMIを共有するための権限設定が求められます。そのためには、AMIのLaunchPermissionプロパティを調整し、特定の第三者のAWSアカウントとのみ共有できる権限を付与します。

しかしながら、このまま暗号化されたAMIを共有するだけでは、第三者のAWSアカウントから暗号化されたAMIを復号して、利用することができません。第三者のAWSアカウントのユーザーが暗号化に使用されたAWS KMSのCMKを利用してAMIを復号するには、そのCMKの利用権限を持っている必要があります。したがって、KMSのキーポリシーを修正し、第三者のAWSアカウントに対してAMIの暗号化に使用されたCMKを利用する権限を付与する必要があります。

オプション１と４は不正解です。暗号化されたAMIおよびスナップショットを公開し、他のAWSアカウントがアクセスできるようにすることで、すべてのユーザーがこれらのリソースを利用可能になります。しかし、この設定はセキュリティリスクを高めるため、問題が生じる可能性があります。

オプション３は不正解です。AWS KMSのキーポリシーを変更し、第三者が所有する新しいKMSキーを信頼してこのAMIに適用した場合でも、このAMIはすでに異なるKMSキーで暗号化されています。したがって、既存のキーを共有しない限り、暗号化されたAMIを復号することは不可能です。

【詳細情報】

暗号化されたAmazonマシンイメージ（AMI）を異なるAWSアカウントと共有するには、AMI自体の共有設定に加え、その暗号化に使用されたKMSキー（AWS Key Management Service）の使用許可を共有先のアカウントに付与する必要があります。

具体的な手順と重要な制約事項を解説します。

重要な前提条件：カスタマーマネージドキーの使用

暗号化されたAMIを共有するためには、そのスナップショットがカスタマーマネージドキー（ユーザーが作成・管理するKMSキー）で暗号化されている必要があります。

• デフォルトキーは不可: デフォルトのAWS管理キー（aws/ebs など）で暗号化されたスナップショットを持つAMIは、共有することができません。

KMSキーの共有設定（キーポリシーの変更）

AMIのバックアップとなっているスナップショットの暗号化に使用されたKMSキーに対して、共有先のAWSアカウントが使用できるように許可を与える必要があります。

• KMSのキーポリシー設定において、共有先のAWSアカウントIDを許可リストに追加し、暗号化・復号化の操作を許可します。

AMIの共有設定（起動許可の付与）

AMI自体に対して、共有先のAWSアカウントからの起動許可（Launch Permission）を付与します。これにはAWSアカウントID（12桁の数値）が必要です。

設定は以下のいずれかの方法で行えます。

• AWSマネジメントコンソール:

EC2コンソールで共有したいAMIを選択します。
[アクション] から [AMI 権限の編集] を選択します。
[共有アカウント] で [アカウント ID の追加] を選択し、共有先のAWSアカウントIDを入力して [AMI の共有] を実行します。

• AWS CLI: modify-image-attribute コマンドを使用し、--launch-permission パラメータで共有先アカウントIDを指定します。

• PowerShell: Edit-EC2ImageAttribute コマンドを使用します。

共有された側の操作と注意点

• インスタンスの起動: 共有を受けたアカウントは、そのAMIを使用してインスタンスを起動できます。

• AMIのコピー: 共有されたAMIを自分のアカウントにコピーする場合、共有元はAMIをバックアップするストレージ（スナップショット）に対する読み取り権限も付与する必要があります。

• 制限: 共有を受けたユーザーは、AMIを削除、再共有、または変更することはできません。

問題29:

ある企業はAWS上でウェブアプリケーションを運営しています。このアプリケーションはEC2インスタンスをWEBサーバーとして活用し、ELBおよびAuto Scalingグループを構成して高い可用性を確保しています。また、ELBに対してRoute53を利用したドメインも設定しています。しかしながら、最近、長時間にわたるDDoS攻撃を受け、リクエストにかかるコストが増大しました。あなたはソリューションアーキテクトとして、このDDoS攻撃によるコスト増加を抑制する必要があります。

この要件を満たすために、ソリューションアーキテクトはどのような手段を講じるべきでしょうか。

AWSサポートのDDoS攻撃コストプランを適用する。

正解
AWS Shield Advancedを適用する。

Amazon GuardDutyを適用する。

回答は不正解です
AWS Shield Standardを適用する。

全体的な説明
CloudFrontやRoute53を使用したAWSリソースへのウェブアクセスを設定している場合、リクエスト数に基づく従量課金が適用されます。したがって、リクエスト数が増加するほど、コストも増大します。DDoS攻撃は、サーバーに大量のリクエストを送信することでサーバーの負荷を増加させ、アプリケーションを停止させるサイバー攻撃です。このため、DDoS攻撃を受けると、膨大なリクエスト数に応じたコストが発生することになります。

オプション２が正解となります。このシナリオでは、DDoS攻撃によってリクエストにかかるコストが増加することが問題となっています。AWS Shield Advancedを利用することで、AWS側は保護されたリソースに対するDDoS攻撃によって発生した費用を保証してくれます。これにより、ユーザーはそのDDoS攻撃によるコストを負担する必要がなくなります。

AWSでは、DDoS攻撃に対処するためにAWS Shieldを利用します。このサービスにはStandard版とAdvanced版があり、Standard版はCloudFrontやRoute53を利用する際に自動的に無料で適用されますが、Advanced版は有料であり、ユーザーが手動で有効化する必要があります。Advanced版は有料サービスであるため、DDoS攻撃によって生じる可能性のあるコストを保証するといった追加機能が提供されています。

オプション１は不正解です。AWSサポートのDDoS攻撃コストプランといったサービスはありません。

オプション３は不正解です。Amazon GuardDutyは、AWSアカウントおよびワークロードに対する悪意のある活動を継続的に監視し、可視化と修復のための詳細なセキュリティ調査結果を提供する脅威検出サービスです。このサービスは、不審な活動としてDDoS攻撃を検出することができますが、DDoS攻撃によって発生したコストを保証してくれません。

オプション４は不正解です。AWS Shield Standardは、CloudFrontなどを利用することで無料で適用される機能であり、そのため一部の高度な機能が利用できません。したがって、AWS Shield StandardはDDoS攻撃によって発生したコストを保証してくれません。

【AWS Shield Advanced の詳細情報】

AWS Shield Advanced の主な機能と特徴を解説します。

アプリケーションレイヤー (レイヤー 7) の保護強化

AWS Shield Advanced は AWS WAF (Web Application Firewall) と統合されており、ウェブアプリケーションに対する高度な攻撃を防御します。

• 自動緩和: 保護されたリソースに対するアプリケーションレイヤー攻撃を検出し、自動的に緩和するように設定できます。攻撃を検知すると、既知の DDoS ソースからのリクエストにレート制限を適用したり、カスタム AWS WAF ルールを自動的に追加・管理したりします。

• WAF のコスト包含: Shield Advanced のサブスクリプション料金には、保護対象リソースで使用する標準的な AWS WAF の料金が含まれています（Web ACL、ルールのコスト、リクエスト検査料など）。

• マネージドスール: Layer 7 Anti-DDoS Amazon Managed Rule グループへのアクセスが含まれます。

高度な検出と可視化

• ヘルスベースの検出: Amazon Route 53 ヘルスチェックを利用してアプリケーションの状態を監視します。これにより、誤検知（フォールスポジティブ）を防ぎつつ、リソースが異常な状態になった際により迅速に攻撃を検出・緩和できます。

• 可視性の向上: DDoS イベントや攻撃に関する高度なリアルタイムメトリクスとレポートを提供し、CloudWatch やコンソールを通じて状況を詳細に把握できます。

専門チームによるサポート (SRT)

• AWS Shield Response Team (SRT): ビジネスサポートまたはエンタープライズサポートプランに加入している場合、DDoS 攻撃の最中にいつでも SRT に連絡して、専門的なサポートやカスタム緩和策の支援を受けることができます。

• プロアクティブな関与: Route 53 ヘルスチェックが異常を示し、攻撃が疑われる場合、SRT からお客様へ直接連絡を入れる「プロアクティブエンゲージメント」機能を利用できます。

コスト保護

DDoS 攻撃によって発生した AWS 請求額の急増（データ転送量 (DTO) の増加などによる予期せぬコスト）に対して、サービスクレジットによるコスト保護を提供します。

管理機能

• 保護グループ: 複数のリソースを論理的なグループとしてまとめて、検出と緩和の精度を向上させることができます。

• 一元管理: AWS Firewall Manager を使用して、複数のアカウントやリソースに対して Shield Advanced の保護を自動的に適用したり、一元管理したりすることが可能です。

問題30:

ある企業は、Amazon EC2インスタンス上で業務アプリケーションを運用しています。このアプリケーションのデータレイヤーにはAmazon DynamoDBテーブルが使用されています。同社は、このテーブルを過去24時間以内の任意の時点に復元できるようにする必要があります。

運用上のオーバーヘッドを抑えつつ、これらの要件を満たすソリューションはどれでしょうか。

回答は正解です
DynamoDBテーブルに対してポイントインタイムリカバリを有効化する。

DynamoDBテーブルに対してAWS Backupを設定して、バックアッププランを設定する。

DynamoDBテーブルに対してAmazon EventBridgeイベントを設定して、バックアップスケジュールを設定する。

DynamoDBテーブルに対してオンデマンドバックアップを有効化する。

全体的な説明
オプション１が正解となります。Amazon DynamoDBテーブルを過去24時間以内の任意の時点に戻すためには、DynamoDBテーブルにポイントインタイムリカバリを有効にする必要があります。Amazon DynamoDBのポイントインタイムリカバリ（PITR）は、DynamoDBテーブルのデータを自動的にバックアップする機能です。継続的バックアップのリカバリ期間は、1日から35日まで設定可能です。この設定によって、継続的バックアップが保持される期間が決まります。例えば、この値を30日に設定すると、テーブルを過去30日間の任意の時点に復元することが可能です。

オプション２は不正解です。AWS Backupを利用することで、DynamoDBテーブルのオンデマンドバックアップをスケジュールし、管理することが可能です。AWS Backupは、自動バックアップスケジュール、保持管理、及びライフサイクル管理を提供します。バックアップのスケジューリングはできますが、ポイントタイムリカバリを適用できません。

オプション３は不正解です。DynamoDBテーブルに対してAmazon EventBridgeイベントを設定してバックアップを行うことはできません。これは、Amazon EventBridgeイベントがバックアップの管理機能を持っていないためです。

オプション４は不正解です。DynamoDBテーブルに対してオンデマンドバックアップを有効にしても、手動でバックアップを実施する必要があります。また、このバックアップではポイントタイムリカバリは利用できません。

【詳細情報】

DynamoDB テーブルのポイントインタイムリカバリ (PITR) の特徴と仕組みを解説します。

主な機能と特徴

• 秒単位の復元: 過去の任意の「秒」を指定して、その時点のデータ状態にテーブルを復元できます。

• 保持期間: リカバリ可能な期間（保持期間）は、最短 1 日から最長 35 日までの間で設定可能です。

• パフォーマンスへの影響なし: 継続的バックアップと PITR の開始は、プロビジョニングされたキャパシティ（読み書きの容量）を消費しません。また、アプリケーションのパフォーマンスや可用性にも影響を与えません。

復元の仕組みと注意点

PITR を使用して復元を行う場合、既存のテーブルを上書きするのではなく、新しいテーブルとして復元されます。

• 非破壊的: 復元オペレーションは非破壊的であり、稼働中の既存テーブルには影響を与えません。

• 復元後の手動設定: 復元された新しいテーブルには、元のテーブルの設定がすべて自動的に引き継がれるわけではありません。以下の項目は復元後に手動で設定する必要があります。

◦ Auto Scaling ポリシー

◦ IAM ポリシー

◦ CloudWatch メトリクスおよびアラーム

◦ タグ

◦ ストリーム設定

◦ 有効期限 (TTL) 設定

◦ 削除保護設定

◦ ポイントインタイムリカバリ (PITR) 設定自体（復元されたテーブルではデフォルトで無効になっています）

用途

誤ってデータを削除や更新してしまった場合や、アプリケーションのバグによるデータ破損が発生した場合に、障害発生直前の状態へテーブル全体を巻き戻すために使用されます。

問題31:

次のIAMポリシーでEC2インスタンスに対する権限設定を行っています。

{

"Version": "2012-10-17",

"Statement": [

{

  "Action": "ec2:*",

  "Effect": "Allow",

  "Resource": "*"

},

{

    "Effect": "Deny",

    "Action": [

    "ec2:*ReservedInstances*",

    "ec2:TerminateInstances"

    ],

    "Resource": "*"

}

]

}

この設定内容として正しい内容を選択してください。

リザーブドインスタンスの操作が許可されている。

EC2インスタンスに対する全ての操作が許可されている。

正解
全てのEC2インスタンスを終了することができない。

回答は不正解です
全てのリザーブドインスタンスに対してのみインスタンスを終了することができない。

全体的な説明
このIAMポリシーでは、EC2の全てのアクションを許可していますが、「リザーブドインスタンス関連の全ての操作」および「全てのインスタンスに関する終了操作」を禁じています。

前半のステートメントでは、全てのEC2に対して、全リソースのあらゆるアクションの許可を行っています。これはフルアクセス権限となっています。

{

  "Action": "ec2:*",

  "Effect": "Allow",

  "Resource": "*"

},

後半のステートメントでは、「リザーブドインスタンスのあらゆるアクション」と「全てをEC2インスタンスの終了させるアクション」に限定して、拒否する設定がされています。

    "Effect": "Deny",

    "Action": [

    "ec2:*ReservedInstances*",

    "ec2:TerminateInstances"

    ],

    "Resource": "*"

結果的に、この設定では、「リザーブドインスタンスに対するあらゆるアクション」と、「全てのEC2インスタンスに対してインスタンス終了処理」ができないことになり、オプション３が正解となります。

【詳細情報】

IAMポリシーは JSON（JavaScript Object Notation）形式で記述します。基本的には「誰が（Principal）※」「どのリソースに対して（Resource）」「どのような条件下で（Condition）」「どのアクションを（Action）」「許可または拒否するか（Effect）」を定義するドキュメントです。 ※アイデンティティベースのポリシーの場合、Principalはポリシーをアタッチしたユーザーやロールとなるため記述を省略します。

資具体的な書き方と構成要素を解説します。

基本構造

IAMポリシーは Version と Statement（ステートメント）の2つの主要部分で構成されます。Statement の中に、具体的な許可ルールを記述します。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ポリシーの識別子（オプション）",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket",
"Condition": { ... }
}
]
}

主要な構成要素

各ステートメントには以下の要素を含める必要があります。

• Version (バージョン): 通常は "2012-10-17" を指定します。

• Effect (効果): アクセスを許可する場合は "Allow"、拒否する場合は "Deny" を指定します。

◦ 重要: 複数のポリシーで「許可」と「拒否」が競合する場合、「拒否」が優先されます。

• Action (アクション): 許可または拒否したいAWSサービスの操作を指定します。形式はサービス名:アクション名です。

◦ 例: s3:GetObject（S3のファイル取得）、ec2:StartInstances（EC2の起動）。

◦ ワイルドカード * を使用して、すべてのアクション（例: apigateway:）や特定のアクション群（例: s3:List）を指定することも可能です。

◦ 複数のアクションを指定する場合はカンマ区切りのリストにします（例: ["s3:GetObject", "s3:PutObject"]）。

• Resource (リソース): アクションの対象となるAWSリソースを ARN (Amazon Resource Name) で指定します。

◦ 例: arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*。

◦ すべてのアクションを許可する場合などは "*"（すべてのリソース）を指定します。

• Condition (条件): オプション設定です。ポリシーが有効になるタイミングや条件（IPアドレス制限、タグ、時間など）を指定します。

具体的な記述例

例1: 特定のS3バケットへの読み書きを許可する

以下は、特定のバケットに対してファイル一覧の取得（ListBucket）と、ファイルのアップロード・取得・削除（Put/Get/Delete）を許可する例です。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
}
]
}
例2: 条件（Condition）を使用してIPアドレスで制限する

Condition ブロックを使用し、特定のIPアドレス範囲（CIDR）からのアクセスのみを許可する例です。

{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
主な条件演算子には以下のようなものがあります。

• IpAddress / NotIpAddress: IPアドレスによる制限

• StringEquals / StringNotEquals: 文字列の一致（タグやユーザー名など）

• Bool: 真偽値（MFA認証済みかどうかなど）

ベストプラクティス

ポリシーを作成する際は、セキュリティ強化のために以下の点を意識することが推奨されています。

• 最小権限の原則: 最初から強い権限を与えず、必要なアクション（Action）とリソース（Resource）だけを許可するように設計します。

• リソースの特定: ワイルドカード（*）を安易に使わず、可能な限り対象リソースをARNで特定します。

• Conditionの活用: 送信元IPアドレスやVPCエンドポイント、タグなどを条件に加えることで、より堅牢なセキュリティを実現します。

問題32:

あるソリューションアーキテクトは、AWSを活用してジョブを並列分散処理するワークロードを設計しています。このアプリケーションでは、メッセージに基づいて処理されるジョブの負荷に応じてEC2インスタンス数が増減されるように調整する必要があります。このジョブはステートレスであり、疎結合に実行されることが求められます。

この要件を満たすために、どのようにソリューションを設計するべきでしょうか。

Amazon SNSトピックを作成して、EC2インスタンスにジョブをメッセージとして送信するように構成する。このインスタンスのAMIを使用した起動テンプレートを作成する。この起動テンプレートを使用して、キューメッセージ数にかかるインスタンスあたりのバックログを指標にしたターゲット追跡スケーリングポリシーを設定したAuto Scalingグループを構成する。

回答は不正解です
Amazon SNSトピックを作成して、EC2インスタンスにジョブをメッセージとして送信するように構成する。このインスタンスのAMIを使用した起動設定を作成する。この起動設定を使用して、キューメッセージ数に基づいてインスタンス総数を増減するターゲット追跡スケーリングポリシーを設定したAuto Scalingグループを構成する。

正解
Amazon SQSキューを作成して、EC2インスタンスにジョブをメッセージとして送信するように構成する。このインスタンスのAMIを使用した起動テンプレートを作成する。この起動テンプレートを使用して、キューメッセージ数にかかるインスタンスあたりのバックログを指標にしたターゲット追跡スケーリングポリシーを設定したAuto Scalingグループを構成する。

Amazon SQSキューを作成して、EC2インスタンスにジョブをメッセージとして送信するように構成する。このインスタンスのAMIを使用した起動テンプレートを作成する。この起動テンプレートを使用して、キューメッセージ総数に基づいてインスタンス数を増減するスケーリングポリシーを設定したAuto Scalingグループを構成する。

全体的な説明
このシナリオにおいては、「ジョブを並列分散処理するワークロードを構成すること」「処理されるジョブの負荷に応じてEC2インスタンス数が増減されるように調整すること。」および「このジョブはステートレスな処理であり、疎結合に実行されること。」が求められています。

オプション３が正解となります。ステートレスで疎結合なジョブ処理を実施する並列分散処理ワークロードを構成するためにはAmazon SQSを用いたキューイング処理を以下のように実装します。

１．Amazon SQSキューを作成し、ジョブメッセージを複数のEC2インスタンスに送信するように連携します。これにより、EC2インスタンスによるバックエンド処理を並列化し、「インスタンス側で状態を保持しない」＝「ステートレス」な形でジョブの同時処理を実現できます。

２.「ジョブの負荷に応じてインスタンスをスケールアップまたはスケールダウンする」ためには、Amazon SQSキューのメッセージ総数をEC2インスタンスで割ったインスタンスあたりのバックログを指標にして自動的に増減させるAuto Scalingを設定します。

・メッセージ処理用に設定されたEC2インスタンスのAMIを使用して、Auto Scalingで利用する起動テンプレートを作成します。

・次に、この起動テンプレートを基に、SNSキューに対するインスタンスあたりのバックログを閾値としてインスタンス数を調整するターゲット追跡スケーリングポリシーを設定したAuto Scalingグループを構成します。

Amazon SQS のメッセージ数に基づいて EC2 インスタンス数を増減させるには、ターゲット追跡スケーリングポリシー (Target Tracking Scaling Policy) を使用するのが一般的かつ推奨される方法です。

単にキューにある「メッセージ総数」だけを見るのではなく、**「インスタンスあたりのバックログ（未処理メッセージ数）」**という指標（メトリクス）を作成し、それを目標値に設定してスケーリングを行います。

なぜ「メッセージ総数」では不十分なのか？

単に SQS の ApproximateNumberOfMessagesVisible（取得可能なメッセージ数）だけを基準にすると、Auto Scaling グループのサイズに応じた適切な判断ができません。例えば、「メッセージが 1,000 件ある」という状況は、インスタンスが 1 台しかない場合は高負荷ですが、100 台ある場合は余裕がある状態です。そのため、インスタンス数に応じて変化する指標が必要になります。

「インスタンスあたりのバックログ」を使用する

解決策として、カスタムメトリクスまたは Metric Math（CloudWatch の数式機能）を使用して、以下の計算値を追跡するポリシーを設定します。

• 指標: インスタンスあたりのバックログ (Backlog Per Instance)

• 計算式: ApproximateNumberOfMessages (SQSのメッセージ数) ÷ InService Instances (稼働中のインスタンス数)

この値をターゲット追跡ポリシーの基準とすることで、インスタンス数が増えれば基準値が下がり、負荷に応じて適切にスケールアウト/インが可能になります。

オプション１と２は不正解です。Amazon SNSのプッシュ通知を利用してメッセージを送信することで、プッシュ型のジョブを実装することが可能です。しかし、Amazon SNSメッセージをトリガーにした同期的なジョブ実行は可能ですが、ジョブを並列分散処理するためにはAmazon SQSキューを利用する必要があります。

オプション４は不正解です。Amazon SQS の ApproximateNumberOfMessagesVisible（取得可能なメッセージ数）だけを基準にすると、Auto Scaling グループのサイズに応じた適切な判断ができません。例えば、「メッセージが 1,000 件ある」という状況は、インスタンスが 1 台しかない場合は高負荷ですが、100 台ある場合は余裕がある状態です。そのため、インスタンス数に応じて変化する指標が必要になります。

ただし、インスタンスのバックログが回答オプションにない場合は、Amazon SQS の ApproximateNumberOfMessagesVisibleを基準とした回答が正解となるパターンもありますので注意してください。

【詳細情報】

Amazon SQS (Simple Queue Service) を使用してキューを作成し、EC2 インスタンスにジョブ（メッセージ）を送信する構成を作成するには、以下の手順が必要です。SQS は「プル型」のサービスであるため、EC2 インスタンス側からキューにメッセージを取りに行く（ポーリングする）構成になる点が重要です。

SQS キューの作成

まず、Amazon SQS コンソールを使用してキューを作成し、キュー URL と ARN を取得します。

• 作成: 標準キューまたは FIFO キューを選択して作成します。

• 情報の取得: 作成後、詳細タブから「URL」と「ARN」をコピーしておきます。これらは後の設定で使用します。

アクセス権限の設定 (IAM)

セキュリティを確保するため、ジョブを送信する側（プロデューサー）と、ジョブを受信して処理する EC2 側（コンシューマー）に適切な権限を付与します。

A. EC2 インスタンス (受信側) への権限付与

EC2 インスタンスがキューからメッセージを取得・削除できるように、IAM ロールを作成してインスタンスにアタッチします。

• 必要なアクション: EC2 上のアプリケーションには、主に以下の権限が必要です。

◦ sqs:ReceiveMessage: メッセージの受信（取得）

◦ sqs:DeleteMessage: 処理完了後のメッセージ削除

• ポリシー例:

B. 送信側 (送信元) への権限付与

ジョブを作成してキューに送信するユーザーやアプリケーションには、sqs:SendMessage 権限を付与します。

メッセージの送信 (ジョブの投入)

構成した送信元（ユーザー、Lambda、別の EC2 など）から、キューに対してメッセージを送信します。

• 送信方法: AWS CLI、SDK、またはマネジメントコンソールを使用します。

• テスト: SQS コンソールの「メッセージを送受信」機能を使用して、テストメッセージを手動で送信して確認することも可能です。

EC2 インスタンスでの受信と処理

EC2 インスタンス上でアプリケーションを実行し、SQS キューをポーリング（定期的に確認）してメッセージを取得します。

• 処理の流れ:

EC2 上のスクリプト/アプリが ReceiveMessage API を呼び出す。
メッセージ（ジョブ内容）を取得する。
ジョブを実行する。
処理が成功したら、DeleteMessage API を呼び出してキューからメッセージを削除する。

▪ ※削除しないと、一定時間（可視性タイムアウト）経過後にメッセージが再度処理可能になり、重複実行の原因となります。

Auto Scaling との連携

EC2 インスタンスの負荷やキュー内のメッセージ数に応じて、処理するインスタンス数を自動的に増減（スケーリング）させることも可能です。

• スケーリングポリシー: ApproximateNumberOfMessagesVisible（取得可能なメッセージ数）などのメトリクスを使用して、キューのバックログ（滞留数）に基づいて Auto Scaling グループをスケールさせることができます。

問題32:

この要件を満たすために、どのようにソリューションを設計するべきでしょうか。

・メッセージ処理用に設定されたEC2インスタンスのAMIを使用して、Auto Scalingで利用する起動テンプレートを作成します。

なぜ「メッセージ総数」では不十分なのか？

「インスタンスあたりのバックログ」を使用する

解決策として、カスタムメトリクスまたは Metric Math（CloudWatch の数式機能）を使用して、以下の計算値を追跡するポリシーを設定します。

• 指標: インスタンスあたりのバックログ (Backlog Per Instance)

• 計算式: ApproximateNumberOfMessages (SQSのメッセージ数) ÷ InService Instances (稼働中のインスタンス数)

【詳細情報】

SQS キューの作成

まず、Amazon SQS コンソールを使用してキューを作成し、キュー URL と ARN を取得します。

• 作成: 標準キューまたは FIFO キューを選択して作成します。

• 情報の取得: 作成後、詳細タブから「URL」と「ARN」をコピーしておきます。これらは後の設定で使用します。

アクセス権限の設定 (IAM)

A. EC2 インスタンス (受信側) への権限付与

EC2 インスタンスがキューからメッセージを取得・削除できるように、IAM ロールを作成してインスタンスにアタッチします。

• 必要なアクション: EC2 上のアプリケーションには、主に以下の権限が必要です。

◦ sqs:ReceiveMessage: メッセージの受信（取得）

◦ sqs:DeleteMessage: 処理完了後のメッセージ削除

• ポリシー例:

B. 送信側 (送信元) への権限付与

ジョブを作成してキューに送信するユーザーやアプリケーションには、sqs:SendMessage 権限を付与します。

メッセージの送信 (ジョブの投入)

構成した送信元（ユーザー、Lambda、別の EC2 など）から、キューに対してメッセージを送信します。

• 送信方法: AWS CLI、SDK、またはマネジメントコンソールを使用します。

• テスト: SQS コンソールの「メッセージを送受信」機能を使用して、テストメッセージを手動で送信して確認することも可能です。

EC2 インスタンスでの受信と処理

EC2 インスタンス上でアプリケーションを実行し、SQS キューをポーリング（定期的に確認）してメッセージを取得します。

• 処理の流れ:

EC2 上のスクリプト/アプリが ReceiveMessage API を呼び出す。
メッセージ（ジョブ内容）を取得する。
ジョブを実行する。
処理が成功したら、DeleteMessage API を呼び出してキューからメッセージを削除する。

▪ ※削除しないと、一定時間（可視性タイムアウト）経過後にメッセージが再度処理可能になり、重複実行の原因となります。

Auto Scaling との連携

EC2 インスタンスの負荷やキュー内のメッセージ数に応じて、処理するインスタンス数を自動的に増減（スケーリング）させることも可能です。

問題33:

次のバケットポリシーでS3バケットに対する権限設定を行っています。

{

"Version": "2012-10-17",

"Id": "S3PolicyId1",

"Statement": [

{

  "Sid": "IPAllow",

  "Effect": "Deny",

  "Principal": "*",

  "Action": "s3:*",

  "Resource": "arn:aws:s3:::examplebucket/*",

  "Condition": {

     "NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}



  }

}

]

}

この設定内容として正しい内容を選択してください。

このS3バケットに対して、指定された IP アドレス範囲から全てのアクションが実行可能である。

このS3バケットに対して、指定された IP アドレス範囲以外から全てのアクションが実行可能である。

回答は不正解です
このS3バケットに対して、指定された IP アドレス範囲からのアクセスが拒否されている。

正解
このS3バケットに対して、指定された IP アドレス範囲以外からのアクセスが拒否されている。

全体的な説明
このバケットポリシーでは、以下の前半のステートメントによって、examplebucketに対する全てのユーザーからの全てのアクションを拒否しています。

  "Effect": "Deny",



  "Principal": "*",



  "Action": "s3:*",



  "Resource": "arn:aws:s3:::examplebucket/*",

後半のステートメントにおいて、許可されたIP アドレスの範囲として 54.240.143.0/24 を指定しています。Condition ブロックでは、NotIpAddress 条件と aws:SourceIpを使用しています。ここではNotIpAddress 条件を利用しているため、54.240.143.0/24 以外のIPアドレスが、このポリシーによって影響されることになります。

  "Condition": {



     "NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}



  }

したがって、このバケットへのリクエストが指定された IP アドレス範囲（54.240.143.0/24）以外である場合には、この S3 バケット内のオブジェクトに対するアクセスが拒否されます。よって、オプション４が正解となります。

【詳細情報】

S3バケットポリシーは JSON（JavaScript Object Notation）形式で記述するアクセスコントロール用のドキュメントです。バケットポリシーを作成する際は、基本的に**「誰が (Principal)」「どのリソースに対して (Resource)」「どのような条件下で (Condition)」「どのアクションを (Action)」「許可または拒否するか (Effect)」**を定義します。

基本的な構文と主要な構成要素、および具体的な書き方の例を解説します。

基本構造

バケットポリシー全体は Version と Statement（ステートメントのリスト）で構成されます。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "任意の識別子 (オプション)",
"Effect": "Allow または Deny",
"Principal": { ... },
"Action": "s3:アクション名",
"Resource": "arn:aws:s3:::バケット名/パス",
"Condition": { ... }
}
]
}

主要な構成要素

各要素の役割と書き方は以下の通りです。

• Version (バージョン): ポリシー言語のバージョンを指定します。現在は "2012-10-17" を指定するのが一般的です。

• Statement (ステートメント): 1つ以上のルールを記述するリストです。

• Sid (ステートメントID): ステートメントを識別するための任意の文字列です（省略可能）。

• Effect (効果): アクセスを許可する場合は "Allow"、拒否する場合は "Deny" を指定します。

◦ 注意: 明示的な "Deny" は "Allow" よりも優先されます。

• Principal (プリンシパル): ポリシーを適用する対象（誰）を指定します。

◦ 特定のAWSアカウント: {"AWS": "arn:aws:iam::アカウントID:root"}

◦ 特定のIAMユーザー: {"AWS": "arn:aws:iam::アカウントID:user/ユーザー名"}

◦ 全員（匿名）: {"AWS": ""} (または単に "" )。

◦ AWSサービス: {"Service": "cloudfront.amazonaws.com"} など。

• Action (アクション): 許可または拒否する操作を指定します。

◦ 読み取り: "s3:GetObject"

◦ 書き込み: "s3:PutObject"

◦ バケット一覧取得: "s3:ListBucket"

◦ すべてのアクション: "s3:*"

• Resource (リソース): 対象となるバケットやオブジェクトを ARN (Amazon Resource Name) で指定します。

◦ バケット自体: "arn:aws:s3:::example-bucket" (ListBucketなどはここに対して行う)

◦ バケット内のオブジェクト: "arn:aws:s3:::example-bucket/*" (GetObject/PutObjectなどはここに対して行う)

• Condition (条件): ポリシーが有効になるタイミングや条件を指定します（オプション）。

◦ IPアドレス制限: IpAddress, NotIpAddress

◦ SSL通信の強制: Bool (aws:SecureTransport)

◦ 文字列一致: StringEquals

具体的な記述例

例1: 匿名のユーザーに読み取り権限を与える（静的ウェブサイトホスティング）

世界中の誰でもファイルを見られるようにする設定です。これを行うには、バケットの「パブリックアクセスブロック」設定を無効にする必要があります。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/"
}
]
}
※ Resource に /* を付けることで、バケット内のすべてのオブジェクトを対象としています。

例2: 特定のIPアドレス以外からのアクセスを拒否する

社内ネットワークなど、許可されたIP以外からのアクセスをブロックする場合に使用します。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Deny",
"Principal": "",
"Action": "s3:",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "54.240.143.0/24"
}
}
}
]
}
※ NotIpAddress で指定したIP 以外の場合、Effect: Deny (拒否) が適用されます。

例3: HTTPS (SSL) 通信のみを許可する

セキュリティ向上のため、暗号化されていない HTTP 通信を拒否する設定です。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictToTLSRequestsOnly",
"Effect": "Deny",
"Principal": "",
"Action": "s3:",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
※ aws:SecureTransport が false (HTTP) の場合、アクセスを拒否します。

例4: CloudFront からのアクセスのみを許可する (OAC)

CloudFront 経由での配信を行い、S3 への直接アクセスを防ぐ場合の推奨設定です（OAC: Origin Access Control を使用する場合）。

{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowCloudFrontServicePrincipalReadOnly",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/DISTRIBUTION_ID"
}
}
}
}
※ Condition ブロックで特定の CloudFront ディストリビューション ARN を指定することで、自分のディストリビューションからのみアクセスできるように制限します。

ポリシー作成のヒント

• ポリシージェネレーター: AWS 公式のポリシージェネレーターツールを使用すると、GUI で選択肢を選ぶだけで JSON の土台を作成できるため便利です。

• ARN の確認: ポリシーを適用するバケットやオブジェクトの ARN は正確に記述してください。特に末尾の /* の有無は重要です（バケット自体の設定か、中のオブジェクトの設定かで異なります）。

問題34:

ある企業は、オンプレミス環境において複数の仮想マシン(VM)とMySQLデータベースを利用したアプリケーションを運用しています。このアプリケーションの災害復旧(DR)対応として、AWSクラウドにリカバリ構成を実現する必要があります。このDR対応で求められる要件は以下の通りです。

・自動フェイルオーバーが実施できる。

・目標復旧時間（RTO）を15分とする。

・フェイルオーバーソリューションをテストしてリカバリを検証できる。

これらの要件を満たす最適なソリューションはどれでしょうか。

AWS DataSyncとAWS Storage Gatewayを使用してバックアップデータをAWSに同期させる。Amazon EC2、Amazon S3、ALBを使用してスタンバイ構成を準備する。Amazon Route53のフェイルオーバールーティングをスタンバイ構成とオンプレミス環境に設定する。

正解
AWS Replication Agentを使用して仮想マシン(VM)を増分的にAWS環境にレプリケートする。Elastic Disaster Recoveryを設定してウォームスタンバイ構成を準備する。

AWS Backupを使用してオンプレミスのVMのバックアップを取得して、スタンバイ構成を保持する。Amazon Route53のフェイルオーバールーティングをバックアップ構成とオンプレミス環境に設定する。

回答は不正解です
AWS DataSyncとAWS Storage Gatewayを使用してバックアップデータをAWS環境に同期させる。Elastic Disaster Recoveryを設定してウォームスタンバイ構成を準備する。

全体的な説明
オプション２が正解となります。AWS Elastic Disaster Recoveryを活用することで、オンプレミス環境の複数の仮想マシンやMySQLデータベースサーバーをAWS環境にコピーして、DR構成を整備することが可能です。·

AWS Elastic Disaster RecoveryはAWS環境内でDisaster Recoveryを実現するサービスです。これを利用して、プライマリー構成のパフォーマンスに影響を与えることなく、複製したい環境（ソースサーバー）をAWSクラウド環境に継続的にレプリケートすることができます。

具体的には、AWS Elastic Disaster Recoveryではオンプレミス環境のVMに対してレプリケーションを以下のように設定します。

1．AWS Replication Agentをオンプレミス環境のVM内にインストールして、VMを増分的にAWS環境にレプリケートするように設定します。これにより、オンプレミス環境の複数の仮想マシンとMySQLデータベースサーバーを常に最新の状態でAWSクラウドにコピーすることが可能となります。

２．次に、Elastic Disaster Recoveryを設定してレプリケートされた仮想サーバーをEC2インスタンスに復元し、ウォームスタンバイ構成を準備することができます。

オプション１と４は不正解です。AWS DataSyncとAWS Storage Gatewayを用いてVMやDBをAWS環境に同期させることはできません。AWS Elastic Disaster Recoveryを利用する際は、AWS Replication Agentを活用してVMデータをAWS環境にレプリケートさせる必要があります。

オプション３は不正解です。AWS Backupを使用してオンプレミスのVMware仮想マシンのバックアップとリストアを行うことは可能ですが、継続的なレプリケーションを実施することができないため、DR対応としては不十分です。

【詳細情報】

AWS Replication Agent と AWS Elastic Disaster Recovery (AWS DRS) を利用した DR（災害復旧）構成は、オンプレミスや他のクラウド上のサーバーを、コスト効率よく AWS 上に複製・復旧するための仕組みです。その構成要素と動作の仕組みを解説します。

構成の概要

この構成では、常時稼働する高価な待機系サイトを用意する代わりに、AWS 上に軽量な「ステージングエリア」を設け、災害時のみフルサイズのサーバーを起動することでコストを削減します。

主な構成要素は以下の通りです。

• ソースサーバー: 保護対象となるサーバー（オンプレミス、VMware、Hyper-V、Azure、他の AWS リージョンなど）。

• AWS Replication Agent: ソースサーバーにインストールされるエージェントソフトウェア。

• ステージングエリア: データ複製先となる AWS 側の環境。軽量なレプリケーションサーバーと EBS ボリュームで構成されます,。

• リカバリインスタンス: 災害時や訓練時に、実際に稼働する AWS 上のインスタンス。

AWS Replication Agent の役割と動作

エージェントはソースサーバー上で動作し、データの複製を担います。

• インストール: ソースサーバーにインストールが必要です。再起動は不要で、アプリケーションへの影響はありません,。

• ブロックレベルの複製: エージェントはメモリ上に常駐し、ディスクに書き込まれるブロックデータを継続的にキャプチャします。

• 圧縮と暗号化: キャプチャしたデータは、CPU 使用率を抑えつつ圧縮および暗号化され、AWS へ転送されます。通信には TLS 1.2 が使用されます。

• 非同期レプリケーション: データは非同期で AWS 上のレプリケーションサーバーへ送信されます。

レプリケーションとステージングエリア

AWS 側では、「レプリケーションサーバー」と呼ばれる軽量な EC2 インスタンスがデータを受信し、EBS ボリュームに書き込みます。

• 継続的な同期: レプリケーションサーバーは、アタッチされた EBS のデータを常にソースサーバーと同期させ、最新の状態に保ちます。

• スナップショットの作成: データの履歴管理のため、定期的に EBS スナップショットを作成します。

• ポイントインタイムリカバリ (PITR): 過去のスナップショットを利用することで、ランサムウェア感染時などに特定の時点（数分前～数日前）の状態に戻すことが可能です。

◦ RPO（目標復旧時点）は秒単位（通常 1 秒未満）を目指して設計されています。

復旧（フェイルオーバー）と変換プロセス

災害発生時や訓練（ドリル）時には、ステージングエリアのデータを使って「リカバリインスタンス」を起動します。

• 変換サーバー (Conversion Server): AWS 上で起動する際、物理サーバーや他の仮想環境の OS を AWS ネイティブな環境（EC2）で動作させるために、自動的に変換処理が行われます。これには、適切なハイパーバイザードライバーの注入やブートローダーの変更などが含まれます。

• インスタンスの起動: 変換が完了すると、指定したスペックの EC2 インスタンスとしてサーバーが起動します。RTO（目標復旧時間）は通常数分程度（OS の起動時間に依存）です。

ネットワーク要件

データ転送にはインターネット経由のほか、VPN や AWS Direct Connect などのプライベート接続を利用することも可能です。

問題35:

ある企業は、AWS上でサーバーレスアプリケーションを活用し、コスト効率の高いワークフローを構築することを決定しました。あなたはソリューションアーキテクトとして、Amazon SQSキューとAWS Lambdaを用いて、AWSクラウドにおけるサーバーレスアプリケーションを設計しています。この構成において、フロントエンド処理を行うLambda関数からAmazon SQSキューにメッセージを送信し、Amazon SQSキューからメッセージを受け取ったEC2インスタンスのバックエンドサーバーがタスクを並行して処理します。その際、Lambda関数と連携するAmazon SQSキューはデフォルトの許可設定が利用されます。

Amazon SQSキューの許可設定がデフォルトのままであることを前提にして、Lambda関数を使用してSQSにメッセージを送信するために必須となる設定はどれでしょうか。

適切なポリシーが定義されたSQS アクセスポリシーをLambda関数に設定して、Amazon SQSへのアクセスを可能にする。

Lambda関数をAmazon API Gatewayと統合して、Amazon SQSキューを処理するように設定する。

回答は正解です
適切なポリシーが付与されたIAMロールをLambda関数に設定して、Amazon SQSへのアクセスを許可する。

セキュリティグループをLambda関数に設定して、Amazon SQSへのアクセスを可能にする。

全体的な説明
AWSリソースと連携するLambda関数を作成する場合、IAMによる実行ロールをLambda関数に設定し、適切なアクセス権限を付与することが求められます。このIAMロールに与えられたアクセス権限により、Lambda関数が操作可能なAWSリソースの範囲が定まります。

オプション３が正解となります。今回のシナリオにおいて、Lambda関数にはAmazon SQSへのアクセス権限が求められます。AWSサービスへのアクセス権を付与するためには、特定のリソースに対するアクションを許可するIAMポリシーをIAMロールに設定する必要があります。LambdaからSQSへメッセージを送信する構成の要点は以下の通りです。

Lambda実行ロールを作成し、lambda.amazonaws.comがロールを引き受けられるように信頼ポリシーを設定する。
そのロールに対し、対象SQSキューへの sqs:SendMessage アクションを許可するIAMポリシーをアタッチする。
必要に応じてSQS側のアクセスポリシーも更新し、Lambdaロールからのアクセスを許可する。

オプション１は不正解です。Lambda関数にSQSアクセスポリシーを設定することで、Amazon SQSへのアクセスを可能にします。Amazon SQSキューにアクセスするためには、SQSアクセスポリシー、IAMポリシー、またはその両方にアクセス許可を追加する必要があります。しかし、Amazon SQSキューがデフォルト設定のままである場合、SQSアクセスポリシーは許可も拒否もしないため、Lambda関数によるアクセスは自動的に許可されます。したがって、本件では追加のSQSアクセスポリシーの設定は不要です。

オプション２は不正解です。SQSキューをトリガーとしてLambda関数を実行するために、Lambda関数をAPI Gatewayと統合する必要はありません。

オプション４は不正解です。AWS LambdaはVPC外で構成されるサービスであり、セキュリティグループをLambda関数に設定してAmazon SQSへのアクセスを制御する必要はありません。さらに、Amazon SQSもVPC外のサービスであるため、セキュリティグループの制御対象にはなりません。

一方で、Amazon EC2やAmazon RDSなどのVPC内のリソースとLambda関数がVPC内で通信する必要がある場合、Lambda関数をVPC内に配置することが可能です。その際には、Lambda関数にセキュリティグループを適用することができます。

【構成の詳細情報】

Lambda関数からAmazon SQSキューへメッセージを送信する（プロデューサーとして動作する）ためには、主にIAM（Identity and Access Management）の権限設定が必要です。

必要な設定手順とポリシーの構成を解説します。

Lambda実行ロールへの権限付与（IAMポリシー）

Lambda関数がSQSキューにアクセスしてメッセージを送信できるように、Lambdaに割り当てられている実行ロールに対して許可を与える必要があります。

具体的には、以下の設定を含むIAMポリシーを実行ロールに追加します。

• アクション (Action): sqs:SendMessage

◦ これはキューにメッセージを送信するための権限です。

• リソース (Resource): 対象となるSQSキューのARN（Amazon Resource Name）

◦ 例: arn:aws:sqs:us-east-1:123456789012:queue_1

• 効果 (Effect): Allow

IAMポリシーステートメントの例:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:queue_1"
}
]
}

SQSアクセスポリシーの設定（必要な場合）

SQSキュー側にも「アクセスポリシー（リソースベースのポリシー）」が存在します。Lambda関数とSQSキューが同じAWSアカウントにある場合、IAMポリシー（上記1）で許可されていれば、SQS側のポリシーで明示的に拒否されていない限りアクセス可能です。

しかし、異なるAWSアカウント間でのアクセスや、より厳密な制御が必要な場合は、SQSアクセスポリシーでもLambdaからの送信を許可する必要があります。

SQSアクセスポリシーの設定例:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [ "arn:aws:iam::111122223333:role/MyLambdaExecutionRole" ]
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:queue_1"
}
]
}
※ PrincipalにはLambda実行ロールのARNを指定します。

暗号化されたキューを使用する場合の注意点

SQSキューがKMSキーで暗号化されている場合、Lambda実行ロールにはSQSの操作権限に加えて、KMSキーの使用権限も必要になります。

• 必要なKMS権限をLambda実行ロールのIAMポリシーに追加してください。

• デフォルトのAWS管理キーを使用している場合、異なるAWSアカウントからのアクセスは制限される点に注意が必要です。

問題36:

ある企業のアプリケーションでは、大量のクリックストリームデータをAmazon S3バケットに保存するためのクリックストリーム分析ツールを開発しています。要件は、ウェブサイトから送信される膨大なクリックストリームをAPI経由で取得し、適切なデータ形式に変換してAmazon S3バケットに保存することです。その後、Amazon S3バケットに保存されたクリックストリームデータを迅速に分析するためのデータパイプラインを構成します。このパイプラインでは、データ内容に応じて保存データを分類した上で、一部のデータはさらに分析する必要があります。

運用上のオーバーヘッドを抑えつつ、これらの要件を満たすソリューションはどれでしょうか。（３つ選択）

正しい選択
Amazon API Gateway APIに連動したAWS Lambda関数がクリックストリームを取得し、Amazon Kinesis Data Streamsに配信する。

選択は不正解です
Amazon API Gateway APIに連動したAWS Lambda関数がクリックストリームを取得し、Amazon Data Firehose に配信する。

選択は正解です
Kinesis Data Streamsがクリックストリームデータを処理し、Amazon Data Firehose を使用してデータを Amazon S3バケットに保存する。

Amazon Data Firehoseがクリックストリームデータを処理して、データを Amazon S3バケットに保存する。

正しい選択
AWS Glueクローラーを設定し、Amazon S3バケット内のデータを分割する。Amazon EMR Sparkジョブを設定し、データをクエリする。

選択は不正解です
AWS Glueクローラーを設定し、Amazon S3バケット内のデータを分割する。Amazon Athenaを設定し、データをクエリする。

全体的な説明
オプション１が正解となります。クリックストリームデータは、ユーザーとウェブサイトまたはモバイルアプリケーションとの間で発生するデジタルインタラクションを収集したデータです。リアルタイムでユーザーアクティビティデータを収集し、有用なインサイトを生成する際に利用します。

「ウェブサイトから送信される膨大なクリックストリームをAPI経由で取得し、適切なデータ形式に変換してAmazon S3バケットに保存する」ために、まずはAmazon API GatewayとAWS Lambda関数を統合して、クリックストリームを取得するAPIアプリケーションを実装します。Lambda関数はAPIを通じてクリックストリームデータを取得し、そのデータをAmazon Kinesis Data Streamsに送信します。

オプション３が正解です。AWS Lambda関数からクリックストリームを受信したAmazon Kinesis Data Streamsがクリックストリームデータを処理します。次にAmazon Kinesis Data StreamsはそのデータをAmazon Data Firehoseに送信します。Amazon Data Firehoseはクリックストリーミングデータを最適なデータ形式に変換してAmazon S3バケットに配信します。

オプション１と３では具体的には、以下のプロセスが実行されます。

1．クライアント（カスタマーWebポータル）は、クリックストリームペイロード（レコード）をAPI Gatewayに送信します。

2．API GatewayはレコードをLambdaに送信し、そこでデータが標準化されます。

3．LambdaはレコードをKinesis Data Streamsに送信して処理を行います。

4．Kinesis Data StreamsはリクエストをKinesis Data Firehoseに転送します。

5．Kinesis Data Firehoseは、1分ごとにレコードをバッファリングし、S3バケットにアップロードします。

オプション５が正解となります。次にAmazon S3バケットに保存されたクリックストリームデータを迅速に分析するためのデータパイプラインを構成する必要があります。このパイプラインでは、データ内容に応じて保存データを分類した上で、一部のデータはさらに分析する要件があります。

AWS Glueクローラーを設定し、Amazon S3バケット内のデータをクロールすることで、データの内容に基づいてクリックストリームデータを分類します。

AWS Glueクローラーは、AWS Glueの主要な機能の一つで、データストアを自動的にスキャンし、データのスキーマやメタデータを推論してAWS Glueデータカタログに登録するツールです。このプロセスにより、データの構造を把握し、ETL（抽出、変換、ロード）ジョブやクエリ処理に利用可能な形でデータを準備できます。

その後、Amazon EMRを使用してSparkジョブを構成することで、分類されたデータ内容に基づいて後続のクエリ分析をリアルタイムかつ高速に実行することができます。Amazon EMRを使用してSparkジョブを実行するには、以下の手順を実行します。

・Amazon EMRコンソールを開き、EMR Serverlessを選択します。

・新しいEMR Studioを作成するか、既存のStudioを選択します。

・アプリケーションページでアプリケーションの作成を選択し、アプリケーションの名前を入力します。

・アプリケーションの設定で、タイプでSparkを選択し、リリースバージョンで使用するAmazon EMRバージョンを選択します。

・アプリケーションのステータスが開始済みに変わったら、アプリケーションの名前を選択します。

・バッチジョブの実行を送信し、ジョブの名前とAmazon S3バケットのスクリプトの保存場所を入力します。

・ジョブの実行を送信し、ジョブの実行ステータスが成功に変わったら、ジョブの結果を確認します。

オプション２は不正解です。Amazon API Gateway APIに連動したAWS Lambda関数は、クリックストリームを取得したら、まずはAmazon Kinesis Data Streamsに配信する必要があります。LambdaはレコードをKinesis Data Streamsに送信し、非同期処理を実施します。

オプション４は不正解です。クリックストリームデータをKinesis Data Streamsが処理を行った上で、Kinesis Data Firehoseに転送することが必要です。Kinesis Data Firehoseだけではクリックストリームデータの処理を実施することができません。

オプション６は不正解です。Amazon Athenaは、標準的なクエリを使用して、Amazon S3内のデータを直接分析することを容易にするインタラクティブなクエリサービスです。これは通常のクエリ分析を行う際には便利なツールですが、今回のような大量のクリックストリームデータをリアルタイムに迅速に分析する際には向いていません。

問題37:

ある企業は、AWS上でWEBアプリケーションを運用しています。このアプリケーションは、Amazon RDS MySQLのマルチAZ配置のデータベースインスタンスと、EC2インスタンスを基盤としたWEBサーバーで構成されています。ソリューションアーキテクトは、現在のデータベース認証方式が安全性に欠けるため、セキュリティ設定の強化を求められました。ユーザーの認証情報を自動的にローテーションし、WEBサーバーからのデータベース接続を安全に保つ必要があります。

この要件を達成するために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

回答は正解です
ユーザー認証情報をAWS Secrets Managerのシークレットに保存する。IAMアクセス許可を付与して、EC2インスタンスによるAWS Secrets Managerへのアクセスを許可する。

データベースユーザー認証機能をAWS Systems Manager パラメーターストアに保存する。IAMアクセス許可を付与して、EC2インスタンスによるOpsCenterへのアクセスを許可する。

ユーザー認証情報をAWS Secrets Manager パラメーターストアに保存する。IAMアクセス許可を付与して、EC2インスタンスによるパラメーターストアへのアクセスを許可する。

ユーザー認証情報をAWS Systems Manager パラメーターストアに保存する。IAMアクセス許可を付与して、EC2インスタンスによるOpsCenterへのアクセスを許可する。

全体的な説明
このシナリオでは、EC2インスタンスがデータベースにアクセスする際の認証方式が安全でないため、セキュリティ設定の強化が求められています。その際は、ユーザー認証情報を定期的にローテーションし、WEBサーバーからのデータベース接続を安全に保つことが要件です。

オプション１が正解となります。AWS Secrets Managerは、データベースやその他のサービスに関連する認証情報を安全に暗号化し、シークレットとして保存および取得するための仕組みを提供します。データベースのユーザー認証情報をSecrets Managerに保存することで、WEBサーバーはSecrets Managerから認証情報を取得し、安全にデータベースに接続することが可能になります。

AWSリソースからSecrets Manager内の情報にアクセスするためには、IAMポリシーによる適切な許可設定が必要です。したがって、EC2インスタンスにSecrets Managerの権限設定が定義されたIAMロールを付与してAWS Secrets Managerにアクセスできるようにする必要があります。これにより、EC2インスタンス上で動作するアプリケーションは、Secrets ManagerへのAPIコールを通じてシークレット内の認証情報を取得できるようになります。

AWS Secrets Managerは、認証情報を安全に保存し、利用するための機能を提供するサービスです。データベース認証情報、アプリケーション認証情報、OAuthトークン、APIキー、その他のシークレットを保存・管理することが可能です。また、ライフサイクル管理機能を通じて、シークレットの管理、取得、ローテーションを行うことができます。

オプション２と４は不正解です。AWS Systems Managerは、オンプレミスおよびAWS環境におけるインフラストラクチャの使用状況を可視化し、管理するための統合運用サービスです。このサービスは、パラメーターストアを活用して資格情報を保存し、提供する機能を備えています。しかし、AWS Systems Managerは自動ローテーションを行うことができません。

オプション３は不正解です。AWS Secrets Manager パラメーターストアという機能はありません。AWS Secrets Manager にシークレットを保存して管理することが必要です。

【【構成の詳細情報】の詳細情報】

AWS Secrets Manager は、アプリケーション、サービス、および IT リソースへのアクセスに必要な認証情報（シークレット）を一元的に保存・管理し、そのライフサイクル全体を保護するためのサービスです。

主な機能とメリットを以下に解説します。

シークレットの一元管理と暗号化

データベースの認証情報、API キー、その他の機密情報を一元的に保存できます。保管中のシークレットは安全に暗号化され、一元的に監査することが可能です。

シークレットの自動ローテーション

Secrets Manager の大きな特徴として、**シークレットを自動的にローテーション（変更）**する機能があります。

• スケジュールに従って定期的に、またはオンデマンドでローテーションを実行できます。

• アクティブなアプリケーションを再デプロイしたり中断したりすることなく、認証情報を更新できるため、セキュリティ運用が効率化されます。

アクセス制御と監査

• IAM との統合: AWS Identity and Access Management (IAM) の許可ポリシーを使用して、シークレットへのアクセス権限をきめ細かく管理できます。「EC2 インスタンスに IAM ロールを付与して Secrets Manager にアクセスさせる」といった構成がこれに該当します。

• モニタリング: AWS のログ記録、モニタリング、通知サービスと統合されており、シークレットの使用状況を監視・監査できます。

ディザスタリカバリ (DR) のサポート

災害対策（ディザスタリカバリ）のシナリオをサポートするために、シークレットを別のリージョンにレプリケート（複製）する機能も提供されています。

【構成の詳細情報】

Amazon RDS MySQL のユーザー認証情報を保存した AWS Secrets Manager に、EC2 インスタンスからアクセスできるようにするには、IAM ロールを作成し、EC2 インスタンスに関連付ける（アタッチする）必要があります。その設定手順とポリシーの構成を解説します。

IAM ポリシーの作成

まず、Secrets Manager に保存されたシークレットへのアクセス権限を定義する IAM ポリシーを作成します。EC2 インスタンスに必要なポリシーの構成要素は以下の通りです。

• Effect (効果): "Allow" を指定します。

• Action (アクション): Secrets Manager からシークレットの値を取得するアクション（secretsmanager:GetSecretValue など）を指定します。

◦ ※S3 や EC2 のアクション例と同様に、Secrets Manager の場合も同様の形式 (サービス名:アクション名) で記述します。

• Resource (リソース): アクセス対象となる特定のシークレットの ARN (Amazon Resource Name) を指定します。

◦ セキュリティの観点から、すべてのリソース（"*"）ではなく、必要なシークレットの ARN だけを特定して記述する「最小権限の原則」に従うことが推奨されます。

ポリシー記述のイメージ:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:Region:AccountIDSecretName"
}
]
}

IAM ロールの作成と EC2 への割り当て

次に、作成したポリシーを EC2 インスタンスに適用するための IAM ロールを設定します。

• 信頼ポリシーの設定: ロールを作成する際、このロールを使用する「信頼されたエンティティ」として EC2 サービス（ec2.amazonaws.com）を指定する必要があります。これにより、EC2 がこのロールを引き受ける（AssumeRole）ことが許可されます。

• ポリシーのアタッチ: 手順 1 で作成した IAM ポリシーをこのロールにアタッチします。

• インスタンスへの適用: 最後に、この IAM ロールを対象の EC2 インスタンスに関連付けます（インスタンスプロファイルの設定）。

暗号化キー (KMS) に関する注意点

Secrets Manager のシークレットがデフォルトのキーではなく、カスタマーマネージドキー (AWS KMS) で暗号化されている場合、その KMS キーを使用して復号化するための権限も必要になります。

• IAM ロールのポリシーに、対象の KMS キーに対する kms:Decrypt などのアクションを許可する設定を追加する必要があります。

• デフォルトのキーを使用している場合でも、異なる AWS アカウントからアクセスする場合などは制約があるため注意が必要です。

問題38:

ある企業は、オンプレミス環境からAWSへの移行を決定しました。現在は火曜日であり、業務に影響を及ぼさないように、今週末の金曜日の夜から月曜日の朝までの72時間以内にデータ移行を完了させる必要があります。移行するデータの容量は10TBであり、データの安全な通信を確保することが求められています。現在、オンプレミス環境とVPCはインターネットを通じて接続されています。

この条件に適した移行方法を選定してください。

回答は不正解です
Snowball edgeによるデータ移行を実施する。

Direct Connect接続によるデータ転送を実施する。

正解
AWS サイト間 VPNを利用したVPN接続によるデータ転送を実施する。

Storage Gatewayによるデータ移行を実施する。

全体的な説明
オプション３が正解となります。Amazon VPC内に配置されたAWSサービスは、デフォルトではオンプレミスネットワークと直接通信することができません。そのため、データセンターやオフィスのネットワークを専用線接続やAWSサイト間VPN接続を通じてAmazon VPCに接続する必要があります。この際、AWSサイト間VPNではインターネットプロトコルセキュリティ（IPsec）を用いて、2点間に暗号化されたVPNトンネルを構築することが可能です。

このシナリオでは、移行データ量と移行スケジュールに基づいて移行方法を選定する必要があります。「週末にデータ転送を行うための時間が短期間であること」および「現在はインターネットを介してのみAWSクラウドに接続されていること」が要件となっています。したがって、物理ネットワーク接続を構成したり、デバイスの調達が必要となるDirect ConnectやSnowballアプライアンスを発注して移行を行うことは難しい状況です。これらを利用するにはAWS側との調整に時間がかかるため、AWSにこれらの機器を発注しても間に合わないからです。唯一、即座に実施可能な手段はVPN接続です。さらに、約10TBのデータ転送はVPN接続を利用することで72時間以内に完了することができます。

オプション１は不正解です。Snowball EdgeはAWSから提供される機器を使用します。数百テラバイトなどの大量のデータを移行する際には便利ですが、今回のように準備時間が限られている場合の少量データ移行には適していません。また、AWSへの申請が必須であり、要件の期間内に準備が整わない可能性があります。

オプション２は不正解です。Direct ConnectはAWS側との専用線接続を物理的に設定する必要があり、これもAWSへの申請が不可欠で、要件の期間内に準備が間に合わないことが予想されます。

オプション４も不正解です。AWS Storage GatewayはS3とオンプレミスストレージ間のデータ転送やバックアップ構成に使用されます。ストレージ間のデータ移行にも利用可能ですが、今回はストレージのみがデータ移行の対象ではありません。データベースのデータも含めて、オンプレミス環境のデータをAWSに移行する必要があります。Storage Gatewayはストレージ間のデータ移行に特化しているため、不正解となります。

【詳細情報】

AWS Site-to-Site VPN を用いたデータ転送は、オンプレミスネットワークと AWS の仮想プライベートクラウド (VPC) 間で、インターネットプロトコルセキュリティ (IPsec) を使用して暗号化された安全な通信を行う方法です。帯域幅の仕様、コスト、および制限事項について重要なポイントを解説します。

帯域幅とパフォーマンス

標準的な構成と、より高速な転送を実現するためのオプションがあります。

• 標準の帯域幅: 各 VPN 接続には 2 つのトンネルが含まれており、標準構成ではトンネルあたり最大 1.25 Gbps の帯域幅をサポートします。

• 広帯域幅トンネル (大量転送向け): Transit Gateway または AWS Cloud WAN に VPN 接続をアタッチして使用する場合、「広帯域幅トンネル」オプションを利用できます。これにより、トンネルあたり最大 5 Gbps の帯域幅がサポートされ、より高速なデータ転送が可能になります。

重要な制限事項

大量のデータを転送する際、ネットワークのチューニングに影響する以下の制限に注意する必要があります。

• パス MTU 検出の非サポート: Site-to-Site VPN 接続は「パス MTU 検出 (Path MTU Discovery)」をサポートしていません。パケットの断片化（フラグメンテーション）やドロップを防ぐために、通信経路上の最小 MTU サイズに合わせてパケットサイズを調整する必要があります。

• プロトコルの制限: 単一の VPN 接続で IPv4 と IPv6 の両方のトラフィックを同時にサポートすることはできません。両方のプロトコルで転送を行う場合は、個別の VPN 接続を作成する必要があります。

コストに関する考慮事項

大量のデータを転送する場合、通信料が高額になる可能性があります。

• データ転送料金: VPN 接続自体の時間単位の料金に加え、AWS からオンプレミスへのデータ転送（アウトバウンド通信）に対して、Amazon EC2 からインターネットへのデータ転送レートで課金されます。

• 高速 VPN (Accelerated VPN) の追加料金: 高速化された Site-to-Site VPN 接続を使用する場合、Global Accelerator の利用に関連する時間単位の料金とデータ転送料金が追加で発生します。

その他の機能

• IKEv2 サポート: Internet Key Exchange バージョン 2 (IKEv2) をサポートしています。

• 暗号化オプション: AES 256 ビット暗号化や SHA-2 ハッシュなど、強固な暗号化オプションを利用できます。

問題39:

あなたはソリューションアーキテクトとして、AWS上に営業管理システム（SFA）を構築しています。このシステムには、営業担当者が日々売上データをアップロードするという業務要件があります。また、これらのデータは営業レポート用に保存される必要があり、レポートの保存先として、高い耐久性と可用性を持つストレージが求められます。また、多くの営業担当者がSFAを利用するため、操作ミスなどによってこれらの記録が誤って削除されないようにすることも重要な要件となっています。

これらの要件を満たすために、適切なデータ保護施策はどれでしょうか。

回答は正解です
Amazon S3標準ストレージクラスを利用して、バージョニング機能を有効化する。

Amazon EBS汎用ボリュームにデータを蓄積して、スナップショットを定期的に自動取得する。

Amazon S3標準ストレージクラスにデータを蓄積して、スナップショットを定期的に自動取得する。

Amazon RDS MySQLにデータを蓄積して、スナップショットを定期的に自動取得する。

全体的な説明
このシナリオにおいては、日常的に使用される営業レポートの保存先に耐久性と可用性を兼ね備えたストレージが必要です。その際、操作ミスなどによってこれらの記録が誤って消去されないようにすることが重要な要件となります。このようなドキュメントデータの保存先としては、Amazon S3（S3 Glacierを含む）が一般的です。これは、Amazon S3バケットが大量のデータを最もコスト効率よく保存できるためです。

オプション１が正解となります。利用頻度の高いデータを保存するには、S3バケットのStandard（標準）ストレージクラスが最適です。さらに、バージョニングを設定することで、オブジェクトの以前のバージョンを簡単に復元できるため、データが誤って削除された場合でも迅速に復元が可能となります。

バージョニングとは、同一バケット内でオブジェクトの複数のバージョンを保持する方法です。バージョニングを有効にすることで、Amazon S3バケットに保存されたオブジェクトに変更があった場合に、過去のバージョンを保存することができます。これにより、意図しないユーザーの操作やアプリケーションの障害によってデータが失われた場合でも、過去のバージョンから容易にデータを復旧することができます。

オプション２は不正解です。Amazon EBSの汎用ボリュームは、複数のEC2インスタンスで共有することができないため、データ共有システムに適したストレージではありません。EBSの汎用ボリュームは、EC2インスタンスに接続してサーバーのデータ処理に使用される標準的なストレージボリュームです。

オプション３は不正解です。Amazon S3にはスナップショット機能が存在しません。S3では、データが自動的に複数のアベイラビリティゾーンにレプリケートされます。また、Glacierや他のS3バケットにバックアップを保存することも可能です。

オプション４は不正解です。Amazon RDSはリレーショナルデータベースであり、主に業務システム向けのデータベース処理に使用されるため、大量データのストレージが求められている場合には利用できません。

【Amazon S3 バージョニングの詳細情報】

Amazon S3 バージョニングの仕組みと特徴を解説します。

主な機能とメリット

• データの保護と復元: バケットに保存されたすべてのオブジェクトのすべてのバージョンを保存、取得、復元できます。

• 誤削除対策: オブジェクトを「削除」しても、S3はデータを完全に消去するのではなく、削除マーカー (delete marker) を挿入します。この削除マーカーが最新バージョンとなりますが、以前のバージョンは残っているため復元が可能です。

• 上書き対策: オブジェクトを上書きすると、新しいデータが新しいバージョンとして保存され、古いデータも以前のバージョンとして保持されます。

• 同時書き込みの保護: 同時に複数の書き込みリクエストを受信した場合でも、すべてのオブジェクトバージョンが保存されます。

バケットの状態設定

S3 バケットには以下の3つのバージョニング状態があります。

バージョニングが無効 (Unversioned): デフォルトの状態です。
バージョニングが有効 (Versioning-enabled): すべてのオブジェクトのバージョン管理が行われます。
バージョニングが停止 (Versioning-suspended): 一度有効にしたバージョニングを「無効」に戻すことはできませんが、「停止」することは可能です。停止中は新しいバージョンIDの生成が中断されます。

注意点: バージョニングを有効にする前に既にバケットに存在していたオブジェクトのバージョン ID は null になります。

コストとライフサイクル管理

• 料金: 保存されるすべてのバージョンに対して通常の S3 料金が適用されます。

◦ バージョンは単なる差分ではなく、オブジェクト全体として保存されます。例えば、同じオブジェクトのバージョンを3つ保存している場合、3つ分の容量に対して課金されます。

• コスト管理 (S3 ライフサイクル):

◦ ストレージコストを抑えるため、S3 ライフサイクル機能と組み合わせて使用することが推奨されます。

◦ 例えば、「最新でないバージョン (Noncurrent versions)」を作成から一定期間後に S3 Glacier などの安価なストレージクラスへ移動したり、一定期間経過後に完全に削除したりするルールを設定できます。

◦ また、不要になった「期限切れオブジェクト削除マーカー」をクリーンアップする設定も可能です。

問題40:

ある企業は、AWS上でWEBアプリケーションを運営しています。このアプリケーションは、Amazon EC2インスタンス、ELB、およびAuto Scalingグループで構成されています。あなたはソリューションアーキテクトとして、ELBにAWS Certificate Manager（ACM）からインポートされた証明書を設定し、トラフィックをHTTPSに切り替えました。この証明書管理において、同社のセキュリティチームが各証明書の有効期限の10日前に通知を受け取るように設定する必要があります。

この要件を達成するために、ソリューションアーキテクトはどのような手段を講じるべきでしょうか。

ACM証明書の有効期限の10日前に、Amazon SNSトピックにカスタムメッセージをパブリッシュするルールをACMに追加する。

ACM証明書の有効期限をチェックするAWS Configルールを作成して、10日以内に有効期限切れになる証明書がある場合は、Amazon SNSトピック通知を発出するAmazon CloudWatchアラームを設定する。

正解
ACM証明書の有効期限をチェックするAmazon EventBridgeルールを作成して、10日以内に有効期限切れになる証明書がある場合に、Amazonトピック通知を発出する。

回答は不正解です
10日以内に期限が切れるACM証明書を検出するAmazon EventBridgeルールを作成する。AWS Lambda関数を呼び出すようにルールを設定する。Amazon SNSによってカスタムアラートを通知するようにLambda関数を設定する。

全体的な説明
このシナリオでは、AWS Certificate Manager（ACM）が発行する証明書の有効期限が10日前に達した際に自動的に通知を受け取る設定が必要です。AWS Certificate Manager（ACM）の証明書は、通信の暗号化に使用されるSSL/TLS証明書であり、これをELBやCloudFrontに適用することで、HTTPS通信を介した安全なウェブサイトへのアクセスが可能となります。

オプション３が正解となります。AWS Certificate Manager（ACM）の証明書の有効期限が10日前に達した際に自動的に通知を受け取るために、ACM証明書の有効期限を確認するAmazon EventBridgeルールを作成し、10日以内に有効期限が切れる証明書が存在することを検知します。そして、EventBridgeルールにAmazon SNSトピックを設定することで、検知結果に基づいてメール通知を行うように設定します。

Amazon EventBridgeは、アプリケーションの可用性に関する問題やリソースの変更など、システムイベントが発生した際に自動的に実行されるジョブを構築します。このサービスを活用することで、AWS Certificate Manager（ACM）のイベントをトリガーとしてアクションを実行することが可能です。

その際は、AWS_ACM_RENEWAL_STATE_CHANGEを使用して、証明書の更新状況や有効期限切れ、または有効期限が迫っていることに基づいたルールを設定できます。これにより、Amazon EventBridgeは有効期限が近づいている証明書を検出し、Amazon SNSと連携してアラーム通知を行うことができます。

オプション１は不正解です。Amazon SNSトピックのみではアラーム通知が実行できるだけであるため、有効期限が近づいている証明書を検出するためには、Amazon EventBridgeと連携する必要があります。

オプション２は不正解です。AWS Configルールを使用してACM証明書の有効期限を確認することにより、有効期限が近づいている証明書を検出することは可能ですが、その場合はConfigから直接Amazon SNS通知を設定します。したがって、CloudWatchアラートを利用してAmazon SNS通知を設定する必要はありません。AWS Configは、変更が発生した際にAmazon SNSを通じて通知を送信します。

オプション４は不正解です。Lambda関数を介してAmazon SNS通知を行う構成は不要です。Amazon EventBridgeを活用することで、有効期限が近づいている証明書を検出し、直接Amazon SNSと連携したアラーム通知を行うことができます。

【構成の詳細情報】

ACMの証明書の有効期限の10日前に通知を受け取るには、Amazon EventBridge を使用して ACM から送信されるイベントを検知し、Amazon SNS などを通じて通知する設定を行います。

デフォルトでは有効期限の「45日前」から通知イベントが開始されますが、これを「10日前」に変更するには、ACM の設定を変更するか、EventBridge 側でフィルタリングを行う必要があります。

具体的な設定手順は以下の通りです。

通知タイミング（日数）の設定

ACM はデフォルトで、有効な証明書の有効期限が切れる 45 日前から、毎日「有効期限が近づいているイベント (ACM Certificate Approaching Expiration)」を送信し始めます。

これを「10日前」に通知されるようにするには、以下のいずれかの方法をとります。

• 方法A: ACM のアカウント設定を変更する (推奨) ACM API の PutAccountConfiguration アクションを使用することで、イベントが送信され始める日数を変更できます。ここで ExpiryEvents の DaysBeforeExpiry パラメータを 10 に設定することで、有効期限の10日前からイベントが生成されるようになります。

• 方法B: EventBridge ルールで特定の日数のみをフィルタリングする ACM から送信されるイベントの JSON データには "DaysToExpiry"（有効期限までの日数）というフィールドが含まれています。EventBridge のイベントパターンでこの値を 10 に指定することで、デフォルト設定（45日前から毎日送信）のままでも、10日前のイベントだけをトリガーして通知することが可能です。

EventBridge ルールの作成

Amazon EventBridge コンソールで、ACM のイベントをキャッチするルールを作成します。

イベントパターンの定義: イベント構造に基づき、以下のようなパターンを設定します。

{
"source": ["aws.acm"],
"detail-type": ["ACM Certificate Approaching Expiration"],
"detail": {
"DaysToExpiry": [3]
}
}
※ 方法A でアカウント設定自体を10日前に変更している場合は、"DaysToExpiry": のフィルタは必須ではありませんが、ピンポイントで通知を受けたい場合には有効です。

通知先 (ターゲット) の設定

EventBridge ルールのターゲットとして Amazon SNS トピックを指定します。事前に Amazon SNS トピックを作成し、あなたのメールアドレスをサブスクライブ（登録）しておくことで、EventBridge がイベントを検知した際にメールで通知を受け取ることができます。

補足: インポートされた証明書の場合

ACM によって生成された証明書は自動更新されますが、外部からインポートした証明書は自動更新されないため、この通知設定による期限切れ前の再インポート作業が特に重要となります。

問題41:

あなたはソリューションアーキテクトとして、Webサーバーとデータベースサーバーから構成されるWebアプリケーションのアーキテクチャを設計しています。Webサーバーとデータベースサーバーは、それぞれ異なるサブネットに配置されたEC2インスタンス上にホストされる予定です。この際、セキュリティを強化するために、データベースサーバーはWebサーバーからのトラフィックのみを受け入れる必要があります。また、このWebサーバーにはAuto Scalingグループを設定して、負荷に応じてインスタンスの数を増減させる必要があります。

この要件を満たすための適切なトラフィック設定方法はどれでしょうか。

DBインスタンスのセキュリティグループのインバウンドルールにWEBサーバーインスタンスのプライベートIPアドレスを設定する。

正解
DBインスタンスのセキュリティグループのインバウンドルールにWEBサーバーインスタンスのセキュリティグループIDを設定する。

回答は不正解です
DBインスタンスのセキュリティグループのインバウンドルールにWEBサーバーインスタンスのElastic IPアドレスを設定する。

DBインスタンスのセキュリティグループのインバウンドルールにWEBサーバーインスタンスのパブリックIPアドレスを設定する。

全体的な説明
このシナリオでは、 EC2インスタンスを利用してWebサーバーとデータベースサーバーを構成しています。その際に、セキュリティを高めるためにデータベースサーバーがWebサーバーからのトラフィックのみを許可するようにセキュリティグループを設定する方法が問われています。インスタンス間の通信を制御するにはセキュリティグループを設定することになります。

オプション２が正解となります。セキュリティグループを設定する際は、ソースにCIDRを用いてIPアドレス範囲を指定するか、他のセキュリティグループIDを設定します。EC2インスタンスのWEBサーバーにAuto Scalingグループを構成している場合、Auto Scalingグループによって起動される新規インスタンスからもデータベースサーバーにアクセスできるようにセキュリティグループIDをセキュリティグループのソースに設定することが必要です。

DBセキュリティグループのソースにインスタンスのIPアドレスを設定した場合、Auto Scalingグループによって新規に起動されるEC2インスタンスのIPアドレスがDBセキュリティグループに設定できないため、その新規インスタンスはデータベースサーバーにアクセスできなくなってしまいます。

代わりに、EC2インスタンスに使用されているセキュリティグループIDをデータベースサーバー側のセキュリティグループのソースに設定することで、このセキュリティグループが設定されている全EC2インスタンスはデータベースサーバーにアクセス可能となります。これにより、Auto Scalingによって新たにインスタンスが起動された際にも、データベースへのアクセスが許可されたセキュリティグループが自動的に適用されるため、データベースとの通信が許可されることになります。

オプション１と３と４は不正解です。DBインスタンスに接続する際には、プライベートIPアドレス、パブリックIPアドレス、またはElastic IPアドレスのいずれを使用しても問題ありません。しかし、このWEBサーバーはAuto Scalingグループに設定されており、新規インスタンスが起動される可能性があります。そのため、DBインスタンス側のセキュリティグループに特定のインスタンスのIPアドレスを設定した場合、そのIPアドレスを持つインスタンスのみが通信を許可されてしまいます。結果として、Auto Scalingグループによって新たに起動されたインスタンスのIPアドレスへの通信は許可されないことになります。

【構成の詳細情報】

EC2 から RDS へ接続する場合の基本的な設定構成は以下の通りです。

セキュリティグループの役割と基本動作

• インバウンドとアウトバウンド: セキュリティグループには、入ってくるトラフィックを制御する「インバウンドルール」と、出ていくトラフィックを制御する「アウトバウンドルール」があります。

• ステートフルな動作: セキュリティグループはステートフル（状態を持つ）です。例えば、EC2 から RDS へのリクエスト（アウトバウンド）が許可されていれば、RDS からの応答トラフィック（インバウンド）は、ルールに関係なく自動的に許可されます。

RDS 側のセキュリティグループ設定（インバウンド）

RDS インスタンスに関連付けられたセキュリティグループに対して、EC2 からの接続を許可するルールを追加します。

• プロトコルとポート: データベースエンジンに応じたポート（例: MySQLなら3306、PostgreSQLなら5432など）とプロトコル（TCP）を指定します。

• 送信元 (Source) の指定: セキュリティ上のベストプラクティスとして、0.0.0.0/0（全許可）のような広い範囲を開放せず、必要な送信元のみに制限すべきです。

◦ 特定の IP アドレス: EC2 インスタンスの IP アドレス範囲を指定します。

◦ セキュリティグループ ID: 最も推奨される方法は、「EC2 インスタンスに関連付けられているセキュリティグループ」を送信元として指定することです。これにより、IP アドレスが変わっても、そのグループに属するインスタンスからのアクセスが許可されます。

EC2 側のセキュリティグループ設定（アウトバウンド）

EC2 インスタンスに関連付けられたセキュリティグループで、RDS への送信トラフィックを許可します。

• デフォルト設定: 通常、セキュリティグループを作成すると、デフォルトですべてのアウトバウンドトラフィックが許可されているため、特別な設定変更は不要な場合が多いです。

• 制限する場合: アウトバウンドルールを厳格に管理している場合は、宛先（RDS の IP またはセキュリティグループ）とポートを指定して許可ルールを追加します。

問題42:

ある企業はAmazon S3バケットにコンテンツデータを保存し、Amazon CloudFrontディストリビューションを設定することで、S3バケット内のオブジェクトをユーザーに配信するアプリケーションを運営しています。あなたはこのアプリケーションの管理者として、最近、提供されるコンテンツのURLリンクが無断で使用されていることに気付きました。他サイトからの直リンクによる不正なリソース消費（ホットリンク）を防ぐために、どうすればよいでしょうか。

この要件を満たすために必要なソリューションはどれですか。

回答は不正解です
署名付きURLを付与してオブジェクトのデータ配信を行う。

正解
AWS WAFによるリンクのReferer制限を行う。

署名付きCookiesを付与してオブジェクトのデータ配信を行う。

S3へのアクセス処理を暗号化することで、配信を制限する。

全体的な説明
オプション２が正解となります。Amazon S3バケットにCloudFrontディストリビューションを用いてコンテンツ配信を設定することで、AWS WAFを活用したReferer制限を実施することが可能です。AWS WAFのReferer制限機能は特定のURLリンクへの直接的な参照を制限することができます。

AWS WAFはウェブアプリケーションファイアウォールであり、CloudFrontに転送されるHTTPおよびHTTPSリクエストの監視や、コンテンツへのアクセス制御を実現します。指定された条件（クエリ文字列の値やリクエストの送信元IPアドレスなど）に基づき、CloudFrontはリクエストされたコンテンツを提供するか、HTTPステータスコード403（Forbidden）で応答します。

WAFのReferer制限は、HTTPリクエストに含まれるページURLに基づいて、そのURLリンクへのリクエストを制限する機能です。外部リンクから自サイトにあるファイルをダウンロードされることを防ぎたい場合などに利用されます。

オプション１と３は不正解です。このシナリオでは、外部からの直接リンクを禁止する設定が求められています。署名付きCookieや署名付きURLはアクセス期間を制限することが可能ですが、その期間中は外部でリンクを利用することができるため、要件に合致しません。

オプション４は不正解です。Amazon S3バケットへのアクセス時の通信は自動的に暗号化されており、これは通信の安全性を高めるための機能です。このため、URLリンクの参照を制限する設定は行えません。

【AWS WAFを活用したReferer制限の詳細情報】

AWS WAFや、AWSリソース（S3やCloudFront）のポリシー設定において、リンクのReferer（リファラー）制限を使用すべき要件は、主に以下のユースケースや制約がある場合です。

S3静的ウェブサイトエンドポイントをCloudFront経由で公開する場合

Amazon S3を「静的ウェブサイトホスティング」として設定し、それをCloudFrontのオリジンとして使用する場合、S3の標準的なアクセス制限機能であるOAC（Origin Access Control）やOAI（Origin Access Identity）を使用することができません。

この構成で、S3バケットへの直接アクセスを防ぎ、CloudFront経由のアクセスのみを許可するためには、以下の構成をとる必要があります。

• 要件: S3の「REST APIエンドポイント」ではなく、「ウェブサイトエンドポイント」を使用する必要がある場合（例：S3のリダイレクト機能などを利用したい場合など）。

• 対策: CloudFront側で特定のカスタムヘッダー（Refererなど）をリクエストに付与し、S3のバケットポリシーでそのRefererを持つリクエストのみを許可します。

画像やコンテンツの直リンク（ホットリンク）を防止したい場合

他社のウェブサイトが、自社の画像や動画ファイルなどを直接リンク（埋め込み）して表示することを防ぎたい場合に有効です。これにより、意図しない帯域幅の消費やコストの増加を防ぐことができます。

• 要件: 自社のドメイン以外からのリソース読み込みをブロックしたい場合。

• 対策: AWS WAFのルールを使用して、許可されたドメイン（ホワイトリスト）からのRefererを含まないリクエスト、または空のRefererを持つリクエストをブロックします。

簡易的なアクセス制御を行いたい場合（セキュリティ強度は低）

特定のウェブページやアプリケーションからの遷移であることを簡易的に確認したい場合に使用されます。

• 要件: 厳密な認証までは不要だが、ブラウザベースの正規のフローを経由していることを確認したい場合。

• 注意点: Refererヘッダーはクライアント側で容易に偽装（改ざん）が可能です。したがって、認証情報の代わりや、機密データへのアクセス制御として使用してはいけません。

問題43:

ある企業は、オンプレミス環境にあるウェブアプリケーションをAWSに移行し、冗長性と可用性を向上させるつもりです。このアプリケーションは、ウェブサーバーとMySQLデータベースで構成されており、主にデータベースに対する大量の読み取り処理が行われています。

現在、このデータベースの災害復旧対策として、1日に1回のバッチ処理によって、データベース内の全データをエクスポートして、別の地域にあるデータセンターのスタンバイ環境にインポートすることで、スタンバイDBを準備しています。この古い方式では即時のデータベース復旧ができないことが問題となっています。このデータベース処理を含むアプリケーションをAWSに移行することで、スタンバイDBへの切り替えを数分程度で実行可能にする必要があります。

この要件を満たすために、コスト効率が良いソリューションはどれでしょうか。

マルチAZ配置を有効化したAmazon RDS MySQL DBインスタンスを本番用データベースとして構成する。Mysqldumpユーティリティを使用したバックアップ/復旧プロセスを実装し、ステージング用データベースに適用する。

Amazon Aurora MySQLクラスターを本番用データベースとして構成する。Auroraレプリカを利用してレプリカを別リージョンに展開する。

回答は正解です
Amazon Aurora MySQLクラスターを本番用データベースとして構成する。Aurora グローバルデータベースを設定して、Auroraレプリカを別リージョンに展開する。

マルチAZ配置を有効化したAmazon RDS MySQL DBインスタンスおよびリードレプリカを本番用データベースとして構成する。Mysqldumpユーティリティを使用したバックアップ/復旧プロセスを実装し、ステージング用データベースに適用する。

全体的な説明
このシナリオでは、AWSへのアプリケーション移行に際して、WEBサーバーとMySQLデータベースの冗長性および可用性を向上させるソリューションが求められています。特に、現在のアプリケーションはプライマリー構成とは異なる地域にスタンバイ構成を有しており、エクスポートおよびインポートを用いてデータの同期を行っています。このアプリケーションをAWSに移行することで、スタンバイ構成処理の自動化とパフォーマンスの向上を図る必要があります。

オプション３が正解となります。通常のAuroraレプリカは別リージョンには展開できませんが、Auroraグローバルデータベース機能を利用することで、Auroraレプリカを別リージョンに展開することができます。これによって、AuroraレプリカのクロスリージョンレプリケーションによってプライマリDBとの同期が自動的に実行されます。

DB クラスターのプライマリインスタンスが失敗した場合、Aurora は次の 2 つの方法のいずれかで、新しいプライマリインスタンスに自動的にフェイルオーバーします。

既存の Aurora レプリカを新しいプライマリインスタンスに昇格する

新しいプライマリインスタンスを作成する

DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格します。障害イベントによって短い中断が発生し、その間は読み取りと書き込みオペレーションが失敗しますが、復元時間は 60 秒未満であり、多くの場合 30 秒未満です。したがって、この構成により、スタンバイDBへの切り替えを数分以内に実行するという要件を達成することができます。

オプション１は不正解です。Mysqldumpユーティリティを用いたバックアップおよび復旧プロセスを実施する方法は、運用の自動化を十分に実現することはできません。また、Amazon RDSのマルチAZ配置だけでは、複数リージョンでのデータベース同期は実施できません。

オプション２は不正解です。Auroraレプリカはグローバルデータベースを利用しない限り、別リージョンにレプリカを展開できません。

オプション４も不正解です。Mysqldumpユーティリティを使用したバックアップおよび復旧プロセスを実施し、ステージング用データベースに適用する方法は、AWSの機能に依存していないため、運用の自動化を十分に達成することはできません。

【Amazon Aurora Global Databaseの詳細情報】

Amazon Aurora において、クロスリージョンでリードレプリカ（読み取り専用の複製）を別リージョンに展開するには、Amazon Aurora Global Database 機能を使用します。この機能を利用することで、単なる非同期レプリケーション以上のパフォーマンスと可用性を実現できます。

構成と仕組み

Aurora Global Database は、複数の AWS リージョンにまたがる単一のデータベースとして機能します。

• プライマリとセカンダリ: 1つのリージョンに書き込み可能な「プライマリ DB クラスター」を配置し、最大 10 個の異なるリージョンに読み取り専用の「セカンダリ DB クラスター」を作成できます。

• 物理レプリケーション: 従来のデータベースエンジンの論理レプリケーション（バイナリログなど）ではなく、専用のインフラストラクチャを使用したストレージレベルの物理レプリケーションを行います。これにより、通常 1 秒未満の低レイテンシーでデータがセカンダリリージョンへ複製され、プライマリクラスターのパフォーマンスへの影響もほとんどありません。

• 読み取りのスケーリング: 各セカンダリリージョンのクラスターには、Aurora リーダーインスタンス（読み取り専用インスタンス）を追加することで、ローカルな読み取り負荷に対してスケールさせることができます（1クラスターあたり最大16インスタンスまでサポート）。

書き込みとエンドポイント

• 書き込み操作: 書き込みは常にプライマリリージョンのプライマリ DB クラスターに対して行います。クライアントは「Aurora Global Database ライターエンドポイント」に接続することで、現在プライマリとなっているクラスターへ適切にルーティングされます。

• 書き込み転送 (Write Forwarding): セカンダリクラスターからプライマリクラスターへ書き込みリクエストを転送する「書き込み転送」機能を設定することも可能です。

可用性と災害復旧 (DR)

Global Database は、リージョン全体に影響する障害からの復旧手段として強力な機能を提供します。

• スイッチオーバー (計画的): 運用手順の一環として、データ損失なしでプライマリクラスターを別のリージョンのセカンダリクラスターへ切り替えることができます（役割のローテーションなど）。

• フェイルオーバー (計画外): プライマリリージョンが停止した場合、クロスリージョンフェイルオーバーを実行して、セカンダリクラスターを新しいプライマリに昇格させることができます。これにより、低い RTO (目標復旧時間) と RPO (目標復旧時点) での復旧が可能です。

制約事項と要件

Aurora Global Database の利用にはいくつかの制限があります。

• バージョン制限: 特定の AWS リージョンおよび Aurora MySQL/PostgreSQL の特定のバージョンでのみ利用可能です。

• 非対応機能: Aurora Serverless v1 や Aurora バックトラック機能は現在サポートされていません。

• バージョンの整合性: マネージドなスイッチオーバーやフェイルオーバーを実行するには、プライマリとセカンダリのクラスターでメジャーおよびマイナーバージョンが一致している必要があります（パッチレベルは異なることが許容される場合があります）。

• 構成変更の注意: グローバルデータベースクラスターの一部である DB インスタンスに対して「マイナーバージョンの自動アップグレード」設定を行っても効果はありません。また、グローバルデータベースのメジャーバージョンアップグレード中はカスタムパラメータグループを適用できないなどの制約があります。

問題44:

ある企業がサーバーレスアプリケーションを開発しています。このアプリケーションは、Amazon API Gatewayを介して呼び出されるAWS Lambda関数で構成されています。このLambda関数は顧客データを取得し、Amazon Aurora MySQLデータベースに保存します。しかし、Amazon Aurora MySQLデータベースのアップグレード中は、アップグレードが完了するまでLambda関数がデータベースに接続できず、その間に発生したデータは保存されません。あなたはソリューションアーキテクトとして、更新期間中のデータを保存する方法を考慮する必要があります。

この要件を満たすために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

Lambda関数が顧客データをLambdaのローカルストレージに保持し、このローカルストレージをスキャンして、顧客データをAuroraデータベースに保存する。

回答は正解です
Lambda関数が取得した顧客データをAmazon SQSキューに保存する。別のLambda関数がこのキューをポーリングして、顧客データをAuroraデータベースに保存する。

Lambda関数の実行時間を上限まで増やす。その上で、このLambda関数でデータベースへの接続に失敗した場合の再試行処理を実装する。

Amazon RDSプロキシをプロビジョニングし、このRDSプロキシに接続するようにLambda関数を構成する。

全体的な説明
このシナリオでは、Amazon Aurora MySQLデータベースの更新中にLambda関数とデータベースとの接続が失われることで、リクエストされたデータ処理がMySQLデータベースに記録されないという問題が生じています。したがって、Lambda関数がデータベース接続に失敗した場合でも、取得したデータが失われないように、処理中にデータを保持する仕組みが求められます。

オプション２が正解となります。Lambda関数が取得したデータをAmazon SQSキューに一旦保存してから、別のLambda関数がそのキューからデータをポーリングしてAuroraデータベースに保存するように構成することで、DB更新中のデータ喪失を防ぐことができます。

Amazon RDSやAmazon Aurora MySQLデータベースでは、DBソフトウェアのアップグレードなどのメンテナンス作業中にダウンタイムが発生する可能性があります。通常、メンテナンスウィンドウを設定し、夜間などの影響が少ない時間帯にメンテナンスを行うことで、通常の稼働に支障をきたさないようにしていますが、24時間稼働するワークフローでは、今回のような問題が発生するリスクがあります。このような状況においては、データベースへのデータ登録に欠損が生じない構成が求められます。

Lambda関数はAmazon SQSキューと連携することで、キューを介した疎結合化されたデータ処理を行うことが可能です。Amazon SQSキューはメッセージ内にデータを保持し、後続の処理を行うコンシューマーがデータを取得するまで保持し続けます。この仕組みを活用し、Lambda関数が取得した顧客データをSQSキューに一旦保存し、その後メッセージをバックエンドのLambda関数がポーリングしてデータ処理を行うことで、Amazon Aurora MySQLデータベースのアップグレード時にデータが記録されない問題を回避することができます。

オプション１は不正解です。AWS Lambdaでは、512 MBから10,240 MBの範囲でエフェメラルストレージ（/tmp）を設定することが可能です。このストレージは、データの読み書き時に使用される一時的な保存領域です。しかし、データベースに一時的に接続できない場合に、エフェメラルストレージにデータを保存し、再接続時に他のLambda関数でそのデータを利用することはできません。このストレージは、あくまで単一のLambda関数内での処理中に限って使用されるものです。

オプション３は不正解です。Lambda関数の実行時間は最大15分まで延長可能ですが、Amazon Aurora MySQLデータベースのアップグレード中に接続エラーが発生することは変わりません。また、Lambda関数がデータベースへの接続に失敗した場合、再試行処理を実装しても、再試行前のデータが失われるリスクがあります。

オプション４は不正解です。Lambda関数をRDSプロキシに接続するように設定しても、Amazon Aurora MySQLデータベースのアップグレード時には接続できないという状況は変わりません。

【構成の詳細情報】

Amazon SQS キューから AWS Lambda 関数がメッセージをポーリングして処理するためには、Lambda 側の「イベントソースマッピング」という機能を利用します。この構成では、Lambda サービス自体がキューをポーリングし、メッセージを取得して関数を同期的に呼び出します。

必要な設定手順と権限、重要なパラメータについて解説します。

必要な IAM 権限 (Lambda 実行ロール)

Lambda 関数に関連付けられた実行ロールには、SQS キューを操作するための以下の権限を含める必要があります。

• sqs:ReceiveMessage: キューからメッセージを受信するため。

• sqs:DeleteMessage: 処理が成功したメッセージをキューから削除するため。

• sqs:GetQueueAttributes: キューの属性情報を取得するため。

暗号化されたキューの場合: SQS キューが AWS KMS カスタマー管理キーで暗号化されている場合は、実行ロールに kms:Decrypt の権限も追加する必要があります。

設定手順 (コンソールでの設定例)

Amazon SQS コンソールから設定を行うのが一般的です。

キューの選択: SQS コンソールで対象のキューを選択します。
トリガーの設定: 「Lambda トリガー」タブを選択し、「Lambda 関数トリガーを設定する」をクリックします。
関数の指定: 呼び出したい Lambda 関数の ARN を入力するか、リストから選択して「保存」します。

◦ 関連付けが完了するまで約 1 分かかります。

重要なパラメータ設定

安定した処理を行うために、以下の設定を調整する必要があります。

• 可視性タイムアウト (Visibility Timeout): キューの可視性タイムアウトは、Lambda 関数のタイムアウト値の 6 倍以上に設定することが推奨されています。これにより、関数がスロットリングされたり処理に時間がかかったりした場合でも、Lambda が再試行するための十分な時間を確保できます。

• バッチサイズ: Lambda はデフォルトで最大 10 件のメッセージを一度にポーリングし、バッチとして関数に渡します。

• バッチウィンドウ: 少数のレコードでの頻繁な呼び出しを避けるため、最大 5 分間レコードをバッファリングしてから関数を呼び出すように設定することも可能です。

メッセージ処理の挙動と注意点

• 処理成功時: Lambda 関数がバッチ内のメッセージを正常に処理して終了すると、Lambda サービスが自動的にそのメッセージをキューから削除します。

• 処理失敗時: 関数がエラーを返した場合、メッセージは削除されず、可視性タイムアウト経過後に再びキューに表示され、再処理の対象となります。

• 冪等性 (Idempotency): 重複してメッセージが処理される可能性があるため、関数コードは同じメッセージを複数回処理しても副作用がないように（冪等に）設計することが強く推奨されます。

• デッドレターキュー (DLQ): 処理に繰り返し失敗したメッセージを退避させるため、デッドレターキューの設定が推奨されます。

問題45:

あなたはソリューションアーキテクトとして、現在開発中のアプリケーションにAWSのメッセージングサービスを活用したメッセージ処理機能を追加する計画を立てています。最も重要な要件は、メッセージの順序が維持され、重複したメッセージが送信されないことです。

この要件を満たすために、最適なソリューションはどれでしょうか。（２つ選択）

選択は正解です
Amazon SQSのFIFOキューを利用する。

選択は正解です
Amazon SNSのFIFO トピックを利用する。

Amazon SESのFIFO トピックを利用する。

AWS Lambdaでメッセージを順序通りに処理する関数を設定する。

Amazon StepFunctionsを利用して、メッセージを順序通りに処理するワークフローを設定する。

全体的な説明
このシナリオでは、アプリケーションにおいてAWSのメッセージングサービスを活用し、メッセージの順序を維持し、重複メッセージの送信を防ぐ仕組みが求められています。

AWS上でメッセージング処理を構築する際には、Amazon SQSキュー、Amazon SNS、またはAmazon MQを利用することが考えられます。今回の要件では、「メッセージの順序を保持し、重複メッセージが送信されないこと」が特に重要なポイントとなります。

オプション１が正解となります。 Amazon SQSのFIFOキューは、メッセージの順序を確保し、少なくとも1回のメッセージ配信を実現しています。

Amazon SQSは、完全に管理されたメッセージキューイングサービスです。このサービスを利用することで、分散型ソフトウェアシステムやコンポーネントをキューを介して統合または分離することが可能になります。キューは、受信したデータやメッセージを到着順に並べ、最初に入った要素から順に取り出すというルールに基づいてメッセージを配信します。これは、レジ待ちの状況に例えると、先に並んでいた人が最初に呼ばれ、後から来た人はその後ろに並ぶという形でメッセージが配信されることを意味します。

Amazon SQSでは、標準キューとFIFOキューの2種類を利用することができます。標準キューはメッセージの順序を保証しない一方で、FIFOキューは高いスループットを提供し、最善の努力による順序付けと少なくとも1回の配信を保証します。さらに、FIFOキューはメッセージ重複排除IDを使用することで、重複メッセージの発生を防ぐことができます。このメッセージ重複排除IDは、送信されたメッセージの重複を排除するためのトークンとして機能します。特定のメッセージ重複排除IDを持つメッセージが正常に送信された場合、そのIDを持つメッセージは5分間の重複排除間隔中に配信されることはありません。

オプション２も正解となります。Amazon SNSはプッシュ型メッセージングサービスであり、SNS FIFOトピックの導入により、複数のサブスクライバーに対して厳密なメッセージの順序を維持し、重複を排除したメッセージ配信が可能となります。

オプション３は不正解です。Amazon SESは、電子メール機能を実装するためのサービスです。メール通知を行うことが主な目的であり、メッセージの順序については保証されていません。

オプション４は不正解です。AWS Lambda関数はメッセージの送受信機能を持っていませんが、Amazon SNSやAmazon SQSからメッセージを受け取ってLambda関数を実行する構成は可能です。そのため、メッセージの順序はAmazon SQSやAmazon SNSに依存することになります。

オプション５は不正解です。Amazon Step Functionsはワークフローを構築するためのサービスであり、メッセージを処理する機能を提供するものではありません。

【Amazon SQS FIFOキューの詳細情報】

Amazon SQS の FIFO (First-In-First-Out) キューとは、メッセージが送信された正確な順序を保持し、かつメッセージが重複して処理されないように設計されたキューの種類です。FIFO キューの主な特徴と仕組みを解説します。

主な特徴

FIFO キューは、標準キューとは異なり、以下の機能を提供します。

• 順序の保証: メッセージは送信された順序通りに受信・処理されます。 SequenceNumber（シーケンス番号）が含まれており、順序付けが管理されています。

• 重複排除 (Exactly-Once Processing): メッセージが重複して配信・処理されるのを防ぎます。MessageDeduplicationId（メッセージ重複排除 ID）という属性が含まれており、これを使用して重複を除外します。

• メッセージグループ: MessageGroupId を使用することで、特定のグループ内での順序を保ちつつ、複数のグループを並行して処理することが可能です。

命名規則

FIFO キューを作成する場合、キューの名前は必ず .fifo というサフィックス（接尾辞）で終わる必要があります。

• 例: arn:aws:sqs:us-east-2:123456789012:fifo.fifo

ユースケース

標準キューでは「少なくとも 1 回」の配信が保証されるため重複が発生する可能性がありますが、FIFO キューは順序付けと重複排除の機能により、銀行取引の処理など、順序と正確性が重要なアプリケーションに適しています。

問題46:

あなたはソリューションアーキテクトとして、AWS上にドキュメント共有アプリケーションを設計しています。このアプリケーションでは、ユーザーがウェブインターフェースまたはモバイルアプリを通じてドキュメントをアップロードすることが可能です。厳格なセキュリティ要件に基づき、すべてのユーザーが新たにアップロードしたドキュメントを保存後に変更または削除できないようにする必要があります。

この要件を達成するために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。

回答は正解です
S3オブジェクトロックのコンプライアンスモードを有効にしたS3バケットを作成して、その中にドキュメントを保存する。

アップロードされたドキュメントをAmazon S3バケットに保存する。さらに、アーカイブをGlacierに移行してボールトロックを適用する。

S3オブジェクトロックのガバナンスモードを有効化したS3バケットを作成して、その中にドキュメントを保存する。

S3バケットを作成した後、プロパティ変更画面でS3オブジェクトロックのガバナンスモードを有効にする。そのバケットの中にドキュメントを保存する。

全体的な説明
このシナリオでは、Amazon S3バケットに保存される新しいドキュメントが、保存後に変更や削除ができないようにすることが求められています。したがって、Amazon S3バケットの設定において、保存されたデータが削除されないようにする方法を選択する必要があります。主な方法は以下の通りです。

・Amazon S3バケットにMFA Delete機能を導入し、ユーザーがデータを削除する際にMFAの入力を必須とすることで、誤って削除されることを防ぐ。

・Amazon S3バケットの初期設定で、データが削除されないようにS3バケットをロックする。

今回の要件は、新しいドキュメントが保存後に変更や削除ができないことであるため、後者の方法が適切な回答となります。

オプション１が正解となります。S3オブジェクトロックを有効にしたS3バケットを作成し、そのバケット内にドキュメントを保存することで、Amazon S3バケットに保存された新しいドキュメントは、保存後に変更や削除が不可能となります。S3オブジェクトロックは、Write Once Read Many (WORM) モデルを採用してオブジェクトを保存します。また、オブジェクトロックのコンプライアンスモードを利用することで、オブジェクトの削除や上書きを一定期間または無期限に防ぐことができます。

オプション２は不正解です。アップロードされたドキュメントをAmazon S3バケットに保存後、アーカイブをGlacierに移行することはデータを二重に移動させることになり、効率的ではありません。また、ボールトロックはボールトロックポリシーに基づいてAmazon S3 Glacierへのアクセスを制御する機能であり、これによりデータ削除を防ぐ設定はできません。

オプション３は不正解です。S3オブジェクトロックのガバナンスモードでは、ルートユーザーなどの特定の管理者がデータを削除することが可能です。このため、どのユーザーでも新しいドキュメントを保存後に変更や削除ができないという要件には適合しません。

オプション４は不正解です。以前はS3オブジェクトロックはS3バケットを作成後に有効化することができませんでしたが、現在は後からS3バケットのオブジェクトロックを有効化することが可能となっています。しかしながら、S3オブジェクトロックのガバナンスモードでは、ルートユーザーなどの特定の管理者がデータを削除することが可能であるため、要件に合致しません。

【S3 オブジェクトロックの詳細情報】

S3 オブジェクトロックとは、Amazon S3 オブジェクトが一定期間、または無期限に削除や上書きされるのを防ぐ機能です。WORM (Write-Once-Read-Many) モデルを使用してオブジェクトを保存し、規制要件への準拠や、誤操作・悪意ある操作からのデータ保護に役立ちます。

この機能を使用するには、S3 バケットのバージョニングが有効になっている必要があります。

主な機能と仕組みは以下の通りです。

ロックの管理方法

オブジェクトの保持を管理するために、以下の2つの方法が提供されています。

• 保持期間 (Retention Period): オブジェクトをロックする期間を日数または年単位で指定します。

◦ 個々のオブジェクトバージョンに設定できるほか、バケット全体にデフォルト設定として適用することも可能です。

◦ 保持期間は延長することができますが、モードによっては短縮できません。

• リーガルホールド (Legal Hold): 有効期限を持たないロック機能です。

◦ 保持期間とは独立して機能し、明示的に解除されるまでロックが維持されます。

◦ 外部監査が完了するまでデータを保持する場合など、期間が不明確な場合に適しています。

リテンションモード (保持モード)

保持期間を設定する場合、以下の2つのモードから選択する必要があります。

• コンプライアンスモード: 最も強力な保護レベルです。AWS アカウントのルートユーザーを含め、誰も保護されたオブジェクトバージョンの上書きや削除ができません。

◦ 保持期間の短縮やモードの変更もできません。

◦ 期間中に削除する唯一の方法は、AWS アカウント自体を削除することです。

• ガバナンスモード: ほとんどのユーザーによる削除を防ぎますが、特別な権限を持つユーザーによる変更を許可するモードです。

◦ s3:BypassGovernanceRetention 権限を持つユーザーは、保持設定の変更やオブジェクトの削除が可能です。

◦ コンプライアンスモードを適用する前のテストや、一部の管理者に操作権限を残したい場合に使用されます。

削除操作時の挙動

ロックされたオブジェクトに対して削除リクエストが発生した場合、以下の動作をします。

• バージョンIDを指定した削除 (永続的削除): アクセス拒否 (403 Forbidden) エラーが返され、削除できません。

• バージョンIDを指定しない削除 (シンプルな削除): 削除マーカーが挿入され、見かけ上は削除されますが、データ自体（古いバージョン）は保護されたまま残ります。

問題48:

ある企業は、AWS上でホストされている業務アプリケーションを活用し、日々の業務に関連する記録管理を行っています。業界の規定に従い、記録データは5年間保存する必要があります。これらの記録の大部分はあまりアクセスされませんが、監査の要求に応じて、24時間以内にデータを提供する義務があります。

この状況において、選択するべきコスト効率の良いストレージはどれでしょうか。

回答は不正解です
Amazon Glacier Flexible Retrieval

正解
Amazon S3 Glacier Deep Archive

S3 Standard

S3 One-Zone IA

S3 Standard IA

全体的な説明
このシナリオでは、S3バケットのストレージクラスを最適に選択する方法についての問題が提示されています。今回の要件は、データを中長期的に5年間保存しつつ、24時間以内にデータを取り出すこと、およびコスト効率が良いストレージクラスを選択することです。

オプション２が正解となります。Glacier Deep Archive ストレージクラスは、S3およびGlacierのストレージクラスの中で最もコスト効率の高いストレージです。このストレージでは、データが3つ以上のAWSアベイラビリティゾーンに分散して保存されており、他のS3ストレージと同様に高い耐久性を確保しています。ただし、アーカイブデータの取得には最大12時間を要するため、データの取り出しに時間がかかるという制約があります。今回は24時間以内にデータを抽出できれば問題ないため、データ取得に時間がかかることは特に懸念されません。そのため、最も経済的なGlacier Deep Archive ストレージクラスを選択することにします。

オプション１は不正解です。Amazon Glacier Flexible Retrievalは、アーカイブ用ストレージとしてAmazon S3の他のストレージクラスよりも低コストでデータを長期間保存できるストレージタイプです。ただし、Glacier Deep Archiveストレージクラスよりも価格が高いため、最も安価なストレージとは言えません。Amazon Glacier Flexible RetrievalはGlacier Deep Archiveよりも若干高価ですが、迅速なデータ取得が可能で、1分から5分程度でデータを取り出すことができます。

オプション３は不正解です。S3 StandardはS3の中で最も高コストなストレージであり、頻繁に使用されるデータを保存するためのものであり、今回の要件には適合しません。

オプション４は不正解です。S3 One Zone-IAは、アクセス頻度が低いデータを単一のアベイラビリティーゾーンに保存することでコストを削減しますが、Glacier Deep Archiveストレージクラスの方がS3 One Zone-IAよりも安価です。

オプション５は不正解です。Standard-IAは低頻度アクセス用のストレージですが、迅速な読み込みが可能なため、突発的なデータ利用にも対応できます。しかしながら、Glacier Deep Archiveストレージクラスの方がStandard-IAよりもコストが安いです。

問題49:

ある企業は、Amazon Route 53パブリックホストゾーンで公開されている単一のAmazon EC2インスタンスにホストされたウェブアプリケーションを運用しています。また同インスタンスはMySQLデータベースも同時に実行しています。ソリューションアーキテクトは、アプリケーションをスケーラブルで高可用性なアーキテクチャに再構成して、MySQLの読み取りレイテンシーも削減することが求められています。

これらの要件を満たすソリューションの組み合わせはどれでしょうか。（2つ選択）

選択は正解です
複数のアベイラビリティーゾーンにEC2インスタンスを展開するようにALBとAuto Scalingグループを設定する。

別リージョンに2つ目のEC2インスタンスを起動する。Route53のフェイルオーバールーティングポリシーを使用して、両方のリージョン内のEC2インスタンスにルーティングを構成する。

選択は不正解です
データベースをAmazon Aurora MySQLのグローバルデータベースに移行して、クロスリージョンリードレプリカを構成する。

正しい選択
データベースをAmazon Aurora MySQLクラスターに移行して、プライマリDBインスタンスとリーダーDBインスタンスを別々のアベイラビリティーゾーンに作成する。

データベースをAmazon Aurora MySQLのグローバルデータベースに移行して、マルチAZ配置を有効化する。

全体的な説明
このシナリオでは、Amazon Route 53パブリックホストゾーンで公開されている単一のAmazon EC2インスタンスにホストされたウェブアプリケーションを、スケーラブルで高可用性なアーキテクチャに再構成することが求められています。また、MySQLの読み取りレイテンシーを削減することも必要です。

オプション１が正解となります。現在のアプリケーションは単一のAmazon EC2インスタンスにホストされているため、単独のAZ障害に対して脆弱な構成となっています。したがって、複数のアベイラビリティーゾーンにEC2インスタンスを展開するようにALBとAuto Scalingグループを設定し、AZ障害に強いマルチAZ構成に変更します。

AWSで柔軟かつスケーラブルなサーバー処理を実現するためには、EC2インスタンスにAuto ScalingとELBを設定することが不可欠です。ELBはトラフィックを複数のインスタンスに分散させることで冗長性を向上させます。また、Auto Scalingは高負荷時に自動的にインスタンス数を増減させてスケーリングを行います。

オプション４が正解となります。MySQLの読み取りレイテンシーを削減するためには、データベースをAmazon Aurora MySQLクラスターに移行し、プライマリDBインスタンスとリーダーDBインスタンスを異なるアベイラビリティーゾーンに作成します。これにより、リーダーDBインスタンスによって読み取り処理が分散されるため、読み取りレイテンシーを削減することが可能になります。

Aurora では、ストレージとコンピューティングが分離されており、データ自体は自動的に複数の AZ に複製されますが、DB インスタンス（コンピューティング）を複数の AZ に分散配置することで、インスタンス障害や AZ 障害時の可用性を高めることができます。

オプション２は不正解です。Route53のフェイルオーバールーティングポリシーを利用して、複数のリージョンにあるEC2インスタンスへのルーティングを設定する方法は、DR対応などの目的において必要な構成です。

オプション３と５は不正解です。Amazon Aurora MySQLのグローバルデータベースは、複数のAWSリージョンにまたがる複数のAurora DBクラスターを設定できる非常に冗長性の高い構成です。これはMySQLの読み取りレイテンシーを低減するためには不要な冗長性となります。

【EC2インスタンスのマルチAZ構成の詳細情報】

Application Load Balancer (ALB) と Auto Scaling グループ (ASG) を組み合わせて、複数のアベイラビリティーゾーン (AZ) に EC2 インスタンスを展開し、高可用性を確保するための設定方法は以下の通りです。

基本的な考え方は、「ALB と ASG の両方で、複数の AZ に対応するサブネットを指定する」ことです。

ネットワーク要件の確認

まず、使用する VPC 内で、少なくとも 2 つのアベイラビリティーゾーンにそれぞれサブネットを作成しておく必要があります。

• ALB (Application Load Balancer) を使用する場合、最低でも 2 つのアベイラビリティーゾーンを有効にする必要があります。

ALB (ロードバランサー) の設定

ロードバランサーがトラフィックを分散できるように、各 AZ のサブネットをマッピングします。

• アベイラビリティーゾーンの有効化: ALB の設定（「ネットワークマッピング」セクション）で、トラフィックをルーティングしたい各アベイラビリティーゾーンを選択し、そのゾーン内のサブネットを 1 つずつ指定します。

• 動作: これにより、ALB は有効化された各 AZ にロードバランサーノードを作成し、そこへトラフィックをルーティングできるようになります。

◦ 注意: ロードバランサー側で有効にしていない AZ にインスタンスが存在していても、そのインスタンスへはトラフィックがルーティングされません。

Auto Scaling グループ (ASG) の設定

Auto Scaling グループがインスタンスを起動する場所として、複数の AZ を指定します。

• サブネットの選択: ASG の作成時または編集時（「ネットワーク」セクション）に、ALB で指定したものと同じ複数のアベイラビリティーゾーン（サブネット）を選択します,。

• 均等な分散 (Rebalancing): ASG は指定されたすべてのアベイラビリティーゾーンにわたって、インスタンスの数を均等に保とうとします。

◦ 新しいインスタンスを起動する際、ASG はインスタンス数が最も少ない AZ での起動を試みます。

◦ ある AZ が障害などで使用できなくなった場合、ASG は影響を受けていない他の AZ で新しいインスタンスを起動します。

◦ 障害が発生していた AZ が復旧すると、ASG は自動的にインスタンスを再配置し、ゾーン間のバランスを整えます。

トラフィック分散の最適化

• クロスゾーン負荷分散: ロードバランサーで「クロスゾーン負荷分散」が有効になっていると、各ロードバランサーノードは、自分の AZ 内だけでなく、有効化されたすべての AZ 内の登録済みインスタンスへ均等にトラフィックを分散します。これにより、特定の AZ にインスタンスが偏った場合でも、負荷を均等に保つことができます。

(参考) 静的安定性 (Static Stability) に基づく設計

より高い耐障害性を求める場合は、Auto Scaling による事後的な復旧に頼るだけでなく、「静的安定性」を考慮した設計が推奨されます。

• 設計方針: 障害発生後に Auto Scaling でインスタンスを追加するのを待つのではなく、1つの AZ がダウンしても残りの AZ だけでピーク時の負荷を処理できる台数を最初から稼働させておきます。

• メリット: Auto Scaling の起動遅延や失敗のリスクを排除し、障害発生直後からサービスレベルを維持できます。

【AuroraDBのマルチAZ構成の詳細情報】

データベースを Amazon Aurora MySQL クラスターに移行し、プライマリ（ライター）DB インスタンスとリーダー（レプリカ）DB インスタンスを別々のアベイラビリティーゾーン (AZ) に配置して高可用性を確保する手順と構成について解説します。

構成の概要

Aurora DB クラスターは以下の2種類のインスタンスで構成されます。

• プライマリ (ライター) DB インスタンス: 読み書き両方に対応し、クラスターへのすべてのデータ変更を実行します。各クラスターに1つ存在します。

• Aurora レプリカ (リーダー) DB インスタンス: 読み取り専用ですが、プライマリに障害が発生した際のフェイルオーバーターゲット（昇格候補）となります。最大15個まで作成可能です。

これらを別々の AZ に配置することで、プライマリがある AZ に障害が発生しても、別 AZ のリーダーが自動的に新しいプライマリに昇格し、ダウンタイムを最小限に抑えることができます。

別々のAZに作成する手順

移行プロセス（スナップショットからの復元や DMS の使用など）を経てクラスターを作成する際、または作成後に以下の手順で構成します。

手順 A: クラスター作成時 (またはスナップショット復元時)

通常、クラスター作成時に「マルチ AZ 配置」を選択するか、異なる AZ にリーダーを作成する設定を行います。

サブネットグループ: クラスターを作成する際、少なくとも 2 つ以上の AZ を含む DB サブネットグループを指定します。
インスタンスの作成: 最初にプライマリインスタンスが作成されます。

手順 B: 既存クラスターへのリーダー追加 (推奨・確実な方法)

プライマリインスタンスのみが存在する状態（シングル AZ）から、別の AZ にリーダーを追加してマルチ AZ 化するのが一般的です。

リーダーの追加: AWS マネジメントコンソールで対象の Aurora クラスターを選択し、「アクション」から**「リーダーの追加 (Add reader)」**を選択します。
AZ の指定: 設定画面の「アベイラビリティーゾーン」の項目で、現在のプライマリインスタンスとは異なる AZ を明示的に指定します。
作成: 設定を完了すると、指定した AZ に Aurora レプリカ（リーダー）が作成され、データの同期は共有ストレージを通じて自動的に行われます。
フェイルオーバーと接続エンドポイント

別々の AZ に配置することで、以下の挙動が可能になります。

• 自動フェイルオーバー: プライマリインスタンスに障害が発生した場合、Aurora は自動的に別 AZ のリーダーを新しいプライマリに昇格させます。この処理は通常 30 秒未満、多くの場合それより短時間で完了します。

• エンドポイントの利用: アプリケーションは、特定のインスタンスのエンドポイントではなく、以下の抽象化されたエンドポイントを使用することで、昇格後も設定変更なしで接続を維持できます。

◦ クラスターエンドポイント: 常に現在のプライマリ（ライター）を指します。書き込み処理に使用します。

◦ リーダーエンドポイント: クラスター内のすべてのリーダー間で読み取りトラフィックを分散します。

補足: データの耐久性について

Aurora はインスタンスの配置にかかわらず、クラスターボリューム（ストレージ層）のデータを 3 つの AZ にまたがって 6 つのコピーとして保存します。したがって、インスタンスを別々の AZ に分ける主な目的は、データの保護ではなく、データベースサービス（接続・処理能力）の可用性維持にあります。

問題50:

ある企業は、AWSを活用して社内文書の管理および保存を行うソリューションを構築しています。保存されたデータは通常はほとんど使用されませんが、必要に応じて管理者の指示に従い、10時間以内にデータを取得することが求められています。あなたはソリューションアーキテクトとして、Amazon Glacier Flexible Retrievalを利用して、データの利用要件を満たしつつ、コスト最適な設定をする必要があります。

Glacier Flexible Retrievalクラスに必要な設定はどれでしょうか。

回答は不正解です
迅速取り出し

正解
標準取り出し

大容量取り出し

ボールトロック

全体的な説明
今回のシナリオでは、Amazon Glacier Flexible Retrievalの最適な設定方法が問われています。この種の質問は、01版の試験形式において一般的であり、出題された際には確実に正解すべき基本的な問題です。

オプション２が正解となります。管理者の指示に従い、10時間以内にデータを取得する必要があるため、Amazon Glacier Flexible Retrievalの標準取り出しが最適な設定となります。標準取り出しを利用することで、3〜5時間以内にすべてのアーカイブにアクセス可能です。

オプション１は不正解です。Amazon Glacier Flexible Retrievalの迅速取り出しは、Glacierからアーカイブデータを取得する際に、最も迅速にデータにアクセスできる方法です。最大サイズのアーカイブ（250 MB以上）を除くすべてのアーカイブについて、迅速取り出しを利用した場合、データは通常1〜5分以内に利用可能となります。しかしながら、「迅速取り出し」は「標準取り出し」に比較して、データ取得時間が早い分、データ取得コストが高くなります。

オプション３は不正解です。Amazon Glacier Flexible Retrievalの大容量取り出しは、Glacierにおける最もコスト効率の良い取り出しオプションであり、ペタバイト規模のデータを1日以内に取得することが可能です。通常、大容量取り出しには5〜12時間を要するため、10時間以内の対応はできません。

オプション４は不正解です。Glacierのボールトロック機能を使用すると、ボールトロックポリシーを通じて各ボールトに対するコンプライアンス管理を容易に展開し、適用することができます。ボールトロックポリシーでは「write once read many」（WORM）などの制御を指定し、ポリシーをロックすることで、今後の編集を不可能にします。この機能はコンプライアンス対応向けの機能であって、今回の要件には関連性がありません。

【詳細情報】

Amazon S3 Glacier のアーカイブを取得（取り出し・復元）する方法について解説します。

S3 Glacier からのデータ取得は非同期オペレーションであり、リクエストを行ってからデータが利用可能になるまでに待機時間が発生します。また、利用しているのが「S3 バケット内の Glacier ストレージクラス」か、従来の「Amazon Glacier ボールト（Vault）」かによって手順が異なります。

S3 オブジェクトとしての取得（S3 Glacier ストレージクラス）

S3 バケット内のオブジェクトとして保存されている場合（Glacier Flexible Retrieval や Deep Archive など）、直接ダウンロードすることはできず、一時的なコピーを作成する「復元」操作が必要です。

• 手順:

復元の開始: S3 コンソールや CLI を使用して、対象のファイル（オブジェクト）を選択し、「復元 (Restore)」アクションを実行します。
オプション指定: 復元されたコピーを利用可能にしておく日数と、取り出しオプション（Standard、Bulk など）を指定します。
待機: 指定したオプションに応じた時間が経過すると、一時的なコピーが作成されます。
ダウンロード: 復元された一時コピーをダウンロードまたはアクセスします。
Amazon Glacier ボールトからの取得（従来のスタンドアロンサービス）

従来の「ボールト」を使用している場合、プロセスは「ジョブの開始」と「出力のダウンロード」の2段階に分かれます。

• 手順:

ジョブの開始: API、CLI、または SDK を使用して、アーカイブの取り出しジョブを開始します。
待機: ジョブが完了するのを待ちます。SNS 通知を設定して完了を知ることも可能です。
出力の取得: ジョブ完了後、Get Job Output オペレーションを使用してデータをダウンロードします。

▪ 注意: ジョブ完了から 24 時間経過すると、データは取得できなくなります。

取り出しオプション（ティア）と所要時間

取得リクエストを行う際、緊急度やコストに応じて以下のオプションを選択できます。

部分的な取得（範囲取得）

アーカイブ全体ではなく、特定のバイト範囲を指定してデータの一部のみを取得することも可能です。これにより、ダウンロードのスケジュール管理や、巨大なアーカイブ内の特定ファイルのみの取り出しが可能になります。

【Glacierの詳細情報】

サービスの構成：S3 ストレージクラスと従来のボールト

Glacier の機能は、現在主に 2 つの異なる方法で利用されています。

• S3 Glacier ストレージクラス (推奨): Amazon S3 バケット内のオブジェクトとしてデータを保存する方法です。「S3 Glacier Instant Retrieval」、「S3 Glacier Flexible Retrieval」、「S3 Glacier Deep Archive」などのストレージクラスとして提供されています。

• Amazon Glacier (従来のスタンドアロンサービス): 「ボールト (Vault)」と呼ばれるコンテナに「アーカイブ」としてデータを保存する独自の API を備えたサービスです。これは新規顧客の受け入れを終了しており、現在は S3 ストレージクラスの利用が推奨されています。

　・ボールト (Vault) とは

ボールトは、アーカイブを保存するための**コンテナ（入れ物）**です。 Amazon S3 における「バケット」に近い概念ですが、S3 バケットとは異なり、Amazon Glacier 独自の API を使用して管理されます。

　・アーカイブ (Archive) とは

アーカイブは、ボールトの中に保存されるデータそのもの（写真、動画、ドキュメントなどのファイル）を指します。 Amazon S3 における「オブジェクト」に相当します。アーカイブとして保存されたデータには、以下の特徴があります。

Amazon Glacier（2012年リリースのスタンドアロンVaultサービス）は、2025年12月15日をもって新規受付を終了しました。

非同期の取り出しプロセス (非同期オペレーション)

S3 Glacier の最大の特徴は、データへのアクセスが非同期である点です。通常の S3 標準クラスのように即座にデータをダウンロードすることはできません。

• 復元のリクエスト: データを使用するには、まず復元（取り出し）ジョブを開始する必要があります。S3 オブジェクトの場合は「復元 (Restore)」アクションを選択し、一時的なコピーを作成します。

• 待機時間: ジョブが完了し、データが利用可能になるまで待機時間が発生します。

• ダウンロード: 処理が完了した後、指定した期間だけデータがダウンロード可能になります。

S3 Glacier Deep Archive の特徴

さらに長期的な保存（数年〜数十年）を目的とした「S3 Glacier Deep Archive」というストレージクラスも提供されています。

• 耐久性とコスト: データは 3 つ以上の AWS アベイラビリティーゾーン (AZ) に保存され、物理テープライブラリに匹敵する低価格で利用可能です。

• ユースケース: 規制コンプライアンスのためのデータ保持、メディアアーカイブ、バックアップなどに適しています。

• 制約: 128 KB 未満のオブジェクトは、Deep Archive を含むアーカイブストレージクラスへの移行が制限されるデフォルト動作があります（設定変更可能）。

データ管理とライフサイクル

S3 Glacier は、S3 のライフサイクル機能と統合されています。

• 自動移行: 「作成から 30 日後に Glacier Flexible Retrieval へ移行」「1 年後に Deep Archive へ移行」といった S3 ライフサイクルルールを設定することで、自動的にデータを最適なコストのストレージクラスへ移動できます,。

• オブジェクトロック: S3 オブジェクトロック機能を使用し、WORM (Write-Once-Read-Many) モデルでデータを保存することで、指定期間中の削除や上書きを防ぐことができます。

問題51:

あなたはソリューションアーキテクトとして、サーバーレスアーキテクチャを用いて業務用アプリケーションを開発しています。このアプリケーションでは、AWS Lambda関数が一連のビジネスロジックを実行し、Amazon DynamoDBテーブルからデータを取得します。その際、HTTPを介してこのアプリケーションを呼び出せるようにする必要があります。

HTTP経由での呼び出しを実現するための最適なソリューションはどれでしょうか。（2つ選択）

選択は正解です
API Gateway APIを作成して、Lambda関数と統合する。

IAMロールをLambda関数に設定して、HTTPアクセスを許可する。

Lambda関数の設定において、HTTPアクセス許可を有効化する。

選択は不正解です
ネットワークACLを設定してLambda関数へのHTTPアクセスを許可する。

正しい選択
Lambdaの関数URLをパブリックに設定する。

全体的な説明
このシナリオでは、HTTPを介してLambda関数を呼び出し、DynamoDBテーブルからデータを取得するためのHTTPリクエスト処理の実装方法が求められています。要件に応じて、Lambda関数URL機能または、Lambda関数とAPI Gatewayの統合を検討する必要があります。

オプション１が正解となります。API Gateway APIをLambda関数に統合することで、HTTPリクエストを介してLambda関数を呼び出して、DynamoDBテーブルからデータを取得するプロセスを実行できます。

API Gatewayは、APIを通じてバックエンドサービスへのHTTPアクセスを提供するAPI管理サービスです。このサービスはLambdaと連携して、API Gateway APIをLambda関数と連携することで、Lambda関数へのAPIアクセスを実現します。これにより、HTTP形式のAPIからLambda関数へのアクセスが可能になります。

オプション５も正解となります。これまで、HTTPを介してLambda関数を実行するにはAPI Gatewayを利用する必要がありました。しかしながら、新たに導入された関数URL（Function URLs）機能により、API Gatewayを経由せずにパブリックに公開されるAPIや、簡易な認証を実装したAPIをAWS Lambdaに設定することが可能となりました。

オプション２は不正解です。IAMロールは、AWSリソースが他のAWSリソースに対してアクセス権を付与するために使用されますが、HTTPアクセスを許可する機能ではありません。

オプション３は不正解です。Lambda関数の設定においてHTTPアクセスを許可するのではなく、関数URLの公開設定を変更する必要があります。

オプション４は不正解です。Lambda関数はVPCを指定してデプロイすることが可能ですが、Lambda関数は通常はVPC外にデプロイされるため、ネットワークACLによってLambda関数へのHTTPアクセスを許可することはできません。さらに、ネットワークACLはアクセスの許可または拒否を設定するファイアウォール機能を提供するだけであり、Lambda関数にHTTPアクセスの機能を付与することはできません。

【Amazon API Gateway と AWS Lambda 関数の詳細情報】

Amazon API Gateway を使用して AWS Lambda 関数を呼び出すことで、HTTP エンドポイントを持つサーバーレスなウェブ API を構築できます。API Gateway が「フロントドア」として機能し、HTTP リクエストを受け取って Lambda 関数にルーティングし、その実行結果をクライアントに返します。

API タイプの選択

Lambda 関数を呼び出すために、主に以下の 2 種類の API タイプから選択します。

• HTTP API:

◦ 軽量で低レイテンシー、かつコスト効率が高い API です。

◦ 自動デプロイや CORS 設定の簡素化などの新機能が含まれており、多くの場合において推奨されます,。

• REST API:

◦ 従来の機能豊富な API です。

◦ リクエスト/レスポンスの変換（マッピングテンプレート）、API キーの使用、WAF との統合など、より高度なカスタマイズや管理機能が必要な場合に使用します。

設定手順（エンドポイントの追加）

Lambda コンソールまたは API Gateway コンソールから設定できます。

関数の選択: Lambda コンソールで対象の関数を開きます。
トリガーの追加: 「トリガーを追加」を選択し、「API Gateway」を選びます。
API の作成または選択:

◦ 新規に作成する場合は、「HTTP API」または「REST API」を選択します。

◦ セキュリティ設定（「Open」や「IAM」など）を選択します。

追加: 設定を完了すると、API Gateway にエンドポイントが作成され、Lambda 関数へのルーティングが確立されます。
プロキシ統合（推奨される統合方法）

Lambda と API Gateway を連携させる最も一般的な方法は「Lambda プロキシ統合」です。

• リクエスト: クライアントからの HTTP リクエスト（ヘッダー、クエリ文字列パラメータ、本文など）は、API Gateway によって JSON 形式のイベントオブジェクトに変換され、そのまま Lambda 関数に渡されます。

• レスポンス: Lambda 関数は、API Gateway が解釈できる特定の形式の JSON オブジェクトを返す必要があります。

Lambda 関数が返すレスポンスの形式例 (Node.js): 関数は statusCode、headers、body を含むオブジェクトを返す必要があります。API Gateway はこれを HTTP レスポンスに変換してクライアントに返します。

{
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": "{"message": "Hello from Lambda"}"
}

必要な権限（リソースベースのポリシー）

API Gateway が Lambda 関数を呼び出すためには、適切な権限が必要です。

• コンソールを使用してトリガーを追加した場合、Lambda 関数のリソースベースのポリシーが自動的に更新され、API Gateway からの lambda:InvokeFunction アクションが許可されます。

• API Gateway と Lambda が異なる AWS アカウントにある場合や、手動で設定する場合は、AWS CLI などを使用して明示的に権限を付与する必要があります。

参考：Lambda 関数 URL (Function URLs)

API Gateway の高度な機能（認証、スロットリング、カスタムドメイン管理など）が不要で、単に HTTP(S) 経由で Lambda を実行したい場合は、Lambda 関数 URL という機能を使用することも可能です。これにより、API Gateway を経由せずに、関数専用の HTTPS エンドポイントを直接作成できます。

問題52:

ある企業が新たにモバイルアプリケーションをAWS上で開発しています。現在、あなたはソリューションアーキテクトとして、ユーザー設定の保存方法について検討しています。個々のユーザー設定データのサイズは約10KBほどです。このモバイルアプリケーションを利用する顧客数は、リリース時に数万人に達すると予想されています。その際は、アプリケーション内でのユーザーセッションの迅速な処理が求められます。

これらの要件を満たすために、最も適切なデータベースはどれでしょうか。

Amazon RDSを利用してユーザーのセッションデータを蓄積する。

Amazon S3を利用してユーザーのセッションデータを蓄積する。

Amazon RedShiftクラスターを利用してユーザーのセッションデータを蓄積する。

回答は正解です
DynamoDBテーブルを利用してユーザーのセッションデータを蓄積する。

全体的な説明
このシナリオでは、ユーザーセッション処理を迅速に行うためのデータレイヤーの構築が求められています。つまり、要件に適したデータベースやストレージの選定が重要です。

オプション４が正解となります。迅速なユーザーセッション処理にはNoSQLデータベースが最適です。DynamoDBは、セッションデータやユーザー設定、メタデータなどを保存するのに適したNoSQLデータベースサービスです。このモバイルアプリケーションを利用する顧客数は数万人に達すると予想されています。それに対して、DynamoDBテーブルを利用してユーザー設定データを用いたセッションを実施することで、迅速な処理が可能となります。

オプション１は不正解です。Amazon RDSはリレーショナルデータベースであり、主に業務データ処理に適したデータベースです。迅速なユーザーセッション処理にはNoSQL型のDynamoDBの方が適しています。

オプション２は不正解です。データボリュームやモバイルアプリケーションの迅速な処理に必要なデータレイヤー向けにはS3バケットは適切ではありません。S3バケットはデータ処理用のストレージレイヤーではなく、画像コンテンツなどの長期保存に適しています。

オプション３は不正解です。Redshiftはデータ解析に特化したリレーショナルデータベース型のデータウェアハウスであり、主にデータ解析に用いられます。ユーザーセッションの迅速な処理にはNoSQL型のDynamoDBの方が適しています。

【詳細情報】

Amazon DynamoDB は、その高速なパフォーマンス、スケーラビリティ、およびサーバーレスアーキテクチャにより、アプリケーション内のユーザーセッション処理（セッションストア）として非常に適しています。

セッション処理に適している理由

ユーザーセッションの管理には、高い同時実行性と低レイテンシーが求められます。DynamoDB は以下の特徴により、ショッピングカートやゲームのセッション履歴などのユースケースで広く利用されています。

• 一桁ミリ秒のパフォーマンス: 規模に関わらず一貫して一桁ミリ秒（10ms未満）の応答速度を提供するため、ユーザー体験を損なわずにセッションの読み書きが可能です。

• Key-Value データモデル: DynamoDB は Key-Value モデルをサポートしており、セッションID をキー、セッションデータを値として保存する形式に最適です。

• 高いスケーラビリティ: ユーザー数が 10 名でも 1 億名でも対応できるように設計されています。トラフィックの増減に応じて自動的にスケールするため、キャンペーンやイベント時の急激なアクセス増にも対応できます。

キャパシティモードの選択

セッションデータはユーザーのアクティビティに依存するため、アクセスパターンが予測しにくい場合があります。DynamoDB では 2 つのキャパシティモードから選択できます。

• オンデマンドモード (推奨):

◦ 特徴: 予測困難なワークロードに適しています。事前にキャパシティを指定する必要がなく、使用した分だけ課金されます。

◦ メリット: セッション数が急増しても DynamoDB が自動的に対応し、管理の手間がありません。ほとんどのワークロードでデフォルトとして推奨されています。

• プロビジョニングモード:

◦ 特徴: 予測可能な安定したトラフィックがある場合に、コストを最適化するために使用します。

セッション管理に役立つ機能

• 有効期限 (TTL) 設定:

◦ セッションには通常「有効期限」があります。DynamoDB の TTL (Time to Live) 機能を使用すると、期限切れのセッションデータを自動的に削除できます。バックアップからの復元時に手動設定が必要な項目として「有効期限 (TTL) 設定」があります。

• グローバルテーブル:

◦ アプリケーションがグローバルに展開されている場合、グローバルテーブルを使用することで、複数のリージョン間でセッションデータをアクティブ/アクティブにレプリケーションできます。これにより、ユーザーは最寄りのリージョンから低レイテンシーでセッション情報にアクセスできます。

• セキュリティ:

◦ すべてのデータはデフォルトで保管時に暗号化されるため、セッションに含まれる機密情報を安全に保護できます。

問題53:

ある企業がDNSサーバーとしてRoute53を利用する計画を立てています。要件として、画像配信を迅速に行うために独自のドメイン名を用いてCloudFrontディストリビューションを設定する必要があります。あなたはソリューションアーキテクトとして、Route53のホストゾーンに新しいレコードを追加し、CloudFrontディストリビューションに独自のドメインを関連付ける役割を担っています。この際、IPv4に基づくドメイン設定が求められます。

この要件を満たすための適切なRoute53の設定手順はどれでしょうか。

レコード作成において[CNAME] をオンにしてレコードタイプはAAAAにする。CloudFrontディストリビューションのドメインを指定する。

レコード作成において[エイリアス] をオンにしてレコードタイプはAAAAにする。CloudFrontディストリビューションのドメインを指定する。

正解
レコード作成において[エイリアス] をオンにしてレコードタイプはAにする。CloudFrontディストリビューションのドメインを指定する。

回答は不正解です
レコード作成において[CNAME] をオンにしてレコードタイプはAにする。CloudFrontディストリビューションのドメインを指定する。

全体的な説明
このシナリオでは、CloudFrontディストリビューションをRoute53レコードに設定し、IPv4に基づくドメインを構成する方法が問われています。Route53は、ELB、CloudFront、EC2などのウェブサイトのフロントエンドリソースに対して、URLを設定するためのドメインを構成できるDNSサーバー機能を提供しています。

オプション３が正解となります。ALIASレコードを作成し、CloudFrontディストリビューションを設定することで、Route 53のDNSレコードにCloudFrontを関連付けることが可能です。この際、IPv4に基づくドメイン設定を行う場合は、Aレコードタイプを選択する必要があります。Route 53のコンソール画面でレコード作成時に[エイリアス]を有効にし、レコードタイプをAに設定した上で、CloudFrontディストリビューションのドメインを指定することで、設定が完了します。

Route 53のドメイン設定において、CloudFrontなどのAWSリソースをRoute 53レコードに設定するためにはALIASレコードを使用する必要があります。ALIASレコードは、Route 53においてELBなどのAWSリソースを設定するためのAWS独自のレコード形式です。ALIASレコードには、IPアドレスやドメイン名の代わりに、CloudFront、Elastic Beanstalk環境、ELB、Amazon S3バケットのエンドポイント、または同じホストゾーン内の他のRoute 53レコードを指定することができます。

オプション１と４は不正解です。CNAMEレコードは特定のドメインに対して別のドメインを設定して、ドメイン間の名前解決を設定する際に利用します。

オプション１と２は不正解です。AAAAレコードタイプはIPv6アドレス用のレコードです。ALIASレコードにおいてリソースを設定する際にIPv4アドレスではなく、IPv6アドレスを利用する際にAAAAレコードタイプを選択します。

【構成の詳細情報】

Route 53 のホストゾーンに新しいレコードを追加し、CloudFront ディストリビューションに独自のドメインを関連付けるには、主に CloudFront 側の設定（代替ドメイン名の追加）と Route 53 側の設定（エイリアスレコードの作成）の 2 つのステップが必要です。

前提条件：CloudFront 側の設定

Route 53 でレコードを作成する前に、CloudFront ディストリビューションがその独自ドメイン（例: example.com）からのリクエストを受け入れるように設定する必要があります。

代替ドメイン名 (CNAME) の追加: CloudFront コンソールでディストリビューションの設定を編集し、[代替ドメイン名 (CNAME)] フィールドに、使用したい独自ドメイン名を入力します。
SSL/TLS 証明書の準備 (HTTPS利用時): HTTPS を使用する場合、ドメイン名に一致するパブリック証明書（AWS Certificate Manager で発行されたものなど）をディストリビューションに関連付ける必要があります。
IPv6 の確認: ディストリビューションで IPv6 が有効になっているか確認してください。有効な場合、Route 53 で IPv4 用と IPv6 用の 2 つのレコードを作成する必要があります。
Route 53 でのレコード作成手順

CloudFront ディストリビューションを指すエイリアスレコードを作成します。エイリアスレコードは CNAME に似ていますが、ルートドメイン（例: example.com）にも作成でき、CloudFront へのクエリに対する追加料金が発生しないという利点があります。

Route 53 コンソールを開く: AWS マネジメントコンソールにサインインし、Route 53 コンソールを開きます。
ホストゾーンの選択: ナビゲーションペインで [ホストゾーン] を選択し、対象のドメインのホストゾーン名を選択します。
レコードの作成: [レコードを作成] を選択し、以下の値を設定します。

◦ レコード名: 使用するサブドメイン（例: www）を入力します。ルートドメイン（example.com）を使用する場合は空のままにします。

◦ レコードタイプ:

▪ IPv4 トラフィック用には [A – IPv4 アドレス] を選択します。

▪ IPv6 トラフィック用には [AAAA – IPv6 アドレス] を選択します（ディストリビューションで IPv6 が有効な場合）。

◦ エイリアス: スイッチを [オン] にします。

◦ トラフィックのルーティング先:

ドロップダウンから [CloudFront ディストリビューションへのエイリアス] を選択します。
リストから対象のディストリビューション（d111111abcdef8.cloudfront.net など）を選択します。

◦ ターゲットの正常性の評価: デフォルトの [いいえ] のままで構いません。

作成: [レコードを作成] を選択して完了します。
注意点

• IPv6 対応: CloudFront で IPv6 が有効になっている場合は、手順を繰り返し、レコードタイプを [AAAA] に変更して 2 つ目のレコードを作成してください。

• 伝播時間: 変更は通常 60 秒以内にすべての Route 53 サーバーに伝播されます。

問題54:

ある企業は、コンテナ化されたアプリケーションを開発しています。このアプリケーションは、高い可用性とスケーラビリティを確保する必要があります。その際は、このコンテナアプリケーションのCPUリソースを設定して管理する必要があります。

これらの要件を満たすソリューションはどれでしょうか。

正解
Amazon Elastic Container Service (Amazon ECS)を使用してコンテナを構成し、CPUインスタンスファミリーのAmazon EC2インスタンスでアプリケーションを実行する。

Amazon Elastic Kubernetes Service (Amazon EKS)を利用してコンテナを構成し、AWS Fargateを使用してコンピューティングリソースとCPUリソースへのアクセスを管理する。

Amazon Elastic Container Service (Amazon ECS)を使用してコンテナを構成し、AWS Fargateを使用してコンピューティングリソースとCPUリソースへのアクセスを管理する。

回答は不正解です
Amazon Elastic Container Service (Amazon ECS)を使用してコンテナを構成し、Amazon ECRを使用してコンピューティングリソースとCPUリソースへのアクセスを管理する。

全体的な説明
このシナリオでは、コンテナ化されたアプリケーションに対する高い可用性とスケーラビリティを確保し、CPUリソースへのアクセスとその管理が求められています。

オプション１が正解となります。Amazon Elastic Container Service (Amazon ECS)を用いてコンテナを設定することで、高い可用性とスケーラビリティを持つコンテナアプリケーションを構築できます。さらに、EC2起動タイプを選択することで、CPUインスタンスファミリーのAmazon EC2インスタンスを使用してアプリケーションを実行します。これにより、ユーザーはEC2インスタンスのCPUリソースへのアクセスを管理することが可能になります。

オプション２と３は不正解です。Fargateはサーバーレスコンピューティングリソースとして提供されているため、CPUリソースの管理はマネージドサービスとして行われており、ユーザーはCPUリソースへのアクセスを管理することができません。

オプション4は不正解です。Amazon ECRはコンテナイメージを保存し、管理するためのレジストリであるため、CPUリソースの管理とは無関係なサービスです。

【詳細情報】

Amazon ECS (Elastic Container Service) を EC2 起動タイプで使用する場合、コンテナアプリケーションの CPU リソース管理は、**「タスクレベル」と「コンテナレベル」**の 2 つの階層で設定します。

以下にEC2 インスタンス上でコンテナの CPU を管理する仕組みと設定戦略について解説します。

基本単位：CPU ユニット

ECS では、CPU リソースを「CPU ユニット」という単位で定義します。

• 1 vCPU = 1,024 CPU ユニットとして扱われます。

• 例えば、2 vCPU (2,048 ユニット) を持つ EC2 インスタンス上で、512 ユニットを必要とするコンテナを 4 つ実行するといった計算になります。

設定戦略：制御 vs 柔軟性

EC2 起動タイプでは、タスク定義での設定方法によって、リソース管理の挙動が大きく 2 つのパターンに分かれます。

A. 制御を最大化する（タスクサイズを設定する）

タスク定義レベルで cpu (タスクサイズ) を明示的に設定する方法です。

• 動作: タスク自体が、その中のコンテナを囲む「ハードな境界（上限）」となります。

• 制限: タスク内で実行されるすべてのコンテナの CPU 使用量の合計は、タスクサイズとして設定された値を超えることはできません。

• メリット: パフォーマンスの予測可能性が高まります。特定のタスクが EC2 インスタンスのリソースを食いつぶすのを防ぐことができます。

B. 柔軟性を最大化する（タスクサイズを設定しない）

タスク定義レベルでの CPU 設定を行わず、コンテナ定義レベルの cpu 設定のみに依存する方法です。EC2 起動タイプでのみ可能な設定です。

• 動作: コンテナ定義で設定した CPU ユニット数は、EC2 インスタンス（ホスト）上の「予約」として機能します。

• バースト: コンテナが割り当てられた CPU ユニットを使用していない場合、他のコンテナはその空き容量を使用（バースト）できます。

• 競合時の配分: ホストの CPU リソースが逼迫した場合、設定された CPU ユニット数は Linux カーネルの「CPU 配分 (Shares)」として機能し、優先順位（重み付け）を決定します。

◦ 例: 1,024 ユニットを持つコンテナは、512 ユニットを持つコンテナの 2 倍の CPU 時間を得ることができます。

具体的な挙動のまとめ

管理のポイント

• コスト効率を高めたい場合: タスクサイズを設定せず、コンテナ定義で最低限必要な CPU ユニット数を指定して予約し、余剰リソースを共有させる「柔軟性を最大化する」アプローチが適しています。

• 安定した性能が必要な場合: 本番環境などで他のタスクの影響を受けたくない場合は、タスクサイズを設定してリソースを確保する「制御を最大化する」アプローチが推奨されます。

問題55:

ある企業は、1つのAmazon EC2インスタンス上で業務アプリケーションを運用しています。このアプリケーションのデータレイヤーには、Amazon RDS for MySQL DBインスタンスが使用されています。ピーク時間帯には、EC2インスタンスのCPU使用率が上昇するため、Amazon RDS DBインスタンスへの読み取りリクエストのパフォーマンスが低下しています。ソリューションアーキテクトは、このパフォーマンスを向上させたいと考えています。

コスト最適に要件を満たすソリューションはどれでしょうか。

EC2インスタンスを、よりCPUキャパシティの大きいEC2インスタンスタイプにリサイズする。最小サイズと最大サイズが1のAuto Scalingグループを設定する。読み取りリクエスト用にRDSリードレプリカを設定する。

EC2インスタンスを、よりCPUキャパシティの大きいEC2インスタンスタイプにリサイズする。最小サイズが1、最大サイズが2のAuto Scalingグループを設定する。読み取りリクエスト用にRDSリードレプリカを設定する。

回答は不正解です
EC2インスタンスに対して最小サイズが1、最大サイズが2のAuto Scalingグループを設定する。

読み取りリクエスト用にRDSリードレプリカを設定する。

正解
EC2インスタンスに対して最小サイズが1、最大サイズが2のAuto Scalingグループを設定する。

全体的な説明
このシナリオでは、ピーク時間帯にEC2インスタンスのCPU使用率が上昇することが原因で、Amazon RDS DBインスタンスへの読み取りリクエストのパフォーマンスが低下しているという問題があり、コスト効率の良いスケーリング設定が求められています。

オプション４が正解となります。EC2インスタンスに対して最小サイズ1、最大サイズ2のAuto Scalingグループを設定することで、通常は1台のEC2インスタンスで実行されているアプリケーションを、ピーク時間帯には2台のEC2インスタンスで処理することが可能になります。Auto Scalingグループの設定で最大サイズを2にすることで、スケーリング時にインスタンス数を2台まで増やすことができます。

EC2インスタンスのスケーリング：Auto Scaling の活用

• Auto Scaling グループの利用: Amazon EC2 Auto Scaling を使用して、CPU使用率などの負荷に応じて自動的にEC2インスタンスの数を増減（スケールアウト/スケールイン）させます。これにより、高負荷時でもアプリケーションのパフォーマンスを維持できます。

• マルチAZ配置とロードバランシング: Auto Scaling グループを複数のアベイラビリティーゾーン（AZ）にまたがって配置し、ロードバランサー（ELB）をアタッチすることで、トラフィックを分散させ、特定のインスタンスやAZへの負荷集中を防ぎます。

オプション１と２は不正解です。最大サイズが1のAuto Scalingグループを設定すると、スケーリングが行われてもインスタンスは1台しか増加しないため、EC2インスタンスのDBリクエスト処理のパフォーマンスを向上させることはできません。

オプション１と２と３は不正解です。RDSリードレプリカを設定することで、Amazon RDS for MySQL DBインスタンスのパフォーマンスを向上させることが可能ですが、このシナリオでは「EC2インスタンスのCPU使用率が高くなることが原因」となっているため、RDS側の読み取り処理はボトルネックとはなっておらず、リードレプリカを利用することでコストだけが増加してしまいます。

問題56:

ある企業は、社員のユーザープロファイルおよびアクセスログをAmazon S3バケットに保存しています。これらのデータは日常的にアップロードや変更が行われるため、ユーザーが誤ってS3バケット内のオブジェクトを削除するリスクが存在します。このため、適切な予防策を講じる必要がありますが、設定変更時にダウンタイムが発生し、業務に支障をきたすことは避けなければなりません。

S3バケット内のオブジェクトの誤削除を防ぐための最適な設定手順の組み合わせはどれでしょうか。（2つ選択）

選択は正解です
S3バケットにおけるバージョニング機能を有効化する。

S3バケットにおける暗号化を有効化する。

選択は正解です
S3バケットにあるMFA Deleteを有効化する。

S3バケットの設定をデータ削除不可とする。

S3バケットにIAMロールによる削除拒否を設定する。

全体的な説明
このシナリオでは、Amazon S3バケットに保存されたデータが誤って削除されないようにするための設定が必要です。主な方法は以下の通りです。

・MFA Delete機能をAmazon S3バケットに適用し、ユーザーがデータを削除する際にMFAの入力を必須とすることで、誤削除を防ぐ。

・初期設定でデータが削除されないようにS3バケットをロックする。

今回は、ユーザーがS3バケット内のオブジェクトを誤って削除するのを防ぐための対策が求められているため、1つ目の方法が適切な回答となります。

オプション１と３が正解となります。S3バケットにMFA削除を有効にすることで、ユーザーがS3バケット内のオブジェクトの削除を試みるたびにMFA認証が必要となり、操作ミスによるオブジェクト削除を防止できます。また、バージョニング機能を有効にすることで、削除されたオブジェクトを復元することが可能です。

オプション２は不正解です。S3バケットにおける暗号化を有効化することで、データ保護を強化できます。しかしながら、オブジェクトデータが暗号化されたとしてもオブジェクトは削除が容易に可能であるため、オブジェクト削除を防ぐことにはなりません。

オプション４は不正解です。S3バケットは初期設定ではオブジェクトロックによってオブジェクトを削除できない設定が可能ですが、それでは削除オペレーションを普段実施できなくなってしまいます。誤削除を予防するという目的以上の設定となっており、正しくありません。

オプション５は不正解です。IAMロールではなくIAMユーザーによって、アクセス権限の設定を行う必要があります。

【Amazon S3 MFA Deleteの詳細情報】

Amazon S3 MFA Delete は、S3 バケットのバージョニング機能と組み合わせて使用するセキュリティオプションで、重要なデータの誤削除や悪意のある削除を防ぐための機能です。

機能の概要

MFA Delete を有効にすると、以下の操作を行う際に、通常の認証情報に加えて MFA（多要素認証）デバイスからの認証コード（トークン）が必須となります。

• オブジェクトの特定のバージョンの完全削除: バージョン ID を指定してデータを削除する操作（永久削除）。

• バケットのバージョニング状態の変更: バージョニングの停止や無効化。

通常のファイルの作成、変更、およびバージョン ID を指定しない削除（削除マーカーの挿入）については、MFA 認証なしで通常通り実行されます。

利用要件と制約

MFA Delete を利用するには、以下の制約があります。

• ルートアカウントの MFA デバイスが必要: IAM ユーザーの MFA ではなく、AWS アカウントのルートユーザー（ルートアカウント）に登録された MFA デバイスのみが利用可能です。

• マネジメントコンソールは未サポート: MFA Delete の有効化設定や、MFA 認証を伴う削除操作は、AWS マネジメントコンソールからは実行できません。AWS CLI や API を使用する必要があります。

◦ コンソール上でバージョン ID を指定して削除しようとすると、MFA 認証に対応していないためエラーとなります。

設定と操作の方法（AWS CLI の例）

• 有効化: aws s3api put-bucket-versioning コマンドを使用し、MfaDelete=Enabled オプションと、ルートアカウントの MFA デバイス情報（シリアルナンバーとトークン）を指定して実行します。

• 削除: aws s3api delete-object コマンドなどでバージョン ID を指定して削除する際、--mfa オプションで MFA デバイスの情報を付与しないと削除が失敗します。

この機能により、万が一 AWS アカウントの認証情報が漏洩した場合や操作ミスがあった場合でも、物理的な MFA デバイスがない限りデータを完全に削除されるリスクを防ぐことができます。

問題57:

あるWEBマーケティング企業は、EC2インスタンス上にホストされたWEBアプリケーションを開発しています。このアプリケーションは、EC2インスタンスにAuto ScalingグループとALBを設定しており、Amazon SQSキューを利用した並列処理を実施しています。しかしながら、Amazon SQSのコンシューマーがメッセージ処理に失敗した場合、他のコンシューマーがそのメッセージを処理するまでに5分以上の遅延が発生することがあります。

この問題を解決するための最適なAmazon SQSキューのリファクタリング方法はどれでしょうか。

正解
可視性タイムアウトの設定時間を減少させる。

回答は不正解です
遅延キューの設定時間を減少させる。

ロングポーリングの設定時間を減少させる。

ショートポーリングの設定時間を減少させる。

全体的な説明
オプション１が正解となります。このシステムにおいて、Amazon SQSキューからメッセージを取得するコンシューマーがメッセージ処理に失敗した場合、他のコンシューマーがそのメッセージを処理するまでに5分以上の遅延が生じることがあります。これは、可視性タイムアウトが5分以上に設定されているためです。

SQSキューのメッセージがコンシューマーに受信された直後は、そのメッセージは依然としてキュー内に残ります。このため、他のコンシューマーが同じメッセージを再処理しないようにするために、Amazon SQSでは可視性タイムアウトを設定します。

この可視性タイムアウトの期間中は、他のコンシューマーが同じメッセージを受信して処理することはできません。デフォルトの可視性タイムアウトは30秒に設定されており、最小値は0秒、最大値は12時間まで設定可能です。

可視性タイムアウトはメッセージの重複処理を防止する際には重要ですが、特定インスタンスの処理に障害が発生した場合に、別のインスタンスで処理を継続させるための待機時間を長期化するという欠点があります。コンシューマーの一つがメッセージを受信すると、そのメッセージの可視性タイムアウトが切れるまで、他のコンシューマーはそのメッセージを再度取得することができないためです。

したがって、可視性タイムアウトの設定時間を短縮することで、他のコンシューマーがメッセージを処理するための待機時間を減少させることが可能です。

オプション２は不正解です。遅延キューは、キュー内のメッセージが配信された後、一定期間すべてのインスタンスからメッセージが見えなくなるように設定されます。今回のケースでは、処理中のインスタンス以外のインスタンスに対する可視性が問題となっているため、遅延キューではなく可視性タイムアウトの調整が必要です。

オプション３は不正解です。ロングポーリングを使用しても、他のコンシューマーがメッセージを処理するまでのタイムラグを5分以上増減させることはできません。ロングポーリングとは、SQSのキューに対してコンシューマーがメッセージを取得する際に、一定時間メッセージを受け取るまでの待機時間が設定されている状態を指します。この設定により、ポーリング回数を減少させることが可能です。

オプション４は不正解です。ショートポーリングを用いても、他のコンシューマーがメッセージを処理するまでのタイムラグを5分以上増減させることはできません。ショートポーリングは、SQSのキューに対してコンシューマーがメッセージを取得する際に、待機時間がゼロに設定されている状態を意味します。

問題58:

ある企業がサーバーレスアプリケーションを開発しています。このアプリケーションは、Amazon EventBridgeのルールによってトリガーされるAWS Lambda関数で構成されています。ソリューションアーキテクトは、最小権限の原則に基づき、AWS Lambda関数を実行するために必要なアクセス権限を適切に設定するadd-permissionコマンドを実行する必要があります。

この要件を達成するために、ソリューションアーキテクトはどのようなコマンドを実行するべきでしょうか。

lambda:InvokeFunctionをアクションに、*をプリンシパルに設定した実行ルールを付与する。

正解
lambda:InvokeFunctionをアクションに、 events.amazonaws.comをプリンシパルに設定した実行ルールを付与する。

lambda:LaunchFunctionをアクションに、*をプリンシパルに設定したリソースベースのポリシーを関数に付与する。

回答は不正解です
lambda:InvokeFunctionをアクションに、 lambda.amazonaws.comをプリンシパルに設定したリソースベースのポリシーを関数に付与する。

全体的な説明
Amazon EventBridgeは、AWS内で発生する多様なイベントや外部のSaaSからのイベントをトリガーとして、さまざまなAWSサービスと連携させることができるサービスです。このサービスは、AWSリソース間の架け橋として機能します。Amazon EventBridgeのルールを設定することで、特定のイベントが発生した際にAWS Lambda関数を呼び出すことが可能です。

このシナリオでは、Amazon EventBridgeのルールによって呼び出されるAWS Lambda関数を設定する際の具体的なリソース間の権限設定方法が求められています。Amazon EventBridgeを通じて他のAWSリソースを呼び出す場合、IAMポリシーによる適切な権限付与が必要です。

オプション２が正解となります。Amazon EventBridgeを利用することで特定のスケジュールに沿ってAWS Lambda関数を実行するルールを設定することが可能となります。

その際は、EventBridge サービスプリンシパル (events.amazonaws.com) のアクセス許可を使用してルールを実行するには、add-permission コマンドを使用することが必要です。アクションとしてlambda:InvokeFunctionを指定し、EventBridgeサービスプリンシパル（events.amazonaws.com）に対するアクセス許可を付与するために、add-permissionコマンドを設定します。

【構成の詳細情報】

Amazon EventBridge のルールによって AWS Lambda 関数を呼び出すためには、Lambda 関数側のリソースベースのポリシーを設定し、EventBridge サービスに対して関数の実行権限を付与する必要があります。

具体的な設定内容と方法は以下の通りです。

必要な権限設定の内容

Lambda 関数に関連付けるポリシーには、以下の要素を指定する必要があります。

• アクション (Action): lambda:InvokeFunction

◦ EventBridge が Lambda 関数を呼び出すことを許可します。

• プリンシパル (Principal): events.amazonaws.com

◦ 許可を与える対象として EventBridge サービスを指定します。

• ソース ARN (SourceArn): 対象となる EventBridge ルールの ARN

◦ 特定のルールからのみ呼び出しを許可するために指定します。これにより、予期しない他のルールからの実行を防ぐことができます。

設定方法（AWS CLI の例）

AWS CLI を使用して設定する場合、aws lambda add-permission コマンドを使用します。具体的なコマンド例は以下の通りです。

aws lambda add-permission
--function-name LogScheduledEvent
--statement-id my-scheduled-event
--action 'lambda:InvokeFunction'
--principal events.amazonaws.com
--source-arn arn:aws:events:us-east-1:123456789012:rule/my-scheduled-rule
このコマンドを実行することで、指定した EventBridge ルール（source-arn）が Lambda 関数（function-name）を呼び出すことが許可されます。

補足

• コンソールでの作成: AWS マネジメントコンソールを使用して EventBridge ルールを作成し、ターゲットとして Lambda 関数を選択する場合は、通常、必要なリソースベースのポリシーが自動的に追加されます。

• 実行ロールとの違い: Lambda 関数が実行時にログを CloudWatch に書き込むなど、他の AWS サービスにアクセスするための権限は「実行ロール (IAM ロール)」で定義しますが、EventBridge が Lambda をトリガーするための権限は、上記のように Lambda 関数自体の「リソースベースのポリシー」で制御します。

問題59:

ある企業では、AWS上で運用されているアプリケーションがあります。このアプリケーションは、2つのパブリックサブネットにそれぞれ配置された2台のEC2インスタンスを使用しています。WEBサーバーには、インターネットを介して社内の特定のユーザーのみがアクセス可能です。もう1台のインスタンスはデータベースサーバーとして機能しています。あなたはセキュリティ担当者として、現在のアーキテクチャのセキュリティ強化を検討しています。

次の中で、最もセキュリティが高いアーキテクチャ構成はどれでしょうか。

回答は不正解です
新しくプライベートサブネットを作成して、そこにNATインスタンスを設置する。社内ネットワークとVPNを構成して、プライベートサブネットに接続する。

WEBサーバーのみプライベートサブネットに移動する。社内ネットワークとVPNを構成して、プライベートサブネットに接続する。

データベースサーバーのみプライベートサブネットに移動する。社内ネットワークとVPNを構成して、プライベートサブネットに接続する。

正解
両方のサーバーを新しいプライベートサブネットに移行して、パブリックサブネットに踏み台サーバーを設定する。社内ネットワークとVPNを構成して、プライベートサブネットに接続する。

全体的な説明
このシナリオでは、AWSのプライベートサブネットとパブリックサブネットを活用したアーキテクチャの基本構成の理解度が問われています。WEBサーバーには、インターネットを通じて社内の特定のユーザーのみがアクセス可能です。もう一つのインスタンスはデータベースサーバーとして設定されており、これらのサーバーに対して最高レベルのセキュリティ構成が必要とされています。

オプション４が正解となります。最もセキュリティが強化される構成は、Webサーバーとデータベースサーバーの両方をプライベートサブネットに配置し、NATゲートウェイをパブリックサブネットに設置することです。この構成により、パブリックサブネットにある踏み台サーバーやELBを通じて、またはプライベートサブネットへのVPN接続を利用して、外部のPCからプライベートサブネット内のWebサーバーにアクセスすることが可能となります。

インターネットからの不特定多数のアクセスがWebサーバーに必要な場合、このWebサーバーはパブリックサブネットに配置する必要があります。しかし、今回のケースでは社内ネットワークからの社内ユーザーのみがWebサーバーにアクセスするため、Webサーバーは社内アクセスに限定されることが明らかです。したがって、Webサーバーをプライベートサブネットに設置する方がセキュリティの観点から望ましいと言えます。

この構成は、特に機密性の高いシステムで推奨され、以下の理由でセキュリティが大幅に向上します。

直接アクセス不可: プライベートサブネットにあるサーバーは直接インターネット（パブリック）からの着信アクセスを受けない。

通信の制御: Web/DBサーバーはインターネットへの送信通信のみをNATゲートウェイ経由で行う。

攻撃面の縮小: 攻撃者がサーバーへ直接到達する経路がなくなる。

なお、この構成において、パブリックアクセスの入り口として、パブリックサブネットにパブリックロードバランサー（ALBなど）を設置するのが一般的です。これらを適切に配置することで、安全性、負荷分散の両面で最適な結果が得られます。

オプション１は不正解です。新たにプライベートサブネットを構築し、サーバーを再配置することが求められています。NATインスタンスはEC2インスタンス内にNAT機能を構成する方法ですが、NATゲートウェイを利用する方が安全に高機能に利用可能であるため、現在は利用が推奨されていません。また、プライベートサブネット内ではなく、パブリックサブネット内にNATを構成する必要があります。

オプション２は不正解です。最高のセキュリティを達成するにはWEBサーバーだけでなく、データベースサーバーもプライベートサブネットに移動する必要があります。

オプション３は不正解です。最高のセキュリティを達成するにはDBサーバーのみをプライベートサブネットに移動するのではなく、WEBサーバーも同様に移動する必要があります。

問題61:

ある企業はAmazon DynamoDBを用いた大量のデータ処理を実施するシステムを運用しています。最近、このデータベースに対する書き込み処理の件数が増加したため、データ処理の遅延や失敗が頻発しています。あなたはソリューションアーキテクトとして、書き込み操作がどのような状況でも失われないようにするための対策を求められています。

この要件を満たすための最適なアプローチを選定してください。

DynamoDBにIOPSボリュームを利用する。さらにDynamoDBにはデッドレターキューを追加する。

回答は不正解です
DynamoDBの書込処理に対してAmazon SQSキューによる分散処理プロセスを設定する。さらにAmazon SQSにはデッドレターキューを追加する。

正解
DynamoDBの書込処理に対してAmazon SQSキューとAWS Lambda関数による分散処理プロセスを設定する。さらにLambda関数にはデッドレターキューを追加する。

EC2インスタンスによってDynamoDBのデータ処理を実行する。さらにEC2インスタンスにはデッドレターキューを追加する。

全体的な説明
このシナリオでは、DynamoDBテーブルに対する書き込みリクエストが途中で消失しないようにする仕組みを構築することが求められています。その際、「保留中のデータベースへの書き込みリクエスト」をAmazon SQSキューに格納し、非同期で処理することが必要です。Amazon SQSは、メッセージのキューイング処理を管理するサービスです。このサービスを利用することで、分散されたソフトウェアシステムやコンポーネントを統合し、または分離することができます。

オプション３が正解となります。Lambda関数とAmazon SQSキューを連携することで、DynamoDBテーブルへの書き込み処理リクエストをAmazon SQSキューに保存して、データベース処理を実行することが可能となります。メッセージをキューに保存することで、書き込み処理に関するメッセージが失われないようにすることができます。

その後、Lambda関数がSQSキューメッセージを取得し、その内容に基づいて書き込み処理を行います。

さらに、Lambda関数にデッドレターキューを追加することで、実行に失敗したメッセージをAmazon SQSキューに蓄積することができます。このデッドレターキューにより、リクエストメッセージが失われることはなく、書き込み処理がどのような状況でも確実に行われる要件を満たしています。

オプション１は不正解です。DynamoDBにはIOPSボリュームという構成はありません。さらに、DynamoDBにはデッドレターキューを追加することはできません。

オプション２は不正解です。Amazon SQSキューはメッセージ配信機能のみを提供しているため、SQSキューだけではDynamoDBテーブルへの書き込み処理を実現することはできません。Lambda関数がSQSキューからメッセージをポーリングして、データ処理を行う必要があります。

オプション４は不正解です。EC2インスタンスがDynamoDBテーブルにアクセスしてデータ処理を行うことは可能ですが、Lambda関数を用いたDynamoDBテーブルのデータ処理の方がコスト効率が高いため、こちらが最適な構成となります。また、EC2インスタンスにはデッドレターキューを追加することはできません。

【Lambda 関数と Amazon SQS キューの詳細情報】

Lambda 関数と Amazon SQS キューを連携させることによる並列処理（および非同期処理）の意義は、主に処理効率の向上（バッチ処理）、スケーリングの制御（スロットリング対策）、および耐障害性の確保にあります。

バッチ処理による効率化

Lambda は SQS キューをポーリングし、キューから取得したメッセージを**「バッチ（束）」**として関数に渡します。

• 意義: 1つのメッセージごとに都度関数を起動するのではなく、複数のメッセージ（デフォルトでは最大10件）をまとめて1回の関数実行で処理できるため、起動オーバーヘッドを減らし、処理スループットを向上させることができます。

• 動作: Lambda はバッチごとに同期的に関数を呼び出します。関数がバッチ処理を正常に完了すると、Lambda はそのメッセージ群をキューから削除します。

トラフィックのバッファリングとスロットリング対策

SQS キューは、Lambda 関数が処理しきれない大量のリクエストを受け止めるバッファとして機能します。

• 意義: 急激なトラフィック増加（スパイク）があっても、メッセージは一旦キューに蓄積されます。これにより、Lambda 関数の同時実行数制限（スロットリング）を超えた場合でも、メッセージが失われることを防ぎます。

• 設定: キューの「可視性タイムアウト」を関数のタイムアウトの 6 倍以上に設定することが推奨されています。これにより、関数がスロットリングされたり処理に時間がかかったりした場合でも、Lambda が再試行するための十分な時間を確保でき、安全に処理を継続できます。

ファンアウト構成による独立した並列処理 (SNSとの組み合わせ)

Amazon SNS と SQS を組み合わせることで、「ファンアウト」と呼ばれる並列処理パターンを実現できます。

• 意義: 1つのイベント（トピックへの発行）をトリガーとして、複数の異なる SQS キューにメッセージを並列に配信できます。各キューに紐づいた Lambda 関数やアプリケーションが、互いに干渉することなく、同時に異なる処理（例：注文処理と分析用ログ保存など）を実行できます。

耐障害性とエラーハンドリング (DLQ)

並列処理において一部のメッセージ処理が失敗した場合のセーフティネットが提供されています。

• 自動リトライ: バッチ処理中に関数がエラーを返した場合、可視性タイムアウト経過後にメッセージが再びキューに表示され、再処理が行われます。

• デッドレターキュー (DLQ): 処理が繰り返し失敗したメッセージを、破棄せずに別のキュー (DLQ) に退避させることができます。これにより、並列処理を止めずに、失敗したデータのみを後で調査・再処理することが可能になります。

◦ Lambda 関数を非同期で呼び出す構成の場合、DLQ を設定することで、成功応答しか返らない非同期呼び出しであってもエラーをキャプチャし、SQS や SNS に通知して監視することが可能になります。

【AWS Lambda におけるデッドレターキューの詳細情報】

AWS Lambda におけるデッドレターキュー (DLQ: Dead Letter Queue) とは、非同期呼び出しされた関数の処理が繰り返し失敗した際に、そのイベントデータを破棄せずに別の場所に転送・保存する機能です。

その仕組みと特徴を解説します。

DLQ の役割と必要性

Lambda 関数を非同期（Event タイプ）で呼び出す場合、Lambda はリクエストを受け付けると呼び出し元に成功応答（ステータスコード 202）を返しますが、実際の処理はバックグラウンドで行われます,。そのため、バックグラウンドでの実行が失敗しても呼び出し元はエラーを検知できません。DLQ を設定することで、処理に失敗したイベントをキャプチャし、エラーの原因調査や再処理を行うことが可能になります。

処理の流れ (リトライとDLQへの送信)

非同期呼び出しが失敗した場合、Lambda は以下の挙動をとります。

自動リトライ: 関数がエラーを返すと、Lambda は自動的に 2 回の再試行を行います。

◦ 1回目の再試行: 初回失敗から 1 分後

◦ 2回目の再試行: 1回目の再試行失敗から 2 分後,

DLQ への送信: 規定の回数（初回 + 再試行 2 回）すべてで処理が失敗した場合、Lambda はそのイベントを DLQ に設定された送信先に転送します。
設定可能な送信先

DLQ として設定できる AWS サービスは以下の 2 つです。

• Amazon SQS キュー

• Amazon SNS トピック

必要な設定と権限

DLQ を機能させるためには、以下の設定が必要です。

• Lambda 関数の設定: 関数の DeadLetterConfig に送信先の ARN (TargetArn) を指定します。

• IAM 権限: Lambda 関数の実行ロールに対し、送信先に応じた以下の権限を付与する必要があります。

◦ Amazon SQS の場合: sqs:SendMessage

◦ Amazon SNS の場合: sns:Publish

この機能を利用することで、非同期処理の信頼性を高め、予期せぬエラーによるデータ損失（イベントの喪失）を防ぐことができます。

問題60:

あなたはソリューションアーキテクトとして、AWS上で決済アプリケーションの開発を担当しています。現在、詐欺行為を防ぐために、Amazon Kinesis Data Streamsを活用して決済処理データのリアルタイム詐欺検出機能を実装しています。このアプリケーションはミリ秒単位のエンドツーエンドのレイテンシーで優れたパフォーマンスを発揮していますが、CloudWatchのパフォーマンスデータによれば、割り当てられたシャードが十分に活用されていないことが示されています。

コストと利用容量を最適化するための最良のソリューションはどれでしょうか。

ホットシャードをマージして、Kinesis Data Streamに要する容量とコストを削減する。

回答は正解です
コールドシャードをマージして、Kinesis Data Streamに要する容量とコストを削減する。

ホットシャードを分割して、Kinesis Data Streamに要する容量とコストを削減する。

コールドシャードを分割して、Kinesis Data Streamに要する容量とコストを削減する。

全体的な説明
このシナリオでは、Amazon Kinesis Data Streamsのパフォーマンス最適化に関する課題が提示されています。具体的には、「割り当てられたシャードが十分に活用されていない」という問題が浮上しており、これによりAmazon Kinesis Data Streamsのシャード数に余剰が生じ、非効率な状況が生まれています。その結果、処理量に比較してコストが割高になってしまっています。

オプション２が正解となります。CloudWatchのパフォーマンスデータに基づき割り当てられたシャードが十分に活用されていないということは、各シャードの処理量が少ないことを示しています。このため、コールドシャードを統合することで、Kinesis Data Streamの容量とコストを削減することが最も効果的な対策となります。Amazon Kinesis Data Streamsでは、パフォーマンスの最適化としてリシャーディングが可能です。リシャーディングには、シャードの分割と結合の2つの操作があります。

・シャードの分割では、1つのシャードを2つに分けます。この分割により、ストリーム内のシャード数が増加し、ストリームのデータ容量も増加します。しかし、Amazon Kinesis Data Streamsはシャード単位で課金されるため、分割によってストリームのコストが増加することになります。

・シャードの結合では、2つのシャードを1つにまとめます。この結合により、ストリーム内のシャード数が減少し、結果としてストリームのデータ容量とコストが削減されます。

Kinesisの各シャードは、データ入力において1MB/秒、データ出力において2MB/秒の処理能力を持っています。また、1つのシャードは1秒間に最大1000件のPUTレコードを処理することが可能です。ストリーム全体の処理能力は、すべてのシャードの容量を合計したものとなります。複数のコンシューマーアプリケーションによる読み取り要求がシャードの制限を超える場合、Kinesisデータストリーム内のシャード数を増加させる必要があります。一方で、各シャードの処理量が少ない場合や、シャードが過剰である場合には、シャード数を減少させることが求められます。

【Kinesis のシャーディングの詳細情報】

Kinesis のシャーディング（リシャーディング）の仕組みと特徴を解説します。

基本的な操作

リシャーディングには、主に以下の 2 種類の操作があります。

• シャードの分割 (Split):

◦ 1 つのシャードを 2 つのシャードに分割します。

◦ 効果: ストリーム内のシャード数が増えるため、データ容量（処理能力）が増加します。ただし、シャード単位で課金されるため、コストも増加します。

• シャードの結合 (Merge):

◦ 2 つのシャードを 1 つのシャードに結合します。

◦ 効果: ストリーム内のシャード数が減るため、データ容量は減少しますが、コストを削減できます。

仕組みと制約

リシャーディングは常に「ペアワイズ」で行われるという特徴があります。

• 親と子: 操作の対象となるシャードを「親シャード」、操作の結果生成されるシャードを「子シャード」と呼びます。

• 数の制限: 1 回の操作で分割できるシャード数は 1 つ（結果として 2 つになる）、結合できるシャード数は 2 つ（結果として 1 つになる）に限られます。これを超える数を一度に操作することはできません。

実行方法と管理

リシャーディングを行うには、以下の方法があります。

• API の利用: UpdateShardCount API を使用して、ストリームのシャード数を指定して再構成することができます。

• 手動操作: 個別に分割（Split）や結合（Merge）の操作を実行することも可能です。

• 管理アプリケーション: 通常、リシャーディングはプロデューサー（送信側）やコンシューマー（受信側）とは別の「管理アプリケーション」によって実行されます。この管理アプリケーションは、Amazon CloudWatch のメトリクスなどを監視し、ストリームのパフォーマンスに基づいてシャード数の調整を判断します。

注意点

• 高度な操作: リシャーディングは高度な操作と見なされており、Kinesis Data Streams の他の機能に慣れてから行うことが推奨されています。

• 権限: リシャーディングを実行する管理アプリケーションには、通常のデータの送受信よりも広範な IAM 権限が必要になります。

問題62:

あなたはソリューションアーキテクトとして、AWS上でWEBアプリケーションを開発しています。このアプリケーションは、ユーザーにデータ変換サービスを提供することを目的としています。変換されるファイルは、まずS3バケットにアップロードされ、その後、EC2のスポットインスタンスのフリートグループによってデータ変換が行われます。ユーザーは無料ユーザーと有料ユーザーに分類され、有料ユーザーからのファイルは優先的に処理される必要があります。

このような要件を満たすための実装方法を選定してください。

Amazon Route53を利用して、顧客タイプに応じたトラフィックルーティングを設定する。

正解
2つのAmazon SQSキューを作成する。有料ユーザーには優先的に処理するキューを１つ設定し、無料ユーザーにはもう1つのデフォルトのキューを設定する。

回答は不正解です
1つのAmazon SQSキューを作成する。AWS Lambda関数を作成して、有料ユーザー向けのメッセージ処理を優先的にポーリング処理するように設定する。

2つのAmazon SNSトピックを作成する。有料ユーザーには優先的に処理するトピックを１つ設定し、無料ユーザーにはもう1つのデフォルトのトピックを設定する。

全体的な説明
オプション２が正解となります。Amazon SQSでは、キューに優先度を設定することが可能です。この機能により、優先的に処理されるキューとそうでないキューを区別することができます。各キューは独立してポーリングされ、優先順位の高いキューが最初に処理されます。この設定により、有料ユーザーには優先的なキューを割り当て、無料ユーザーには標準のキューを利用させることができます。

優先順位の設定方法は以下の通りです。

１．SQSを使用して、優先順位ごとに複数のキューを作成する。

２．処理を急ぐリクエストは、優先順位の高いキューに配置する。

３．優先順位に基づいて、キューを処理するためのサーバーの台数を確保する。

４．キューの「メッセージの遅延送信」機能を活用することで、処理開始のタイミングを遅らせることも可能です。

オプション１は不正解です。Route53はルーティングポリシーに従って最適なルーティングを実現することができますが、顧客タイプに応じて優先度をつけたトラフィックルーティングを設定する機能はありません。

オプション３は不正解です。Lambda関数を利用して有料ユーザーのメッセージ処理を優先的に処理するポーリング処理を設定することはできません。キューの優先度はSQSキューにおいて設定します。

オプション４は不正解です。Amazon SNSは柔軟なフルマネージド型の pub/sub メッセージング/モバイル通知サービスです。Amazon SNSにおいてメッセージの優先順位をつける機能はありません。

問題63:

あなたはソリューションアーキテクトとして、AWS上でアプリケーションを開発しています。このアプリケーションでは、VPCのパブリックサブネットにパブリックIPを持つLinuxのEC2インスタンスを配置しています。しかし、あなたはインターネット経由でSSHを使用してLinux EC2インスタンスに接続することができませんでした。EC2インスタンスが存在するVPC環境を確認したところ、次のような設定がなされていました。

・EC2インスタンスにはパブリックIPアドレスが割り当てられている。

・セキュリティグループではSSHのインバウンドアクセスが許可されている。

・サブネットのネットワークACLではSSHのインバウンドおよびアウトバウンドアクセスが許可されている。デフォルトのネットワークACLは利用されていない。

・パブリックサブネットにはインターネットゲートウェイへのルートが設定されている。

インターネットからEC2インスタンスに接続するためには、追加でどのような手順を実施するべきでしょうか？

正解
ネットワークACLのアウトバウンド通信設定にエフェメラルポートへのアウトバウンド通信を許可するルールを追加する。

回答は不正解です
セキュリティグループにSSHのアウトバウンドのアクセスを許可するルールを追加する。

セカンダリーIPアドレスをEC2インスタンスに設定する。

パブリックサブネットのルートテーブルにNATゲートウェイへのルートを設定する。

全体的な説明
オプション１が正解となります。このEC2インスタンスをインターネットからアクセス可能にするためには、セキュリティグループおよびネットワークACLにおいて適切な通信設定が行われていること、さらに設置されているパブリックサブネットのルートテーブルにはインターネットゲートウェイへのルートが設定されていることを確認する必要があります。

ネットワークACLはステートレスであるため、インバウンド通信を許可するだけでなく、アウトバウンド通信の許可設定も求められます。PC端末からLinux EC2インスタンスへとSSH通信アクセスを実施する場合、アウトバウンド通信時のためにはPC端末を想定したポート番号が必要となります。そのために利用するのがエフェメラルポートを使用した設定です。

具体的には、1024から65535のポート番号範囲でSSHを許可する必要があります。これにより、PC側で設定されたポート番号が1024から65535の範囲内であれば、ネットワークACLによって戻りトラフィックが許可されることになります。

インターネット経由でSSHを用いてLinux EC2インスタンスに接続するためには、EC2インスタンスが存在するVPC環境に以下のような設定が必要です。

■EC2インスタンスはパブリックIPアドレスまたはElastic IPアドレスが付与されている。

パブリックインターネットからEC2インスタンスにアクセスするにはパブリックIPアドレスが必要です。プライベートサブネット内に展開されている場合は、NATゲートウェイを介してElastic IPアドレスを交換します。

■セキュリティグループにはSSHのインバウンドアクセスが許可されている。
セキュリティグループはステートフルであるため、SSHのインバウンドアクセスが許可されていればアウトバウンドの許可は必要はありません。

■サブネットのネットワークACLにはSSHのインバウンドアクセスに加えて、アウトバウンド通信設定にエファメルポートへのアウトバウンド通信の許可ルールを設定する。

ネットワークACLはステートレスであるため、アウトバウンド通信の許可設定も必要となります。その場合は、PC側の広範囲なポート番号が必要となるため、エフェメラルポートの設定が必要となります。これは1024-65535のポート番号範囲でSSHを許可する設定です。これによって、PC側で1024-65535のポート番号範囲のいずれかが設定されたとしても、ネットワークACLによって戻りトラフィックが許可されることになります。

■パブリックサブネットにはインターネットゲートウェイへのルートが設定されている。

これによって、パブリックサブネットはインターネットへの通信が可能となります。

オプション２は不正解です。セキュリティグループはステートフルであるため、SSHのインバウンドアクセスが許可されていればアウトバウンドの許可は必要はありません。

オプション３は不正解です。インターネットからアクセスするためには、セカンダリーIPは必須ではありません。

オプション４は不正解です。NATゲートウェイはプライベートサブネットにあるEC2インスタンスからインターネットへのトラフィック返信を可能にするアドレス変換ゲートウェイ機能であるため、正しくありません。

問題64:

ある企業が、高可用性を求めるWEBアプリケーションを開発しています。このアプリケーションは、Amazon EC2インスタンス上のWindowsサーバーでホストされています。アプリケーショントラフィックは、ELBを通じてインターネットと接続されています。過去に大規模なDDoS攻撃を受けてアプリケーションが停止した経験があるため、企業はこのような攻撃を未然に防ぐための対策を講じる必要があります。

ソリューションアーキテクトが採るべきアクションの組み合わせはどれでしょうか？（2つ選択）

選択は正解です
AWS Shield Advancedを適用してDDoS攻撃を止める。

攻撃を自動的に遮断するようにAmazon GuardDutyを設定する。

EC2インスタンスをオリジンサーバーとしてAmazon CloudFrontディストリビューションを設定し、WEBアプリケーションのコンテンツ配信処理に適用する。

AWS Lambda関数によって、ネットワークACLの拒否設定にDDoS攻撃に利用されているIPアドレスを自動で追加する仕組みを実装する。

選択は正解です
ELBをオリジンサーバーとしてAmazon CloudFrontディストリビューションを設定し、WEBアプリケーションのコンテンツ配信処理に適用する。

全体的な説明
このシナリオでは、大規模かつ高度なDDoS攻撃から保護するためのネットワークセキュリティ機能や構成の選択方法が求められています。大規模なDDoS攻撃に対処するためには、AWS ShieldおよびAWS WAFをCloudFrontおよびRoute53に設定することが不可欠です。この質問では、機能の詳細な設定方法の理解も必要とされています。

オプション１は正解となります。AWS Shieldは、マネージド型の分散サービス妨害（DDoS）攻撃からの保護を提供するサービスです。AWS Shield Standardは、ウェブサイトやアプリケーションを対象としたネットワークおよびトランスポートレイヤーのDDoS攻撃を防ぐ役割を果たします。このサービスは、Amazon CloudFrontとRoute 53を利用することで自動的に適用されます。

一方、AWS Shield Advancedは、AWS Shield Standardの機能に加え、Elastic IPアドレス、ELB、Amazon CloudFront、Global Accelerator、またはRoute 53リソースに対して、トラフィックパターンに基づいたカスタマイズ可能な検出方法を設定することが可能です。これにより、大規模かつ高度なDDoS攻撃に対する追加の検出および緩和策を実施することができます。

オプション５は正解となります。ELBをオリジンサーバーにしてAmazon CloudFrontディストリビューションを設定するだけで、自動的にAWS Shield Standard版が適用されます。AWS Shieldは、ELBやAmazon CloudFrontまたはRoute 53を起動する際に設定されます。Amazon CloudFrontとAWS Shieldを組み合わせることで、ウェブアプリケーションに対するDDoS攻撃に対して最適な防御を構築することができます。

オプション２は不正解です。Amazon GuardDutyは、AWSアカウントおよびワークロードを悪意のある活動から継続的に監視し、自動的に対策を講じる機能を提供します。DDoS攻撃を除くさまざまなネットワークへの不正アクセスを自動的に検出し、緩和することが可能です。

オプション３は不正解です。このアプリケーションはELBを利用してEC2へのトラフィックを分散させています。CloudFrontを直接EC2インスタンスに適用すると、トラフィックが単一のEC2に集中してしまい、適切な構成とは言えません。

オプション４は不正解です。AWS Lambda関数を使用して、ネットワークACLの拒否リストにDDoS攻撃に使用されるIPアドレスを自動的に追加する仕組みを構築することは可能ですが、数千のIPアドレスをすべてACLで管理するのは非効率的です。

問題65:

ある企業がAWSを活用して画像共有アプリケーションを運営しています。このアプリケーションはEC2インスタンスを基盤として構成されており、同一のAWSリージョン内に存在する複数のAmazon S3バケット間で画像を共有する必要があります。画像のアップロードやダウンロードが頻繁に行われるため、データ転送にかかるコストが増大しています。あなたはソリューションアーキテクトとして、コスト削減の施策を講じる必要があります。

この要件を満たすために、ソリューションアーキテクトはどのような対策を講じるべきでしょうか。（2つ選択）

選択は不正解です
インターフェースエンドポイントをパブリックサブネットにデプロイして、エンドポイント経由でルーティングしてAmazon S3バケットにアクセスするようにルートテーブルを設定する。

正しい選択
インターフェースエンドポイントをVPC内のプライベートサブネットに配置する。エンドポイントにセキュリティグループによる適切な通信許可を設定する。Amazon S3バケットへのアクセスを許可するエンドポイントポリシーをアタッチする。

アプリケーションをパブリックサブネットにデプロイして、インターネットゲートウェイ経由でルーティングしてAmazon S3バケットにアクセスする。

選択は正解です
ゲートウェイエンドポイントをVPCに配置する。エンドポイントに適切なルートテーブルを設定する。Amazon S3バケットへのアクセスを許可するエンドポイントポリシーをアタッチする。

ゲートウェイエンドポイントをVPCに配置する。エンドポイントのプライベート IP アドレスを使用して Amazon S3バケットにアクセスする。

全体的な説明
オプション４が正解となります。Amazon EC2インスタンスはVPC内で動作するサービスですが、Amazon S3はリージョンに配置されるVPC外のサービスとなります。このため、デフォルトのネットワーク設定では、EC2インスタンスとS3バケット間の通信はインターネットを経由することになり、データ転送に伴うコストが発生します。

VPCエンドポイントを利用することで、インターネットを介さずにVPC内のサービスからVPC外のAWSサービスに通信が可能となります。これにより、EC2インスタンスからS3バケットへの通信がインターネットを通さずに行われ、同一リージョン内での通信は無料となるため、通信料金が発生しなくなります。

VPC内のリソースからAmazon S3へのアクセスには、ゲートウェイエンドポイントとインターフェイスエンドポイント（AWS PrivateLinkを使用）の2種類のVPCエンドポイントを利用できます。

ゲートウェイエンドポイントは、AWSネットワークを通じてVPCからAmazon S3にアクセスするために、VPCのルートテーブルにルートを設定する必要があります。このエンドポイントは、VPCがインターネットゲートウェイやNATデバイスを介さずに、Amazon S3およびDynamoDBへの信頼性の高い接続を提供します。S3やDynamoDBに接続したいリソースが存在するVPCにVPCエンドポイントを割り当て、ルートテーブルにそのルーティングを設定します。

オプション２も正解となります。以前は、Amazon S3はインターフェースエンドポイントに対応していませんでしたが、2021年にAWS PrivateLink for Amazon S3という新機能が導入されました。この機能により、VPCのインターフェースエンドポイントからAmazon S3バケットへのアクセスが可能となりました。

インターフェースエンドポイントでは、サブネットにエンドポイントのネットワークインターフェイスが作成され、サブネットのIPアドレス範囲からプライベートIPアドレスが割り当てられます。インターフェースエンドポイントはネットワークインターフェイスを利用した接続を行うため、セキュリティグループによる通信設定が可能であり、エンドポイントポリシーを用いたアクセス許可が必要となります。

オプション１は不正解です。インターフェイス VPC エンドポイント (インターフェイスエンドポイント) を利用する場合は、 Amazon S3 へのアクセスをコントロールするエンドポイントポリシーをアタッチすることが必要です。

オプション３は不正解です。インターネットゲートウェイ経由でルーティングしてS3バケットにアクセスすることは可能ですが、画像をダウンロードするインターネットへのアウトバウンド通信の際にデータ転送コストが発生してしまいます。

オプション５は不正解です。ゲートウェイエンドポイントはパブリックIPアドレスを介して、 Amazon S3 にアクセスします。

【Amazon S3 における VPC エンドポイントの詳細情報】

Amazon S3 で VPC エンドポイントを利用する場合、ゲートウェイエンドポイントとインターフェイスエンドポイント (AWS PrivateLink) の 2 種類があり、それぞれ特徴や用途が異なります。

エンドポイントの種類の選択

S3 へのアクセス要件に応じて、以下のいずれか、または両方を組み合わせて使用します。

ハイブリッド構成 (併用): 同じ VPC 内で両方のエンドポイントを併用することが可能です。例えば、VPC 内の EC2 からの通信にはコストのかからない「ゲートウェイエンドポイント」を使用し、オンプレミスからの通信には「インターフェイスエンドポイント」を使用することで、コストと接続性を最適化できます。

インターフェイスエンドポイントの設定と DNS

インターフェイスエンドポイントを使用する場合、DNS 設定によりアクセスの利便性を向上できます。

• DNS 名: インターフェイスエンドポイントを作成すると、エンドポイント固有の DNS 名が生成されます。

• プライベート DNS: このオプションを有効にすると、S3 の標準的な DNS 名 (例: s3.us-east-1.amazonaws.com) へのクエリが、インターフェイスエンドポイントのプライベート IP アドレスに解決されるようになります。

◦ オンプレミスのアプリケーションがコード変更なしで S3 にアクセスできるようになります。

◦ 注意: 「インバウンドエンドポイントでのみプライベート DNS を有効にする」オプションを使用する場合、VPC 内のトラフィックが意図せずインターフェイスエンドポイント (有料) を通らないよう、VPC 内にゲートウェイエンドポイントが存在する必要があります。

セキュリティとアクセス制御

VPC エンドポイントを利用する際、以下のポリシーを使用してアクセスを厳格に制御できます。

• VPC エンドポイントポリシー: エンドポイント自体にポリシーをアタッチし、そのエンドポイント経由で「誰が」「どの S3 バケットに対して」「何ができるか」を制御します。

◦ 例: 特定のバケット (例: amzn-s3-demo-bucket1) へのアクセスのみを許可する。

◦ 例: 特定の AWS アカウントのバケットへのアクセスのみを許可する。

• S3 バケットポリシー: S3 バケット側で、特定の VPC エンドポイントからのアクセスのみを許可するように制限します。

◦ aws:sourceVpce 条件キー: 特定の VPC エンドポイント ID (例: vpce-1a2b3c4d) からのアクセスのみを許可し、それ以外 (インターネット経由など) を拒否することができます,。

◦ 注意: バケットポリシーで制限をかける際は、使用するエンドポイント ID が正しいことを確認してください。誤った設定を行うとバケットへのアクセスが完全にブロックされる可能性があります。

制約事項

S3 のインターフェイスエンドポイントにはいくつかの制限があります。

• Web サイトエンドポイント、FIPS エンドポイントなどはサポートされていません。

• 異なるリージョンのバケット間での CopyObject などはサポートされていません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up