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 ボリュームに更新する。チケットサービスを新しいローカルソースに向けるように改修する。
現状の課題は、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（動的スケーリング + ウォームプール + ライフサイクルフック）が最も要件に適した構成です。
-------------