About Me
Hello! My name is dasu. I’m passionate about technology, AWS, and blogging. This is a simple HTML page to get started with web development.
My Interests
- Cloud Computing
- Web Development
プラットフォームはAmazon Elastic Container Service（ECS）クラスタで稼働しており、ECSクラスタはAuto Scalingグループに属するAmazon EC2のオンデマンドインスタンスで構成されています。Auto Scalingグループは予測スケーリングポリシーを利用しています。
ECSクラスタは頻繁にAmazon S3バケットにアクセスしてチケットの資産をダウンロードします。ECSクラスタとS3バケットは同じAWSリージョンかつ同一アカウント内にあり、両者間の通信はNATゲートウェイを経由しています。
会社はプラットフォームの可用性を下げずにコストを最適化したいと考えています。
どの組み合わせの対策がこの要件を満たしますか？（2つ選びなさい）
A. S3バケット用にゲートウェイVPCエンドポイントを作成する。
B. スポットインスタンスを使うAuto Scalingグループを持つ別のECSキャパシティプロバイダーを追加し、新しいキャパシティプロバイダーストラテジーの重みを既存のものと同じに設定する。
C. スケジュールスケーリングポリシーの期間に対応したオンデマンドキャパシティ予約を作成する。
D. S3バケットでS3 Transfer Accelerationを有効にする。
E. 予測スケーリングポリシーを、スケジュールされたイベントに合わせたスケジュールスケーリングポリシーに置き換える。
解説
A: ECSクラスタとS3バケットが同じリージョンかつ同じアカウント内であれば、ゲートウェイVPCエンドポイントを作成することでS3への通信がインターネット経由でなくなり、NATゲートウェイの使用を避けて通信料を削減できる。コスト削減につながる。
E: 会社は顧客イベントの日時を把握しているため、予測スケーリングよりも特定の日時に合わせたスケジュールスケーリングポリシーを使うほうが効率的であり、無駄なスケールアウトを抑えてコストを最適化できる。
B: スポットインスタンスはコスト削減にはなるが、インスタンスの中断が発生しやすいため可用性を下げるリスクがある。
C: オンデマンドキャパシティ予約は確実にキャパシティを確保できるが、予約分の料金が常に発生しコスト増加につながる。
D: S3 Transfer Accelerationはグローバルに高速転送する機能だが、追加料金が発生し今回の要件には適さない。
同社は、オンプレミスのKubernetesクラスターをAmazon Elastic Kubernetes Service（Amazon EKS）クラスターに移行することを決定しました。EKSクラスターでは、EKSのマネージドノードグループを使用し、ノード数は固定とします。また、オンプレミスのデータベースもAmazon RDS for PostgreSQLに移行します。
ソリューションアーキテクトは、移行前にこのワークロードの総所有コスト（TCO）を見積もる必要があります。
どのソリューションが必要なTCO情報を提供しますか？
A. Migration Evaluatorへのアクセスを申請する。Migration Evaluator Collectorを実行してデータをインポートする。シナリオを構成する。Migration EvaluatorからQuick Insightsレポートをエクスポートする。
B. オンプレミスのデータベースに対してAWS Database Migration Service（AWS DMS）を起動する。アセスメントレポートを生成する。EKS移行のコストをAWS Pricing Calculatorで見積もる。
C. AWS Application Migration Serviceを初期化する。オンプレミスサーバーをソースサーバーとして追加する。テストインスタンスを起動する。Application Migration ServiceからTCOレポートを出力する。
D. AWS Cloud Economics CenterのWebページにアクセスしてAWS Cloud Value Frameworkを評価する。Cloud Value FrameworkからAWSのコストおよび使用状況レポートを作成する。
解説
Migration Evaluator（旧称TSO Logic）は、オンプレミスのワークロードをAWSに移行する際の総所有コスト（TCO）を評価するための専用ツールです。Migration Evaluator Collectorを使用して現在の使用状況を収集し、それに基づいた「Quick Insights」などのレポートを生成することで、AWS上でのコスト予測が可能になります。移行の意思決定のための費用対効果分析に最適な方法です。
BのDMSはデータベースの移行を支援しますが、TCO全体を評価するためのツールではありません。CのApplication Migration Serviceはサーバー移行に使いますが、TCOレポートの出力機能はありません。DのCloud Economics CenterやCloud Value Frameworkは概念的な価値評価ツールであり、実際の見積もりやTCO算出には使用できません。したがって、正解はAです。
データサイエンティストは、これらのEC2インスタンスからデータレイクへアクセスする必要がある。EC2インスタンスには既にAmazon S3へアクセスするための権限があるIAMロールが割り当てられている。会社のポリシーでは、許可されたネットワークからのみIoTデータへのアクセスが許可されている。
この要件を満たすために、ソリューションアーキテクトが取るべきステップの組み合わせはどれか。（2つ選べ）
A. データサイエンティストのVPCにAmazon S3用のゲートウェイVPCエンドポイントを作成する。
B. データサイエンティストのAWSアカウント内にデータレイク用のS3アクセスポイントを作成する。
C. EC2インスタンスのIAMロールを更新する。s3:GetObjectアクションを許可するポリシーに、s3:DataAccessPointArn条件キーの値が有効なアクセスポイントARNである場合のみ許可する条件を追加する。
D. VPCのルートテーブルを更新して、S3トラフィックをS3アクセスポイントにルーティングする。
E. S3バケットポリシーに、s3:GetObjectアクションを許可する条件として、s3:DataAccessPointArn条件キーの値が有効なアクセスポイントARNである場合に許可する設定を追加する。
解説：
- A は、S3へのプライベートアクセスを提供するために必要です。会社のポリシーでは「許可されたネットワークのみがIoTデータへアクセス可能」とあるため、インターネット経由ではなくVPCエンドポイント経由でのアクセスが求められます。
- E は、アクセスポイントベースのアクセス制御をS3側で行うためのバケットポリシーの設定です。これにより、特定のアクセスポイント経由のみでデータへアクセスを許可できます。
B は誤りです。S3アクセスポイントはバケットの所有アカウントで作成する必要があります。
C はIAM側の設定であり有効ですが、バケット側で制御するのがより確実で推奨される手法です。
D は無効です。VPCルートテーブルではS3アクセスポイントへのルーティングはできません。VPCエンドポイントが必要です。
アプリケーションは5秒ごとにセンサーデータを送信します。新しいセンサーデータは、アプリケーションがデータを収集してから30分以内にAmazon S3で利用可能になる必要があります。AWS IoT Coreからのセンサーデータを処理する他のアプリケーションはありません。
最もコスト効率的にこれらの要件を満たすソリューションはどれですか？
A. AWS IoT Coreでトピックを作成してセンサーデータを取り込みます。データを加工してAmazon S3に書き込むAWS Lambda関数を作成します。Lambda関数を呼び出すAWS IoTルールアクションを設定します。
B. AWS IoT Core Basic Ingestを使用してセンサーデータを取り込みます。Amazon Kinesis Data Firehoseにデータを書き込むAWS IoTルールアクションを設定します。Kinesis Data Firehoseのバッファリング間隔を900秒に設定します。Kinesis Data FirehoseでAWS Lambda関数を呼び出してデータを加工し、Kinesis Data FirehoseでAmazon S3にデータを配信するよう設定します。
C. AWS IoT Coreでトピックを作成してセンサーデータを取り込みます。Amazon Timestreamテーブルにデータを送信するAWS IoTルールアクションを設定します。Timestreamからデータを読み取るAWS Lambda関数を作成します。Lambda関数でデータを加工してAmazon S3に書き込むよう設定します。
D. AWS IoT Core Basic Ingestを使用してセンサーデータを取り込みます。Amazon Kinesis Data Streamsにデータを書き込むAWS IoTルールアクションを設定します。Kinesis Data Streamsからデータを処理してデータを加工するコンシューマーAWS Lambda関数を作成します。Lambda関数からS3 PutObject API操作を呼び出してAmazon S3にデータを書き込みます。
解説：この問題では、コスト効率性、データ加工の必要性、30分以内の配信要件、5秒ごとのデータ送信頻度を考慮する必要があります。
選択肢Bが最もコスト効率的な理由は以下の通りです：
AWS IoT Core Basic Ingestは通常のトピックベースのメッセージングよりもコストが低く、データのルーティングのみを行う場合に適しています。
Kinesis Data Firehoseは自動的にデータをバッファリングして一括処理するため、Lambda関数の実行回数を大幅に削減できます。900秒（15分）のバッファリング間隔により、30分の要件を満たしながらコストを最適化できます。
Firehoseのデータ変換機能を使用してLambda関数でデータ加工を行い、その後自動的にS3に配信されるため、効率的です。
他の選択肢の問題点：
選択肢A：5秒ごとのデータ送信で毎回Lambda関数が実行されるため、コストが高くなります。
選択肢C：Timestreamは時系列データベースとして不要なコストが発生し、Lambda関数で定期的にデータを読み取る複雑性が追加されます。
選択肢D：Kinesis Data Streamsは継続的な処理能力を提供しますが、このユースケースではFirehoseの方がシンプルでコスト効率的です。
同社は、アプリケーションの応答が遅いというユーザーからの報告を受けています。パフォーマンスメトリクスによると、通常時のCPU使用率は10%ですが、ピーク時（通常は数時間続く）にはCPU使用率が100%に達しています。
同社は、アプリケーションの応答遅延の問題を解決するための新しいアーキテクチャを必要としています。
この要件を最もコスト効率よく満たすソリューションはどれですか？
A. Auto Scalingグループを作成し、そのグループをNLBのターゲットグループにアタッチします。最小容量を20、希望容量を28に設定します。20台分のリザーブドインスタンスを購入します。
B. リクエストタイプを「request」とするSpot Fleetを作成します。TotalTargetCapacity パラメータを20に設定し、DefaultTargetCapacityType パラメータをオンデマンドに設定します。Spot Fleetを作成する際にNLBを指定します。
C. リクエストタイプを「maintain」とするSpot Fleetを作成します。TotalTargetCapacity パラメータを20に、DefaultTargetCapacityType パラメータをスポットに設定します。NLBをApplication Load Balancerに置き換えます。
D. Auto Scalingグループを作成し、そのグループをNLBのターゲットグループにアタッチします。最小容量を4、最大容量を28に設定します。4台分のリザーブドインスタンスを購入します。
理由：
- アプリケーションは常に稼働しており、トラフィックのピーク時にだけリソース不足になります。
- D案では、最低限必要なインスタンス（4台）をReserved Instancesでコスト最適化し、必要に応じてAuto Scalingにより最大28台までスケールアウトします。
- ステートレスなアプリケーションであるため、スケーリングも容易です。
- オンデマンドインスタンスを最小限に抑え、スパイク時のみ増加させることで、コストを効果的に抑えつつパフォーマンスを維持できます。
- A案は常に28台を動かす前提であり、過剰リソースで高コストになります。
- B・C案はSpot Fleetの利用ですが、可用性やスケーラビリティの観点からAuto Scalingの方が堅牢であり、NLBとの統合もスムーズです。
この企業は、使用率の低い開発用EC2インスタンスを検出して停止する必要があります。インスタンスは、過去14日間のうち少なくとも4日間で1日平均CPU使用率が10%以下かつネットワークI/Oが5MB以下の場合に使用率が低いとみなされます。
最も運用オーバーヘッドが少なくこれらの要件を満たすソリューションはどれですか？
A. 部門、事業単位、環境のタグに基づいてEC2インスタンスの使用率を監視するAmazon CloudWatchダッシュボードを設定します。使用率の低い開発用EC2インスタンスを停止するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成します。
B. EC2インスタンスの使用率を追跡し、使用率の低いインスタンスをAmazon CloudWatchに報告するようにAWS Systems Managerを設定します。部門、事業単位、環境のタグでCloudWatchデータをフィルタリングします。使用率の低い開発用EC2インスタンスを停止するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成します。
C. AWS Trusted Advisorによって報告されるEC2インスタンスの低使用率を検出するAmazon EventBridgeルールを作成します。部門、事業単位、環境のタグでデータをフィルタリングし、使用率の低い開発用EC2インスタンスを停止するAWS Lambda関数を呼び出すようにルールを設定します。
D. すべてのEC2インスタンスの使用率データを取得するために毎日実行するAWS Lambda関数を作成します。データをAmazon DynamoDBテーブルに保存します。DynamoDBテーブルをデータソースとして使用して、使用率の低い開発用EC2インスタンスを識別して停止するAmazon QuickSightダッシュボードを作成します。
解説：この問題では、運用オーバーヘッドを最小限に抑えながら、特定の条件（CPU使用率10%以下、ネットワークI/O 5MB以下、過去14日間のうち4日間）に基づいて使用率の低いEC2インスタンスを自動的に検出・停止する必要があります。
選択肢Cが最適な理由：
AWS Trusted AdvisorはAWS Business Supportプランに含まれており、追加コストなしで利用できます。
Trusted Advisorは既に「Low Utilization Amazon EC2 Instances」チェックを提供しており、問題で指定された条件（CPU使用率10%以下、ネットワークI/O低使用率、過去14日間の監視）と一致します。
EventBridgeとの統合により、Trusted Advisorの結果に基づいて自動的にアクションを実行できます。
既存のマネージドサービスを活用するため、カスタム監視ロジックの構築や維持が不要で運用オーバーヘッドが最小です。
他の選択肢の問題点：
選択肢A：CloudWatchダッシュボードは手動監視用であり、指定された複雑な条件での自動検出には適していません。
選択肢B：Systems Managerにはこの特定の使用率追跡機能は標準で含まれておらず、カスタム設定が必要で運用オーバーヘッドが増加します。
選択肢D：毎日実行されるLambda関数とDynamoDBによるカスタムソリューションは複雑で運用オーバーヘッドが高く、QuickSightは可視化ツールであり自動停止機能は提供しません。
ソリューションアーキテクトがこれらの要件を満たすために実行すべき手順の組み合わせはどれですか？（2つ選択してください）
A. Amazon Data Firehoseを宛先とするAmazon SES設定セットを作成します。Amazon S3バケットにログを送信するように選択します。
B. AWS CloudTrailログ記録を有効にします。ログの宛先としてAmazon S3バケットを指定します。
C. 受信者、件名、送信時刻についてAmazon S3バケット内のログをクエリするためにAmazon Athenaを使用します。
D. Amazon CloudWatchログ群を作成します。ログ群にログを送信するようにAmazon SESを設定します。
E. 受信者、件名、送信時刻についてAmazon CloudWatch内のログをクエリするためにAmazon Athenaを使用します。
解説：この問題では、Amazon SESのメール配信に関する詳細なログ記録と、特定の条件（受信者、件名、送信時刻）での検索機能が求められています。
選択肢Aが正しい理由：
Amazon SES設定セットは、メール送信イベント（送信、配信、バウンス、苦情など）の詳細なログを記録するための適切な方法です。
Amazon Data Firehose（旧Kinesis Data Firehose）を宛先とすることで、ログデータを自動的にS3バケットに配信できます。
この方法により、メール配信の詳細情報（受信者、件名、送信時刻など）を構造化された形式で記録できます。
選択肢Cが正しい理由：
Amazon Athenaは、S3に保存されたデータに対してSQLクエリを実行できるサーバーレス分析サービスです。
SES設定セットによってS3に保存されたログデータに対して、受信者、件名、送信時刻などの条件で効率的に検索を実行できます。
構造化されたログデータに対するクエリ性能が優れています。
他の選択肢が不適切な理由：
選択肢B：CloudTrailはAPI呼び出しの監査ログを記録しますが、メール配信の詳細情報（受信者、件名など）は含まれません。
選択肢D：SESは直接CloudWatchログ群にログを送信する機能を提供していません。
選択肢E：AthenaはCloudWatchログを直接クエリできません。CloudWatchログをクエリするにはCloudWatch Logsの検索機能を使用する必要がありますが、複雑な条件での検索には制限があります。
ただし、アプリケーションは他のVPCにはアクセスできてはいけません。
両リージョンのVPCには重複するCIDR範囲はありません。すべてのアカウントは既にAWS Organizations内の1つの組織に統合されています。
最もコスト効率的にこれらの要件を満たすソリューションはどれですか？
A. eu-west-1に1つのトランジットゲートウェイを作成します。us-east-2のVPCとeu-west-1のVPCをトランジットゲートウェイにアタッチします。トラフィックがトランジットゲートウェイを通してルーティングされるように、各VPCに必要なルートエントリを作成します。
B. 各リージョンに1つずつトランジットゲートウェイを作成します。関連するサブネットを地域のトランジットゲートウェイにアタッチします。トラフィックが地域のトランジットゲートウェイを通してルーティングされるように、各サブネットの関連するルートテーブルに必要なルートエントリを作成します。2つのトランジットゲートウェイをピアリングします。
C. すべてのVPC間でフルメッシュVPCピアリング接続設定を作成します。トラフィックがVPCピアリング接続を通してルーティングされるように、各VPCに必要なルートエントリを作成します。
D. us-east-2の各VPCからeu-west-1のVPCへの1つずつのVPCピアリング接続を作成します。トラフィックがVPCピアリング接続を通してルーティングされるように、各VPCに必要なルートエントリを作成します。
解説：この問題では、us-east-2リージョンの5つのVPCがeu-west-1リージョンの1つのVPCにのみアクセスできるようにし、他のVPCには一切アクセスできないようにする必要があります。
選択肢Dが最もコスト効率的な理由：
要件に応じた最小限の接続：us-east-2の各VPC（5つ）からeu-west-1の1つのVPCへの直接的なピアリング接続のみを作成するため、必要最小限の接続数（5つ）で済みます。
VPCピアリングは1対1の接続であり、他のVPCへの意図しないアクセスを防げます。
追加のインフラストラクチャ（トランジットゲートウェイ）が不要で、VPCピアリングの時間単位課金のみでコストを抑えられます。
クロスリージョンVPCピアリングは直接サポートされており、シンプルで効率的です。
他の選択肢の問題点：
選択肢A：eu-west-1にトランジットゲートウェイを作成し、us-east-2のVPCをクロスリージョンでアタッチするのは技術的に不可能です。トランジットゲートウェイはリージョン固有のサービスです。
選択肢B：各リージョンにトランジットゲートウェイを作成し、それらをピアリングする方法は技術的に可能ですが、トランジットゲートウェイの時間単位課金とデータ処理料金により、VPCピアリングよりもコストが高くなります。
選択肢C：フルメッシュ構成では15個のピアリング接続（5×6÷2）が必要になり、要件を超えた不要な接続が含まれ、コストと複雑性が増加します。また、us-east-2内のVPC間での通信も可能になってしまい、要件に反します。
A. ポート80のアウトバウンドトラフィックをブロックするネットワークACLを作成します。ネットワークACLをアプリケーションアカウント内のすべてのサブネットに関連付けます。アプリケーションアカウントとコアアカウントで、カスタムVPNサーバーを実行するEC2インスタンスを1つずつデプロイします。プライベートVPCにアクセスするためのVPNトンネルを作成します。アプリケーションアカウントのルートテーブルを更新します。
B. Systems ManagerとAmazon S3用のプライベートVIFを作成します。アプリケーションアカウントのVPCからNATゲートウェイを削除します。コアアカウント内のパッチソースリポジトリEC2インスタンスにアクセスするためのトランジットゲートウェイを作成します。コアアカウントのルートテーブルを更新します。
C. Systems ManagerとAmazon S3用のVPCエンドポイントを作成します。アプリケーションアカウントのVPCからNATゲートウェイを削除します。コアアカウント内のパッチソースリポジトリEC2インスタンスにアクセスするためのVPCピアリング接続を作成します。両方のアカウントのルートテーブルを更新します。
D. ポート80のインバウンドトラフィックをブロックするネットワークACLを作成します。ネットワークACLをアプリケーションアカウント内のすべてのサブネットに関連付けます。コアアカウント内のパッチソースリポジトリEC2インスタンスにアクセスするためのトランジットゲートウェイを作成します。両方のアカウントのルートテーブルを更新します。
解説：この問題では、インターネットアクセスを完全に遮断しながら、Systems Manager、S3、およびクロスアカウントのパッチソースリポジトリへのアクセスを確保する必要があります。
選択肢Cが正しい理由：
VPCエンドポイントの使用：Systems ManagerとS3用のVPCエンドポイントを作成することで、インターネットを経由せずにこれらのAWSサービスに直接アクセスできます。これにより、インターネット接続の必要性を排除できます。
NATゲートウェイの削除：NATゲートウェイを削除することで、EC2インスタンスのインターネットアクセスを完全に遮断できます。
VPCピアリング接続：アプリケーションアカウントとコアアカウント間でVPCピアリング接続を作成することで、プライベートネットワーク経由でパッチソースリポジトリにアクセスできます。
完全なインターネット遮断：この構成により、EC2インスタンスは完全にインターネットから切り離されながら、必要なすべてのサービスにアクセスできます。
他の選択肢の問題点：
選択肢A：ポート80のみをブロックするネットワークACLでは、他のポート（443など）を通じたインターネットアクセスが可能であり、完全な遮断にはなりません。また、カスタムVPNソリューションは複雑で管理オーバーヘッドが高くなります。
選択肢B：プライベートVIFはDirect Connect環境で使用されるもので、この問題の文脈では適用されません。また、この構成ではインターネットアクセスの完全な遮断が保証されません。
選択肢D：ポート80のインバウンドトラフィックをブロックしても、アウトバウンドのインターネットアクセスは制限されません。また、S3へのアクセス方法が明確でありません。
これらの要件を満たすアクションの組み合わせはどれですか？（3つ選択してください）
A. Amazon Inspectorを有効化します。自動CVEスキャンを開始します。
B. Amazon InspectorでLambda標準スキャンとLambdaコードスキャンを有効化します。
C. Amazon GuardDutyを有効にします。GuardDutyでLambda Protection機能を有効にします。
D. コードスキャンが必要なLambda関数のMonitor設定でスキャンを有効にします。
E. コードスキャンが不要なLambda関数にタグを付けます。タグには、InspectorCodeExclusionのキーとLambdaCodeScanningの値を含めます。
F. Amazon Inspectorを使用して、コードスキャンのためにLambda .zipパッケージとLambdaレイヤー.zipファイルを含むS3バケットをスキャンします。
解説：この問題では、Lambda関数とレイヤーのCVEスキャンと、選択的なコードスキャンの実装が求められています。
選択肢Aが正しい理由：
Amazon InspectorはAWSのセキュリティ評価サービスで、Lambda関数の脆弱性スキャンに対応しています。
CVE（Common Vulnerabilities and Exposures）スキャンを自動化するための基盤となるサービスです。
Lambda関数とLambdaレイヤーの両方に対してCVEスキャンを実行できます。
選択肢Bが正しい理由：
Lambda標準スキャン：CVEスキャンを含む基本的な脆弱性検出を行います。
Lambdaコードスキャン：潜在的なデータ漏洩やその他のコード脆弱性を検出する高度なスキャン機能です。
この2つの機能を有効にすることで、要件で求められているすべてのスキャンタイプを網羅できます。
選択肢Eが正しい理由：
Amazon Inspectorでは、特定のタグを使用してコードスキャンから除外するLambda関数を指定できます。
InspectorCodeExclusionキーとLambdaCodeScanningの値を使用することで、選択的なスキャンを実現できます。
この方法により、「選択されたLambda関数のみ」という要件を満たすことができます。
他の選択肢が不適切な理由：
選択肢C：GuardDutyのLambda Protection機能は、Lambda関数の実行時の異常な動作を検出しますが、静的コード分析やCVEスキャンは実行しません。
選択肢D：Lambda関数のMonitor設定にはコードスキャンを有効にする機能はありません。これはCloudWatchメトリクスなどの監視設定用です。
選択肢F：Amazon InspectorはS3バケット内のファイルを直接スキャンする機能を提供していません。InspectorはデプロイされたLambda関数を対象とします。
A. Amazon CloudWatchを使用してECSクラスター内の各サービスのSample Count統計を監視します。数式sample count/SERVICE_QUOTA(service)*100が80より大きい場合にアラームを設定します。Amazon Simple Notification Service（Amazon SNS）を使用して開発チームに通知します。
B. Amazon CloudWatchを使用してAWS/Usageメトリック名前空間で公開されているサービスクォータを監視します。数式metric/SERVICE_QUOTA(metric)*100が80より大きい場合にアラームを設定します。Amazon Simple Notification Service（Amazon SNS）を使用して開発チームに通知します。
C. ECSクラスターから詳細メトリクスをポーリングするAWS Lambda関数を作成します。実行中のFargateタスクの数が80より大きい場合、Amazon Simple Email Service（Amazon SES）を呼び出して開発チームに通知します。
D. FargateのSERVICE_QUOTAが80より大きいかどうかを評価するAWS Configルールを作成します。AWS ConfigルールがCompliantでない場合、Amazon Simple Email Service（Amazon SES）を使用して開発チームに通知します。
解説：この問題では、Fargateタスクのサービスクォータ（上限値）の80%に達した際の監視と通知システムの実装が求められています。
選択肢Bが正しい理由：
AWS/Usageメトリック名前空間：AWSは各サービスの使用量とサービスクォータをCloudWatchメトリクスとして自動的に公開しており、これがFargateタスクの監視に最適な方法です。
数式による計算：metric/SERVICE_QUOTA(metric)*100という数式により、現在の使用量をサービスクォータに対する割合として計算できます。
自動監視：CloudWatchアラームにより、80%閾値を自動的に監視し、SNSを通じて通知できます。
スケーラブル：100の異なるサービスすべてに対して効率的に適用できます。
他の選択肢の問題点：
選択肢A：Sample Count統計はタスク数の監視には適していません。また、SERVICE_QUOTA(service)という関数は存在しません。Sample Countは通常、メトリクスデータポイントの数を表します。
選択肢C：Lambda関数によるポーリングは非効率的で、リアルタイム監視には適していません。また、「80より大きい」という条件は80%という割合ではなく、絶対値80を指しており、要件と一致しません。
選択肢D：AWS Configは設定変更の監視に使用されるサービスで、リアルタイムの使用量監視には適していません。また、SERVICE_QUOTAが80より大きいという条件は要件と異なります。
A. 暗号化されていないEBSボリュームを識別するAWS Configマネージドルールを設定します。自動修復アクションを設定します。新しい暗号化されたEBSボリュームを作成する手順を含むAWS Systems Manager Automationランブックを関連付けます。AWS Key Management Service（AWS KMS）のカスタマー管理キーを作成します。キーポリシーに、暗号化されていないEBSボリュームの作成を拒否するステートメントを含めます。
B. AWS Systems Manager Fleet Managerを使用して暗号化されていないEBSボリュームのリストを作成します。新しい暗号化されたEBSボリュームを作成する手順を含むSystems Manager Automationランブックを作成します。暗号化されていないEBSボリュームの作成を拒否するSCPを作成します。
C. AWS Systems Manager Fleet Managerを使用して暗号化されていないEBSボリュームのリストを作成します。新しい暗号化されたEBSボリュームを作成する手順を含むSystems Manager Automationランブックを作成します。新しいEBSボリュームを常に暗号化するように、EBS暗号化のAWSアカウント設定を変更します。
D. 暗号化されていないEBSボリュームを識別するAWS Configマネージドルールを設定します。自動修復アクションを設定します。新しい暗号化されたEBSボリュームを作成する手順を含むAWS Systems Manager Automationランブックを関連付けます。新しいEBSボリュームを常に暗号化するように、EBS暗号化のAWSアカウント設定を変更します。
解説：この問題では、既存の暗号化されていないEBSボリュームの自動修復と、将来の暗号化されていないEBSボリューム作成の防止という2つの要件を満たす必要があります。
選択肢Dが正しい理由：
AWS Configマネージドルール：「encrypted-volumes」ルールにより、暗号化されていないEBSボリュームを自動的に識別できます。これは継続的な監視を提供します。
自動修復アクション：AWS Configの自動修復機能により、コンプライアンス違反が検出された際に自動的にSystems Manager Automationランブックを実行できます。
Systems Manager Automationランブック：既存の暗号化されていないボリュームを特定し、新しい暗号化されたボリュームを作成してデータを移行する自動化されたプロセスを提供します。
EBS暗号化のアカウント設定：「EBS encryption by default」を有効にすることで、今後作成されるすべてのEBSボリュームが自動的に暗号化されます。これは最もシンプルで効果的な予防策です。
他の選択肢の問題点：
選択肢A：KMSキーポリシーでは暗号化されていないEBSボリュームの作成を直接拒否することはできません。キーポリシーはそのキーの使用を制御するものであり、EBSボリューム作成自体を制御するものではありません。
選択肢B：Fleet Managerは主にEC2インスタンスの管理用であり、EBSボリュームの継続的な監視には適していません。また、SCPは組織レベルの制御であり、単一アカウント内での実装には複雑すぎます。
選択肢C：Fleet Managerによる一回限りのリスト作成では、継続的な監視と自動修復が提供されません。新しい暗号化されていないボリュームが作成された際の検出ができません。
A. 同社のサードパーティIDプロバイダーをAPI Gatewayと統合します。IDプロバイダーからのトークンを検証するAPI Gateway Lambda認可器を設定します。すべてのAPIルートでLambda認可器を必須にします。WebアプリケーションがIDプロバイダーからトークンを取得し、API Gateway HTTP APIを呼び出す際にAuthorizationヘッダーにトークンを含めるよう更新します。
B. 同社のサードパーティIDプロバイダーをAWS Directory Serviceと統合します。IDプロバイダーからのトークンを検証するAPI Gateway認可器としてDirectory Serviceを設定します。すべてのAPIルートでDirectory Service認可器を必須にします。SAML 2.0 IDプロバイダーとしてAWS IAM Identity Centerを設定します。WebアプリケーションをカスタムSAML 2.0アプリケーションとして設定します。
C. 同社のサードパーティIDプロバイダーをAWS IAM Identity Centerと統合します。ゼロ設定の認証と認可のためにIAM Identity Centerを使用するようAPI Gatewayを設定します。WebアプリケーションがIAM Identity CenterからAWS Security Token Service（AWS STS）トークンを取得し、API Gateway HTTP APIを呼び出す際にAuthorizationヘッダーにトークンを含めるよう更新します。
D. 同社のサードパーティIDプロバイダーをAWS IAM Identity Centerと統合します。API Gateway HTTP APIを呼び出す権限を持つIAMユーザーを設定します。WebアプリケーションがIAMユーザーからリクエストパラメータを抽出し、API Gateway HTTP APIを呼び出す際にAuthorizationヘッダーにパラメータを含めるよう更新します。
解説：この問題では、既存のサードパーティOAuth IDプロバイダーとAPI Gatewayを統合し、統合された認可システムを実装する必要があります。
選択肢Aが正しい理由：
直接統合：API Gateway Lambda認可器は、サードパーティIDプロバイダーからのOAuthトークンを直接検証できる最も適切な方法です。
OAuthトークンサポート：Lambda認可器はOAuthトークンの検証に特化しており、JWTトークンの検証、署名の確認、有効期限のチェックなどを行えます。
柔軟性：カスタムLambda関数により、特定のビジネスロジックや複雑な認可ルールを実装できます。
既存インフラとの整合性：既存のOAuthベースのアーキテクチャとシームレスに統合できます。
シンプルな実装：WebアプリケーションはIDプロバイダーから取得したトークンをAuthorizationヘッダーに含めるだけで済みます。
他の選択肢の問題点：
選択肢B：AWS Directory ServiceはActive Directory統合用のサービスであり、OAuthトークンの検証には適していません。また、SAML 2.0の設定は複雑で、既存のOAuthフローと一致しません。
選択肢C：API Gatewayには「ゼロ設定の認証と認可」でIAM Identity Centerを使用する標準機能はありません。また、STSトークンはAWS API用であり、サードパーティOAuthトークンとは異なります。
選択肢D：IAMユーザーを手動で作成・管理する方法は、動的なユーザー認証には適していません。また、「リクエストパラメータを抽出」という表現は技術的に不正確で、OAuthフローと一致しません。
この要件を満たすソリューションはどれか？
A. 各アカウントにAWS CloudTrailのトレイルを作成する。トレイルにはCloudTrail管理イベントを指定する。CloudTrailをAmazon CloudWatch Logsにイベントを送信するよう構成する。CloudWatchのクロスアカウント観測性を設定する。CloudWatch Logs Insightsでデータをクエリする。
B. 委任管理者アカウントを使用してAWS CloudTrail Lakeのデータストアを作成する。データストアにはCloudTrail管理イベントを指定する。組織内のすべてのアカウントに対してデータストアを有効にする。CloudTrail Lakeでデータをクエリする。
C. 委任管理者アカウントを使用してAWS CloudTrailのトレイルを作成する。トレイルにはCloudTrail管理イベントを指定する。組織内のすべてのアカウントに対してトレイルを有効にする。他の設定はすべてデフォルトのままにする。CloudTrailのイベント履歴ページからCloudTrailデータをクエリする。
D. AWS CloudFormation StackSetsを使用して、各アカウントにAWS CloudTrail Lakeのデータストアをデプロイする。データストアにはCloudTrail管理イベントを指定する。他の設定はすべてデフォルトのままにする。CloudTrail Lakeでデータをクエリする。
解説：
• B のCloudTrail Lakeは、複数のAWSアカウントからのCloudTrailイベントデータを中央の場所に統合して保存・クエリできる最新のサービスです。SQLによるクエリも可能で、組織全体に対して委任管理者アカウントから一括で有効化できます。
• A はCloudWatch Logsへの出力とクロスアカウント観測性を組み合わせる必要があり、管理が複雑でオーバーヘッドが大きくなります。
• C はCloudTrailイベント履歴ページからの簡易検索にとどまり、SQLクエリには対応していません。また、保存期間も短いです。
• D は各アカウントに分散してCloudTrail Lakeを展開する方法で、中央管理やクエリの統一性が欠けます。運用効率が低下します。
A. VM Import/Exportを使用して各VMのイメージを作成します。AWS Application Migration Serviceを使用してイメージを管理・表示します。Windowsファイル共有データをAmazon Elastic File System（Amazon EFS）ファイルシステムにコピーします。移行後、ファイル共有をEFSファイルシステムに再マップします。
B. AWS Application Discovery ServiceエージェントレスアプライアンスをVMware vCenterにデプロイします。AWS Migration Hubで検出されたVMのポートフォリオを確認します。
C. AWS Application Migration ServiceエージェントレスアプライアンスをVMware vCenterにデプロイします。Windowsファイル共有データをAmazon FSx for Windows File Serverファイルシステムにコピーします。移行後、各VMのファイル共有をFSx for Windows File Serverファイルシステムに再マップします。
D. AWS Application Discovery Service AgentとAWS Application Migration Service Agentを各VMware hypervisorに直接デプロイします。AWS Migration Hubでポートフォリオを確認します。各VMのファイル共有データをAmazon FSx for Windows File Serverファイルシステムにコピーします。移行後、各VMのファイル共有をFSx for Windows File Serverファイルシステムに再マップします。
この問題を解決するための重要なポイントは以下の通りです：
最短時間での移行が要求されているため、効率的で最小限の手動作業を必要とする方法を選択する必要があります。コンプライアンス要件により、各VMへの個別のエージェントインストールは変更要求と承認プロセスが必要となり、時間がかかります。
選択肢Cが最適な理由：
AWS Application Migration Service（MGN）のエージェントレスアプライアンスをvCenterにデプロイすることで、個々のVMに変更を加えることなく移行プロセスを開始できます。これによりコンプライアンス要件による遅延を回避できます。Amazon FSx for Windows File ServerはWindowsベースのファイル共有に最適化されており、既存のWindowsファイル共有との互換性が高く、移行後の再マッピングが簡単です。10GBのDirect Connect接続により、100GB以上のファイル共有データを効率的に転送できます。
他の選択肢が適切でない理由：
選択肢AのVM Import/ExportとEFSの組み合わせは、WindowsファイルシステムにとってFSx for Windows File Serverほど最適化されていません。選択肢Bは発見フェーズのみで、実際の移行手順が含まれていません。選択肢Dは各ハイパーバイザーへの直接エージェントデプロイが必要で、コンプライアンス承認プロセスにより時間がかかります。
A. S3 Multi-Region Access Pointsを実装する
B. S3 Cross-Region Replication（CRR）を使用してコンテンツを異なるリージョンにコピーする
C. クライアントのリージョンへのルーティングを追跡するAWS Lambda関数を作成する
D. AWS Site-to-Site VPN接続を使用してMulti-Region Access Pointに接続する
E. AWS PrivateLinkとAWS Direct Connectを使用してMulti-Region Access Pointに接続する
この問題の要件を満たすために以下の点を考慮する必要があります：
顧客に地理的に最も近いリージョンからコンテンツを提供する必要があります。オンプレミスからS3への接続は最小限のレイテンシーでパブリックインターネットを経由しない必要があります。運用オーバーヘッドを最小限に抑える必要があります。
選択肢Aが正解である理由：
S3 Multi-Region Access Pointsは、複数のリージョンにあるS3バケットへの単一のグローバルエンドポイントを提供します。自動的に最も近いリージョンにリクエストをルーティングし、運用オーバーヘッドを最小限に抑えます。フェイルオーバー機能も組み込まれており、信頼性を向上させます。
選択肢Eが正解である理由：
AWS Direct ConnectはオンプレミスとAWS間の専用ネットワーク接続を提供し、パブリックインターネットを経由しません。AWS PrivateLinkを使用することで、Multi-Region Access Pointへのプライベート接続を確立できます。この組み合わせにより、最小限のレイテンシーとセキュアな接続を実現できます。
他の選択肢が不適切な理由：
選択肢BのCRRは複数リージョンへのデータ複製には有効ですが、自動的な最適ルーティング機能がありません。選択肢Cのカスタムルーティング機能は運用オーバーヘッドが大きく、既存のAWSサービスで解決可能です。選択肢DのSite-to-Site VPNはDirect Connectと比較してレイテンシーが高く、要件を満たしません。
A. 全額前払いで同じReserved Instancesをさらに3年間購入する。管理アカウントで全額前払いの3年間Compute Savings Planを購入して追加のコンピュートコストをカバーする
B. 各メンバーアカウントで前払いなしの1年間Compute Savings Planを購入する。AWS Cost ManagementコンソールのSavings Plans推奨事項を使用してCompute Savings Planを選択する
C. 管理アカウントで前払いなしの3年間EC2 Instance Savings Planを購入して各AWSリージョンのEC2コストをカバーする。管理アカウントで前払いなしの3年間Compute Savings Planを購入して追加のコンピュートコストをカバーする
D. 各メンバーアカウントで全額前払いの3年間EC2 Instance Savings Planを購入する。AWS Cost ManagementコンソールのSavings Plans推奨事項を使用してEC2 Instance Savings Planを選択する
この問題の重要なポイントは以下の通りです：
企業には既存のEC2ワークロードと新しいサーバーレスワークロードの両方があります。3年間の長期コミットメントが可能です。AWS Organizationsの環境でコスト最適化を行う必要があります。
選択肢Aが最適な理由：
Reserved Instancesの全額前払いは最大の割引率を提供します（最大75%の削減）。3年間のコミットメントにより長期割引を最大化できます。Compute Savings PlanはEC2、AWS Lambda、AWS Fargateを含む幅広いコンピュートサービスをカバーするため、サーバーレスワークロードにも適用されます。管理アカウントでの購入により、組織全体でSavings Planの利益を共有できます。全額前払いにより最大の割引率を実現できます。
他の選択肢が不適切な理由：
選択肢Bの1年間のプランは長期割引を活用できず、各アカウントでの個別購入は管理オーバーヘッドが増加します。選択肢CのNo Upfront支払いは割引率が最小となり、コスト削減効果が限定的です。選択肢Dの各メンバーアカウントでの個別購入は、Savings Planの共有利益を活用できず、管理が複雑になります。
AWS Organizationsの統合請求機能により、管理アカウントで購入したReserved InstancesやSavings Plansは組織全体のアカウント間で自動的に適用されるため、選択肢Aが最も効率的で最大のコスト削減を実現します。
同社は動画をAWSに移行する計画で、高速なAWS Direct Connect接続を持っており、現在のファイルシステムからMAMソリューションの動画コンテンツを直接移行したいと考えています。
最小限の運用管理負荷で、既存システムに最小限の影響を与えながら、これらの要件を満たすにはどのソリューションが最適ですか？
A. オンプレミスに AWS Storage Gateway（ファイルゲートウェイ）をセットアップし、MAMソリューションを使って現在のアーカイブから動画を抽出してゲートウェイにプッシュする。Amazon Rekognition に顔のカタログを元にコレクションを作成し、AWS Lambda 関数で Rekognition JavaScript SDK を使用して、ゲートウェイ裏の Amazon S3 から動画を処理させ、取得したメタデータを MAM に送信する。
B. オンプレミスに AWS Storage Gateway（テープゲートウェイ）をセットアップし、MAM から動画をテープゲートウェイにプッシュする。顔カタログで Rekognition にコレクションを作成し、Lambda で動画をテープゲートウェイから処理してメタデータを MAM に送信する。
C. Amazon Kinesis Video Streams を構成して動画ストリームを処理する。MAM から動画を Kinesis にストリーミングし、Rekognition で分析。ストリームコンシューマがメタデータを取得し、MAM に送信する。動画は Amazon S3 に保存されるよう構成する。
D. OpenCV を実行する Amazon EC2 インスタンスをセットアップし、オンプレミスの動画・画像・顔カタログを EBS にコピーする。EC2 上で動画を処理してメタデータを MAM に送信し、動画ファイルを Amazon S3 にも保存する。
理由：
- 要件は「最小限の運用管理負荷」と「最小限のシステムへの影響」。つまり、既存のMAMソリューションとできる限りシームレスに連携しつつ、クラウドへの移行を進めたい。
- 選択肢Aでは、AWS Storage Gatewayのファイルゲートウェイを使うことで、MAMが動画をローカルファイルとして扱いつつ、その裏で自動的にS3へアップロードされるため、既存のワークフローを大きく変更する必要がない。
- RekognitionとLambdaを組み合わせることで、動画からのメタデータ抽出処理もサーバーレスで自動化されており、継続的な管理コストを削減できる。
- B案のテープゲートウェイは、バックアップ用途に適しており、直接動画を処理するには適していない。
- C案のKinesis Video Streamsはリアルタイムストリーミングには向いているが、テープにある既存動画の移行・バッチ処理には適していない。
- D案は多くの手動ステップとEC2の運用管理が必要で、管理オーバーヘッドが高い。
A. Amazon Elastic Container Service（Amazon ECS）クラスターを作成します。処理をAWS Fargateタスクとして実行するように構成します。コンテナ選択ロジックを抽出して、適切なFargateタスクを開始するAmazon EventBridgeルールとして実行します。ファイルがEFSファイルシステムに追加されたときに実行されるようにEventBridgeルールを構成します。
B. Amazon Elastic Container Service（Amazon ECS）クラスターを作成します。処理をAWS Fargateタスクとして実行するように構成します。コンテナ選択ロジックを更新およびコンテナ化して、適切なFargateタスクを開始するFargateサービスとして実行します。ファイルがEFSファイルシステムに追加されたときにFargateサービスを呼び出すようにEFSイベント通知を構成します。
C. Amazon Elastic Container Service（Amazon ECS）クラスターを作成します。処理をAWS Fargateタスクとして実行するように構成します。コンテナ選択ロジックを抽出して、適切なFargateタスクを開始するAWS Lambda関数として実行します。ファイルアップロードのストレージをAmazon S3バケットに移行します。処理コードをAmazon S3を使用するように更新します。オブジェクトが作成されたときにLambda関数を呼び出すようにS3イベント通知を構成します。
D. 処理用のAWS Lambdaコンテナイメージを作成します。コンテナイメージを使用するようにLambda関数を構成します。コンテナ選択ロジックを抽出して、適切なLambda処理関数を呼び出す決定Lambda関数として実行します。ファイルアップロードのストレージをAmazon S3バケットに移行します。処理コードをAmazon S3を使用するように更新します。オブジェクトが作成されたときに決定Lambda関数を呼び出すようにS3イベント通知を構成します。
この問題の重要な要件は以下の通りです：
EC2インスタンスを排除する必要があります。データ処理は最大2時間かかります。ファイルベースの処理ワークフローです。イベント駆動型のアーキテクチャが必要です。
選択肢Cが最適な理由：
AWS Fargateタスクは最大2時間の長時間実行タスクに適しており、EC2インスタンスの管理が不要です。Lambda関数はコンテナ選択ロジックに最適で、軽量で高速な実行が可能です。Amazon S3はファイルストレージに適しており、ネイティブなイベント通知機能を提供します。S3イベント通知は信頼性が高く、ファイルアップロード時に自動的にLambda関数をトリガーできます。このアーキテクチャはサーバーレスでスケーラブルであり、管理オーバーヘッドが最小限です。
他の選択肢が不適切な理由：
選択肢AのEventBridgeルールは、EFSファイルシステムからの直接的なファイルイベントをサポートしていません。選択肢BのEFSイベント通知機能は存在せず、Fargateサービスは常時実行されるため非効率です。選択肢DのLambda関数は15分の実行時間制限があり、最大2時間の処理要件を満たすことができません。
選択肢CはEC2インスタンスを完全に排除し、イベント駆動型のサーバーレスアーキテクチャを提供し、長時間実行タスクをサポートする最も適切なソリューションです。
A. データサイエンティストにユーザー名タグと一致するS3バケットプレフィックスへのアクセスを許可するカスタムIAM Identity Center権限セットを作成します。${aws:PrincipalTag/userName}/*条件でパスへのアクセスを制限するポリシーを使用します。
B. Amazon S3の読み取りアクセスと書き込みアクセスを持つデータサイエンティストグループ用のIAM Identity Centerロールを作成します。IAM Identity Centerロールへのアクセスを許可するS3バケットポリシーを追加します。
C. S3データイベントをログに記録し、ログをS3バケットに配信するようにAWS CloudTrailを構成します。Amazon S3のCloudTrailログに対してクエリを実行し、レポートを生成するためにAmazon Athenaを使用します。
D. S3管理イベントをCloudWatchにログ記録するようにAWS CloudTrailを構成します。ログにクエリを実行し、レポートを生成するためにAthenaのCloudWatchコネクタを使用します。
E. EMR File System（EMRFS）へのS3アクセスログを有効にします。ログにクエリを実行し、レポートを生成するためにAmazon S3 Selectを使用します。
この問題の要件は以下の通りです：
各データサイエンティストが自分の作業のみにアクセスできるようにする必要があります。どのドキュメントに各ユーザーがアクセスしたかを追跡し、月次レポートを作成する必要があります。IAM Identity Centerを使用した認証システムを活用する必要があります。
選択肢Aが正解である理由：
カスタムIAM Identity Center権限セットにより、ユーザー名タグに基づいてS3バケット内の特定のプレフィックスへのアクセスを制限できます。${aws:PrincipalTag/userName}/*条件を使用することで、各ユーザーは自分のユーザー名に対応するフォルダ（プレフィックス）のみにアクセス可能となります。これにより各データサイエンティストが自分の作業のみにアクセスできるという要件を満たします。
選択肢Cが正解である理由：
AWS CloudTrailのS3データイベントログにより、S3オブジェクトへのアクセス（読み取り、書き込み）を詳細に追跡できます。ログをS3バケットに保存し、Amazon Athenaを使用してクエリを実行することで、各ユーザーのドキュメントアクセス履歴を分析し、月次レポートを生成できます。
他の選択肢が不適切な理由：
選択肢Bは個別ユーザーアクセス制御を提供せず、すべてのデータサイエンティストが同じアクセス権限を持つことになります。選択肢Dの管理イベントはバケット操作のみを記録し、個別ファイルアクセスは追跡できません。選択肢EのEMRFSアクセスログは標準的な機能ではなく、この要件には適用できません。
選択肢AとCの組み合わせにより、適切なアクセス制御とアクセス追跡の両方を実現し、要件を完全に満たすことができます。
A. 現在のインフラストラクチャ設計用のAWS CloudFormationテンプレートを作成します。リージョンを含む重要なシステム値にパラメータを使用します。CloudFormationテンプレートを使用して第2リージョンに新しいインフラストラクチャを作成します。
B. AWS Management Consoleを使用して第1リージョンの既存のインフラストラクチャ設計を文書化し、第2リージョンに新しいインフラストラクチャを作成します。
C. アプリケーションのRoute 53ホストゾーンレコードを更新して重み付きルーティングを使用します。トラフィックの50%を各リージョンのALBに送信します。
D. アプリケーションのRoute 53ホストゾーンレコードを更新してレイテンシベースルーティングを使用します。各リージョンのALBにトラフィックを送信します。
E. DynamoDB Streamsを有効にして既存のDynamoDBテーブルの構成を更新します。グローバルテーブルを作成するために第2リージョンを追加します。
この問題の要件は以下の通りです：
災害復旧機能を提供する必要があります。将来の成長に対応し、ユーザーのアクセス時間を改善する必要があります。管理オーバーヘッドを最小限に抑える必要があります。第2リージョンに完全なアプリケーションスタックを複製する必要があります。
選択肢Aが正解である理由：
AWS CloudFormationテンプレートはInfrastructure as Code（IaC）を提供し、インフラストラクチャの一貫した複製を可能にします。パラメータを使用することで、同じテンプレートを異なるリージョンで再利用でき、管理オーバーヘッドを最小限に抑えます。手動での設定ミスを防ぎ、迅速で正確なデプロイメントを実現します。
選択肢Dが正解である理由：
レイテンシベースルーティングは、ユーザーに最も近いリージョンに自動的にトラフィックを送信し、アクセス時間を改善します。災害復旧時には、1つのリージョンが利用できない場合に自動的に健全なリージョンにトラフィックを送信します。ユーザーエクスペリエンスの最適化と可用性の向上を同時に実現します。
選択肢Eが正解である理由：
既存のDynamoDBテーブルでStreamsを有効にし、グローバルテーブルとして設定することで、両リージョン間でデータの自動同期を実現できます。追加のデータコピー作業が不要で、管理オーバーヘッドが最小限です。リアルタイムでのデータ複製により、災害復旧時のデータ整合性を保証します。
他の選択肢が不適切な理由：
選択肢Bの手動設定は管理オーバーヘッドが大きく、設定ミスのリスクがあります。選択肢Cの重み付きルーティングは地理的最適化を提供せず、アクセス時間改善の要件を満たしません。選択肢Fは新しいテーブル作成と手動データコピーが必要で、複雑性と管理オーバーヘッドが増加します。
A. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーにマネージャーのロールを引き受ける権限を与え、テンプレートとそれが作成するリソースに権限を制限するポリシーを追加します。CloudFormationコンソールからテンプレートを起動するようにユーザーをトレーニングします。
B. 環境テンプレートからAWS Service Catalog製品を作成します。既存のロールで製品に起動制約を追加します。QA部門のユーザーにAWS Service Catalog APIのみを使用する権限を与えます。AWS Service Catalogコンソールからテンプレートを起動するようにユーザーをトレーニングします。
C. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーにCloudFormationとS3 APIを使用する権限を与え、テンプレートとそれが作成するリソースに権限を制限する条件を付けます。CloudFormationコンソールからテンプレートを起動するようにユーザーをトレーニングします。
D. 環境テンプレートからAWS Elastic Beanstalkアプリケーションを作成します。QA部門のユーザーにElastic Beanstalk権限のみを与えます。Elastic Beanstalk CLIでElastic Beanstalk環境を起動し、既存のロールをサービスロールとして環境に渡すようにユーザーをトレーニングします。
この問題の要件は以下の通りです：
テスターが独自に環境を起動できるようにする必要があります。各ユーザーに広範な権限を付与したくありません。既存のCloudFormationテンプレートを活用する必要があります。セキュリティを維持しながら使いやすさを提供する必要があります。
選択肢Bが最適な理由：
AWS Service Catalogは、承認されたITサービスのカタログを作成・管理するためのサービスです。起動制約（Launch Constraint）により、ユーザーは限定された権限しか持たなくても、マネージャーの強力な権限を使用してリソースを作成できます。ユーザーはService Catalog APIのみの権限で済み、EC2やCloudFormationの直接的な権限は不要です。テンプレートの標準化と制御を維持しながら、セルフサービス機能を提供できます。管理者は製品のバージョン管理や制約設定を通じて、きめ細かい制御を行えます。
他の選択肢が不適切な理由：
選択肢Aではユーザーがマネージャーのロールを引き受けることになり、結果的に広範な権限を持つことになります。選択肢Cでは条件付きポリシーが複雑になり、管理が困難です。また、ユーザーに直接的なCloudFormationとS3権限を付与する必要があります。選択肢DのElastic Beanstalkは既存のCloudFormationテンプレートを直接活用できず、アーキテクチャの変更が必要になります。
AWS Service Catalogは、まさにこのような「管理された自己サービス」のユースケースのために設計されており、セキュリティと使いやすさのバランスを最適に実現できます。
価格ファイルは1〜15分ごとに更新され、数千行のアイテムが含まれている。各 EC2 インスタンスは起動時に価格ファイルをダウンロードしている。
しかし、EC2 インスタンスが古い価格情報を使うことがあり、顧客に誤った請求が発生することがある。
この問題を最もコスト効率よく解決する方法はどれか？
選択肢：
A. 価格ファイルが更新されるたびに AWS Lambda 関数を起動し、新価格を Amazon DynamoDB テーブルに更新する。チケットサービスを DynamoDB を参照するように改修する。
B. 価格ファイルが更新されるたびに AWS Lambda 関数を起動し、Amazon Elastic File System (EFS) のファイル共有を更新する。チケットサービスを EFS で価格ファイルにアクセスするように改修する。
C. EC2 インスタンスの AMI に Mountpoint for Amazon S3 をインストールし、価格ファイルが入っている S3 バケットをマウントする。チケットサービスをマウントポイントを参照するように改修する。
D. Amazon Elastic Block Store (EBS) ボリュームを作成し、EBS Multi-Attach で全ての EC2 インスタンスにアタッチする。新しいインスタンス起動時に価格ファイルを EBS ボリュームに更新する。チケットサービスを新しいローカルソースに向けるように改修する。
C
【解説】
• 現状の課題は、EC2 インスタンスが起動時に一度だけ価格ファイルを取得しており、その後更新を取り込めていないことにある。よって、ファイルの最新状態を常に参照できる仕組みが必要。
• 選択肢 A の DynamoDB 化は構成変更が大きく、既存のファイルベースアクセスからの改修コストが高い。
• 選択肢 B の EFS はファイル共有を実現できるが、EFS のランニングコストが S3 より高く、コスト効率が悪い。
• 選択肢 D の EBS Multi-Attach は特定のワークロードに限定的な機能であり、複数インスタンス間での同時読み書きには向かない。また、管理負荷が高い。
• 選択肢 C の Mountpoint for Amazon S3 を使用すると、S3 のファイルをローカルファイルシステムのようにマウントして読み書き可能。これにより常に最新の価格ファイルを参照できるため、古い情報を使う問題が解消できる。S3 のストレージコストが低いため、コスト効率も良い。
よって、最もコスト効率良く問題を解決できるのは選択肢 C である。
A. Lambda関数に直接送信する代わりに、Amazon Simple Queue Service（Amazon SQS）キューにリクエストを送信するようにAPIを構成します。キューからメッセージを消費し、リクエストを処理するようにLambda関数を更新します。新しいメッセージが到着したときにLambda関数を呼び出すようにキューを設定します。
B. 各Lambda関数にプロビジョニング済み同時実行を構成します。AWS Application Auto Scalingを使用してLambda関数をターゲットとして登録します。API使用量の変化に合わせて容量を増減するスケーリングスケジュールを設定します。
C. API Gateway APIキーとAWS WAF Regional web ACLを作成します。web ACLをProductionステージに関連付けます。web ACLにレートベースルールを追加します。ルールで、レート制限とX-API-Keyヘッダーを使用するカスタムリクエスト集約を指定します。外部開発チームとAPIキーを共有します。
D. API Gateway APIキーと使用量プランを作成します。使用量プランでスロットリング制限とクォータを定義します。使用量プランをProductionステージとAPIキーに関連付けます。外部開発チームとAPIキーを共有します。
この問題の要件は以下の通りです：
Lambda関数を再作業せずにコストと使用量を制限する必要があります。突発的な使用量増加に対処する必要があります。最もコスト効率的なソリューションが必要です。外部開発チームが唯一の消費者です。
選択肢Dが最適な理由：
API Gateway使用量プランはAPI使用量を制御するためのネイティブ機能です。スロットリング制限により、秒単位のリクエスト数を制限し、突発的なトラフィックを防ぎます。クォータ機能により、特定期間（日次、週次、月次）のリクエスト総数を制限できます。APIキーと組み合わせることで、特定のクライアント（外部開発チーム）の使用量を効果的に管理できます。Lambda関数の変更が不要で、API Gatewayレベルでの制御のため実装が簡単です。追加のサービス費用がかからず、最もコスト効率的です。
他の選択肢が不適切な理由：
選択肢AはSQSの追加費用が発生し、Lambda関数の大幅な変更（キューからの消費処理）が必要で、要件に反します。選択肢Bのプロビジョニング済み同時実行は継続的なコストが発生し、コスト削減の目的に反します。選択肢CのAWS WAFは追加費用がかかり、レートベースルールはDDoS攻撃対策が主目的で、コスト制御には過剰な機能です。
API Gateway使用量プランは、まさにこのような「API使用量の制御とコスト管理」のユースケースのために設計されており、シンプルで効果的、かつコスト効率的なソリューションを提供します。
- 収集および処理されたすべてのIoTデータのデータストアとしてのMongoDBクラスター
- 5分ごとにIoTデバイスに接続してデータを収集するためにMessage Queuing Telemetry Transport（MQTT）を使用するアプリケーション
- IoTデータからレポートを生成するために定期的にジョブを実行するアプリケーション。ジョブの実行完了には120-600秒かかります
- ウェブサーバー上で動作するウェブアプリケーション。エンドユーザーは一般公開されるレポートを生成するためにこのウェブアプリケーションを使用します
企業は、パフォーマンスを維持しながら運用オーバーヘッドを削減するためにプラットフォームをAWSに移行する必要があります。最小限の運用オーバーヘッドでこれらの要件を満たす手順の組み合わせはどれですか？（3つ選択してください）
A. レポートを準備し、レポートをAmazon S3に書き込むためのAWS Lambda タスクを持つAWS Step Functions状態マシンを作成します。レポートを提供するためにS3オリジンを持つAmazon CloudFront配信を構成します。
B. AWS Lambda関数を作成します。IoTデバイスに接続し、データを処理し、データストアにデータを書き込むようにLambda関数をプログラムします。処理のためにメッセージを一時的に保存するLambdaレイヤーを構成します。
C. レポートを準備するためにAmazon EC2インスタンスを持つAmazon Elastic Kubernetes Service（Amazon EKS）クラスターを構成します。レポートを提供するためにEKSクラスター上にingressコントローラーを作成します。
D. メッセージを公開するためにIoTデバイスをAWS IoT Coreに接続します。メッセージが受信されたときに実行されるAWS IoTルールを作成します。AWS Lambda関数を呼び出すようにルールを構成します。デバイスメッセージデータを解析、変換し、データストアに保存するようにLambda関数をプログラムします。
E. MongoDBクラスターをAmazon DocumentDB（MongoDB互換）に移行します。
F. MongoDBクラスターをAmazon EC2インスタンスに移行します。
この問題の要件は以下の通りです：
運用オーバーヘッドを最小限に抑える必要があります。パフォーマンスを維持する必要があります。IoTデータの収集、処理、レポート生成、配信機能を移行する必要があります。
選択肢Aが正解である理由：
AWS Step Functionsは複雑なワークフローをサーバーレスで管理でき、運用オーバーヘッドが最小限です。Lambda関数により120-600秒のレポート生成ジョブを効率的に処理できます。S3への保存とCloudFrontによる配信により、スケーラブルで高パフォーマンスなレポート提供が可能です。サーバー管理が不要で、自動スケーリングが提供されます。
選択肢Dが正解である理由：
AWS IoT CoreはMQTTプロトコルをネイティブサポートし、IoTデバイスからのデータ収集に最適化されています。IoTルールにより受信メッセージを自動的に処理でき、Lambda関数との統合が簡単です。デバイス接続の管理、認証、セキュリティ機能が組み込まれており、運用オーバーヘッドが大幅に削減されます。
選択肢Eが正解である理由：
Amazon DocumentDBはMongoDB互換のマネージドサービスで、既存のMongoDBアプリケーションコードをほぼ変更なしで移行できます。自動バックアップ、パッチ適用、モニタリングが提供され、運用オーバーヘッドが最小限です。高可用性とスケーラビリティが組み込まれています。
他の選択肢が不適切な理由：
選択肢BのLambda関数による直接IoTデバイス接続は効率的でなく、Lambdaレイヤーはメッセージ保存には適していません。選択肢CのEKSクラスターは運用オーバーヘッドが大きく、要件に反します。選択肢FのEC2でのMongoDB運用は、パッチ適用、バックアップ、高可用性設定などの運用作業が必要で、運用オーバーヘッドが大きくなります。
この企業はソースコードにアクセスできませんが、アプリケーションのJavaアーカイブ（JAR）ファイルをデプロイすることができます。このアプリケーションは各月末にトラフィックが増加します。
最も運用オーバーヘッドが少ない方法で、これらの要件を満たすソリューションはどれでしょうか。
A. 複数のアベイラビリティーゾーンでAmazon EC2インスタンスを起動します。Amazon Elastic File System（Amazon EFS）マウントポイントを使用して、すべてのインスタンスにTomcatとPostgreSQLをデプロイします。AWS Step Functionsを使用して追加のEC2インスタンスをデプロイし、トラフィック増加に対応してスケールします。
B. 複数のAWSリージョンにわたってAuto Scalingグループ内にAmazon Elastic Kubernetes Service（Amazon EKS）をプロビジョニングします。コンテナイメージ内にTomcatとPostgreSQLをデプロイします。Network Load Balancerを使用してトラフィック増加に対応してスケールします。
C. JavaアプリケーションをPythonベースのコンテナにリファクタリングします。アプリケーションロジックにはAWS Lambda関数を使用します。アプリケーションデータはAmazon DynamoDBグローバルテーブルに格納します。AWS Storage GatewayとLambdaの同時実行機能を使用してトラフィック増加に対応してスケールします。
D. AWS Elastic Beanstalkを使用して、複数のアベイラビリティーゾーンでオートスケーリング機能付きのTomcatサーバーをデプロイします。アプリケーションデータはAmazon RDS for PostgreSQLデータベースに格納します。Amazon CloudFrontとApplication Load Balancerをデプロイしてトラフィック増加に対応してスケールします。
解説
この問題では、運用オーバーヘッドを最小限に抑えながら、既存のJava/Tomcat/PostgreSQLアプリケーションをAWSに移行する最適な方法を選択する必要があります。
選択肢Dが正解である理由：
AWS Elastic Beanstalkは、Javaアプリケーション（JAR、WAR、EAR）の デプロイと管理に特化したPaaS（Platform as a Service）です。インフラストラクチャの管理、オートスケーリング、ロードバランシング、ヘルスモニタリングなどを自動的に処理するため、運用オーバーヘッドが大幅に削減されます。また、Amazon RDS for PostgreSQLを使用することで、データベースの管理も自動化され、バックアップ、パッチ適用、高可用性設定などが簡素化されます。CloudFrontとALBの組み合わせにより、効率的なトラフィック分散とキャッシングが実現されます。
他の選択肢が不適切な理由：
選択肢A：EC2インスタンスの手動管理とStep Functionsによる複雑なスケーリング設定が必要で、運用オーバーヘッドが高くなります。
選択肢B：EKSは高度なコンテナオーケストレーション機能を提供しますが、Kubernetesクラスターの管理が必要で、この要件には過度に複雑です。
選択肢C：アプリケーションの完全なリファクタリング（JavaからPython）が必要で、ソースコードにアクセスできない制約に反します。また、Storage Gatewayの使用目的も不明確です。
同社はコンテンツ更新を遅延させることなく、ブログプラットフォームを移行する必要があります。同社は、Application Load Balancerの背後でブログプラットフォームを実行するために、複数のアベイラビリティーゾーンにわたってAmazon EC2インスタンスをデプロイしています。また、同社はオンプレミスサーバーから200TBのアーカイブデータを可能な限り早くAmazon S3に移動する必要があります。
これらの要件を満たす手順の組み合わせはどれでしょうか。（2つ選択してください。）
A. Amazon EventBridgeで週次のcronジョブを作成します。cronジョブを使用してAWS Lambda関数を呼び出し、NASサーバーからEC2インスタンスを更新します。
B. コンテンツアクセスのためにEC2インスタンスが共有するAmazon Elastic Block Store（Amazon EBS）Multi-Attachボリュームを設定します。EBSボリュームをNASサーバーと週次で同期するコードを記述します。
C. オンプレミスサーバーにAmazon Elastic File System（Amazon EFS）ファイルシステムをマウントして、NASサーバーとして機能させます。ブログデータをEFSファイルシステムにコピーします。コンテンツを提供するためにEC2インスタンスにEFSファイルシステムをマウントします。
D. AWS Snowball Edge Storage Optimizedデバイスを注文します。静的データアーティファクトをデバイスにコピーします。デバイスをAWSに発送します。
E. AWS Snowcone SSDデバイスを注文します。静的データアーティファクトをデバイスにコピーします。デバイスをAWSに発送します。
解説
この問題では、ブログプラットフォームのリアルタイム移行と大容量アーカイブデータの効率的な転送という2つの要件を満たす必要があります。
選択肢Cが正解である理由：
Amazon EFSは、複数のEC2インスタンスから同時にアクセス可能な共有ファイルシステムを提供します。オンプレミスのNASサーバーからEFSにブログデータを移行し、EC2インスタンスからEFSをマウントすることで、複数の著者による継続的なコンテンツ更新を中断することなく、シームレスな移行が可能になります。EFSはNFSプロトコルをサポートしており、既存のファイル共有ワークフローとの互換性が高く、Site-to-Site VPN経由でのアクセスも可能です。
選択肢Dが正解である理由：
200TBという大容量のアーカイブデータを効率的に転送するには、AWS Snowball Edge Storage Optimizedデバイスが最適です。このデバイスは最大80TBのストレージ容量を持ち、複数のデバイスを使用することで200TBのデータ転送が可能です。インターネット経由での転送と比較して、大幅な時間短縮とコスト削減が実現できます。
他の選択肢が不適切な理由：
選択肢A：週次更新では、1日に数回更新されるコンテンツの要件を満たせません。
選択肢B：EBS Multi-Attachは同時書き込みに制限があり、複数著者による頻繁な更新には適していません。また、週次同期では更新頻度の要件を満たせません。
選択肢E：AWS Snowcone SSDは最大14TBの容量しかなく、200TBのデータ転送には不適切です。
移行のために同社が実行すべき手順の組み合わせはどれでしょうか。（2つ選択してください。）
A. Migration Evaluator Quick Insightsを使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。
B. AWS Application Migration Serviceを使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。
C. AWS Schema Conversion Tool（AWS SCT）を使用して、必要な変更についてソースデータベースを分析します。
D. AWS Database Migration Service（AWS DMS）を使用して、ソースデータベースをAmazon RDSに移行します。
E. AWS DataSyncを使用して、ソースデータベースからAmazon RDSにデータを移行します。
解説
この問題では、異なるデータベースエンジン（SQL Server、MySQL、Oracle）とカスタムスキーマ・ストアドプロシージャを含む複雑なデータベース移行について問われています。
選択肢Cが正解である理由：
AWS Schema Conversion Tool（AWS SCT）は、データベース移行において必須のツールです。異なるデータベースエンジン間でのスキーマ変換を自動化し、カスタムスキーマ、ストアドプロシージャ、関数、トリガーなどのデータベースオブジェクトの互換性を分析します。SCTは移行前に必要な変更点を特定し、可能な限り自動的にコード変換を行い、手動対応が必要な箇所を明確に示します。特に、SQL ServerやOracleからAmazon RDS（MySQL、PostgreSQL、Aurora等）への移行では、スキーマ変換が不可欠です。
選択肢Dが正解である理由：
AWS Database Migration Service（AWS DMS）は、データベース移行専用のサービスです。同種間移行（homogeneous migration）と異種間移行（heterogeneous migration）の両方をサポートし、最小限のダウンタイムでデータを移行できます。継続的なデータレプリケーション機能により、移行中もソースデータベースの運用を継続でき、段階的な移行が可能です。また、SCTで変換されたスキーマと組み合わせて使用することで、完全なデータベース移行ソリューションを提供します。
他の選択肢が不適切な理由：
選択肢A：Migration Evaluator Quick Insightsは、インフラストラクチャのサイジングと移行計画に焦点を当てており、データベーススキーマやストアドプロシージャの詳細分析には適していません。
選択肢B：AWS Application Migration Serviceは、アプリケーションサーバーの移行に特化しており、データベースのスキーマ分析やストアドプロシージャの変換には使用されません。
選択肢E：AWS DataSyncは、ファイルシステム間のデータ同期サービスであり、データベースの移行には適用されません。データベース間のデータ転送にはDMSが適切です。
どのソリューションがこの要件を最も満たすか？
A. 予測スケーリングポリシーを使用する。ユーザーデータスクリプトを実行するためにインスタンスメンテナンスポリシーを使用する。デフォルトのインスタンスウォームアップ時間を 0 秒に設定する。
B. 動的スケーリングポリシーを使用する。ユーザーデータスクリプトを実行するためにライフサイクルフックを使用する。デフォルトのインスタンスウォームアップ時間を 0 秒に設定する。
C. 予測スケーリングポリシーを使用する。Auto Scaling グループにウォームプールを有効にする。ユーザーデータスクリプトを実行するためにインスタンスメンテナンスポリシーを使用する。
D. 動的スケーリングポリシーを使用する。Auto Scaling グループにウォームプールを有効にする。ユーザーデータスクリプトを実行するためにライフサイクルフックを使用する。
解説：このシナリオでは、CPU 使用率が高くなるピーク時に動的な負荷に対応する必要があるため、**予測スケーリング（predictive scaling）よりも、現在の需要に応じてスケーリングする動的スケーリング（dynamic scaling）**が適しています。また、新しいインスタンスの起動が遅いため、**ウォームプール（warm pool）を使用して事前に初期化されたインスタンスをスタンバイ状態にしておくことで、起動時間を短縮しレイテンシを減らせます。さらに、EC2 起動時に実行されるユーザーデータスクリプトが時間のかかる処理（カスタムパッケージのインストール）**を行うため、それをインスタンス起動のライフサイクルの中で柔軟に処理できるように、ライフサイクルフックを利用するのが最適です。以上の理由から、**選択肢 D（動的スケーリング + ウォームプール + ライフサイクルフック）**が最も要件に適した構成です。
最近、ウェブサイトはSQLインジェクションとWebエクスプロイト攻撃の試行を経験しています。また、顧客はピーク使用時間中に注文処理時間が増加していると報告しています。これらの期間中、Lambda関数はしばしばコールドスタートを経験します。企業が成長するにつれて、トラフィックピーク時のスケーラビリティと低レイテンシアクセスを確保する必要があります。また、企業はデータベースコストを最適化し、SQLインジェクションとWebエクスプロイト攻撃に対する保護を追加する必要があります。
これらの要件を満たすソリューションはどれでしょうか。
A. ピーク期間中にタイムアウト値を増加させるようにLambda関数を設定します。データベースにはRDS予約インスタンスを使用します。SQLインジェクションとWebエクスプロイト攻撃から保護するために、CloudFrontを使用してAWS Shield Advancedにサブスクライブします。
B. Lambda関数のメモリを増加させます。データベースはAmazon Redshiftに移行します。SQLインジェクションとWebエクスプロイト攻撃から保護するために、Amazon InspectorをCloudFrontと統合します。
C. ピーク期間中のコンピューティングには、プロビジョニングされた同時実行を持つLambda関数を使用します。データベースはAmazon Aurora Serverlessに移行します。SQLインジェクションとWebエクスプロイト攻撃から保護するために、CloudFrontを使用してAWS Shield Advancedにサブスクライブします。
D. ピーク期間中のコンピューティングには、プロビジョニングされた同時実行を持つLambda関数を使用します。データベースにはRDS予約インスタンスを使用します。SQLインジェクションとWebエクスプロイト攻撃から保護するために、AWS WAFをCloudFrontと統合します。
解説
この問題では、パフォーマンス最適化、コスト最適化、セキュリティ強化という3つの要件を同時に満たす必要があります。
選択肢Dが正解である理由：
プロビジョニングされた同時実行（Provisioned Concurrency）を使用することで、Lambda関数のコールドスタート問題を解決し、ピーク時のレスポンス時間を改善できます。これにより、事前に指定した数のExecution Environmentが常に準備された状態となり、即座にリクエストを処理できます。RDS予約インスタンスは、過去12か月間一貫した使用量があることから、オンデマンドと比較して大幅なコスト削減を実現できます。予約インスタンスは1年または3年の契約により、最大75%のコスト削減が可能です。AWS WAFをCloudFrontと統合することで、SQLインジェクション、クロスサイトスクリプティング（XSS）、その他のWebアプリケーション攻撃を効果的に防御できます。WAFはアプリケーション層での保護を提供し、悪意のあるリクエストをフィルタリングします。
他の選択肢が不適切な理由：
選択肢A：タイムアウトの増加はコールドスタート問題を解決しません。AWS Shield Advancedは主にDDoS攻撃に対する保護であり、SQLインジェクションやWebエクスプロイトには効果的ではありません。
選択肢B：Amazon RedshiftはOLAP用途のデータウェアハウスサービスであり、eコマースのトランザクション処理には適していません。Amazon InspectorはEC2インスタンスの脆弱性評価ツールであり、Webアプリケーション攻撃の防御には使用されません。
選択肢C：Aurora Serverlessは自動スケーリング機能を持ちますが、コスト面では一貫した使用量がある場合、予約インスタンスの方が経済的です。また、AWS Shield AdvancedはDDoS保護に特化しており、SQLインジェクション対策としては不適切です。
ほとんどの動画のサイズは100MBを超えています。ユーザーは動画をアップロードする際にインターネット接続が悪いことが多く、アップロードの失敗が発生しています。企業は動画のマルチパートアップロードを使用しています。
ソリューションアーキテクトは、アプリケーションのS3コストを最適化する必要があります。
これらの要件を満たすアクションの組み合わせはどれでしょうか。（2つ選択してください。）
A. S3バケットをRequester Paysバケットとして設定します。
B. S3 Transfer Accelerationを使用して動画をS3バケットにアップロードします。
C. 不完全なマルチパートアップロードを開始から7日後に期限切れにするS3ライフサイクル設定を作成します。
D. 1日後にオブジェクトをS3 Glacier Instant Retrievalに移行するS3ライフサイクル設定を作成します。
E. 180日後にオブジェクトをS3 Standard-Infrequent Access（S3 Standard-IA）に移行するS3ライフサイクル設定を作成します。
解説
この問題では、S3ストレージコストの最適化に焦点を当てており、アクセスパターンと技術的な課題を考慮した解決策が求められています。
選択肢Cが正解である理由：
不完全なマルチパートアップロードの期限切れ設定は、重要なコスト最適化手法です。ユーザーのインターネット接続が悪く、アップロード失敗が頻発している状況では、不完全なマルチパートアップロードのパーツがS3に残り続け、ストレージ料金が発生し続けます。これらの不完全なアップロードを7日後に自動削除することで、無駄なストレージコストを削減できます。マルチパートアップロードが7日以内に完了しない場合、そのアップロードは失敗したものと見なして削除するのが合理的です。
選択肢Eが正解である理由：
アクセスパターン分析に基づいた適切なストレージクラス移行です。180日以降はアクセスがまれになるため、S3 Standard-IAに移行することで大幅なコスト削減が実現できます。S3 Standard-IAは、アクセス頻度が低いデータに最適化されており、S3 Standardと比較して約45%のストレージコスト削減が可能です。180日という移行タイミングは、アクセスパターンの変化点と一致しており、最適な設定です。
他の選択肢が不適切な理由：
選択肢A：Requester Paysは、データ転送とリクエストコストを利用者に転嫁する機能ですが、匿名ユーザーがアクセスする環境では実装が困難であり、根本的なストレージコスト最適化にはなりません。
選択肢B：S3 Transfer Accelerationは、アップロード速度を向上させる機能ですが、追加料金が発生するため、コスト最適化の観点では逆効果になります。
選択肢D：1日後にGlacier Instant Retrievalに移行するのは、最初の180日間に頻繁にアクセスされるという要件に反します。また、S3 Standardから直接Glacierストレージクラスに移行するには、最低30日間S3 Standardに保存する必要があるという制約もあります。
同社は、AWS CloudFormationスタックを起動することで、アプリケーションの新しいバージョンをデプロイします。スタックは必要なリソースを作成します。新しいバージョンを検証した後、同社は古いスタックを削除します。古い開発スタックの削除が最近失敗しました。ソリューションアーキテクトは、大幅なアーキテクチャの変更なしにこの問題を解決する必要があります。
これらの要件を満たすソリューションはどれでしょうか。
A. S3バケットからオブジェクトを削除するLambda関数を作成します。S3バケットリソースを指すDependsOn属性を持つカスタムリソースとして、CloudFormationスタックにLambda関数を追加します。
B. S3バケットにDeleteの値を持つDeletionPolicy属性を添付するようにCloudFormationスタックを変更します。
C. S3バケットリソースにSnapshotの値を持つDeletionPolicy属性を追加するようにCloudFormationスタックを更新します。
D. 一時ファイルをAmazon S3の代わりに保存するためのAmazon Elastic File System（Amazon EFS）ファイルシステムを作成するようにCloudFormationテンプレートを更新します。EFSファイルシステムと同じVPCでLambda関数を実行するように設定します。
解説
この問題は、CloudFormationスタック削除時にS3バケット内にオブジェクトが残っているために削除が失敗する典型的な問題を扱っています。
選択肢Aが正解である理由：
CloudFormationはデフォルトでは、S3バケット内にオブジェクトが存在する場合、バケットの削除を実行できません。これは意図しないデータ損失を防ぐためのAWSの安全機能です。Lambda関数をカスタムリソースとして実装し、スタック削除時にS3バケットからすべてのオブジェクトを削除する処理を自動化することで、この問題を解決できます。DependsOn属性により、S3バケットの削除前にLambda関数によるオブジェクト削除が確実に実行されます。カスタムリソースは、CloudFormation操作（作成、更新、削除）に応じて特定の処理を実行でき、スタック削除時にのみオブジェクト削除処理を実行するように設計できます。これにより、大幅なアーキテクチャ変更なしに問題を解決できます。
他の選択肢が不適切な理由：
選択肢B：DeletionPolicy属性のDeleteは、CloudFormationスタックが削除されてもリソースを保持するための設定です。S3バケット内のオブジェクトが存在する限り、バケット自体は削除できないため、根本的な問題解決にはなりません。
選択肢C：DeletionPolicy属性のSnapshotは、削除前にリソースのスナップショットを作成する機能ですが、S3バケットはスナップショット機能をサポートしていません。また、これも根本的な削除問題を解決しません。
選択肢D：Amazon EFSへの移行は大幅なアーキテクチャ変更を伴います。また、EFSはファイルシステムベースのストレージであり、S3のオブジェクトベースストレージとは異なる特性を持つため、アプリケーションの大幅な修正が必要になります。VPC設定も必要となり、要件の「大幅なアーキテクチャ変更なし」に反します。
オンプレミスのデータベースには空間データが含まれており、メンテナンス用のcronジョブを実行しています。同社は、AWSからオンプレミスシステムに直接接続して、外部テーブルとしてデータをクエリする必要があります。
これらの要件を満たすソリューションはどれでしょうか。
A. オートスケーリングが有効なAmazon DynamoDBグローバルテーブルを作成します。AWS Schema Conversion Tool（AWS SCT）とAWS Database Migration Service（AWS DMS）を使用して、オンプレミスからDynamoDBにデータを移動します。空間データをAmazon S3に移動するAWS Lambda関数を作成します。Amazon Athenaを使用してデータをクエリします。Amazon EventBridgeを使用してDynamoDBでメンテナンス用ジョブをスケジュールします。外部テーブルサポートにはAmazon API Gatewayを使用します。
B. Amazon RDS for Microsoft SQL Server DBインスタンスを作成します。ネイティブレプリケーションを使用して、オンプレミスからDBインスタンスにデータを移動します。レプリケーション後に必要に応じてSQL Serverスキーマを変更するために、AWS Schema Conversion Tool（AWS SCT）を使用します。空間データをAmazon Redshiftに移動します。システムメンテナンスにはストアドプロシージャを使用します。外部テーブルサポートのために、オンプレミスのOracleデータベースに接続するAWS Glueクローラーを作成します。
C. OracleデータベースをホストするためのAmazon EC2インスタンスを起動します。EC2インスタンスをAuto Scalingグループに配置します。AWS Application Migration Serviceを使用して、オンプレミスからEC2インスタンスにデータを移動し、リアルタイムの双方向変更データキャプチャ（CDC）同期を行います。Oracleネイティブの空間データサポートを使用します。AWS Step Functionsワークフローの一部として、メンテナンスジョブを実行するAWS Lambda関数を作成します。外部テーブルサポートのためにインターネットゲートウェイを作成します。
D. Amazon RDS for PostgreSQL DBインスタンスを作成します。AWS Schema Conversion Tool（AWS SCT）とAWS Database Migration Service（AWS DMS）を使用して、オンプレミスからDBインスタンスにデータを移動します。PostgreSQLネイティブの空間データサポートを使用します。メンテナンス用にDBインスタンスでcronジョブを実行します。外部テーブルサポートのために、DBインスタンスをオンプレミス環境に接続するAWS Direct Connectを使用します。
解説
この問題では、Oracleデータベースの移行、空間データの処理、メンテナンスジョブの継続、外部テーブル機能という複数の要件を満たす必要があります。
選択肢Dが正解である理由：
PostgreSQLは、Oracleデータベースからの移行において最も互換性が高いリレーショナルデータベースの一つです。AWS SCTとAWS DMSの組み合わせにより、OracleからPostgreSQLへの効率的なスキーマ変換とデータ移行が可能です。PostgreSQLはPostGIS拡張により、Oracleの空間データ機能と同等の高度な空間データ処理能力を提供します。RDS for PostgreSQLでは、カスタムメンテナンススクリプトを実行でき、既存のcronジョブ機能を維持できます。PostgreSQLの外部データラッパー（FDW：Foreign Data Wrapper）機能により、AWS Direct Connect経由でオンプレミスのOracleデータベースに接続し、外部テーブルとしてデータをクエリできます。この構成により、ハイブリッド環境での統合データアクセスが実現されます。
他の選択肢が不適切な理由：
選択肢A：DynamoDBはNoSQLデータベースであり、Oracleのような複雑なリレーショナルデータ構造や空間データの移行には適していません。また、外部テーブル機能をAPI Gatewayで実現するのは技術的に困難で非効率的です。
選択肢B：OracleからSQL Serverへの移行は、PostgreSQLと比較して互換性が低く、より多くのスキーマ変更が必要になります。また、空間データをRedshiftに分離することで、データの一貫性と管理の複雑さが増加します。AWS GlueクローラーはETL処理用であり、リアルタイムの外部テーブルアクセスには適していません。
選択肢C：EC2上でのOracle運用は、ライセンスコストとインフラ管理のオーバーヘッドが高くなります。AWS Application Migration Serviceは主にアプリケーション層の移行に使用され、データベース移行の最適解ではありません。また、インターネットゲートウェイはセキュリティ面で外部テーブル接続に適切ではありません。
EC2インスタンスは正常に起動しています。しかし、一定時間後、EC2インスタンスは次のエラーメッセージで終了されます：「ELBシステムヘルスチェック失敗に応答してインスタンスがサービスから削除されました。」Auto Scalingイベントにより、EC2インスタンスが起動と終了を繰り返す無限ループが続いています。
デプロイメントに対する唯一の最近の変更は、企業がS3バケットに大量の重要なコンテンツを追加したことです。企業は本番環境でユーザーデータスクリプトを変更したくありません。
本番環境が正常にデプロイできるように、ソリューションアーキテクトは何をすべきでしょうか。
A. EC2インスタンスのサイズを増加させます。
B. ALBのヘルスチェックタイムアウトを増加させます。
C. ALBのヘルスチェックパスを変更します。
D. Auto Scalingグループのヘルスチェック猶予期間を増加させます。
解説
この問題は、EC2インスタンスの初期化時間とAuto Scalingグループのヘルスチェック猶予期間のミスマッチが原因で発生している典型的な問題です。
選択肢Dが正解である理由：
Auto Scalingグループのヘルスチェック猶予期間（Health Check Grace Period）は、新しく起動したEC2インスタンスがヘルスチェックの対象になるまでの待機時間を定義します。S3バケットに大量のコンテンツが追加されたことで、ユーザーデータスクリプトによるダウンロード処理とアプリケーションの初期化に時間がかかるようになりました。現在の猶予期間では、アプリケーションが完全に起動する前にヘルスチェックが開始され、失敗として判定されてインスタンスが終了されています。ヘルスチェック猶予期間を延長することで、アプリケーションが完全に初期化されるまでの十分な時間を確保でき、誤った終了を防ぐことができます。この設定変更により、ユーザーデータスクリプトを変更することなく問題を解決できます。
他の選択肢が不適切な理由：
選択肢A：EC2インスタンスのサイズ増加は、ネットワーク帯域幅の向上により多少のダウンロード時間短縮効果はありますが、根本的な解決策ではありません。また、コスト増加を伴う可能性があります。
選択肢B：ALBのヘルスチェックタイムアウトは、各ヘルスチェックリクエストの応答待機時間を設定するものです。アプリケーションが起動していない状態では、タイムアウトを延長してもヘルスチェックは失敗し続けます。
選択肢C：ヘルスチェックパスの変更は、アプリケーションが提供する異なるエンドポイントを指定することですが、アプリケーション自体が初期化中の場合、どのパスに対してもレスポンスできない状態は変わりません。問題の根本原因である初期化時間の問題は解決されません。
企業はS3バケットを他のリージョンにレプリケートしています。ソリューションアーキテクトは、アプリケーションがリージョン間でデータの暗号化と復号化を行えるソリューションを設計する必要があります。アプリケーションは、各リージョンでデータを復号化するために同じキーを使用する必要があります。
これらの要件を満たすソリューションはどれでしょうか。
A. KMSマルチリージョンプライマリキーを作成します。KMSマルチリージョンプライマリキーを使用して、アプリケーションが実行されている各追加リージョンでKMSマルチリージョンレプリカキーを作成します。各リージョンで特定のレプリカキーを使用するようにアプリケーションコードを更新します。
B. アプリケーションが実行されている各追加リージョンで新しい顧客管理KMSキーを作成します。各リージョンで特定のKMSキーを使用するようにアプリケーションコードを更新します。
C. AWS Private Certificate Authorityを使用して、プライマリリージョンで新しい認証局（CA）を作成します。アプリケーションのウェブサイトURLに対してCAから新しいプライベート証明書を発行します。AWS Resource Access Manager（AWS RAM）を使用して追加リージョンとCAを共有します。各リージョンで共有CA証明書を使用するようにアプリケーションコードを更新します。
D. AWS Systems Manager Parameter Storeを使用して、アプリケーションが実行されている各追加リージョンでパラメータを作成します。プライマリリージョンのKMSキーからキーマテリアルをエクスポートします。各リージョンのパラメータにキーマテリアルを格納します。各リージョンでパラメータからキーデータを使用するようにアプリケーションコードを更新します。
解説
この問題では、複数のAWSリージョンで同じ暗号化キーを使用してデータの暗号化・復号化を行う必要があり、AWS KMSのマルチリージョンキー機能が最適な解決策となります。
選択肢Aが正解である理由：
AWS KMSマルチリージョンキーは、複数のリージョンで同じキーマテリアルを使用できる機能です。プライマリキーを作成した後、各リージョンでレプリカキーを作成することで、論理的には同じキーでありながら、各リージョンでローカルに暗号化・復号化処理を実行できます。これにより、リージョン間でのレイテンシを最小限に抑えながら、同じキーマテリアルを使用した一貫した暗号化・復号化が可能になります。S3クロスリージョンレプリケーションされたデータも、各リージョンで同じキーを使用して復号化できるため、要件を完全に満たします。マルチリージョンキーは、キーローテーションや権限管理も統一的に行えるため、運用面でも優れています。
他の選択肢が不適切な理由：
選択肢B：各リージョンで個別のKMSキーを作成する場合、キーマテリアルが異なるため、あるリージョンで暗号化されたデータを他のリージョンで復号化することができません。「同じキーを使用する」という要件に反します。
選択肢C：AWS Private Certificate Authorityは、PKI（公開キー基盤）証明書の管理に使用されるサービスであり、対称キー暗号化を行うKMSの代替にはなりません。また、S3のサーバーサイド暗号化とは全く異なる用途のサービスです。
選択肢D：KMSキーのキーマテリアルを直接エクスポートしてParameter Storeに保存することは、セキュリティ上重大な問題があります。KMSの設計思想では、キーマテリアルをプレーンテキストで外部に取り出すことは推奨されておらず、AWS管理下でのハードウェアセキュリティモジュール（HSM）内での処理が基本です。このアプローチは、KMSのセキュリティ保証を無効化してしまいます。
これらの要件を満たすソリューションはどれですか？
A. AWS Storage Gateway テープ ゲートウェイをプロビジョニングします。テープ ゲートウェイを設定してAmazon S3バケットにデータを保存します。AWS Backupをデプロイしてボリュームのポイントインタイム コピーを取得します。
B. Amazon FSx File GatewayとAmazon S3 File Gatewayをプロビジョニングします。AWS Backupをデプロイしてデータのポイントインタイム コピーを取得します。
C. AWS Storage Gateway ボリューム ゲートウェイをキャッシュ モードでプロビジョニングします。AWS Backupを使用してオンプレミスのStorage Gatewayボリュームをバックアップします。
D. AWS Storage Gateway ファイル ゲートウェイをキャッシュ モードでプロビジョニングします。AWS Backupをデプロイしてボリュームのポイントインタイム コピーを取得します。
解説
この問題の要件を整理すると以下の通りです：
レガシーなオンプレミス ファイル アプリケーション向けのスケーラブル ストレージ
AWS Backupを使用したポイントインタイム コピーの取得
頻繁にアクセスされるデータへの低レイテンシ アクセス
iSCSIデバイスとしてマウント可能なストレージ ボリューム
各選択肢を分析します：
選択肢A（テープ ゲートウェイ）：テープ ゲートウェイは仮想テープライブラリ（VTL）機能を提供し、主にバックアップ用途に使用されます。iSCSIボリュームとしてのマウントには適していません。
選択肢B（FSx File GatewayとS3 File Gateway）：これらはファイル ベースのアクセスを提供しますが、iSCSIブロック レベルのアクセスは提供しません。また、Amazon FSx File Gatewayというサービスは存在しません。
選択肢C（ボリューム ゲートウェイ - キャッシュ モード）：AWS Storage Gateway ボリューム ゲートウェイのキャッシュ モードは、プライマリ データをS3に保存し、頻繁にアクセスされるデータをローカルにキャッシュします。これにより低レイテンシ アクセスが実現されます。iSCSIプロトコルをサポートし、AWS Backupとも統合可能です。すべての要件を満たしています。
選択肢D（ファイル ゲートウェイ）：ファイル ゲートウェイはNFSやSMBプロトコルを使用したファイル ベースのアクセスを提供しますが、iSCSIブロック レベルのアクセスは提供しません。
したがって、iSCSIボリュームのマウント、低レイテンシ アクセス、AWS Backupとの統合という要件をすべて満たすのは選択肢Cのボリューム ゲートウェイ（キャッシュ モード）です。
開発者には以下の要件があります：
- ソース管理にAWS CodeCommitを使用する
- 単体テストとセキュリティスキャンを自動化する
- 単体テストが失敗した際に開発者にアラートを送信する
- CI/CDの一部として、アプリケーション機能のオン/オフを切り替え、デプロイメントを動的にカスタマイズする
- アプリケーションをデプロイする前にリード開発者の承認を得る
これらの要件を満たすソリューションはどれですか？
A. AWS CodeBuildを使用して単体テストとセキュリティスキャンを実行します。Amazon EventBridgeルールを使用して、単体テストが失敗した際に開発者にAmazon SNSアラートを送信します。異なるソリューション機能用にAWS Cloud Development Kit（AWS CDK）コンストラクトを記述し、マニフェストファイルを使用してAWS CDKアプリケーション内で機能のオン/オフを切り替えます。パイプライン内で手動承認ステージを使用して、リード開発者がアプリケーションを承認できるようにします。
B. AWS Lambdaを使用して単体テストとセキュリティスキャンを実行します。パイプライン内の後続ステージでLambdaを使用して、単体テストが失敗した際に開発者にAmazon SNSアラートを送信します。異なるソリューション機能用にAWS Amplifyプラグインを記述し、ユーザープロンプトを利用して機能のオン/オフを切り替えます。パイプライン内でAmazon SESを使用して、リード開発者がアプリケーションを承認できるようにします。
C. Jenkinsを使用して単体テストとセキュリティスキャンを実行します。パイプライン内のAmazon EventBridgeルールを使用して、単体テストが失敗した際に開発者にAmazon SESアラートを送信します。異なるソリューション機能用にAWS CloudFormationネストされたスタックとパラメータを使用して機能のオン/オフを切り替えます。パイプライン内でAWS Lambdaを使用して、リード開発者がアプリケーションを承認できるようにします。
D. AWS CodeDeployを使用して単体テストとセキュリティスキャンを実行します。パイプライン内のAmazon CloudWatchアラームを使用して、単体テストが失敗した際に開発者にAmazon SNSアラートを送信します。異なるソリューション機能用にDockerイメージとAWS CLIを使用して機能のオン/オフを切り替えます。パイプライン内で手動承認ステージを使用して、リード開発者がアプリケーションを承認できるようにします。
**解説**
この問題は、AWS CodePipelineを使用したCI/CDパイプラインの要件を満たすソリューションを選択する問題です。各要件に対して適切なAWSサービスを選択する必要があります。
要件分析：
1. ソース管理：AWS CodeCommit（全選択肢で満たされる）
2. 単体テスト・セキュリティスキャンの自動化
3. テスト失敗時のアラート通知
4. 機能の動的な切り替え
5. リード開発者による承認プロセス
各選択肢の分析：
選択肢A：AWS CodeBuildは単体テストとセキュリティスキャンに最適なサービスです。EventBridgeルールによるSNSアラートは標準的なアラート手法です。AWS CDKとマニフェストファイルによる機能切り替えは柔軟で実用的です。手動承認ステージはCodePipelineの標準機能です。
選択肢B：Lambdaは単体テストやセキュリティスキャンには適していません（実行時間制限や環境制約）。AWS Amplifyプラグインは主にフロントエンド開発用で、CI/CDパイプラインでの機能切り替えには不適切です。Amazon SESは承認メカニズムではなくメール送信サービスです。
選択肢C：JenkinsはAWS外部のツールであり、AWSマネージドサービスを使用するという前提に合いません。Lambda による承認プロセスは複雑で、CodePipelineの手動承認ステージの方が適切です。
選択肢D：CodeDeployはデプロイメントサービスであり、単体テストやセキュリティスキャンの実行には適していません。Dockerイメージとの組み合わせも機能切り替えには過度に複雑です。
選択肢Aが最も適切な理由：
- CodeBuildは継続的インテグレーションに特化したマネージドサービス
- EventBridge + SNSは標準的なアラート仕組み
- AWS CDK + マニフェストファイルは Infrastructure as Codeのベストプラクティス
- 手動承認ステージはCodePipelineの組み込み機能
したがって、すべての要件を適切に満たし、AWSマネージドサービスを効果的に活用する選択肢Aが正解です。
EC2インスタンスがAWS Systems Managerコンソールでマネージドインスタンスとして表示されません。
この問題をトラブルシューティングするために、ソリューションアーキテクトが実行すべきステップの組み合わせはどれですか？（2つ選択してください。）
A. Systems Manager AgentがインスタンスにインストールされていることとSystemsManagerエージェントが実行されていることを確認します。
B. インスタンスにSystems Manager用の適切なIAMロールが割り当てられていることを確認します。
C. VPCにVPCエンドポイントが存在することを確認します。
D. AWS Application Discovery Agentが設定されていることを確認します。
E. Systems Manager用のサービスリンクロールが正しく設定されていることを確認します。
**正解: A, B**
**解説**
EC2インスタンスがAWS Systems Managerでマネージドインスタンスとして表示されない問題は、主に以下の要因によるものです。この問題を解決するための最も重要なステップを理解する必要があります。
EC2インスタンスがSystems Managerでマネージドインスタンスとして認識されるための前提条件：
1. Systems Manager Agent（SSM Agent）がインスタンスにインストールされ、実行されている
2. インスタンスに適切なIAMロール（AmazonSSMManagedInstanceCore ポリシーを含む）が割り当てられている
3. インスタンスがAWS Systems Managerサービスと通信できる
各選択肢の分析：
選択肢A（正解）：Systems Manager Agentは、EC2インスタンスがSystems Managerサービスと通信するために必須のコンポーネントです。VM Importで作成されたインスタンスには、SSM Agentがインストールされていない可能性があります。最新のAmazon Linux、Ubuntu、Windows Server AMIには事前にインストールされていますが、カスタムAMIやインポートされたVMには含まれていない場合があります。
選択肢B（正解）：EC2インスタンスがSystems Managerと通信するためには、適切なIAMロールが必要です。このロールには少なくともAmazonSSMManagedInstanceCoreポリシーが含まれている必要があります。このポリシーがないと、インスタンスはSystems Managerサービスに登録できません。
選択肢C：パブリックサブネットにあるインスタンスで、インターネットゲートウェイ経由でAWSサービスにアクセスできる場合、VPCエンドポイントは必須ではありません。VPCエンドポイントはプライベートサブネットのインスタンスやより高いセキュリティが必要な場合に使用されます。
選択肢D：AWS Application Discovery Agentは、オンプレミス環境でのアプリケーション検出に使用されるサービスで、Systems Managerでのマネージドインスタンス登録には関係ありません。
選択肢E：サービスリンクロールはAWSサービスが他のAWSサービスを呼び出すために使用されるロールですが、EC2インスタンスがSystems Managerに登録される際の直接的な要因ではありません。
VM Importで作成されたインスタンスでは、元のオンプレミス環境の設定が保持されるため、AWS固有のエージェントやIAM設定が不足している可能性が高くなります。したがって、SSM Agentのインストール・実行状況の確認と適切なIAMロールの割り当て確認が最も重要なトラブルシューティングステップとなります。
起動パフォーマンス要件を最もコスト効率的に満たすソリューションはどれですか？
A. すべての初期化コードを各Lambda関数のハンドラーに移動します。各Lambda関数でLambda SnapStartを有効化します。SnapStartを設定して各Lambda関数の$LATESTバージョンを参照するようにします。
B. 各Lambda関数のバージョンを公開します。各Lambda関数のエイリアスを作成します。各エイリアスが対応するバージョンを指すように設定します。各Lambda関数の予約された同時実行設定を設定して、対応するエイリアスを指すようにします。
C. 各Lambda関数のバージョンを公開します。各Lambda関数の予約された同時実行設定を設定して、対応するバージョンを指すようにします。Lambda関数の公開されたバージョンでLambda SnapStartを有効化します。
D. Lambda関数を更新してプレスナップショットフックを追加します。一意のIDを生成するコードをハンドラーに移動します。各Lambda関数のバージョンを公開します。Lambda関数の公開されたバージョンでLambda SnapStartを有効化します。
**解説**
この問題は、Java Lambda関数のコールドスタート時間を最小化する最もコスト効率的な方法を選択する問題です. Lambda SnapStartとProvisioned Concurrencyの違いと適切な使用方法を理解する必要があります。
Lambda SnapStartとProvisioned Concurrencyの比較：
Lambda SnapStart：初期化プロセスのスナップショットを事前に作成し、関数呼び出し時にそのスナップショットから復元することでコールドスタートを削減します。Java関数に特化した機能で、追加のコンピューティング料金は発生しません。
Provisioned Concurrency：事前に関数インスタンスをウォームアップ状態で待機させる機能です。継続的に課金され、使用量に関係なく高額になる可能性があります。
各選択肢の分析：
選択肢A：初期化コードをハンドラー内に移動することは、SnapStartの利点を無効化します。SnapStartは初期化フェーズをスナップショット化するため、初期化コードはハンドラー外に置く必要があります。また、$LATESTバージョンではSnapStartは使用できません。
選択肢B：Provisioned Concurrencyのみを使用しており、継続的な課金が発生するため、コスト効率的ではありません。また、SnapStartを活用していないため、初期化時間の最適化が限定的です。
選択肢C：Provisioned ConcurrencyとSnapStartを組み合わせていますが、両方を使用する必要がなく、Provisioned Concurrencyによる継続的な課金でコスト効率が悪くなります。
選択肢D（正解）：SnapStartの適切な実装方法です。プレスナップショットフックを使用することで、スナップショット作成前に必要な処理を実行できます。一意のIDの生成コードをハンドラーに移動することで、各関数呼び出しで新しい一意のIDが生成されます。これにより、初期化時間を最小化しながら、継続的な課金を回避できます。
SnapStartを使用する際の重要なポイント：
1. 公開されたバージョンでのみ使用可能（$LATESTでは使用不可）
2. 一意性が必要なデータ（ID、乱数、タイムスタンプなど）はハンドラー内で生成する
3. プレスナップショットフックを使用して、スナップショット作成前の処理をカスタマイズ可能
4. Provisioned Concurrencyと比較して、大幅にコスト効率が良い
したがって、レイテンシ要件を満たしながら最もコスト効率的なソリューションは選択肢Dです。
この問題を解決するために、ソリューションアーキテクトが実行すべきステップはどれですか？
A. インターフェースエンドポイントへのルートをサブネットルートテーブルに追加します。
B. VPC属性でプライベートDNSオプションを有効にします。
C. AWSサービスへの接続を許可するようにインターフェースエンドポイントのセキュリティグループを設定します。
D. 内部アプリケーション用の条件付きフォワーダーを持つAmazon Route 53プライベートホストゾーンを設定します。
**解説**
この問題は、VPCインターフェースエンドポイントのDNS解決に関する問題です。インターフェースエンドポイントが正しく機能するためには、プライベートDNS解決が適切に設定されている必要があります。
問題の状況分析：
サービス名（例：s3.amazonaws.com）がパブリックIPアドレスに解決されているということは、DNS解決がインターフェースエンドポイントのプライベートIPアドレスではなく、AWSサービスのパブリックIPアドレスに向かっていることを意味します。これにより、トラフィックがインターフェースエンドポイントを経由せず、インターネット経由でAWSサービスにアクセスしようとしています。
各選択肢の分析：
選択肢A：ルートテーブルの設定は通常、インターフェースエンドポイントには必要ありません。インターフェースエンドポイントは同じVPC内に作成され、VPC内のルーティングは自動的に処理されます。また、DNS解決の問題とは関係ありません。
選択肢B（正解）：VPCでプライベートDNSオプション（enableDnsHostnames と enableDnsSupport）を有効にすることで、AWS サービス名がインターフェースエンドポイントのプライベートIPアドレスに正しく解決されるようになります。これにより、アプリケーションは標準のAWSサービス名（s3.amazonaws.com など）を使用しながら、プライベートIPアドレス経由でサービスにアクセスできます。
選択肢C：セキュリティグループの設定は重要ですが、この問題はDNS解決の問題であり、セキュリティグループの設定問題ではありません。DNS解決が正しく動作していない状態では、セキュリティグループを修正してもサービス名がパブリックIPに解決される問題は解決されません。
選択肢D：Route 53プライベートホストゾーンの設定は可能な解決策ですが、VPCのプライベートDNSオプションを有効にする方がより簡単で標準的な解決方法です。条件付きフォワーダーは複雑な設定を必要とし、この状況では過剰です。
VPCインターフェースエンドポイントの重要なポイント：
1. enableDnsHostnames と enableDnsSupport の両方がVPCで有効になっている必要があります
2. これらが有効になっていると、AWS サービス名が自動的にインターフェースエンドポイントのプライベートIPアドレスに解決されます
3. プライベートDNSが有効でない場合、アプリケーションは特定のエンドポイントURL（vpce-xxx.s3.us-east-1.vpce.amazonaws.com など）を使用する必要があります
4. プライベートDNS解決により、既存のアプリケーションコードを変更することなく、インターフェースエンドポイントを使用できます
したがって、サービス名がパブリックIPアドレスに解決されている問題を解決するには、VPCのプライベートDNSオプションを有効にする選択肢Bが正解です。
最近のセールイベント中に、Webトラフィックの急激な増加により、APIパフォーマンスの低下とデータベース接続の失敗が発生しました。企業は、Lambda関数のレイテンシを最小化し、トラフィックのバーストをサポートするソリューションを実装する必要があります。
アプリケーションへの変更を最小限に抑えながら、これらの要件を満たすソリューションはどれですか？
A. Lambda関数のコードを更新して、Lambda関数が関数ハンドラーの外側でデータベース接続を開くようにします。Lambda関数のプロビジョンド同時実行数を増やします。
B. データベース用のRDS Proxyエンドポイントを作成します。データベースシークレットをAWS Secrets Managerに保存します。必要なIAM許可を設定します。RDS Proxyエンドポイントに接続するようにLambda関数を更新します。Lambda関数のプロビジョンド同時実行数を増やします。
C. カスタムパラメータグループを作成します。max_connectionsパラメータの値を増やします。カスタムパラメータグループをRDS DBインスタンスに関連付け、再起動をスケジュールします。Lambda関数のリザーブド同時実行数を増やします。
D. データベース用のRDS Proxyエンドポイントを作成します。データベースシークレットをAWS Secrets Managerに保存します。必要なIAM許可を設定します。RDS Proxyエンドポイントに接続するようにLambda関数を更新します。Lambda関数のリザーブド同時実行数を増やします。
**解説**
この問題は、サーバーレスアプリケーションでのデータベース接続問題とトラフィックバーストへの対応について扱っています。主な問題は、Lambda関数の急激なスケールアップによるデータベース接続の枯渇と、コールドスタートによるレイテンシの増加です。
問題の根本原因：
1. データベース接続の枯渇：Lambda関数が同時に大量実行されると、それぞれが独立したデータベース接続を作成し、RDS の最大接続数を超えてしまいます
2. コールドスタート：トラフィックバースト時に新しいLambda関数インスタンスが起動するため、初期化時間によるレイテンシが発生します
各選択肢の分析：
選択肢A：データベース接続をハンドラー外に移動することで接続の再利用は可能ですが、Lambda関数の同時実行数が増加した場合の根本的なデータベース接続枯渇問題は解決されません。プロビジョンド同時実行はコールドスタート問題を解決しますが、データベース接続問題には対処できません。
選択肢B（正解）：RDS Proxyがデータベース接続プールを管理し、Lambda関数からの接続を効率的に処理します。これにより、データベース接続の枯渇問題が解決されます。プロビジョンド同時実行により、事前にウォームアップされたLambda関数インスタンスが準備され、コールドスタートによるレイテンシが最小化されます。トラフィックバーストへの対応も可能です。
選択肢C：max_connectionsパラメータを増やすことで一時的にデータベース接続数は増加しますが、Lambda関数のスケールアウトには限界があります。また、リザーブド同時実行は最大同時実行数を制限する機能であり、トラフィックバーストに対しては逆効果です。データベースの再起動も必要で、アプリケーションへの変更が大きくなります。
選択肢D：RDS Proxyの使用は適切ですが、リザーブド同時実行は間違った選択です。リザーブド同時実行は関数の最大同時実行数を制限するため、トラフィックバーストに対応できません。
RDS Proxyの利点：
1. 接続プーリング：多数のLambda関数からの接続を効率的に管理
2. 接続の再利用：新しい接続の作成コストを削減
3. フェイルオーバー時間の短縮：データベースの可用性向上
4. IAM認証のサポート：セキュリティの強化
プロビジョンド同時実行 vs リザーブド同時実行：
- プロビジョンド同時実行：事前にウォームアップされた関数インスタンスを準備し、コールドスタートを防ぐ（トラフィックバースト対応に適している）
- リザーブド同時実行：関数の最大同時実行数を制限し、他の関数のリソースを保護する（トラフィック制限に使用）
したがって、データベース接続問題を解決するRDS Proxyと、レイテンシ最小化とトラフィックバースト対応のためのプロビジョンド同時実行を組み合わせた選択肢Bが最適解です。
この情報を得るために、同社はMigration Evaluatorの評価リクエストを開始しました。オンプレミス環境には制約なくコレクターソフトウェアをインストールすることが可能です。
最小限の運用負荷で必要な情報を提供するソリューションはどれですか？
A. 各オンプレミスVMにAWS Application Discovery Agentをインストールする。データ収集期間終了後、AWS Migration Hubでアプリケーション依存関係を確認し、Migration HubからQuick Insights評価レポートをダウンロードする。
B. 各オンプレミスVMにMigration Evaluator Collectorをインストールする。データ収集期間終了後、Migration Evaluatorでアプリケーション依存関係を確認し、発見されたサーバーリストをエクスポートする。リストをAmazon QuickSightにアップロードし、QuickSightレポートを生成後、Quick Insights評価レポートをダウンロードする。
C. オンプレミス環境にAWS Application Discovery ServiceのAgentless Collectorをセットアップする。データ収集期間終了後、AWS Migration Hubでアプリケーション依存関係を確認し、発見されたサーバーリストをApplication Discovery ServiceからエクスポートしてMigration Evaluatorにアップロードする。Migration Evaluatorレポート生成後、Quick Insights評価をダウンロードする。
D. オンプレミス環境にMigration Evaluator Collectorをセットアップし、各VMにAWS Application Discovery Agentをインストールする。データ収集期間終了後、AWS Migration Hubでアプリケーション依存関係を確認し、Migration EvaluatorからQuick Insights評価レポートをダウンロードする。
解説
AWS Migration Evaluatorはオンプレミス環境の評価を簡易に行うサービスで、専用のCollectorを使用してデータ収集が可能ですが、今回の条件では「コレクターソフトウェアを自由にインストール可能」なため、AWS Application Discovery AgentをVMにインストールし、Migration Hubで依存関係を可視化し、Quick Insights評価レポートを直接入手できるAの方法が最も運用負荷が少なく効率的です。BやDはMigration Evaluator Collectorの利用やQuickSightを経由するため手間が増え、CはAgentless CollectorとMigration Evaluatorの二段階作業が必要で複雑です。
ソリューションの高可用性を設定するために、ソリューションアーキテクトは何をすべきですか？
A. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスを各リージョンのディレクトリに関連付けます。Route 53フェイルオーバールーティングポリシーを作成します。Evaluate Target Healthを「はい」に設定します。
B. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53複数値回答ルーティングポリシーを作成します。
C. プライマリリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53重み付きルーティングポリシーを作成します。
D. プライマリリージョンに接続エイリアスを作成します。接続エイリアスをフェイルオーバーリージョンのディレクトリに関連付けます。Route 53フェイルオーバールーティングポリシーを作成します。Evaluate Target Healthを「はい」に設定します。
**解説**
この問題は、Amazon WorkSpacesの高可用性設計において、複数リージョンにわたる接続エイリアスとRoute 53ルーティングポリシーの適切な設定方法を理解する必要があります。
Amazon WorkSpacesの高可用性アーキテクチャの要件：
1. 複数リージョンでのWorkSpacesデプロイ
2. 各リージョンでの独立したディレクトリサービス
3. 接続エイリアスによるクライアント接続の抽象化
4. DNS フェイルオーバーによる自動的なリージョン切り替え
Amazon WorkSpaces接続エイリアスの重要な概念：
接続エイリアスは、WorkSpacesクライアントが特定のリージョンやディレクトリに依存せずに接続できるようにする機能です。これにより、ユーザーは統一されたエンドポイントを使用して接続でき、バックエンドでのフェイルオーバーが透過的に処理されます。
各選択肢の分析：
選択肢A（正解）：両方のリージョンに接続エイリアスを作成し、それぞれを対応するリージョンのディレクトリに関連付けます。Route 53のフェイルオーバールーティングポリシーと健全性チェックを使用することで、プライマリリージョンが利用不可能になった場合に自動的にフェイルオーバーリージョンに切り替わります。これは真の高可用性を実現します。
選択肢B：両方のリージョンに接続エイリアスを作成していますが、両方をプライマリリージョンのディレクトリにのみ関連付けています。これでは、プライマリリージョンが利用不可能になった場合に、フェイルオーバーリージョンの接続エイリアスも機能しません。また、複数値回答ルーティングポリシーは負荷分散には適していますが、明確なフェイルオーバー動作は提供しません。
選択肢C：プライマリリージョンにのみ接続エイリアスを作成しており、高可用性を実現できません。重み付きルーティングポリシーも、健全性チェックに基づく自動フェイルオーバーを提供しません。
選択肢D：プライマリリージョンの接続エイリアスをフェイルオーバーリージョンのディレクトリに関連付けており、設計上の問題があります。プライマリリージョンが利用不可能になった場合、接続エイリアス自体が利用できなくなります。
Route 53フェイルオーバールーティングポリシーの利点：
1. プライマリリソースの健全性を監視
2. 障害検出時の自動的なセカンダリリソースへの切り替え
3. プライマリリソースの復旧時の自動的な切り戻し
4. Evaluate Target Healthオプションにより、エンドポイントの実際の可用性を確認
高可用性設計における重要なポイント：
1. 各リージョンで完全に独立したWorkSpaces環境を構築
2. 接続エイリアスを使用してクライアント接続を抽象化
3. DNS レベルでの自動フェイルオーバー機能を実装
4. 健全性チェックによる障害の自動検出と対応
したがって、真の高可用性を実現するためには、両方のリージョンに適切に設定された接続エイリアスと、健全性チェック付きのフェイルオーバールーティングポリシーが必要であり、選択肢Aが正解です。
より多くのスマートメーターがデプロイされるにつれて、エンジニアはLambda関数の完了に1〜2分かかることに気づきました。また、デバイスから新しいタイプのメトリクスが収集されるにつれて、関数の実行時間も増加しています。DynamoDBでPUT操作を実行中に多くのProvisionedThroughputExceededException エラーが発生しており、LambdaからもTooManyRequestsException エラーが多数発生しています。
これらの問題を解決する変更の組み合わせはどれですか？（2つ選択してください。）
A. DynamoDBテーブルの書き込みキャパシティユニットを増やします。
B. Lambda関数で利用可能なメモリを増やします。
C. スマートメーターからのペイロードサイズを増やして、より多くのデータを送信します。
D. API GatewayからAmazon Kinesisデータストリームにデータをストリーミングし、データをバッチで処理します。
E. Amazon SQS FIFOキューでデータを収集し、各メッセージを処理するLambda関数をトリガーします。
**解説**
この問題は、スケーラビリティとパフォーマンスの問題を抱えるサーバーレスアーキテクチャの最適化に関するものです。現在のアーキテクチャでは、同期処理による制約とリソースの容量不足が主な問題となっています。
現在の問題の分析：
1. ProvisionedThroughputExceededException：DynamoDBの書き込み容量不足
2. TooManyRequestsException：Lambda の同時実行制限に達している
3. Lambda関数の実行時間増加：処理量の増加と非効率な処理方法
4. リアルタイム同期処理による制約：各リクエストが個別に処理されるため、スケーラビリティに限界
各選択肢の分析：
選択肢A（正解）：DynamoDBテーブルの書き込みキャパシティユニットを増やすことで、ProvisionedThroughputExceededException エラーを直接解決できます。スマートメーターの数が増加している状況では、それに応じてDynamoDBの容量も増加する必要があります。
選択肢B：メモリを増やすことでLambda関数のパフォーマンスは向上する可能性がありますが、根本的な問題（大量の同期リクエスト処理）は解決されません。また、TooManyRequestsException は同時実行数の問題であり、メモリ増加では解決されません。
選択肢C：ペイロードサイズを増やすことは、現在の問題を悪化させる可能性があります。より大きなペイロードは処理時間を増加させ、Lambda関数の実行時間をさらに延長します。
選択肢D（正解）：Kinesis Data Streamを使用することで、リアルタイムストリーミングデータを効率的に処理できます。バッチ処理により、Lambda関数は複数のレコードを一度に処理でき、DynamoDBへの書き込み操作も最適化されます。また、Kinesisが自動的にデータをバッファリングし、Lambda の同時実行制限の問題も軽減されます。
選択肢E：SQS FIFOキューは各メッセージを個別に処理するため、現在の同期処理の問題は解決されません。むしろ、FIFO の順序保証によりスループットが制限される可能性があります。
推奨されるアーキテクチャの改善：
現在のアーキテクチャ：API Gateway → Lambda → DynamoDB（同期処理）
改善されたアーキテクチャ：API Gateway → Kinesis Data Stream → Lambda（バッチ処理）→ DynamoDB
Kinesis Data Streamの利点：
1. データのバッファリングとバッチ処理
2. 自動的なスケーリング
3. Lambda関数での複数レコードの一括処理
4. DynamoDB への効率的な書き込み（バッチ操作）
5. 同時実行制限の問題の軽減
DynamoDBキャパシティ増加の必要性：
スマートメーターの数が増加し、新しいメトリクスが追加されているため、書き込み容量の増加は必須です。Auto Scalingの設定も検討すべきです。
時間帯別料金制のユースケースでは、5分間隔のデータ収集はリアルタイム性よりもスループットが重要であり、バッチ処理アプローチが適しています。
したがって、DynamoDBの容量増加（選択肢A）とKinesisを使用したバッチ処理アーキテクチャへの変更（選択肢D）が最適な解決策です。
企業の組織内のすべてのクラウドリソースには、BusinessUnitという名前のタグが付けられています。すべてのタグには既に事業部門名の適切な値が設定されています。
企業は、クラウドコストを異なる事業部門に配分する必要があります。また、各事業部門のクラウドコストを可視化する必要もあります。
これらの要件を満たすソリューションはどれですか？
A. 組織の管理アカウントで、BusinessUnitという名前のコスト配分タグを作成します。また管理アカウントで、Amazon S3バケットとAWS Cost and Usage Report（AWS CUR）を作成します。S3バケットをAWS CURの出力先として設定します。管理アカウントから、Amazon Athenaを使用してAWS CURデータをクエリします。可視化にはAmazon QuickSightを使用します。
B. 各メンバーアカウントで、BusinessUnitという名前のコスト配分タグを作成します。組織の管理アカウントで、Amazon S3バケットとAWS Cost and Usage Report（AWS CUR）を作成します。S3バケットをAWS CURの出力先として設定します。可視化用にAmazon CloudWatchダッシュボードを作成します。
C. 組織の管理アカウントで、BusinessUnitという名前のコスト配分タグを作成します。各メンバーアカウントで、Amazon S3バケットとAWS Cost and Usage Report（AWS CUR）を作成します。各S3バケットをそれぞれのAWS CURの出力先として設定します。管理アカウントで、可視化用にAmazon CloudWatchダッシュボードを作成します。
D. 各メンバーアカウントで、BusinessUnitという名前のコスト配分タグを作成します。また各メンバーアカウントで、Amazon S3バケットとAWS Cost and Usage Report（AWS CUR）を作成します。各S3バケットをそれぞれのAWS CURの出力先として設定します。管理アカウントから、Amazon Athenaを使用してAWS CURデータをクエリします。可視化にはAmazon QuickSightを使用します。
**解説**
この問題は、AWS Organizations環境でのコスト配分とコスト可視化のベストプラクティスについて理解する必要があります。組織全体のコスト管理は管理アカウントから一元的に行うのが最適です。
AWS Organizations でのコスト管理の基本原則：
1. 管理アカウントが組織全体のコスト情報を集約
2. コスト配分タグは管理アカウントで一元管理
3. AWS CURは管理アカウントで組織全体のデータを生成
4. 分析と可視化も管理アカウントから実行
各選択肢の分析：
選択肢A（正解）：
- 管理アカウントでコスト配分タグを作成：組織全体のタグベースコスト配分を一元管理
- 管理アカウントでAWS CUR設定：組織全体のコストデータを統合して取得
- Athena + QuickSight：高度な分析と可視化に最適な組み合わせ
- 一元化されたアプローチで管理が簡素化
選択肢B：
- メンバーアカウントでのコスト配分タグ作成は非効率：各アカウントで個別に管理する必要があり、組織レベルでの一貫性が保てません
- CloudWatch ダッシュボード：コスト分析には制限があり、AWS CURデータの詳細分析には不適切
選択肢C：
- 各メンバーアカウントでのAWS CUR作成：データが分散し、統合分析が困難
- 管理の複雑性が増加し、組織全体のコスト把握が困難
- CloudWatch ダッシュボードの制限
選択肢D：
- 各メンバーアカウントでの個別AWS CUR作成：データの統合が複雑
- 分散したS3バケットからのデータクエリは非効率
- 管理アカウントから各メンバーアカウントのS3バケットへのアクセス権限管理が複雑
AWS Organizations でのコスト管理ベストプラクティス：
1. コスト配分タグの一元管理：管理アカウントで組織全体のタグポリシーを設定し、統一されたコスト配分を実現
2. 統合請求とAWS CUR：管理アカウントで組織全体のコストデータを一箇所に集約
3. 分析ツールの選択：Athena + QuickSightの組み合わせにより、SQL クエリベースの柔軟な分析と豊富な可視化オプションを提供
4. セキュリティと権限管理：管理アカウントからの一元的なアクセス制御
コスト配分タグの重要性：
既存のBusinessUnitタグを活用してコスト配分を行うため、管理アカウントでこのタグをコスト配分タグとして有効化する必要があります。これにより、各リソースのコストが適切な事業部門に割り当てられます。
Athena + QuickSight の利点：
1. AWS CURの大容量データを効率的にクエリ
2. 事業部門別、サービス別、時間別など多角的な分析が可能
3. インタラクティブなダッシュボードによる可視化
4. コスト効率的な分析環境（使用量ベースの課金）
したがって、組織全体のコスト管理を一元化し、効率的な分析・可視化環境を構築する選択肢Aが最適解です。
また、データは将来的な分析処理のためにデータパイプラインを通じて永続化できる必要がある。
この要件を最小の運用負荷で満たすソリューションはどれか？
A. Amazon Aurora Global Database を使用し、マルチリージョンでレプリケーションを構成する
B. 読み取りレプリカを持つ Amazon RDS データベースを作成する。アプリケーションの書き込み先をライターエンドポイントに設定し、読み取り先をリーダーエンドポイントに設定する
C. マルチ AZ モードで Amazon MemoryDB for Redis クラスターを作成する。アプリケーションをプライマリノードと連携させる
D. 複数の Redis ノードを複数のアベイラビリティゾーンに分散した Amazon EC2 インスタンス上に作成し、Amazon S3 にバックアップを構成する
解説：
このシナリオでは、リアルタイム性が非常に重要であり、マイクロ秒単位の読み取りと 1 桁ミリ秒の書き込みレイテンシが求められています。また、数テラバイト規模のデータを扱い、プライマリノード障害時でも 1 分以内に復旧する必要があり、さらにデータの永続化と将来的な分析処理のための保存も必要です。
Amazon MemoryDB for Redis は、インメモリのデータベースサービスであり、Redis 互換でマイクロ秒単位のレイテンシを実現しつつ、データをディスクに永続化する機能も備えています。マルチ AZ 配置と自動フェイルオーバーにより、1 分未満の復旧も可能です。さらにフルマネージドであるため、運用負荷も最小限に抑えられます。
他の選択肢について：
- A は Aurora の強力なレプリケーションを活用しますが、ミリ秒以下のレイテンシには向いていません。
- B の RDS はマイクロ秒レイテンシを保証できず、要件に不適。
- D は Redis の構成として柔軟ではありますが、手動運用や可用性の確保、バックアップ処理などの負荷が高いため、最小の運用負荷という条件を満たしません。
自動復号化のソリューションを完成させるために、ソリューションアーキテクトが次に行うべきことは何か？
A. PGP の公開鍵を Secrets Manager に保存する。Transfer Family 管理ワークフローに通常ステップを追加してファイルを復号化する。通常ステップに PGP 暗号化パラメータを設定する。ワークフローを Transfer Family サーバーに関連付ける。
B. PGP の秘密鍵を Secrets Manager に保存する。Transfer Family 管理ワークフローに例外処理ステップを追加してファイルを復号化する。例外処理に PGP 暗号化パラメータを設定する。ワークフローを SFTP ユーザーに関連付ける。
C. PGP の秘密鍵を Secrets Manager に保存する。Transfer Family 管理ワークフローに通常ステップを追加してファイルを復号化する。通常ステップに PGP 復号化パラメータを設定する。ワークフローを Transfer Family サーバーに関連付ける。
D. PGP の公開鍵を Secrets Manager に保存する。Transfer Family 管理ワークフローに例外処理ステップを追加してファイルを復号化する。例外処理に PGP 復号化パラメータを設定する。ワークフローを SFTP ユーザーに関連付ける。
解説：
PGP 暗号化の復号には秘密鍵が必要であるため、秘密鍵を Secrets Manager に保存する必要がある。Transfer Family の管理ワークフローで自動復号化を行うには、ファイル受信時に通常処理（nominal step）として復号化ステップを追加し、ここに PGP 復号化のパラメータを設定するのが正しい方法である。例外処理ステップはエラー対応用であり、正常な復号化処理には通常ステップを使うべきである。さらに、ワークフローはサーバーレベルで設定し、SFTP ユーザー単位ではなくサーバー単位で適用するのが一般的である。これにより、受信したすべてのファイルに対して復号化が適用される。
ソリューションアーキテクトはCloudFormationテンプレート内でロールを再作成し、同じロール名を使用します。CloudFormationテンプレートが子アカウントで起動されると、権限不足のため、EC2インスタンスは親アカウントのロールを引き受けることができなくなります。
この問題を解決するために、ソリューションアーキテクトは何をすべきでしょうか？
A. 親アカウントで、EC2インスタンスが引き受ける必要があるロールの信頼ポリシーを編集します。sts:AssumeRoleアクションを許可する既存のステートメント内のターゲットロールARNが正しいことを確認します。信頼ポリシーを保存します。
B. 親アカウントで、EC2インスタンスが引き受ける必要があるロールの信頼ポリシーを編集します。子アカウントのルートプリンシパルに対してsts:AssumeRoleアクションを許可するステートメントを追加します。信頼ポリシーを保存します。
C. CloudFormationスタックを再度更新します。CAPABILITY_NAMED_IAMケーパビリティのみを指定します。
D. CloudFormationスタックを再度更新します。CAPABILITY_IAMケーパビリティとCAPABILITY_NAMED_IAMケーパビリティを指定します。
**解説**
この問題は、CloudFormationでIAMロールを再作成した際に発生するクロスアカウントアクセスの問題です。
手動で作成されたロールをCloudFormationで再作成すると、たとえ同じロール名を使用しても、ロールのARN（Amazon Resource Name）が変更される可能性があります。これは、CloudFormationが内部的に一意の識別子を生成するためです。
親アカウントの信頼ポリシーでは、特定のロールのARNに対してsts:AssumeRoleを許可していたため、新しいロールのARNが異なると、権限が適用されなくなります。
選択肢Aが正解である理由：
- 親アカウントの信頼ポリシー内のターゲットロールARNを、CloudFormationで新しく作成されたロールの正しいARNに更新する必要があります
- これにより、EC2インスタンスが新しいロールを使用して親アカウントのロールを引き受けることができるようになります
選択肢Bが不正解である理由：
- 子アカウントのルートプリンシパルに権限を与えるのはセキュリティ上のベストプラクティスではありません
- 特定のロールに対して権限を付与する方がより安全です
選択肢CとDが不正解である理由：
- CAPABILITY_IAMやCAPABILITY_NAMED_IAMは、CloudFormationがIAMリソースを作成する際の確認機能ですが、この問題の根本原因であるARNの不一致は解決されません
高負荷時にチケット販売取引の信頼性を最も向上させる解決策はどれか？
A. ECS クラスター内に待機室専用の別サービスを作成し、別のスケーリング設定を使用する。チケット販売サービスが JWT 情報を使って適切に待機室サービスへリクエストを転送するようにする。
B. アプリケーションを Amazon Elastic Kubernetes Service（Amazon EKS）クラスターに移行する。待機室モジュールをチケット販売ポッドから分離し、StatefulSet の一部としてチケット販売ポッドを作成する。チケット販売ポッドが JWT 情報を使って待機室ポッドへ適切にリクエストを転送するようにする。
C. ECS クラスター内に待機室専用の別サービスを作成し、別のスケーリング設定を使用する。CloudFront 関数を作成し、JWT 情報を検査してリクエストをチケット販売サービスか待機室サービスへ適切に振り分ける。
D. アプリケーションを Amazon EKS クラスターに移行し、待機室モジュールをチケット販売ポッドから分離する。AWS App Mesh を利用し、Kubernetes 用 App Mesh コントローラーを導入する。mTLS 認証とサービス間認証を有効にし、チケット販売ポッドが JWT 情報を使って待機室ポッドへ適切にリクエストを転送するようにする。
解説：
高負荷時のアプリケーション信頼性向上の鍵は、待機室の負荷を分離しつつ、効率的に振り分けを行うことである。ECS 内で待機室を別サービスに分離し、スケーリングを独立して管理できるようにするのは適切な設計である。さらに、CloudFront 関数で JWT を検査しリクエストの振り分けを行えば、アプリケーションに負荷がかかる前にリクエストを振り分けできるため、負荷分散の効率と信頼性が大幅に向上する。選択肢 A は振り分けをアプリケーションレイヤーで行うため負荷が高く、B と D は Kubernetes への移行や複雑なサービスメッシュ導入が必要で、運用負荷が増すため最小限の運用負荷という要件に合致しない。
この要件を最小限の運用負荷で満たす解決策はどれか？
A. AWS Security Hub を有効化し、Security Hub で EKS ノードと ECR リポジトリのスキャンを設定する。
B. Amazon Inspector を有効化し、EKS ノードと ECR リポジトリのスキャンを設定する。
C. 新しい Amazon EC2 インスタンスを起動し、AWS Marketplace から脆弱性スキャンツールをインストールする。EC2 インスタンスで EKS ノードをスキャンするよう設定し、Amazon ECR には基本的なプッシュ時スキャンを設定する。
D. EKS ノードに Amazon CloudWatch エージェントをインストールし、継続的なスキャンを設定する。Amazon ECR には基本的なプッシュ時スキャンを設定する。
解説：
Amazon Inspector は AWS が提供するマネージドな脆弱性評価サービスであり、EKS ノード（EC2 インスタンスまたは管理ノード）と Amazon ECR のコンテナイメージの両方に対し自動かつ継続的なスキャンを提供する。これによりセキュリティ要件を満たしながら運用負荷を最小限にできる。
選択肢 A の Security Hub は脆弱性スキャン自体の機能はなく、脆弱性結果の統合管理に優れるがスキャン実行には別サービスが必要。
選択肢 C は手動でのツール導入と管理が必要で運用負荷が高い。
選択肢 D の CloudWatch エージェントは監視向けであり、脆弱性スキャン機能は持たない。
よって、最も適切かつ運用負荷の少ない選択肢は B である。
最近のマーケティングプロモーション中に、アプリケーションがクラッシュしたため、顧客が注文を行うことができませんでした。分析の結果、3つの層すべてが過負荷状態であることが判明しました。アプリケーションは応答しなくなり、読み取り操作によってデータベースが容量制限に達しました。同社では、近い将来に類似のプロモーションを複数予定しています。
ソリューションアーキテクトは、これらの問題を解決するためのAWSへの移行計画を策定する必要があります。ソリューションはスケーラビリティを最大化し、運用負荷を最小化する必要があります。
これらの要件を満たす手順の組み合わせはどれですか？（3つ選択）
A. 静的アセットをAmazon S3でホストできるようにフロントエンドをリファクタリングします。Amazon CloudFrontを使用してフロントエンドを顧客に配信します。フロントエンドをJavaアプリケーションに接続します。
B. フロントエンドのApache WebサーバーをAuto Scalingグループ内のAmazon EC2インスタンスにリホストします。Auto Scalingグループの前にロードバランサーを使用します。Apache Webサーバーが必要とする静的アセットをホストするためにAmazon Elastic File System（Amazon EFS）を使用します。
C. Javaアプリケーションをオートスケーリングを含むAWS Elastic Beanstalk環境にリホストします。
D. Javaアプリケーションをリファクタリングします。Javaアプリケーションを実行するDockerコンテナを開発します。コンテナをホストするためにAWS Fargateを使用します。
E. AWS Database Migration Service（AWS DMS）を使用してPostgreSQLデータベースをAmazon Aurora PostgreSQLデータベースにリプラットフォームします。読み取りレプリカにAurora Auto Scalingを使用します。
F. PostgreSQLデータベースをオンプレミスサーバーの2倍のメモリを持つAmazon EC2インスタンスにリホストします。
**解説**
この問題は、スケーラビリティを最大化し運用負荷を最小化するAWS移行戦略について問われています。各層で最適なソリューションを選択する必要があります。
**選択肢A（正解）：**
静的アセットをS3に配置しCloudFrontで配信することで、フロントエンドの負荷を大幅に軽減できます。CloudFrontはグローバルなCDNとして機能し、静的コンテンツを効率的に配信します。これにより運用負荷が最小化され、スケーラビリティが向上します。
**選択肢B（不正解）：**
Apache WebサーバーをEC2でホストする従来的なアプローチです。Auto Scalingは提供されますが、選択肢Aと比較して運用負荷が高く、静的アセット配信の効率性も劣ります。
**選択肢C（正解）：**
Elastic Beanstalkはアプリケーションの実行環境を自動的に管理し、オートスケーリング機能を提供します。モノリシックなJavaアプリケーションを最小限の変更でAWSに移行でき、運用負荷を大幅に削減します。
**選択肢D（不正解）：**
Dockerコンテナ化とFargateの使用は優れたソリューションですが、アプリケーションのリファクタリングが必要となり、運用負荷の最小化という要件に合致しません。
**選択肢E（正解）：**
Aurora PostgreSQLは高可用性とスケーラビリティを提供し、Auto Scalingによる読み取りレプリカで読み取り負荷の問題を解決できます。フルマネージドサービスのため運用負荷が最小化されます。
**選択肢F（不正解）：**
単にメモリを増やすだけでは根本的なスケーラビリティの問題は解決されず、読み取り負荷の分散もできません。また、EC2での自己管理は運用負荷を増加させます。
この組み合わせにより、3層すべてでスケーラビリティが向上し、AWSのマネージドサービスを活用することで運用負荷が最小化されます。
これらの要件を満たすために、ソリューションアーキテクトは何をすべきでしょうか？
A. AWS Site-to-Site VPN接続を作成し、VPNとAD DSの統合を構成する。MFA対応のAmazon WorkSpacesクライアントを使用してVPN接続を確立する。
B. AWS Client VPNエンドポイントを作成し、AD DSと統合するためにAD Connectorディレクトリを作成する。AD ConnectorでMFAを有効にし、AWS Client VPNを使ってVPN接続を確立する。
C. AWS VPN CloudHubを使用して複数のAWS Site-to-Site VPN接続を作成する。AWS VPN CloudHubとAD DSの統合を構成する。AWS Copilotを使ってVPN接続を確立する。
D. Amazon WorkLinkエンドポイントを作成し、Amazon WorkLinkとAD DSの統合を構成する。Amazon WorkLinkでMFAを有効にし、AWS Client VPNを使ってVPN接続を確立する。
理由：AWS Client VPNはリモートユーザー向けのマネージドVPNサービスであり、AD Connectorを使うことで既存のAD DS環境とシームレスに連携できます。これによりユーザー認証はADで行い、MFAもAD Connector経由で有効化できます。Site-to-Site VPNは拠点間接続用でありリモートユーザー向けではなく、WorkSpacesやWorkLinkはVPN接続の代替として適切ではありません。したがって、最も要件を満たし、運用負荷が少ないのは選択肢Bの構成です。
これらの要件を満たす最も運用効率の高いソリューションはどれですか？
A. 組織内のすべてのAWSアカウントで新しいCloudTrailトレイルを作成するAWS Lambda関数を作成します。Amazon EventBridgeのスケジュールされたアクションを使用して、Lambda関数を毎日実行します。
B. 組織の管理アカウントで新しいCloudTrailトレイルを作成します。組織内のすべてのAWSアカウントのすべてのイベントをログに記録するようにトレイルを設定します。
C. 組織内のすべてのAWSアカウントで新しいCloudTrailトレイルを作成します。新しいアカウントが作成されるたびに新しいトレイルを作成します。トレイルの削除または変更を防ぐSCPを定義します。SCPをルートOUに適用します。
D. 組織内のすべてのAWSアカウントでCloudTrailトレイルを作成するAWS Systems Manager Automationランブックを作成します。Systems Manager State Managerを使用してオートメーションを実行します。
解説
この問題は、AWS Organizationsにおける組織全体でのCloudTrail設定の最適化について問われています。「最も運用効率の高い」という要件が重要なポイントです。
選択肢B（正解）：
組織の管理アカウントで組織トレイルを作成することで、単一のトレイルで組織内のすべてのアカウントのイベントを自動的にログ記録できます。新しいアカウントが組織に追加されると、自動的にそのアカウントのイベントもログに含まれるため、追加の設定や管理作業が不要です。これは最も運用効率が高く、管理オーバーヘッドが最小限のソリューションです。
選択肢A（不正解）：
Lambda関数を使用した定期実行によるアプローチは、継続的な監視と実行が必要で運用負荷が高くなります。また、新しいアカウントの追加タイミングと定期実行のタイミングが合わない可能性があり、完全性に問題があります。
選択肢C（不正解）：
各アカウントに個別のトレイルを作成し、手動で新しいアカウントにトレイルを追加する方法は、運用負荷が非常に高くなります。SCPによる保護は良いアプローチですが、初期設定と継続的な管理の複雑さが問題となります。
選択肢D（不正解）：
Systems Manager Automationを使用する方法は技術的には可能ですが、組織トレイルの機能を活用せずに複雑なオートメーションを構築することになり、運用効率の観点で最適ではありません。
組織トレイルの機能を使用することで、AWS Organizationsの管理機能を最大限に活用し、単一の設定で組織全体のCloudTrail要件を満たすことができます。これにより、新しいアカウントの追加時の追加作業が不要となり、長期的な運用効率が大幅に向上します。
各アプリケーションは注文処理の異なる部分を担当する複数のコンポーネントで構成され、これらのコンポーネントはさまざまなソースからのデータを使用します。週に一度のETLジョブが実行され、各アプリケーションから分析データベースへデータをコピーしています。
ソリューションアーキテクトは、このアーキテクチャをサーバーレスサービスを使ったイベント駆動型のソリューションに再設計し、ほぼリアルタイムで更新される分析を提供しなければなりません。
どのソリューションがこれらの要件を満たすでしょうか？
A. 個々のアプリケーションをマイクロサービスとしてAmazon Elastic Container Service (Amazon ECS) のFargateを使ったコンテナに移行する。小売用MySQLデータベースはAmazon EC2上に維持し、分析データベースはAmazon Neptuneに移行する。すべての入力データをマイクロサービスと分析データベースに送るためにAmazon Simple Queue Service (Amazon SQS) を使用する。
B. 各アプリケーション用にAuto Scalingグループを作成し、各Auto Scalingグループに必要なEC2インスタンス数を指定する。小売用MySQLデータベースと分析データベースをAmazon Aurora MySQLに移行する。すべての入力データを適切なEC2インスタンスと分析データベースに送るためにAmazon Simple Notification Service (Amazon SNS) を使用する。
C. 個々のアプリケーションをマイクロサービスとしてAmazon Elastic Kubernetes Service (Amazon EKS) のFargateを使ったコンテナに移行する。小売用MySQLデータベースをAmazon Aurora Serverless MySQLに、分析データベースをAmazon Redshift Serverlessに移行する。すべての入力データをマイクロサービスと分析データベースに送るためにAmazon EventBridgeを使用する。
D. 個々のアプリケーションをマイクロサービスとしてAmazon AppStream 2.0に移行する。小売用MySQLデータベースをAmazon Aurora MySQLに、分析データベースをAmazon Redshift Serverlessに移行する。すべての入力データをマイクロサービスと分析データベースに送るためにAWS IoT Coreを使用する。
理由：要件はイベント駆動型でサーバーレスサービスを使い、ほぼリアルタイムで分析を更新することです。EKSのFargateはサーバーレスなコンテナ管理を可能にし、Aurora Serverless MySQLは小売用DBにスケーラブルでマネージドなMySQL互換サービスを提供します。Redshift Serverlessは分析向けにサーバーレスでスケール可能なデータウェアハウスです。EventBridgeはイベント駆動型アーキテクチャを実現するためのネイティブなイベントバスであり、ほぼリアルタイムでのイベント伝達が可能です。他の選択肢はEC2維持や非サーバーレスサービスを使っているため、要件に適しません。
同社の最新のフラッシュセール中に、API呼び出しの急増がアプリケーションのパフォーマンスに悪影響を与えました。ソリューションアーキテクトはその時のAmazon CloudWatchメトリクスを確認し、Lambda実行回数とデータベース接続の大幅な増加に気づきました。データベースインスタンスのCPU使用率も高くなっていました。
アプリケーションのパフォーマンスを最適化するために、ソリューションアーキテクトは何を推奨すべきでしょうか？
A. Lambda関数のメモリを増やします。データが取得されたときにデータベース接続を閉じるようにLambda関数を変更します。
B. RDSデータベースから頻繁にアクセスされるデータを保存するためにAmazon ElastiCache for Redisクラスターを追加します。
C. Lambdaコンソールを使用してRDSプロキシを作成します。プロキシエンドポイントを使用するようにLambda関数を変更します。
D. 関数のハンドラーの外側でデータベースに接続するようにLambda関数を変更します。新しい接続を作成する前に既存のデータベース接続を確認します。
解説
この問題は、Lambda関数からRDSへの大量の同時接続による性能問題の解決策について問われています。問題の核心は「Lambda実行回数とデータベース接続の大幅な増加」および「DBインスタンスの高いCPU使用率」です。
選択肢C（正解）：
RDS Proxyは、Lambda関数とRDSデータベース間の接続プールを管理するサービスです。多数のLambda関数実行による大量の同時データベース接続を効率的に管理し、接続プールを通じて実際のデータベース接続数を制限します。これにより、データベースの接続オーバーヘッドが削減され、CPU使用率の改善とスケーラビリティの向上を実現できます。フラッシュセールのような急激な負荷増加に対して最も効果的なソリューションです。
選択肢A（不正解）：
Lambda関数のメモリ増加は実行速度を向上させる可能性がありますが、データベース接続数の問題は解決されません。接続を適切に閉じることは良い習慣ですが、同時接続数の制限という根本的な問題は残ります。
選択肢B（不正解）：
ElastiCacheによるキャッシングは読み取り性能の向上には有効ですが、問題の主原因である大量の同時データベース接続は解決されません。また、キャッシュ戦略の実装には追加的な複雑さが伴います。
選択肢D（不正解）：
Lambda関数でグローバル変数を使用した接続の再利用は部分的に有効ですが、Lambda の実行モデル（コンテナの再利用）に依存するため、確実性に欠けます。また、大量の同時実行時には依然として多数の接続が作成される可能性があります。
RDS Proxyを使用することで、Lambda関数からの大量同時接続を効率的に管理し、データベースの負荷を軽減しながら、アプリケーションの可用性とパフォーマンスを大幅に改善できます。これは特にサーバーレスアーキテクチャでのデータベース接続管理において推奨されるベストプラクティスです。
データベースは自動バックアップが設定されており、RTOは15分、RPOは2時間です。WebアプリケーションはAmazon Route 53のレコードを使用してデータベースへのトラフィックをルーティングするように構成されています。
どの組み合わせのステップが、すべての要件を満たす高可用性アーキテクチャを実現するでしょうか？（2つ選択してください）
A. セカンダリリージョンにデータベースのクロスリージョンリードレプリカを作成する。フェイルオーバーイベント時にリードレプリカを昇格させるため、セカンダリリージョンでAWS Lambda関数を設定する。
B. プライマリリージョンで、障害が検出された場合にAWS Lambda関数を呼び出すデータベースのヘルスチェックを作成する。Lambda関数をプログラムして、セカンダリリージョンの最新のデータベーススナップショットからデータベースを再作成し、Route 53のホストレコードを更新する。
C. AWS Lambda関数を作成し、最新の自動バックアップを2時間ごとにセカンダリリージョンにコピーする。
D. Route 53でフェイルオーバールーティングポリシーを作成し、データベースのDNSレコードのプライマリおよびセカンダリエンドポイントをそれぞれのリージョンのエンドポイントに設定する。
E. セカンダリリージョンにホットスタンバイデータベースを作成する。プライマリデータベースが障害を起こした場合に、AWS Lambda関数を使用してセカンダリデータベースを最新のRDS自動バックアップから復元する。
理由：RTO 15分、RPO 2時間を満たすためには、クロスリージョンリードレプリカを利用し、障害時にすぐに昇格できる仕組みが必要です。Lambda関数でリードレプリカの昇格を自動化することで迅速なフェイルオーバーが可能です。Route 53のフェイルオーバールーティングを使うことで、DNSレコードを切り替え、アプリケーションのトラフィックをプライマリからセカンダリに即座にルーティングできます。他の選択肢は復旧時間が長くなったり運用負荷が高くなるため、要件を満たしません。
A. 中央ネットワーキングアカウントにGateway Load Balancerをデプロイします。AWS PrivateLinkを使用するエンドポイントサービスを設定します。
B. 中央ネットワーキングアカウントにNetwork Load Balancerをデプロイします。AWS PrivateLinkを使用するエンドポイントサービスを設定します。
C. Auto Scalingグループと、ファイアウォールアプライアンスを設定するためのユーザーデータとして新しいスクリプトを使用する起動テンプレートを作成します。インスタンスターゲットタイプを使用するターゲットグループを作成します。
D. Auto Scalingグループを作成します。ファイアウォールアプライアンスを設定するためのユーザーデータとして新しいスクリプトを使用するAWS Launch Wizardデプロイメントを設定します。IPターゲットタイプを使用するターゲットグループを作成します。
E. 各メンバーアカウントにVPCエンドポイントを作成します。VPCエンドポイントを指すようにルートテーブルを更新します。
F. 中央ネットワーキングアカウントにVPCエンドポイントを作成します。VPCエンドポイントを指すように各メンバーアカウントのルートテーブルを更新します。
解説
この問題は、中央集約型ファイアウォールアーキテクチャの近代化と自動化に関するものです。要件として水平スケーリング、高可用性、コスト効率性が求められています。
選択肢Aが正しい理由は、Gateway Load Balancer（GWLB）がファイアウォールのような仮想アプライアンスに特化して設計されているためです。GWLBはレイヤー3およびレイヤー4でトラフィックを処理し、ファイアウォールアプライアンスの前段に配置して負荷分散とスケーリングを提供します。AWS PrivateLinkを使用することで、複数のアカウント間でセキュアに接続できます。
選択肢Cが正しい理由は、Auto Scalingグループと起動テンプレートの組み合わせにより、需要に応じたファイアウォールインスタンスの自動スケーリングが可能になるためです。新しい設定スクリプトをユーザーデータとして使用することで、インスタンス起動時の自動設定が実現されます。インスタンスターゲットタイプを使用することで、EC2インスタンスを直接ターゲットとして指定できます。
選択肢Fが正しい理由は、中央ネットワーキングアカウントにVPCエンドポイントを作成し、各メンバーアカウントのルートテーブルを更新することで、すべてのトラフィックを中央のファイアウォールサービス経由でルーティングできるためです。これにより統一されたセキュリティポリシーの適用が可能になります。
選択肢Bが不適切な理由は、Network Load BalancerがGateway Load Balancerと比較してファイアウォールアプライアンスの用途には最適化されていないためです。選択肢Dは、AWS Launch Wizardが不要に複雑であり、IPターゲットタイプよりもインスタンスターゲットタイプの方が管理しやすいためです。選択肢Eは、各メンバーアカウントでVPCエンドポイントを個別に管理する必要があり、中央集約型アーキテクチャのメリットを活用できないためです。
最も運用効率が高く、要件を満たすソリューションはどれですか？
A. 支店のパブリックIPアドレスのリストでIPアクセスコントロールグループルールを作成し、そのIPアクセスコントロールグループをWorkSpacesディレクトリに関連付ける。
B. AWS Firewall Managerを使用して、支店のパブリックIPアドレスのリストを含むIPSetでWeb ACLルールを作成し、そのWeb ACLをWorkSpacesディレクトリに関連付ける。
C. AWS Certificate Manager (ACM)を使って支店に配備されたマシンに信頼されたデバイス証明書を発行し、WorkSpacesディレクトリで制限付きアクセスを有効にする。
D. Windowsファイアウォールで支店のパブリックIPアドレスへのアクセスを制限するように設定したカスタムWorkSpaceイメージを作成し、そのイメージを使ってWorkSpacesを展開する。
理由：WorkSpacesのIPアクセスコントロールグループを使用して支店のパブリックIPアドレスからのアクセスを制限する方法は、最もシンプルで運用管理が容易です。将来的に支店が増えた場合もIPリストを更新するだけで済み、管理効率が高いです。BのFirewall ManagerはWorkSpacesのアクセス制御には直接対応しておらず、CやDは証明書管理やカスタムイメージ作成など運用負荷が高くなります。
会社はDirect Connect接続を使用してトランジットVIF経由でVPCリソースに接続しなければなりません。
これらの要件を満たすための組み合わせの手順はどれですか？（2つ選択）
A. 1 GbpsのDirect Connect接続を10 Gbpsに更新する。
B. トランジットVIF経由でオンプレミスのネットワークプレフィックスを広告する。
C. Direct ConnectゲートウェイからオンプレミスネットワークへトランジットVIF経由でVPCプレフィックスを広告する。
D. Direct Connect接続のMACsec暗号化モード属性をmust_encryptに更新する。
E. Direct Connect接続にMACsec接続キー名/接続性関連キー（CKN/CAK）ペアを関連付ける。
理由：
トランジットVIFを介してオンプレミスとVPCリソースを接続するには、オンプレミスネットワークのプレフィックスをトランジットVIF上で広告し（B）、またDirect Connectゲートウェイからオンプレミスに向けてVPCのプレフィックスを広告する（C）必要があります。これにより双方向のルーティングが確立されます。Aは帯域幅の増強であり必須ではなく、DとEはMACsec暗号化の設定であり今回の要件には直接関係しません。
セキュリティエンジニアはAmazon Athenaを使って時折ログを分析していますが、ログの量が増加するにつれてクエリのパフォーマンスが低下しています。ソリューションアーキテクトはログ分析のパフォーマンスを改善し、VPCフローログが使用するストレージ容量を削減しなければなりません。
これらの要件を最も大きく満たす解決策はどれですか？
A. AWS Lambda関数を作成し、gzipファイルを解凍してbzip2圧縮で再圧縮する。Lambda関数をS3バケットのs3:ObjectCreated:Putイベント通知にサブスクライブする。
B. S3バケットに対してS3 Transfer Accelerationを有効にする。アップロードされたファイルをすぐにS3 Intelligent-Tieringストレージクラスに移動するライフサイクル設定を作成する。
C. VPCフローログの設定を更新し、Apache Parquet形式でファイルを保存する。ログファイルに対して時間単位のパーティションを指定する。
D. データ使用制限のない新しいAthenaワークグループを作成し、Athenaエンジンバージョン2を使用する。
理由：
Apache Parquet形式は列指向フォーマットで、クエリ性能を大幅に向上させ、かつストレージの効率化にも寄与します。また、時間単位のパーティションを設定することで、クエリ実行時に対象データを絞り込み、さらなる性能改善が可能です。Aは圧縮方式を変えるだけで大きな性能改善は期待できず、Bは転送速度やストレージ階層管理の話でクエリ性能の改善には直接関係しません。DはAthenaの設定変更ですが、データフォーマットの最適化ほどの性能向上は見込めません。
この要件を満たすために、ソリューションアーキテクトは何をすべきですか？
A. Amazon CloudFrontディストリビューションを作成し、各ALBをオリジンとするオリジングループを作成する。一方のオリジンをプライマリに設定する。
B. 各ALBに対してAmazon Route 53ヘルスチェックを作成する。2つのALBを指すRoute 53フェイルオーバールーティングレコードを作成し、「Evaluate Target Health」値を「Yes」に設定する。
C. 各ALBをオリジンとする2つのAmazon CloudFrontディストリビューションを作成する。2つのCloudFrontディストリビューションを指すRoute 53フェイルオーバールーティングレコードを作成し、「Evaluate Target Health」値を「Yes」に設定する。
D. 各ALBに対してAmazon Route 53ヘルスチェックを作成する。2つのALBを指すRoute 53レイテンシーエイリアスレコードを作成し、「Evaluate Target Health」値を「Yes」に設定する。
理由：
Route 53のレイテンシールーティングは、ユーザーに最も低レイテンシーで応答できるリージョンのALBを選択します。「Evaluate Target Health」を「Yes」に設定することで、Route 53はそのターゲットが正常であるかどうかを確認し、障害がある場合には自動的に別のリージョンにフェイルオーバーします。これにより、最も近いリージョンから取得するという要件と、フェイルオーバーの要件の両方を満たすことができます。
データセンター内の各VMでSimple Network Management Protocol（SNMP）が有効になっています。企業はデータセンターにVMを追加することができず、VM上に追加のソフトウェアをインストールすることもできません。検出データはAWS Migration Hubに自動的にインポートされる必要があります。
どのソリューションがこれらの要件を満たしますか？
A. AWS Application Migration Serviceエージェントレスサービスと AWS Migration Hub Strategy Recommendationsを使用してTCOレポートを生成する。
B. Windows Amazon EC2インスタンスを起動する。EC2インスタンス上にMigration Evaluatorエージェントレスコレクターをインストールする。TCOレポートを生成するようにMigration Evaluatorを設定する。
C. Windows Amazon EC2インスタンス上を起動する。EC2インスタンス上にMigration Evaluatorエージェントレスコレクターをインストールする。TCOレポートを生成するようにMigration Hubを設定する。
D. VPC内でAWS Migration Readiness Assessment toolを使用する。TCOレポートを生成するようにMigration Evaluatorを設定する。
選択肢Bが正しい理由は、Migration Evaluatorエージェントレスコレクターが最も適切なソリューションだからです。このコレクターはAWS上のWindows EC2インスタンス上で動作し、既存のSNMPプロトコルを使用してオンプレミスのVMからデータを収集できます。これにより、オンプレミスのVMに追加ソフトウェアをインストールする必要がありません。Migration EvaluatorはTCO分析に特化したサービスであり、収集したデータを基に詳細なコスト比較レポートを生成できます。また、Migration EvaluatorはMigration Hubと統合されており、検出データの自動インポートが可能です。
選択肢Aが不適切な理由は、AWS Application Migration Serviceが主に実際の移行作業に使用されるサービスであり、TCO分析には特化していないためです。また、Strategy Recommendationsは移行戦略の推奨を提供しますが、詳細なTCO計算には適していません。
選択肢Cが不適切な理由は、Migration Hubはデータの統合プラットフォームであり、TCOレポートを直接生成する機能を持たないためです。TCO分析にはMigration Evaluatorが必要です。
選択肢Dが不適切な理由は、AWS Migration Readiness Assessment toolが組織の移行準備状況を評価するツールであり、インフラストラクチャの検出やTCO計算を行うものではないためです。
このVPCにはトランジットゲートウェイがアタッチされています。
同社は新しい機能を開発中で、開発環境を作成しました。その環境では共有サービスアカウント内のアプリケーションへアクセスする必要があります。また、開発アカウント内のリソースを頻繁に削除・再作成する予定です。さらに、開発チームが必要に応じて共有サービスアカウントへの接続を再作成できるようにしたいと考えています。
これらの要件を満たすソリューションはどれですか？
A. 開発アカウントにトランジットゲートウェイを作成する。共有サービスアカウントに対してトランジットゲートウェイのピアリングリクエストを作成する。共有サービスのトランジットゲートウェイを自動的にピアリングを受け入れるよう構成する。
B. 共有サービスアカウントのトランジットゲートウェイで自動受け入れを有効にする。AWS Resource Access Manager（AWS RAM）を使用して、共有サービスアカウントのトランジットゲートウェイリソースを開発アカウントと共有する。開発アカウントでリソースを受け入れる。開発アカウント内でトランジットゲートウェイアタッチメントを作成する。
C. 共有サービスアカウントのトランジットゲートウェイで自動受け入れを有効にする。VPCエンドポイントを作成する。エンドポイントポリシーを使用して、開発アカウントへのアクセス権を付与する。エンドポイントサービスを接続リクエストを自動的に受け入れるよう構成する。エンドポイントの詳細を開発チームに提供する。
D. Amazon EventBridgeルールを作成して、開発アカウントがアタッチメントリクエストを行った際にAWS Lambda関数を呼び出してトランジットゲートウェイアタッチメントを受け入れるようにする。AWS Network Managerを使用して、共有サービスアカウントのトランジットゲートウェイを開発アカウントと共有する。開発アカウントでトランジットゲートウェイを受け入れる。
理由：
AWS Resource Access Manager（RAM）を使用して、共有サービスアカウントのトランジットゲートウェイを開発アカウントと共有することで、開発アカウントのチームは自分たちでトランジットゲートウェイへのアタッチメントを作成できるようになります。さらに、自動受け入れを有効にすることで、頻繁な再作成作業にも柔軟に対応できます。これは最も運用効率が高く、セキュアな方法です。
最小の運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？
A. すべてのAWSアカウントに適用されるSCPを作成し、管理者ロールのみにIAMアクションを許可する。SCPをルートOUに適用する。
B. IAMアクションに関連する各イベントに対してAWS Lambda関数を呼び出すようにAWS CloudTrailを設定する。アクションを呼び出したユーザーが管理者でない場合にアクションを拒否するように関数を設定する。
C. すべてのAWSアカウントに適用されるSCPを作成し、管理者ロールを持つユーザーを除くすべてのユーザーのIAMアクションを拒否する。SCPをルートOUに適用する。
D. IAMアクションを許可するIAMアクセス許可境界を設定する。すべてのAWSアカウントのすべての管理者ロールにアクセス許可境界をアタッチする。
解説
この問題は、AWS Organizations環境でIAMアクションの制御を集中管理する方法に関するものです。重要なポイントは、ソリューションアーキテクトがすべてのAWSアカウントにアクセス権を持たないということです。
選択肢Cが正しい理由は、Service Control Policy（SCP）を使用してルートOUレベルで制御を行うことで、組織全体に一括してポリシーを適用できるためです。SCPは拒否ベースのポリシーとして機能し、管理者ロール以外のすべてのユーザーに対してIAMアクションを明示的に拒否します。これにより、個別のアカウントにアクセスすることなく、組織レベルで統一的な制御が可能になります。また、運用オーバーヘッドが最小限に抑えられます。
選択肢Aが不適切な理由は、SCPの動作原理にあります。SCPは本質的に拒否ベースのセキュリティ境界であり、明示的な許可よりも拒否に重点を置いています。管理者ロールに対してのみ許可を与える設計よりも、非管理者に対して拒否を設定する方が効果的です。
選択肢Bが不適切な理由は、CloudTrailとLambdaを使用したリアクティブなアプローチが運用オーバーヘッドを大幅に増加させるためです。また、この方法では事後対応となり、実際のIAMアクションが実行された後に制御するため、プロアクティブな防止策としては不適切です。
選択肢Dが不適切な理由は、IAMアクセス許可境界を全アカウントの全管理者ロールに個別にアタッチする必要があり、ソリューションアーキテクトがすべてのアカウントにアクセス権を持たないという制約に反するためです。また、管理作業が分散化され、運用オーバーヘッドが大幅に増加します。
ある企業が、単一のAWSリージョンで実行されている重要なアプリケーションの災害復旧を実装する必要があります。アプリケーションのユーザーは、Application Load Balancer（ALB）の背後にあるAmazon EC2インスタンス上でホストされているWebフロントエンドとやり取りします。アプリケーションはAmazon RDS for MySQL DBインスタンスに書き込みます。アプリケーションはまた、Amazon S3バケットに保存される処理済みドキュメントを出力します。
企業の財務チームは、レポートを実行するためにデータベースに直接クエリを実行します。繁忙期間中、これらのクエリがリソースを消費し、アプリケーションのパフォーマンスに悪影響を与えます。
ソリューションアーキテクトは、災害時に回復力を提供するソリューションを設計する必要があります。ソリューションはデータ損失を最小限に抑え、財務チームのクエリによって生じるパフォーマンス問題を解決する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. データベースをAmazon DynamoDBに移行し、DynamoDBグローバルテーブルを使用する。財務チームに別のリージョンのグローバルテーブルに対してクエリを実行するよう指示する。元のS3バケットの内容を別のリージョンの新しいS3バケットに定期的に同期するAWS Lambda関数を作成する。別のリージョンでEC2インスタンスを起動し、ALBを作成する。新しいS3バケットを指すようにアプリケーションを設定する。
B. 別のリージョンでアプリケーションをホストする追加のEC2インスタンスを起動する。追加のインスタンスを既存のALBに追加する。別のリージョンで、RDS DBインスタンスのリードレプリカを作成する。財務チームにリードレプリカに対してクエリを実行するよう指示する。元のS3バケットから別のリージョンの新しいS3バケットにS3クロスリージョンレプリケーション（CRR）を使用する。災害時に、リードレプリカをスタンドアロンDBインスタンスに昇格させる。新しいS3バケットと新しく昇格したリードレプリカを指すようにアプリケーションを設定する。
C. 別のリージョンでRDS DBインスタンスのリードレプリカを作成する。財務チームにリードレプリカに対してクエリを実行するよう指示する。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成する。AMIを別のリージョンにコピーする。元のS3バケットから別のリージョンの新しいS3バケットにS3クロスリージョンレプリケーション（CRR）を使用する。災害時に、リードレプリカをスタンドアロンDBインスタンスに昇格させる。AMIからEC2インスタンスを起動し、エンドユーザーにアプリケーションを提示するALBを作成する。新しいS3バケットを指すようにアプリケーションを設定する。
D. RDS DBインスタンスの1時間ごとのスナップショットを作成する。スナップショットを別のリージョンにコピーする。既存のRDSデータベースの前にAmazon ElastiCacheクラスターを追加する。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成する。AMIを別のリージョンにコピーする。元のS3バケットから別のリージョンの新しいS3バケットにS3クロスリージョンレプリケーション（CRR）を使用する。災害時に、最新のRDSスナップショットからデータベースを復元する。AMIからEC2インスタンスを起動し、エンドユーザーにアプリケーションを提示するALBを作成する。新しいS3バケットを指すようにアプリケーションを設定する。
解説
この問題は、災害復旧とパフォーマンス問題の両方を解決する必要があります。主要な要件は、データ損失の最小化、災害時の回復力の確保、および財務チームのクエリによるパフォーマンス問題の解決です。
選択肢Cが正しい理由は、すべての要件を効果的に満たしているためです。まず、別のリージョンにRDSリードレプリカを作成することで、リアルタイムでデータが同期され、データ損失を最小限に抑えられます。財務チームがリードレプリカに対してクエリを実行することで、本番データベースへの負荷を軽減し、パフォーマンス問題を解決できます。EC2インスタンスのAMIを作成して別のリージョンにコピーすることで、災害時に迅速にアプリケーションを復旧できます。S3 CRRにより、処理済みドキュメントも自動的に別のリージョンに複製されます。災害時には、リードレプリカを昇格させることで、数分でデータベースサービスを復旧できます。
選択肢Aが不適切な理由は、既存のMySQLデータベースをDynamoDBに移行することが大規模な変更を伴い、アプリケーションの大幅な修正が必要になるためです。また、Lambda関数による定期同期は効率的ではありません。
選択肢Bが不適切な理由は、別のリージョンのEC2インスタンスを既存のALBに追加することができないためです。ALBはリージョン固有のサービスであり、異なるリージョンのインスタンスを対象にできません。
選択肢Dが不適切な理由は、1時間ごとのスナップショットでは最大1時間のデータ損失が発生する可能性があり、リアルタイムのリードレプリカと比較してRTO（目標復旧時間）とRPO（目標復旧時点）が劣るためです。また、ElastiCacheの追加は財務チームのクエリ問題を根本的に解決しません。
会社の財務チームはレポート作成のために直接データベースをクエリしますが、繁忙期にはこれらのクエリがリソースを消費し、アプリケーションのパフォーマンスに悪影響を及ぼしています。
ソリューションアーキテクトは、災害時のレジリエンシーを提供し、データ損失を最小限に抑え、財務チームのクエリによるパフォーマンス問題を解決するソリューションを設計する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. データベースをAmazon DynamoDBに移行し、DynamoDBグローバルテーブルを使用する。財務チームには別のリージョンにあるグローバルテーブルをクエリさせる。AWS Lambda関数を作成して元のS3バケットの内容を定期的に別のリージョンの新しいS3バケットに同期する。別のリージョンにEC2インスタンスとALBを起動し、アプリケーションを新しいS3バケットを参照するように構成する。
B. 別のリージョンにアプリケーションをホストする追加のEC2インスタンスを起動し、それらを既存のALBに追加する。別のリージョンにRDSのリードレプリカを作成し、財務チームにはリードレプリカに対してクエリを実行させる。元のS3バケットから別のリージョンの新しいS3バケットへS3クロスリージョンレプリケーション（CRR）を使用する。災害時にはリードレプリカをスタンドアロンDBインスタンスに昇格させる。アプリケーションを新しいS3バケットおよび昇格後のDBに向けて構成する。
C. 別のリージョンにRDSのリードレプリカを作成し、財務チームにはリードレプリカに対してクエリを実行させる。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、別のリージョンにコピーする。元のS3バケットから別のリージョンの新しいS3バケットへS3クロスリージョンレプリケーション（CRR）を使用する。災害時にはリードレプリカをスタンドアロンDBインスタンスに昇格させる。AMIからEC2インスタンスを起動し、ALBを作成してアプリケーションをエンドユーザーに提供する。アプリケーションを新しいS3バケットに向けて構成する。
D. RDS DBインスタンスのスナップショットを毎時作成し、別のリージョンにコピーする。既存のRDSデータベースの前にAmazon ElastiCacheクラスターを追加する。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、別のリージョンにコピーする。元のS3バケットから別のリージョンの新しいS3バケットへS3クロスリージョンレプリケーション（CRR）を使用する。災害時には最新のRDSスナップショットからデータベースを復元する。AMIからEC2インスタンスを起動し、ALBを作成してアプリケーションをエンドユーザーに提供する。アプリケーションを新しいS3バケットに向けて構成する。
解説
本問では「ディザスタリカバリのレジリエンシー確保」「データ損失の最小化」「財務チームのクエリによるパフォーマンス問題の解決」が求められています。
選択肢Cは、別リージョンにRDSリードレプリカを作成し財務チームのクエリをそちらに振り分けることで、本番DBの負荷を軽減しパフォーマンス問題を解決しています。リードレプリカは災害時にスタンドアロンDBへ昇格可能で、データ損失を最小限に抑えられます。アプリケーション用のEC2インスタンスをAMIとして別リージョンに複製し、災害時に迅速に復旧可能です。S3のクロスリージョンレプリケーションによりドキュメントも確実に別リージョンに同期されます。
AはDynamoDBへの大規模な移行を伴い現実的でなく、BはALBのリージョン間共有ができないため誤り、Dはスナップショット復元が災害復旧として遅く、ElastiCacheはクエリの読み取り負荷軽減には有効ですが災害時のレジリエンシーとは直接関係ありません。
CMSはファイルシステムとして永続的なNFS互換ストレージを必要とします。AWS上の新しいソリューションは、予測できないトラフィックの増加に応じて2台のAmazon EC2インスタンスから30台までスケールできる必要があります。また、新しいソリューションはウェブサイトに変更を加える必要がなく、データ損失を防ぐ必要があります。
この要件を満たすソリューションはどれですか？
A. Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。CMSをApplication Load BalancerおよびAuto Scalingグループを使用してAWS Elastic Beanstalkにデプロイする。.ebextensionsを使用してEFSファイルシステムをEC2インスタンスにマウントする。Elastic Beanstalk環境とは別にAmazon Aurora MySQLデータベースを作成する。
B. Amazon Elastic Block Store（Amazon EBS）Multi-Attachボリュームを作成する。CMSをNetwork Load BalancerおよびAuto Scalingグループを使用してAWS Elastic Beanstalkにデプロイする。.ebextensionsを使用してEBSボリュームをEC2インスタンスにマウントする。Elastic Beanstalk環境内にAmazon RDS for MySQLデータベースを作成する。
C. Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。起動テンプレートとAuto Scalingグループを作成して、CMSをサポートするEC2インスタンスを起動する。Network Load Balancerを作成してトラフィックを分散する。Amazon Aurora MySQLデータベースを作成する。EC2 Auto Scalingのスケールインライフサイクルフックを使用して、EFSファイルシステムをEC2インスタンスにマウントする。
D. Amazon Elastic Block Store（Amazon EBS）Multi-Attachボリュームを作成する。起動テンプレートとAuto Scalingグループを作成して、CMSをサポートするEC2インスタンスを起動する。Application Load Balancerを作成してトラフィックを分散する。MySQLデータベースをサポートするためにAmazon ElastiCache for Redisクラスターを作成する。EC2のユーザーデータを使用してEBSボリュームをEC2インスタンスにアタッチする。
理由：
Amazon EFSはNFS互換であり、複数のEC2インスタンスから同時アクセス可能な共有ストレージを提供するため、CMSの要件を満たします。また、Elastic Beanstalkを使用することでスケーラブルなデプロイが可能であり、自動スケーリングに対応します。.ebextensionsでEFSのマウントも自動化できます。Aurora MySQLは高可用性とスケーラビリティを備えた適切なRDBMSソリューションです。変更なしでの移行とデータ損失防止という条件も満たします。
別のシステムが不定期にSQSキューにURLを追加します。インスタンスは各URLのクローリングを10秒以内で完了します。
メトリクスによると、SQSキューにURLが存在しない場合、一部のインスタンスがアイドル状態になっていることがわかっています。ソリューションアーキテクトはコスト最適化のためにアーキテクチャを再設計する必要があります。
この要件を最もコスト効率よく満たす手順の組み合わせはどれですか？（2つ選択）
A. Webクローリング処理にt2.microインスタンスの代わりにm5.8xlargeインスタンスを使用する。フリート内のインスタンス数を50%削減する。
B. Webクローリング処理をAWS Lambda関数に変換する。Lambda関数を構成してSQSキューからURLを取得する。
C. Webクローリング処理を修正して、結果をAmazon Neptuneに保存する。
D. Webクローリング処理を修正して、結果をAmazon Aurora Serverless MySQLインスタンスに保存する。
E. Webクローリング処理を修正して、結果をAmazon S3に保存する。
理由：
B: Lambdaはイベントドリブンで、使用された時間分のみ課金されるため、URLが不定期にキューに追加されるような低頻度のワークロードに最適です。アイドル状態のEC2インスタンスにかかるコストを排除できます。
E: Amazon S3はスケーラブルで高耐久なオブジェクトストレージであり、.csvファイルのような構造化データをコスト効率よく保存できます。EFSのようなファイルシステムよりも、クローリング結果のストレージとしてコスト効果が高いです。
企業のセキュリティチームは、パイプラインで長期間有効なシークレットキーを使用できなくなるという新しい要件を実装しています。ソリューションアーキテクトは、シークレットキーを短期間有効なソリューションに置き換える必要があります。
最小の運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？
A. AWS Identity and Access Management（IAM）でIAM SAML 2.0アイデンティティプロバイダー（IdP）を作成する。sts:AssumeRole API呼び出しを許可する適切な信頼ポリシーを持つ新しいIAMロールを作成する。既存のIAMポリシーを新しいIAMロールにアタッチする。パイプライン用にSAML認証を使用するようにGitHubを更新する。
B. AWS Identity and Access Management（IAM）でIAM OpenID Connect（OIDC）アイデンティティプロバイダー（IdP）を作成する。GitHub OIDC IdPからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する適切な信頼ポリシーを持つ新しいIAMロールを作成する。パイプライン用にロールを引き受けるようにGitHubを更新する。
C. Amazon Cognitoアイデンティティプールを作成する。GitHubを使用するように認証プロバイダーを設定する。GitHub認証プロバイダーからのsts:AssumeRoleWithWebIdentity API呼び出しを許可する適切な信頼ポリシーを持つ新しいIAMロールを作成する。認証プロバイダーとしてCognitoを使用するようにパイプラインを設定する。
D. AWS Private Certificate Authorityに信頼アンカーを作成する。AWS IAM Roles Anywhereで使用するクライアント証明書を生成する。sts:AssumeRole API呼び出しを許可する適切な信頼ポリシーを持つ新しいIAMロールを作成する。既存のIAMポリシーを新しいIAMロールにアタッチする。クレデンシャルヘルパーツールを使用し、新しいIAMロールを引き受けるためにクライアント証明書の公開キーを参照するようにパイプラインを設定する。
解説
この問題は、GitHub ActionsからAWSリソースへの認証方法を、長期間有効なシークレットキーから短期間有効なソリューションに移行することに関するものです。
選択肢Bが正しい理由は、GitHub ActionsがOpenID Connect（OIDC）プロバイダーとしてネイティブにサポートされており、最も簡単で運用オーバーヘッドが少ないソリューションだからです。GitHub ActionsはOIDCトークンを自動的に生成し、このトークンを使用してAWS IAMロールを一時的に引き受けることができます。IAM OIDC IdPを作成し、適切な信頼ポリシーを設定することで、GitHub ActionsワークフローはAPI呼び出し時に短期間有効なクレデンシャルを取得できます。このアプローチは追加のサービスや複雑な設定を必要とせず、GitHubが提供する標準的な機能を活用します。
選択肢Aが不適切な理由は、GitHub ActionはSAML 2.0プロバイダーとしてネイティブにサポートされておらず、SAML認証を実装するために追加の設定と複雑さが必要になるためです。また、GitHub自体がSAMLプロバイダーとして動作するための設定が困難です。
選択肢Cが不適切な理由は、Amazon Cognitoアイデンティティプールが不必要な中間レイヤーを追加し、運用オーバーヘッドを増加させるためです。GitHub ActionsはOIDCを直接サポートしているため、Cognitoを経由する必要がありません。
選択肢Dが不適切な理由は、AWS Private Certificate AuthorityとIAM Roles Anywhereを使用するアプローチが過度に複雑であり、証明書の管理という追加の運用負担を伴うためです。また、CI/CDパイプラインのような自動化された環境では、証明書ベースの認証よりもOIDCトークンベースの認証の方が適しています。
新しいライセンススキーマの一環として、同社はクライアントごとに、日次・週次・月次でのユニークユーザー数を把握する必要があります。
アプリケーションへの変更を最小限に抑えつつ、この情報を取得する方法はどれですか？
A. Amazon CloudWatch Logs のメトリクスフィルターを設定して、各成功したログインをメトリクスとして保存する。ユーザー名とクライアント名をメトリクスのディメンションとして設定する。
B. アプリケーションのロジックを変更して、各成功したログイン時にAWS SDKを使って、ユーザー名とクライアント名をディメンションとするカスタムメトリクスをCloudWatchに送信するようにする。
C. CloudWatch エージェントを構成して、ログから成功したログインのメトリクスを抽出する。さらに、CloudWatch エージェントがユーザー名とクライアント名をディメンションとするカスタムメトリクスとして保存するように設定する。
D. AWS Lambda 関数を設定して、アプリケーションログの Amazon CloudWatch Logs ストリームを処理するようにする。さらに、Lambda 関数でユーザー名とクライアント名をディメンションとする CloudWatch のカスタムメトリクスをインクリメントするようにする。
理由：アプリケーションに最小限の変更で済む方法が求められており、すでにログがCloudWatch Logsに送られていることから、Lambdaを使ってログストリームを処理することで、ログインイベントを検出してメトリクスに変換できます。CloudWatch Logsストリームをリアルタイムに処理して、必要なカスタムメトリクスを生成できるため、アプリケーションのコードを変更せずに要件を満たせます。
企業はオンプレミスでMicrosoft Hyper-V環境を持ち、利用可能なコンピュート容量があります。企業はストレージ容量がなく、AWSに画像をアーカイブしたいと考えています。企業はリクエストから1週間以内にアーカイブされたデータを取得する能力が必要です。
企業はオンプレミスデータセンターとAWS間に10GbpsのAWS Direct Connect接続を持っています。企業は帯域幅制限を設定し、営業時間外にアーカイブされた画像をAWSにコピーするようスケジュールする必要があります。
どのソリューションが最もコスト効率よくこれらの要件を満たしますか？
A. 新しいGPUベースのAmazon EC2インスタンス上にAWS DataSyncエージェントをデプロイする。DataSyncエージェントを設定して、オンプレミスNFSサーバーからAmazon S3 Glacier Instant Retrievalへファイルのバッチをコピーする。コピーが成功した後、オンプレミスストレージからデータを削除する。
B. オンプレミスのHyper-V VM上にAWS DataSyncエージェントをデプロイする。DataSyncエージェントを設定して、オンプレミスNFSサーバーからAmazon S3 Glacier Deep Archiveへファイルのバッチをコピーする。コピーが成功した後、オンプレミスストレージからデータを削除する。
C. 新しい汎用Amazon EC2インスタンス上にAWS DataSyncエージェントをデプロイする。DataSyncエージェントを設定して、オンプレミスNFSサーバーからAmazon S3 Standardへファイルのバッチをコピーする。コピーが成功した後、オンプレミスストレージからデータを削除する。1日後にオブジェクトをS3 StandardからS3 Glacier Deep Archiveに移行するS3ライフサイクルルールを作成する。
D. Hyper-V環境のオンプレミスにAWS Storage Gateway Tape Gatewayをデプロイする。Tape GatewayをAWSに接続する。自動テープ作成を使用する。Amazon S3 Glacier Deep Archiveプールを指定する。画像のバッチがコピーされた後、テープを取り出す。
解説
この問題は、大量の画像データを最もコスト効率よくAWSにアーカイブする方法に関するものです。重要な要件として、1週間以内の取得可能性、帯域幅制限とスケジュール設定、コスト効率性があります。
選択肢Bが正しい理由は、複数の要件を最適に満たしているためです。まず、AWS DataSyncエージェントをオンプレミスのHyper-V VM上にデプロイすることで、既存のコンピュート容量を活用し、追加のEC2インスタンスコストを回避できます。DataSyncは帯域幅制限とスケジュール機能を提供するため、営業時間外の転送要件を満たします。S3 Glacier Deep Archiveは最も低コストなアーカイブストレージクラスであり、1週間以内の取得要件（標準取得で12時間以内）を満たします。長期アーカイブという用途に最適です。
選択肢Aが不適切な理由は、GPU基盤のEC2インスタンスが不要であり、コストが高くなるためです。また、S3 Glacier Instant RetrievalはGlacier Deep Archiveよりもコストが高く、長期アーカイブには適していません。
選択肢Cが不適切な理由は、新しいEC2インスタンスの追加コストが発生し、S3 Standardへの初期保存によって不要なストレージコストが発生するためです。ライフサイクル移行による一時的な追加料金も発生します。
選択肢Dが不適切な理由は、Storage Gateway Tape Gatewayが物理テープライブラリをエミュレートするサービスであり、この用途には過度に複雑で不適切だからです。また、テープベースのワークフローは管理が複雑で、NFSからの直接転送と比較して運用オーバーヘッドが高くなります。
各ジョブは、S3 バケットに保存されているデータ 15～20 GB を処理する必要があります。企業はジョブの出力を別の Amazon S3 バケットに保存し、その後の分析に使用します。
この要件を最もコスト効率よく満たすソリューションはどれですか？
A. サーバーレスのデータパイプラインを作成する。オーケストレーションには AWS Step Functions を使用し、データ処理にはプロビジョンドキャパシティを持つ AWS Lambda 関数を使用する。
B. Amazon EC2 スポットインスタンスを含む AWS Batch コンピューティング環境を作成する。SPOT_CAPACITY_OPTIMIZED アロケーション戦略を指定する。
C. Amazon EC2 オンデマンドインスタンスとスポットインスタンスを含む AWS Batch コンピューティング環境を作成する。スポットインスタンスには SPOT_CAPACITY_OPTIMIZED アロケーション戦略を指定する。
D. Amazon Elastic Kubernetes Service（Amazon EKS）を使用して処理ジョブを実行する。Amazon EC2 オンデマンドインスタンスとスポットインスタンスの組み合わせを含むマネージドノードグループを使用する。
理由：
ジョブは中断に耐えられる処理であり、結果の即時性も求められていません。このようなワークロードには Amazon EC2 スポットインスタンス を利用することで、大幅にコストを削減できます。AWS Batch はバッチ処理に最適化されており、SPOT_CAPACITY_OPTIMIZED アロケーション戦略を用いることで、インスタンスの中断を最小限に抑えることができます。
他の選択肢（A、C、D）はそれぞれ有効な方法ですが、コスト効率の面では B が最も適している と言えます。特に Lambda は 15〜20 GB のデータ処理には適しておらず、EKS は運用コストと管理の負担が大きくなります。
企業は、移行時間を最小限に抑え、アプリケーションコードに変更を加えず、インフラストラクチャの管理も行いたくないと考えています。
この要件を満たすソリューションはどれですか？
A. アプリケーションをリファクタリングして、AWS Toolkit for .NET Refactoring を使用してコンテナ化する。Amazon Elastic Container Service（Amazon ECS）の Fargate 起動タイプを使用して、コンテナ化されたアプリケーションをホストする。
B. Windows Web Application Migration Assistant を使用して、アプリケーションを AWS Elastic Beanstalk に移行する。Elastic Beanstalk を使用してアプリケーションをデプロイおよび管理する。
C. Windows Web Application Migration Assistant を使用して、アプリケーションを Amazon EC2 インスタンスに移行する。EC2 インスタンスを使用してアプリケーションをデプロイおよび管理する。
D. アプリケーションをリファクタリングして、AWS Toolkit for .NET Refactoring を使用してコンテナ化する。Amazon Elastic Kubernetes Service（Amazon EKS）の Fargate 起動タイプを使用して、コンテナ化されたアプリケーションをホストする。
理由：
要件では「アプリケーションコードに変更を加えず」「インフラストラクチャの管理をしたくない」「移行時間を最小化したい」と述べられています。
Elastic Beanstalk は、アプリケーションコードをそのままデプロイでき、インフラ管理を自動化してくれるPaaS型サービスです。Windows Web Application Migration Assistant は .NET Framework アプリケーションを Beanstalk に容易に移行できるツールで、要件に最も適合します。
他の選択肢（A, C, D）は、コードのリファクタリングやインフラ管理が必要となるため、要件に合致しません。
どのソリューションがこれらの要件を満たしますか？
A. IAMユーザーがS3バケットでアクションを実行する際にMFAコードの入力を求めるポリシーをS3バケットにアタッチする。AWS CLIでIAMアクセスキーを使用してAmazon S3を呼び出す。
B. プリンシパルがグループを引き受ける際にMFAの使用を要求するようにS3-accessグループの信頼ポリシーを更新する。AWS CLIでIAMアクセスキーを使用してAmazon S3を呼び出す。
C. MFAが存在しない場合にすべてのS3アクションを拒否するポリシーをS3-accessグループにアタッチする。AWS CLIでIAMアクセスキーを使用してAmazon S3を呼び出す。
D. MFAが存在しない場合にすべてのS3アクションを拒否するポリシーをS3-accessグループにアタッチする。AWS Security Token Service（AWS STS）から一時的なクレデンシャルをリクエストする。ユーザーがAmazon S3でアクションを実行する際にAmazon S3が参照するプロファイルに一時的なクレデンシャルをアタッチする。
解説
この問題は、AWS CLIを使用してS3にアクセスする際にMFA認証を強制する方法に関するものです。重要なポイントは、長期間有効なIAMアクセスキーではMFA情報を含めることができないということです。
選択肢Dが正しい理由は、MFA認証を適切に実装する唯一の方法だからです。まず、S3-accessグループにMFAが存在しない場合にすべてのS3アクションを拒否するポリシーをアタッチします。これにより、MFA認証なしでのS3アクセスを防止できます。次に、AWS STSから一時的なクレデンシャルをリクエストします。STSのGetSessionToken APIを使用してMFAトークンと共に認証することで、MFA情報を含む一時的なクレデンシャルを取得できます。これらの一時的なクレデンシャルをAWS CLIプロファイルで使用することで、MFA認証が完了した状態でS3操作を実行できます。
選択肢Aが不適切な理由は、S3バケットポリシーではMFAコードの入力を直接促すことができないためです。また、IAMアクセスキーにはMFA情報が含まれないため、この方法では要件を満たせません。
選択肢Bが不適切な理由は、IAMグループには信頼ポリシーが存在しないためです。信頼ポリシーはIAMロールに適用されるものであり、IAMグループには適用されません。
選択肢Cが不適切な理由は、長期間有効なIAMアクセスキーにはMFA情報が含まれないためです。MFAを要求するポリシーを適用しても、通常のIAMアクセスキーを使用してはMFA認証を実現できません。MFA認証を行うには、STSから取得した一時的なクレデンシャルが必要です。
A. 新しいIAMロールを作成する。新しいバックアッププランを作成する。新しいIAMロールを使用してバックアップを作成する。新しいIAMロールがキーを使用できるようにKMSキーポリシーを更新する。ファイルシステムの1時間ごとのバックアップスケジュールを実装する。
B. 新しいバックアッププランを作成する。AWSServiceRoleForBackup IAMロールがキーを使用できるようにKMSキーポリシーを更新する。30分ごとにファイルシステムのバックアップを実行するカスタムcron式を実装する。
C. 新しいIAMロールを作成する。既存のバックアッププランを使用する。新しいIAMロールがキーを使用できるようにKMSキーポリシーを更新する。ポイントインタイム復旧のための継続的バックアップを有効にする。
D. 既存のバックアッププランを使用する。AWSServiceRoleForBackup IAMロールがキーを使用できるようにKMSキーポリシーを更新する。ファイルシステムのクロスリージョンレプリケーションを有効にする。
解説:
この問題の要点は100分のRPO（Recovery Point Objective）要件を満たすことです。デフォルトのAWS Backupプランは通常1日1回の実行であり、これでは100分のRPO要件を満たすことができません。
選択肢Cと選択肢Dは既存のデフォルトバックアッププランを使用するため、1日1回のバックアップ頻度では100分のRPO要件を満たせません。また、選択肢CのAmazon EFSにおける継続的バックアップ（ポイントインタイム復旧）は利用できない機能です。
選択肢BはAWS Backupで30分間隔のカスタムcron式を提案していますが、AWS Backupの最小バックアップ間隔は1時間であり、30分間隔でのバックアップは標準機能では実現できません。このような高頻度バックアップにはEventBridgeとLambda関数を使用したカスタムソリューションが必要になります。
選択肢Aは新しいバックアッププランを作成し、1時間ごとのバックアップスケジュールを実装します。60分間隔は100分のRPO要件を満たし、AWS Backupで実現可能な現実的なソリューションです。新しいIAMロールの作成により適切な権限管理が可能で、暗号化されたEFSファイルシステムにアクセスするためのKMSキーポリシー更新も含まれています。
近代化後、ユーザーは最大4GBの動画ファイルをアプリケーションにアップロードできるようになります。他のユーザーはアプリケーションから動画ファイルをダウンロードできる必要があります。企業には迅速なスケーリングを提供する動画ストレージソリューションが必要です。このソリューションはアプリケーションのパフォーマンスに影響を与えてはいけません。
どのソリューションがこれらの要件を満たしますか？
A. AWS Database Migration Service（AWS DMS）を使用してデータベースをAmazon Aurora PostgreSQLに移行する。動画をデータベースのTEXTカラムにbase64エンコードされた文字列として保存する。
B. AWS Database Migration Service（AWS DMS）とAWS Schema Conversion Tool（AWS SCT）を使用してデータベースをAmazon DynamoDBに移行する。動画をAmazon S3にオブジェクトとして保存し、S3キーを対応するDynamoDBアイテムに保存する。
C. AWS Database Migration Service（AWS DMS）とAWS Schema Conversion Tool（AWS SCT）を使用してデータベースをAmazon Keyspaces（for Apache Cassandra）に移行する。動画をAmazon S3にオブジェクトとして保存し、S3オブジェクト識別子を対応するAmazon Keyspacesエントリに保存する。
D. AWS Database Migration Service（AWS DMS）とAWS Schema Conversion Tool（AWS SCT）を使用してデータベースをAmazon DynamoDBに移行する。動画を対応するDynamoDBアイテムにbase64エンコードされた文字列として保存する。
解説
この問題では、最大4GBの動画ファイルを扱うアプリケーションの近代化において、迅速なスケーリングとパフォーマンスに影響を与えないソリューションを選択する必要があります。
各選択肢を分析すると：
選択肢A（Aurora PostgreSQL + base64エンコード）は、4GBの動画ファイルをbase64エンコードするとサイズが約33%増加し、データベースに大きな負荷をかけます。これはパフォーマンスに大きく影響し、要件に適しません。
選択肢B（DynamoDB + S3）は、動画ファイルを専用のオブジェクトストレージであるAmazon S3に保存し、そのS3キーをDynamoDBに保存します。S3は大容量ファイルに最適化されており、自動スケーリング機能があります。DynamoDBも高いパフォーマンスと自動スケーリングを提供します。
選択肢C（Keyspaces + S3）は技術的には可能ですが、単純なユーザープロファイルデータの保存にはCassandraベースのKeyspacesは過度に複雑です。DynamoDBの方がこの用途に適しています。
選択肢D（DynamoDB + base64エンコード）は、DynamoDBの400KBのアイテムサイズ制限により、4GBの動画ファイルを保存することが物理的に不可能です。
したがって、選択肢Bが最適な解決策です。S3は大容量ファイルのストレージとスケーリングに特化しており、DynamoDBはメタデータの高速アクセスを提供します。この組み合わせにより、アプリケーションのパフォーマンスを維持しながら迅速なスケーリングを実現できます。
企業は、ソリューションが高可用性、耐障害性、セキュアであることを確保するために、既存のネットワーク接続ソリューションを更新する必要があります。
どのソリューションが最もコスト効率的にこれらの要件を満たしますか？
A. 動的プライベートIPのAWS Site-to-Site VPNをセカンダリパスとして追加し、転送中のデータを保護し、Direct Connect接続に対する復旧力を提供する。MACsecを設定してDirect Connect接続内のトラフィックを暗号化する。
B. 企業のオンプレミスデータセンターとAWSの間に別のDirect Connect接続をプロビジョニングして、転送速度を向上させ、復旧力を提供する。MACsecを設定してDirect Connect接続内のトラフィックを暗号化する。
C. 複数のプライベートVIFを設定する。オンプレミスデータセンターとAWSの間でVIF間でデータをロードバランスして復旧力を提供する。
D. 静的AWS Site-to-Site VPNをセカンダリパスとして追加し、転送中のデータを保護し、Direct Connect接続に対する復旧力を提供する。
解説
この問題では、既存のDirect Connect接続に対して高可用性、耐障害性、セキュリティを提供する最もコスト効率的なソリューションを選択する必要があります。
各選択肢を分析すると：
選択肢A（動的プライベートIP VPN + MACsec）は、動的プライベートIPを使用するVPNは追加の複雑さとコストを伴います。MACsecは暗号化を提供しますが、追加のハードウェアとライセンスコストが必要です。
選択肢B（追加のDirect Connect + MACsec）は、2つ目のDirect Connect接続は月額料金、ポート料金、クロスコネクト料金など高額な継続コストが発生します。さらにMACsecの追加コストもあり、最もコスト効率的ではありません。
選択肢C（複数のプライベートVIF）は、単一のDirect Connect接続内の複数VIFでは、物理的な接続障害時にすべてのVIFが影響を受けるため、真の冗長性を提供しません。
選択肢D（静的Site-to-Site VPN）は、Site-to-Site VPNは比較的安価で、Direct Connect接続に障害が発生した場合のバックアップパスとして機能します。静的VPNは動的VPNよりもシンプルで設定が容易です。VPNはインターネット経由で暗号化された接続を提供し、セキュリティ要件も満たします。
Direct Connect + VPNの組み合わせは、AWSが推奨する高可用性パターンです。通常時はDirect Connectを使用し、障害時にはVPNにフェイルオーバーします。この構成により、コストを抑えながら必要な冗長性とセキュリティを確保できます。
-------------