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
Lambda関数がNeptune DBクラスターとDynamoDBテーブルにアクセスできるようにする可能なソリューションはどれですか？（2つ選択してください。）
A. Neptune VPCに3つのパブリックサブネットを作成し、インターネットゲートウェイ経由でトラフィックをルーティングする。3つの新しいパブリックサブネットでLambda関数をホストする。
B. Neptune VPCに3つのプライベートサブネットを作成し、NATゲートウェイ経由でインターネットトラフィックをルーティングする。3つの新しいプライベートサブネットでLambda関数をホストする。
C. Lambda関数をVPC外でホストする。Lambda関数のIPレンジからのアクセスを許可するようにNeptuneセキュリティグループを更新する。
D. Lambda関数をVPC外でホストする。Neptuneデータベース用のVPCエンドポイントを作成し、Lambda関数がVPCエンドポイント経由でNeptuneにアクセスできるようにする。
E. Neptune VPCに3つのプライベートサブネットを作成する。3つの新しい分離されたサブネットでLambda関数をホストする。DynamoDB用のVPCエンドポイントを作成し、DynamoDBトラフィックをVPCエンドポイントにルーティングする。
解説
この問題は、Lambda関数がVPC内のNeptuneとVPC外のDynamoDBの両方にアクセスする必要がある複合的なネットワーク構成に関する問題です。
選択肢Bが正解である理由：
Lambda関数をVPC内のプライベートサブネットに配置することで、同じVPC内のNeptuneに直接アクセスできます。NATゲートウェイを使用することで、プライベートサブネット内のLambda関数がインターネット経由でDynamoDBにアクセスできます。この構成では、Neptuneへの内部アクセスとDynamoDBへの外部アクセスの両方が実現されます。
選択肢Eが正解である理由：
Lambda関数をプライベートサブネットに配置してNeptuneにアクセスし、DynamoDB用のVPCエンドポイントを作成することで、インターネットを経由せずにDynamoDBにアクセスできます。VPCエンドポイントを使用することで、セキュリティが向上し、レイテンシも削減されます。この構成は、両方のサービスへの安全で効率的なアクセスを提供します。
他の選択肢が不適切な理由：
選択肢A：パブリックサブネットにLambda関数を配置することは、セキュリティ上のベストプラクティスではありません。また、パブリックIPを持つLambda関数は推奨されません。
選択肢C：Lambda関数のIPアドレスは動的に変更されるため、セキュリティグループで固定的にIPレンジを許可することは実用的ではありません。
選択肢D：NeptuneはVPCエンドポイントをサポートしていません。Neptuneにアクセスするには、Lambda関数がVPC内に配置される必要があります。
ソリューションアーキテクトは、セキュリティ要件を満たすコンテナ化されたアーキテクチャを作成し、Amazon ECSクラスターにアプリケーションをデプロイしました。
要件を満たすために、デプロイメント後に必要なステップはどれですか？（2つ選択してください。）
A. ブリッジネットワークモードを使用してタスクを作成する。
B. awsvpcネットワークモードを使用してタスクを作成する。
C. Amazon EC2インスタンスにセキュリティグループを適用し、他のリソースにアクセスするためにEC2インスタンス用のIAMロールを使用する。
D. タスクにセキュリティグループを適用し、他のリソースにアクセスするために起動時にコンテナにIAM認証情報を渡す。
E. タスクにセキュリティグループを適用し、他のリソースにアクセスするためにタスク用のIAMロールを使用する。
解説 この問題は、Amazon ECSにおけるコンテナのネットワーキングとセキュリティ設定に関するベストプラクティスを問う問題です。 選択肢Bが正解である理由： awsvpcネットワークモードは、各ECSタスクに独自のElastic Network Interface（ENI）を提供し、VPC内で専用のプライベートIPアドレスを割り当てます。これにより、タスクレベルでのネットワーク分離が実現され、セキュリティグループをタスクに直接適用できます。最小権限の原則に従って、各タスクに必要最小限のネットワークアクセス権限のみを付与することが可能になります。 選択肢Eが正解である理由： IAMロールforタスクは、各ECSタスクに個別のIAMロールを割り当てる機能で、最小権限の原則を実現するためのベストプラクティスです。各タスクが必要とするAWSリソースへのアクセス権限のみを付与でき、タスク間での権限の分離が可能になります。この方法により、セキュリティが向上し、コンテナ内にIAM認証情報をハードコーディングする必要がなくなります。 他の選択肢が不適切な理由： 選択肢A：ブリッジネットワークモードでは、タスクレベルでのセキュリティグループの適用ができず、細かいネットワーク制御が困難です。また、ポートマッピングが必要になり、セキュリティ上の制約があります。 選択肢C：EC2インスタンスレベルでのIAMロールは、そのインスタンス上で実行されるすべてのタスクが同じ権限を持つことになり、最小権限の原則に反します。 選択肢D：コンテナ起動時にIAM認証情報を渡すことは、セキュリティ上のリスクがあり、認証情報の管理が困難になります。また、認証情報のローテーションも複雑になります。
A. AWS Client VPNエンドポイントを設定および構成する。Client VPNエンドポイントをVPC内のサブネットに関連付ける。Client VPNセルフサービスポータルを設定する。開発者にClient VPN用のクライアントを使用して接続するよう指示する。
B. トランジットゲートウェイを作成し、VPCに接続する。AWS Site-to-Site VPNを作成する。トランジットゲートウェイへのアタッチメントを作成する。開発者にOpenVPNクライアントを使用して接続するよう指示する。
C. トランジットゲートウェイを作成し、VPCに接続する。AWS Direct Connect接続を注文する。Direct Connect接続にパブリックVIFを設定する。パブリックVIFをトランジットゲートウェイに関連付ける。開発者にDirect Connect接続に接続するよう指示する。
D. VPCのパブリックサブネットに踏み台ホストを作成および設定する。踏み台ホストのセキュリティグループを企業のCIDR範囲からのSSHアクセスを許可するよう設定する。開発者にSSHを使用して接続するよう指示する。
解説:
この問題では、VPC内のOpenSearch Serviceクラスターに対して、在宅勤務者と複数のオフィス拠点にいる開発者からのアクセスを提供する必要があります。各選択肢を詳しく分析します。
選択肢A（正解）: AWS Client VPNは、リモートユーザーがVPCリソースに安全にアクセスするための理想的なソリューションです。Client VPNは各開発者の個人デバイスからの接続を可能にし、在宅勤務者と複数のオフィス拠点の両方のシナリオに対応できます。セルフサービスポータルにより、開発者は自分でVPN設定をダウンロードして接続を管理できます。
選択肢B: Site-to-Site VPNは主にサイト間接続（オフィス拠点とAWS間）用に設計されています。在宅勤務者の個人デバイスからのアクセスには適していません。また、OpenVPNクライアントの指示は不正確です。
選択肢C: Direct Connectは高帯域幅が必要な本番環境向けの物理接続サービスです。開発者の個人アクセス用途には過剰であり、コストが高く、複数の個人デバイスからのアクセスには不適切です。
選択肢D: 踏み台ホストは一つの解決策ですが、各開発者がSSH経由でアクセスしてからOpenSearch Serviceに接続する必要があり、直接的なアクセスを提供しません。また、OpenSearch Serviceの分析・可視化ツールを使用するには追加の複雑な設定が必要になります。
AWS Client VPNは個人デバイスからVPCリソースへの直接的で安全なアクセスを提供し、在宅勤務者と複数オフィス拠点の開発者両方のニーズを満たす最適なソリューションです。
A. モバイルソフトウェアから直接Amazon S3にファイルをアップロードする。S3イベント通知を使用してAmazon MQキューにメッセージを作成する。
B. モバイルソフトウェアから直接Amazon S3にファイルをアップロードする。S3イベント通知を使用してAmazon Simple Queue Service（Amazon SQS）標準キューにメッセージを作成する。
C. キューでメッセージが利用可能になった時にAWS Lambda関数を呼び出して画像処理を実行する。
D. キューでメッセージが利用可能になった時にS3 Batch Operations ジョブを呼び出して画像処理を実行する。
E. 処理が完了した時にAmazon Simple Notification Service（Amazon SNS）を使用してモバイルアプリにプッシュ通知を送信する。
F. 処理が完了した時にAmazon Simple Email Service（Amazon SES）を使用してモバイルアプリにプッシュ通知を送信する。
解説:
この問題では、高いトラフィック負荷に対応できるスケーラブルな画像処理システムの設計が求められています。各選択肢を詳しく分析します。
選択肢B（正解）: Amazon SQSは高度にスケーラブルで、1分間に数千のメッセージを処理できます。S3イベント通知との統合により、新しいファイルがアップロードされるたびに自動的にキューにメッセージが作成されます。SQSは完全マネージドサービスで、負荷に応じて自動的にスケールします。
選択肢C（正解）: AWS Lambdaは自動スケーリング機能を持ち、SQSキューからのメッセージに基づいて同時実行数を調整します。画像処理のような短時間のタスクに適しており、使用した分だけの課金となるため、使用パターンが不規則な場合に最適です。
選択肢E（正解）: Amazon SNSはモバイルアプリへのプッシュ通知に対応しており、iOS、Android、その他のプラットフォームに通知を送信できます。Lambda関数から直接SNSを呼び出して処理完了を通知することができます。
不正解の選択肢:
選択肢A: Amazon MQはメッセージブローカーサービスですが、SQSと比較してスケーラビリティが劣り、この規模の負荷には適していません。また、設定と管理がより複雑です。
選択肢D: S3 Batch Operationsはバッチ処理用のサービスで、リアルタイムの画像処理には適していません。また、個別のファイルアップロードに対する即座の処理には不向きです。
選択肢F: Amazon SESは電子メール送信サービスで、モバイルアプリへのプッシュ通知には適していません。リアルタイム通知が必要な場合、メールは適切な通知方法ではありません。
この組み合わせ（B、C、E）により、S3へのファイルアップロード、SQSによるメッセージキューイング、Lambdaによる自動スケーリング処理、SNSによるプッシュ通知という完全なサーバーレスアーキテクチャが構築され、負荷の変動に柔軟に対応できます。
A. DynamoDB Accelerator（DAX）をインメモリキャッシュとしてセットアップする。アプリケーションをDAXを使用するように更新する。EC2インスタンス用のAuto Scalingグループを作成する。Application Load Balancer（ALB）を作成する。Auto ScalingグループをALBのターゲットとして設定する。Route 53レコードをALBのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用するように更新する。コンテンツ更新前にEC2インスタンスのスケジュールスケーリングを設定する。
B. Amazon ElastiCache for Redisをセットアップする。アプリケーションをElastiCacheを使用するように更新する。EC2インスタンス用のAuto Scalingグループを作成する。Amazon CloudFrontディストリビューションを作成し、Auto Scalingグループをディストリビューションのオリジンとして設定する。Route 53レコードをCloudFrontディストリビューションのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用するように更新する。コンテンツ更新前に手動でEC2インスタンスをスケールアップする。
C. Amazon ElastiCache for Memcachedをセットアップする。アプリケーションをElastiCacheを使用するように更新する。EC2インスタンス用のAuto Scalingグループを作成する。Application Load Balancer（ALB）を作成する。Auto ScalingグループをALBのターゲットとして設定する。Route 53レコードをALBのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用するように更新する。コンテンツ更新前にアプリケーションのスケジュールスケーリングを設定する。
D. DynamoDB Accelerator（DAX）をインメモリキャッシュとしてセットアップする。アプリケーションをDAXを使用するように更新する。EC2インスタンス用のAuto Scalingグループを作成する。Amazon CloudFrontディストリビューションを作成し、Auto Scalingグループをディストリビューションのオリジンとして設定する。Route 53レコードをCloudFrontディストリビューションのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用するように更新する。コンテンツ更新前に手動でEC2インスタンスをスケールアップする。
解説:
この問題では、旅行情報検索アプリケーションの高可用性とスケーラビリティの向上が求められています。各選択肢を詳しく分析します。
選択肢A（正解）: この選択肢が最適な理由は以下の通りです。DAXはDynamoDBに特化したインメモリキャッシュで、既存のDynamoDB使用アプリケーションに最適です。Auto Scalingグループにより需要に応じてEC2インスタンス数を調整でき、ALBが複数インスタンス間で負荷を分散します。スケジュールスケーリングにより、コンテンツ更新という予測可能な負荷増加に事前に対応できます。これにより手動介入が不要になり、運用効率が向上します。
選択肢B: ElastiCache for RedisはRedisから移行しやすい選択肢ですが、CloudFrontは静的なWebコンテンツの配信に適しており、動的な検索アプリケーションには必ずしも最適ではありません。また、手動スケーリングは自動化されていないため運用負荷が高くなります。
选择肢C: ElastiCache for MemcachedはシンプルなキャッシュソリューションですがRedisと比較して機能が限定的です。ALBの使用は適切ですが、「アプリケーションのスケジュールスケーリング」という表現が曖昧で、実際にはEC2インスタンスのスケーリングを指すべきです。
選択肢D: DAXの使用は適切ですが、CloudFrontが動的アプリケーションに必ずしも最適ではなく、手動スケーリングは自動化の観点から劣ります。
技術的なポイント:
DAXはDynamoDBの読み取り性能を大幅に向上させ、マイクロ秒レベルのレスポンスタイムを実現します。Auto Scalingグループとスケジュールスケーリングの組み合わせにより、予測可能な負荷パターンに対して自動的に準備できます。ALBはヘルスチェック機能により障害インスタンスを自動的に除外し、高可用性を確保します。この構成により、年4回のコンテンツ更新時の負荷増加に対して自動的に対応でき、ダウンタイムを防止できます。
この企業は、AWS Serverless Application Model（AWS SAM）を使用してソリューションをデプロイした。ソリューションは複数のアベイラビリティーゾーンにまたがっているが、災害復旧（DR）プランは存在しない。
ソリューションアーキテクトは、別のAWSリージョンでこのソリューションを復旧できるようにするDR戦略を設計しなければならない。ソリューションにはRTO（目標復旧時間）5分、RPO（目標復旧時点）1分の要件がある。
この要件を満たすには、ソリューションアーキテクトは何をすべきか？
A. Aurora Serverless v1データベースのリードレプリカを対象リージョンに作成する。AWS SAMを使用して、対象リージョンにソリューションをデプロイするためのランブックを作成する。災害発生時にはリードレプリカをプライマリに昇格させる。
B. Aurora Serverless v1データベースを、ソースリージョンと対象リージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。AWS SAMを使用して、対象リージョンにソリューションをデプロイするためのランブックを作成する。
C. 複数のライターインスタンスを持つAurora Serverless v1 DBクラスタを対象リージョンに作成する。対象リージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で動作させるように構成する。
D. Aurora Serverless v1データベースを、ソースリージョンと対象リージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。対象リージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で動作させるように構成する。
RTOが5分、RPOが1分という厳しい要件があるため、高速なフェイルオーバーとデータレプリケーションが必要です。
Aurora Serverless v1 はクロスリージョンのレプリケーションやグローバルデータベースをサポートしていないため、Aurora Global Database（スタンダードAurora MySQL）に変更する必要があります。
D は、事前にソリューションを対象リージョンに起動しておき、アクティブ-パッシブ構成をとるため、災害時の即時切り替えが可能であり、RTO/RPO要件を満たします。
B はグローバルDBに変更する点では正しいですが、対象リージョンでの起動が事前にされていないため、RTOに不安が残ります。
A のAurora Serverless v1はクロスリージョンレプリカ非対応、C はAurora Serverlessにライターを複数持たせることができないため、いずれも不適です。
A. Amazon S3バケットにアタッチされたAWS Storage Gatewayファイルゲートウェイ NFSファイル共有をプロビジョニングする。クラスター内の各EC2インスタンスにNFSファイル共有をマウントする。
B. General Purposeパフォーマンスモードを使用する新しいAmazon Elastic File System（Amazon EFS）ファイルシステムをプロビジョニングする。クラスター内の各EC2インスタンスにEFSファイルシステムをマウントする。
C. io2ボリュームタイプを使用する新しいAmazon Elastic Block Store（Amazon EBS）ボリュームをプロビジョニングする。EBSボリュームをクラスター内のすべてのEC2インスタンスにアタッチする。
D. Max I/Oパフォーマンスモードを使用する新しいAmazon Elastic File System（Amazon EFS）ファイルシステムをプロビジョニングする。クラスター内の各EC2インスタンスにEFSファイルシステムをマウントする。
解説:
この問題では、ビッグデータ分析クラスター用のストレージソリューションの選択が求められています。要件として高可用性、耐障害性、POSIX互換性、高スループットが必要です。各選択肢を詳しく分析します。
選択肢D（正解）: Amazon EFS Max I/Oパフォーマンスモードが最適な理由は以下の通りです。EFSは完全マネージドのNFSファイルシステムで、複数のアベイラビリティゾーンにまたがって自動的にレプリケーションされ、高可用性と耐障害性を提供します。POSIX準拠のファイルシステムインターフェースを提供し、複数のEC2インスタンスから同時にマウントできます。Max I/Oモードは、より高いレベルの集約スループットとオペレーション/秒を実現できるため、ビッグデータ分析のような高スループットが必要なワークロードに最適です。
不正解の選択肢:
選択肢A: AWS Storage Gatewayファイルゲートウェイは、オンプレミス環境とS3の間のブリッジとして設計されています。ビッグデータ分析に必要な高スループットには適しておらず、レイテンシも高くなる可能性があります。また、Storage Gatewayは単一障害点となる可能性があります。
選択肢B: EFS General Purposeモードも要件を満たしますが、Max I/Oモードと比較してスループット性能が劣ります。ビッグデータ分析では高いスループットが重要な要素であるため、Max I/Oモードの方が適しています。
選択肢C: EBSボリュームは単一のEC2インスタンスにのみアタッチできるブロックストレージです。複数のインスタンスから同時にアクセスすることはできないため、クラスター環境での共有ストレージとしては使用できません。また、EBS Multi-Attachは限定的な使用ケースでのみ利用可能で、ファイルシステムレベルでの共有はサポートしていません。
技術的なポイント:
EFS Max I/Oモードは、数千の同時接続クライアントをサポートし、10 GB/s以上のスループットを実現できます。General Purposeモードと比較して若干のレイテンシ増加がありますが、ビッグデータ分析ワークロードでは一般的にスループットがレイテンシよりも重要です。EFSは自動的にストレージ容量を調整し、使用した分だけの課金となるため、ビッグデータワークロードの変動する要求に柔軟に対応できます。
A. データベースバックアップを実行する。バックアップファイルをAWS Snowball Edge Storage Optimizedデバイスにコピーする。バックアップをAmazon S3にインポートする。保存時の暗号化にはAmazon S3管理暗号化キー（SSE-S3）によるサーバーサイド暗号化を使用する。転送中の暗号化にはTLSを使用する。Amazon S3からDBインスタンスにデータをインポートする。
B. AWS Database Migration Service（AWS DMS）を使用してデータをAWSに移行する。プライベートサブネットにDMSレプリケーションインスタンスを作成する。AWS DMS用のVPCエンドポイントを作成する。フルロードと変更データキャプチャ（CDC）を使用してオンプレミスデータベースからDBインスタンスにデータをコピーするDMSタスクを設定する。保存時の暗号化にはAWS Key Management Service（AWS KMS）のデフォルトキーを使用する。転送中の暗号化にはTLSを使用する。
C. データベースバックアップを実行する。AWS DataSyncを使用してバックアップファイルをAmazon S3に転送する。保存時の暗号化にはAmazon S3管理暗号化キー（SSE-S3）によるサーバーサイド暗号化を使用する。転送中の暗号化にはTLSを使用する。Amazon S3からDBインスタンスにデータをインポートする。
D. Amazon S3 File Gatewayを使用する。AWS PrivateLinkを使用してAmazon S3へのプライベート接続を設定する。データベースバックアップを実行する。バックアップファイルをAmazon S3にコピーする。保存時の暗号化にはAmazon S3管理暗号化キー（SSE-S3）によるサーバーサイド暗号化を使用する。転送中の暗号化にはTLSを使用する。Amazon S3からDBインスタンスにデータをインポートする。
解説:
この問題では、機密データを含む5TBのMySQLデータベースを最小ダウンタイムでAWSに移行する必要があります。要件として、インターネット経由の転送禁止、転送中および保存時の暗号化、継続的なデータ更新への対応が求められています。各選択肢を詳しく分析します。
選択肢B（正解）: AWS DMSが最適な理由は以下の通りです。DMSはデータベース移行に特化したサービスで、フルロード＋CDCによりダウンタイムを最小限に抑えられます。初期のフルロードで全データを移行し、その後CDCで継続的に変更を同期するため、カットオーバー時のダウンタイムは数分程度に短縮できます。プライベートサブネットとVPCエンドポイントの使用により、トラフィックは完全にAWSネットワーク内に留まり、インターネットを経由しません。Direct Connect経由でプライベート接続が確立され、転送中はTLS暗号化、保存時はKMS暗号化が適用されます。
不正解の選択肢:
選択肢A: Snowball Edgeは物理デバイスの配送が必要で、5TBのデータに対しては過剰な手段です。また、バックアップからの復元には長時間を要し、その間のデータ変更は失われるため、ダウンタイムが長くなります。新しいデータが常に更新される環境には適していません。
選択肢C: DataSyncはファイル転送サービスですが、データベースの継続的な変更を同期する機能はありません。バックアップファイルの転送と復元の間に発生した変更は失われ、ダウンタイムが長くなります。また、DataSyncは主にファイルシステム間の同期に使用されるため、データベース移行には最適ではありません。
選択肢D: S3 File Gatewayを使用する方法も継続的な変更同期ができないため、ダウンタイムが長くなります。PrivateLinkの使用は適切ですが、データベース移行の観点では効率的ではありません。
技術的なポイント:
AWS DMSのCDC機能は、ソースデータベースのトランザクションログを読み取り、リアルタイムで変更をレプリケートします。これにより、移行中もアプリケーションは通常通り動作でき、カットオーバー時には最新の変更のみを同期すれば完了します。1Gbps Direct Connect接続があれば、5TBの初期ロードも数時間で完了し、全体的な移行時間を大幅に短縮できます。VPCエンドポイントによりDMSサービスへの通信もプライベート接続となり、セキュリティ要件を満たします。
APIトラフィックの分析により、クライアントが短時間に同じクエリに対して複数のHTTP GETリクエストを送っていることが判明した。トラフィックは営業時間中に集中し、祝日やイベント時にピークを迎える。
この企業は、追加の利用に対応する能力を向上させつつ、ソリューションに関連するコストの増加を最小限に抑えたいと考えている。
この要件を満たす戦略はどれか？
A. API GatewayのRegionalエンドポイントをエッジ最適化エンドポイントに変換し、本番ステージでキャッシュを有効にする。
B. Amazon ElastiCache for Redisキャッシュを実装し、データベース呼び出しの結果を保存する。Lambda関数を修正してキャッシュを使用するようにする。
C. Aurora Serverless DBクラスタの構成を変更して、利用可能な最大メモリを増やす。
D. API Gatewayの本番ステージでスロットリングを有効にし、レートおよびバースト値を設定して受信呼び出しを制限する。
問題の根本原因は「同じクエリに対して短期間に多数のGETリクエストが送られ、DBに負荷が集中していること」によるデータベースのメモリエラーです。
B のように ElastiCache（Redis）を導入して、頻繁にアクセスされるクエリ結果をキャッシュすることで、Lambda関数はDBではなくキャッシュからレスポンスを返せるようになります。これによりDBへの負荷を大幅に削減でき、コストの増加も抑えつつスケーラビリティを改善できます。
A のAPI GatewayのキャッシュはGETメソッドに限定的に有効ですが、TTLの柔軟性や制御が限定され、Redisの方がスケーラブルで高性能です。
C はAurora Serverlessのスケールを広げる対処療法ですが、アクセスパターンの根本的改善にはなりません。コストも比例して増えます。
D のスロットリングはリクエスト制限により負荷を下げる対策ですが、ユーザー体験を損なう可能性があり、スケーラビリティの向上にはなりません。
A. finance1@example.comに送信された初期AWS Organizationsメールからの64文字のパスワードを使用して、AWSアカウントルートユーザー認証情報でAWS Management Consoleにサインインする。必要に応じてIAMユーザーを設定する。
B. 管理アカウントから、新しいメンバーアカウントのアカウントIDでOrganizationAccountAccessRoleロールを引き受けるようにロールを切り替える。必要に応じてIAMユーザーを設定する。
C. AWS Management Consoleのサインインページに移動する。「ルートアカウント認証情報を使用してサインイン」を選択する。メールアドレスfinance1@example.comと管理アカウントのルートパスワードを使用してサインインする。必要に応じてIAMユーザーを設定する。
D. AWS Management Consoleのサインインページに移動する。新しいメンバーアカウントのアカウントIDとSupport1 IAM認証情報を使用してサインインする。必要に応じてIAMユーザーを設定する。
解説:
この問題では、AWS Organizationsで作成された新しいメンバーアカウントでIAMユーザーを作成する適切な方法が問われています。各選択肢を詳しく分析します。
選択肢B（正解）: AWS Organizationsで作成されたメンバーアカウントには、自動的にOrganizationAccountAccessRoleという管理ロールが作成されます。このロールは管理アカウントからのアクセスを許可し、メンバーアカウントでの管理タスクを実行するためのフルアクセス権限を持っています。管理アカウントから新しいメンバーアカウントのOrganizationAccountAccessRoleを引き受けることで、セキュアかつ効率的にメンバーアカウントにアクセスし、IAMユーザーを作成できます。これがAWS Organizationsの標準的なベストプラクティスです。
不正解の選択肢:
選択肢A: AWS Organizationsで作成されたアカウントには、初期の64文字のランダムパスワードが設定されますが、この方法はセキュリティ上推奨されません。ルートユーザーアクセスは最小限に抑える必要があり、日常的な管理タスクには使用すべきではありません。また、ルートユーザーのパスワードリセットプロセスを経る必要があります。
選択肢C: 管理アカウントのルートパスワードは新しいメンバーアカウントでは使用できません。各AWSアカウントは独立した認証システムを持っており、異なるアカウント間でパスワードを共有することはできません。この方法は技術的に不可能です。
選択肢D: IAMユーザーSupport1は管理アカウントに属しており、新しいメンバーアカウントに直接サインインすることはできません。アカウントIDを指定しても、そのアカウントにSupport1ユーザーは存在しないため、認証に失敗します。
技術的なポイント:
OrganizationAccountAccessRoleは、信頼関係により管理アカウントのエンティティ（IAMユーザーやロール）がメンバーアカウントでこのロールを引き受けることを許可します。このロールを使用することで、管理アカウントから複数のメンバーアカウントを効率的に管理でき、セキュリティベストプラクティスに従った運用が可能になります。ロールの切り替えは、AWS Management Console、AWS CLI、またはAWS SDKを通じて実行できます。この方法により、各メンバーアカウントでルートユーザーアクセスを有効にする必要がなくなり、セキュリティリスクを最小限に抑えることができます。
A. Amazon Aurora DBクラスターをデプロイし、5分ごとにクラスターのスナップショットを取得する。スナップショットが完了したら、障害時のバックアップとして機能させるため、スナップショットをセカンダリリージョンにコピーする。
B. セカンダリリージョンにクロスリージョンリードレプリカを持つAmazon RDSインスタンスをデプロイする。障害時には、リードレプリカを昇格させてプライマリにする。
C. プライマリリージョンにAmazon Aurora DBクラスターを、セカンダリリージョンに別のクラスターをデプロイする。AWS DMSを使用してセカンダリリージョンを同期状態に保つ。
D. 同一リージョン内にリードレプリカを持つAmazon RDSインスタンスをデプロイする。障害時には、リードレプリカを昇格させてプライマリにする。
解説:
この問題では、RPO 5分、RTO 10分という厳しい要件を満たしつつ、セカンダリリージョンへのフェイルオーバー能力を最低コストで実現する必要があります。各選択肢を詳しく分析します。
選択肢B（正解）: Amazon RDSのクロスリージョンリードレプリカが最適な理由は以下の通りです。リードレプリカは自動的にソースデータベースからの変更を非同期で複製し、通常数分以内にデータが同期されるため、RPO 5分の要件を満たします。リードレプリカの昇格は数分で完了するため、RTO 10分の要件も満たします。クロスリージョンリードレプリカにより、セカンダリリージョンでの災害復旧が可能になります。コスト面では、リードレプリカのインスタンス料金とデータ転送料金のみが発生し、他の選択肢と比較して最も経済的です。
不正解の選択肢:
選択肢A: スナップショットベースのアプローチには複数の問題があります。10TBのデータのスナップショット作成と跨リージョンコピーには相当な時間がかかり、RTO 10分の要件を満たすことは困難です。また、5分間隔でのスナップショット作成は頻繁すぎて、データベースのパフォーマンスに影響を与える可能性があります。さらに、頻繁なスナップショット作成とクロスリージョンコピーによるコストが高くなります。
選択肢C: AWS DMSを使用した継続的レプリケーションは技術的に可能ですが、コストが高く複雑になります。2つの独立したAuroraクラスターを維持する必要があり、DMSレプリケーションインスタンスの追加コストも発生します。また、DMSの設定と管理が複雑で、運用負荷が高くなります。
選択肢D: 同一リージョン内のリードレプリカは、セカンダリリージョンへのフェイルオーバーという要件を満たしません。リージョン全体の障害に対する保護を提供できないため、災害復旧の観点から不適切です。
技術的なポイント:
Amazon RDSクロスリージョンリードレプリカは、AWS独自のログシッピング技術を使用して効率的にデータを複製します。10TBのデータベースでも、変更分のみが転送されるため、ネットワーク帯域幅とコストを最適化できます。リードレプリカの昇格は自動化されており、AWS CLIやコンソールから簡単に実行できます。昇格後は、アプリケーションの接続文字列を変更するだけで、新しいプライマリデータベースに接続できます。この方法により、RPOとRTOの要件を満たしながら、コストと運用の複雑さを最小限に抑えることができます。
A. DRリージョンに宛先Amazon S3バケットを作成する。Amazon FSx File Gatewayを使用して、プライマリリージョンのFSx for Windows File ServerファイルシステムとDRリージョンのS3バケット間の接続を確立する。FSx File GatewayでS3バケットを継続的バックアップソースとして設定する。
B. DRリージョンにFSx for Windows File Serverファイルシステムを作成する。AWS Site-to-Site VPNを使用して、プライマリリージョンのVPCとDRリージョンのVPC間の接続を確立する。AWS DataSyncをVPNエンドポイントを使用して通信するように設定する。
C. DRリージョンにFSx for Windows File Serverファイルシステムを作成する。VPCピアリングを使用して、プライマリリージョンのVPCとDRリージョンのVPC間の接続を確立する。AWS DataSyncをAWS PrivateLinkを使用したインターフェイスVPCエンドポイントを使用して通信するように設定する。
D. DRリージョンにFSx for Windows File Serverファイルシステムを作成する。各リージョンでAWS Transit Gatewayを使用して、プライマリリージョンのVPCとDRリージョンのVPC間の接続を確立する。プライベートAWSバックボーンネットワーク経由でプライマリリージョンのFSx for Windows File ServerファイルシステムとDRリージョンのFSx for Windows File Serverファイルシステム間でファイルをコピーするためにAWS Transfer Familyを使用する。
解説:
この問題では、機密データをパブリックインターネットを経由せずに災害復旧用にクロスリージョンでコピーする適切なソリューションが求められています。各選択肢を詳しく分析します。
選択肢C（正解）: VPCピアリングとAWS DataSyncの組み合わせが最適な理由は以下の通りです。VPCピアリングにより、プライマリとDRリージョン間のプライベート接続が確立され、データがパブリックインターネットを経由しません。AWS DataSyncは、FSx for Windows File Server間のデータ同期に特化したマネージドサービスで、効率的な差分同期とデータ整合性チェックを提供します。インターフェイスVPCエンドポイントとAWS PrivateLinkの使用により、DataSyncの通信も完全にプライベートネットワーク内で行われます。これにより、セキュリティ要件を満たしながら、AWSマネージドサービスを最大限活用できます。
不正解の選択肢:
選択肢A: Amazon FSx File Gatewayという製品は存在しません。AWS Storage Gatewayには複数のタイプがありますが、FSx for Windows File Serverと直接統合するFile Gatewayは提供されていません。また、継続的バックアップソースとしてS3バケットを設定するという概念も不正確です。
選択肢B: Site-to-Site VPNは技術的に可能ですが、VPCピアリングと比較して複雑で、管理オーバーヘッドが高くなります。また、VPNエンドポイントという表現が曖昧で、DataSyncとの統合についても明確ではありません。VPCピアリングの方がシンプルで効率的なソリューションです。
選択肢D: AWS Transit Gatewayは大規模なネットワーク接続に適していますが、2つのリージョン間の単純な接続には過剰です。AWS Transfer FamilyはFTP/SFTP/FTPS用のマネージドファイル転送サービスで、FSx間の直接同期には適していません。また、コストも高くなり、この用途には不適切です。
技術的なポイント:
AWS DataSyncは、NFS、SMB、FSx、EFS、S3間でのデータ転送を効率的に行うサービスです。FSx for Windows File Server間の同期では、変更されたデータのみを転送する増分同期機能により、帯域幅使用量とコストを最適化できます。VPCピアリングは同一AWSアカウント内の異なるリージョン間で簡単に設定でき、低レイテンシかつ高帯域幅の接続を提供します。インターフェイスVPCエンドポイントにより、DataSyncエージェントがAWSサービスAPIにアクセスする際もプライベート接続を維持でき、セキュリティ要件を完全に満たします。このソリューションは、運用の簡素化、コスト最適化、セキュリティ要件の遵守を同時に実現できる理想的な構成です。
A. 指定された国に属するIP範囲のリストを含むIPSetを作成します。AWS WAF web ACLを作成します。IPSet内のIP範囲から発信されていないリクエストをブロックするルールを設定します。ルールをweb ACLに関連付けます。web ACLをALBに関連付けます。
B. AWS WAF web ACLを作成します。指定された国から発信されていないリクエストをブロックするルールを設定します。ルールをweb ACLに関連付けます。web ACLをALBに関連付けます。
C. 指定された国から発信されていないリクエストをブロックするようにAWS Shieldを設定します。AWS ShieldをALBに関連付けます。
D. 指定された国に属するIP範囲からのポート80と443を許可するセキュリティグループルールを作成します。セキュリティグループをALBに関連付けます。
解説
この問題は地理的制限（Geo-blocking）とログ記録の要件を満たすソリューションを選ぶ問題です。
選択肢Bが正解である理由：
AWS WAFには地理的マッチ条件（Geographic match condition）が組み込まれており、特定の国からのトラフィックを直接ブロックまたは許可することができます。この機能により、IPアドレス範囲を手動で管理する必要がなく、メンテナンスが最小限に抑えられます。さらに、AWS WAFは自動的にブロックされたリクエストをログに記録し、Amazon CloudWatchやAWS CloudTrailと統合してアクセス制御の監視と分析を提供します。
他の選択肢が適切でない理由：
A. IPSetを使用する方法は技術的には可能ですが、特定の国のIP範囲を手動で管理する必要があり、メンテナンスが増加します。IP範囲は変更される可能性があるため、定期的な更新が必要になります。
C. AWS Shieldは主にDDoS攻撃から保護するサービスであり、地理的制限機能は提供していません。地理的ブロッキングには適していません。
D. セキュリティグループは主にポートレベルでのアクセス制御を行うものであり、地理的制限には適していません。また、ブロックされたリクエストの詳細なログ記録機能も限定的です。
AWS WAFの地理的マッチ条件を使用することで、最小限のメンテナンスで要件を満たすことができ、包括的なログ記録機能も提供されます。
A. 各日のAWS WAFログを1つのログファイルに統合するAWS Lambda関数を作成します。
B. 毎日異なるS3バケットにログを送信するようにAWS WAFを設定して、スキャンするデータ量を削減します。
C. Amazon S3内のデータを日付と時刻でパーティション化するようにKinesis Data Firehoseの設定を更新します。Amazon Redshift用の外部テーブルを作成します。データソースをクエリするためにAmazon Redshift Spectrumを設定します。
D. データを日付と時刻でパーティション化するようにKinesis Data Firehoseの設定とAthenaテーブル定義を変更します。関連するパーティションを表示するようにAthenaクエリを変更します。
解説
この問題は、時間の経過とともにクエリパフォーマンスが低下する問題を解決するためのソリューションを選ぶ問題です。
選択肢Dが正解である理由：
Amazon Athenaでは、データをパーティション化することで特定の条件に基づいてスキャンするデータ量を大幅に削減できます。Kinesis Data Firehoseにはデータをパーティション化してS3に保存する機能が組み込まれており、日付や時刻によるパーティション化を簡単に設定できます。パーティション化されたデータに対してAthenaクエリを実行する際、WHERE句で特定のパーティションを指定することで、過去24時間分のデータのみをスキャンし、全体のデータセットをスキャンする必要がなくなります。これにより、時間が経過してもクエリパフォーマンスが一定に保たれ、運用オーバーヘッドも最小限に抑えられます。
他の選択肢が適切でない理由：
A. Lambda関数を使用してログファイルを統合する方法は、追加の処理ステップとコストが発生し、運用オーバーヘッドが増加します。また、データの処理遅延も発生する可能性があります。
B. 毎日異なるS3バケットを使用する方法は管理が複雑になり、運用オーバーヘッドが大幅に増加します。また、複数のバケットにまたがるクエリを実行する際の複雑さも増します。
C. Amazon Redshift Spectrumを使用する方法は技術的には可能ですが、Redshiftクラスターの管理が必要になり、運用オーバーヘッドが増加します。また、コストも高くなる可能性があります。
パーティション化は、時系列データのクエリパフォーマンスを向上させる最も効果的で運用効率の高い方法であり、AWS環境でのベストプラクティスでもあります。
• AWSインフラストラクチャを起動する際にユーザーに最小権限アクセスを提供し、ユーザーが承認されていないサービスをプロビジョニングできないようにする。
• 中央アカウントを使用してインフラストラクチャサービスの作成を管理する。
• AWS Organizations内の複数のアカウントにインフラストラクチャサービスを配布する機能を提供する。
• ユーザーが開始するあらゆるインフラストラクチャにタグを強制適用する機能を提供する。
AWSサービスを使用したアクションの組み合わせのうち、これらの要件を満たすものはどれですか？（3つ選択してください。）
A. AWS CloudFormationテンプレートを使用してインフラストラクチャサービスを開発します。テンプレートを中央のAmazon S3バケットに追加し、S3バケットポリシーにアクセスが必要なIAMロールまたはユーザーを追加します。
B. AWS CloudFormationテンプレートを使用してインフラストラクチャサービスを開発します。各テンプレートを中央のAWSアカウントで作成されたポートフォリオにAWS Service Catalogプロダクトとしてアップロードします。これらのポートフォリオを企業向けに作成されたOrganizations構造と共有します。
C. ユーザーIAMロールにAWSCloudFormationFullAccessおよびAmazonS3ReadOnlyAccessの権限を許可します。AWSアカウントのルートユーザーレベルでOrganizations SCPを追加し、AWS CloudFormationとAmazon S3以外のすべてのサービスを拒否します。
D. ユーザーIAMロールにServiceCatalogEndUserAccessの権限のみを許可します。自動化スクリプトを使用して中央ポートフォリオをローカルAWSアカウントにインポートし、TagOptionをコピーし、ユーザーアクセスを割り当て、起動制約を適用します。
E. 企業が必要とするタグのリストを維持するためにAWS Service Catalog TagOptionライブラリを使用します。TagOptionをAWS Service Catalogプロダクトまたはポートフォリオに適用します。
F. ユーザー向けに作成されるCloudFormationテンプレートにタグの適用を強制するためにAWS CloudFormation Resource Tagsプロパティを使用します。
解説
この問題は企業レベルでのインフラストラクチャサービス管理における最小権限原則、中央管理、組織全体への配布、タグ強制適用の要件を満たすソリューションの組み合わせを選ぶ問題です。
正解の組み合わせ（B、D、E）の理由：
選択肢B：AWS Service Catalogを使用することで、中央アカウントでインフラストラクチャサービスを管理し、組織全体に配布することができます。CloudFormationテンプレートをService Catalogプロダクトとして管理することで、承認されたサービスのみをユーザーに提供できます。
選択肢D：ServiceCatalogEndUserAccessは最小権限の原則に従った適切な権限設定です。この権限により、ユーザーはService Catalogからのみリソースを起動でき、直接AWSサービスにアクセスして承認されていないリソースを作成することはできません。
選択肢E：Service Catalog TagOptionライブラリを使用することで、企業が要求するタグを一元管理し、プロダクトやポートフォリオに適用することでタグの強制適用を実現できます。
他の選択肢が適切でない理由：
A：S3バケットを使用した直接的なCloudFormationテンプレートの配布は、アクセス制御やタグ強制適用の要件を満たしません。また、組織全体への配布機能も限定的です。
C：CloudFormationFullAccessは過度な権限であり、最小権限の原則に反します。ユーザーが承認されていないリソースを作成する可能性があります。
F：CloudFormation Resource Tagsプロパティは有効ですが、Service Catalog TagOptionライブラリを使用する方が企業レベルでのタグ管理により適しています。
この組み合わせにより、最小権限アクセス、中央管理、組織全体への配布、タグ強制適用のすべての要件を効果的に満たすことができます。
最近、本番アカウントで、ある開発部門のメンバーが別の開発部門に属するEC2インスタンスを終了させるというインシデントが発生しました。ソリューションアーキテクトは、将来同様のインシデントが発生することを防ぐソリューションを作成する必要があります。そのソリューションは、開発者が自分のワークロードで使用するインスタンスを管理する可能性も許可する必要があります。
これらの要件を満たす戦略はどれですか？
A. 各開発部門用にAWS Organizationsで別々のOUを作成します。作成したOUを企業のAWSアカウントに割り当てます。開発部門名と一致するDevelopmentUnitリソースタグに対してdenyアクションとStringNotEquals条件を持つ別々のSCPを作成します。SCPを対応するOUに割り当てます。
B. SAMLフェデレーション中にDevelopmentUnitの属性をAWS Security Token Service（AWS STS）セッションタグとして渡します。開発者の想定IAMロールのIAMポリシーを、DevelopmentUnitリソースタグとaws:PrincipalTag/DevelopmentUnitに対してdenyアクションとStringNotEquals条件で更新します。
C. SAMLフェデレーション中にDevelopmentUnitの属性をAWS Security Token Service（AWS STS）セッションタグとして渡します。DevelopmentUnitリソースタグとaws:PrincipalTag/DevelopmentUnitに対してallowアクションとStringEquals条件を持つSCPを作成します。SCPをルートOUに割り当てます。
D. 各開発部門用に別々のIAMポリシーを作成します。すべてのIAMポリシーに対して、DevelopmentUnitリソースタグと開発部門名に対してallowアクションとStringEquals条件を追加します。SAMLフェデレーション中に、AWS Security Token Service（AWS STS）を使用して、IAMポリシーを割り当て、開発部門名を想定IAMロールに一致させます。
解説
この問題は、共有の本番アカウントにおいて、開発部門間でのリソース分離を実現するためのアクセス制御戦略を選ぶ問題です。
選択肢Bが正解である理由：
SAMLフェデレーション時にDevelopmentUnitをセッションタグとして渡し、IAMポリシーでdenyアクションとStringNotEquals条件を使用することで、開発者は自分の開発部門のタグが付いたリソースのみを操作できるようになります。この方法により、開発者は自分のワークロードのインスタンスを管理できる一方で、他の開発部門のリソースにアクセスすることは明示的に拒否されます。セッションタグ（aws:PrincipalTag/DevelopmentUnit）とリソースタグ（DevelopmentUnit）を比較することで、動的で柔軟なアクセス制御が実現されます。
他の選択肢が適切でない理由：
A：SCPはOU単位で適用されますが、この問題では各開発部門が同じ本番アカウントを共有している状況です。各開発部門用に別々のOUを作成しても、同一アカウント内でのリソース分離は効果的に実現されません。
C：allowアクションでSCPを作成する方法は、デフォルトでdenyとなるため、必要な他のAWSサービスへのアクセスも制限される可能性があります。また、ルートOUに割り当てることで、組織全体に影響を与える可能性があります。
D：各開発部門用に別々のIAMポリシーを作成し、STSで動的に割り当てる方法は実装が複雑になります。また、allowアクションのみでは他の開発部門のリソースへのアクセスを明示的に防ぐことができません。
選択肢Bの方法は、属性ベースのアクセス制御（ABAC）を実装する標準的なアプローチであり、運用の複雑さを最小限に抑えながら効果的なリソース分離を実現できます。
A. Amazon CloudFrontディストリビューションを作成します。CloudFrontオリジングループを作成します。各追加リージョンのNLBをオリジングループに追加します。ディストリビューションのエッジロケーションのIPアドレス範囲を顧客に提供します。
B. AWS Global Accelerator標準アクセラレータを作成します。各追加リージョンのNLB用に標準アクセラレータエンドポイントを作成します。Global AcceleratorのIPアドレスを顧客に提供します。
C. Amazon CloudFrontディストリビューションを作成します。各追加リージョンのNLB用にカスタムオリジンを作成します。ディストリビューションのエッジロケーションのIPアドレス範囲を顧客に提供します。
D. AWS Global Acceleratorカスタムルーティングアクセラレータを作成します。カスタムルーティングアクセラレータ用のリスナーを作成します。各追加リージョンのNLBのIPアドレスとポートを追加します。Global AcceleratorのIPアドレスを顧客に提供します。
解説
この問題では、複数リージョンに展開されたSaaSアプリケーションに対して、静的IPアドレスの提供と地理的に最適なルーティングの両方を実現する必要があります。
選択肢Bが正解である理由：
AWS Global Accelerator標準アクセラレータは、静的なAnycast IPアドレス（通常2つ）を提供し、複数のリージョンにあるエンドポイント（この場合はNLB）への地理的に最適なルーティングを自動的に行います。顧客は提供された固定のGlobal Accelerator IPアドレスを許可リストに追加するだけで済み、地理的な位置に基づいて最も近いリージョンに自動的にルーティングされます。また、Global Acceleratorはヘルスチェック機能も提供し、障害が発生したリージョンから自動的にトラフィックを迂回させます。
他の選択肢が適切でない理由：
A：CloudFrontオリジングループは複数のオリジンを設定できますが、主にフェイルオーバー用途に設計されており、地理的ルーティングには適していません。また、エッジロケーションのIPアドレス範囲は非常に多く、頻繁に変更される可能性があり、顧客の許可リスト管理が困難になります。
C：CloudFrontは複数のカスタムオリジンを設定できますが、地理的ルーティングを自動的に行う機能はありません。また、選択肢Aと同様にエッジロケーションのIPアドレス範囲の管理が問題となります。
D：カスタムルーティングアクセラレータは、特定のIPアドレスとポートの組み合わせに対してより詳細な制御を提供しますが、この用途には過度に複雑であり、標準アクセラレータで十分に要件を満たすことができます。
Global Accelerator標準アクセラレータは、グローバルなアプリケーション配信において静的IPアドレスと地理的最適化を同時に実現する最適なソリューションです。
A. AWS Application Discovery Serviceを使用し、データセンター内の各仮想マシンにデータ収集エージェントをデプロイします。
B. ローカル環境内のすべてのサーバーでAmazon CloudWatchエージェントを設定し、メトリクスをAmazon CloudWatch Logsに公開します。
C. AWS Application Discovery Serviceを使用し、既存の仮想化環境でエージェントレス探索を有効にします。
D. AWS管理コンソールでAWS Application Discovery Serviceを有効にし、VPN経由でのスキャンを許可するように企業ファイアウォールを設定します。
解説
この問題では、クラウド移行のために詳細なサーバー情報を収集する最もコスト効率の良い方法を選ぶ必要があります。要件を満たすために必要な情報は、CPU・メモリ・ディスク使用率の詳細メトリクス、実行中のプロセスのインベントリ、サーバー間のネットワーク接続マッピングです。
選択肢Aが正解である理由：
AWS Application Discovery Serviceのエージェントベース探索は、サーバープロファイル情報（OS、CPU数、RAM容量など）、データベースメタデータ、使用率メトリクス、オンプレミスサーバー間のネットワークトラフィックに関するデータを収集します。 AWS Application Discovery Service FAQs - Amazon Web Serivcesエージェントベースの方法では、各仮想マシンに軽量なエージェントをインストールすることで、CPU、メモリ、ディスクI/O、ネットワーク使用率などの詳細なパフォーマンスデータ、実行中のプロセスの完全なインベントリ、サーバー間のネットワーク接続の詳細なマッピングを取得できます。これらの情報は正確なEC2サイジングに不可欠であり、移行計画の精度を大幅に向上させます。
他の選択肢が適切でない理由：
B：CloudWatchエージェントは主にAWS環境でのモニタリング用に設計されており、オンプレミス環境からの継続的なメトリクス送信には高いデータ転送コストが発生します。また、実行中のプロセスの詳細なインベントリやサーバー間の通信マッピング機能は提供されません。
C：エージェントレス探索は基本的なサーバー情報と使用状況を収集できますが、エージェントベース探索と比較して詳細度が限定的です。特に実行中のプロセスの詳細なインベントリや、ネットワーク接続の詳細なマッピングは十分に提供されません。
D：この選択肢は実際のApplication Discovery Serviceの動作方法を正確に表していません。管理コンソールでの有効化だけではデータ収集は開始されず、エージェントのデプロイまたはエージェントレス探索の設定が必要です。
エージェントベース探索は、移行計画に必要なすべての詳細情報を包括的に収集でき、長期的な移行成功のためのコスト効率の最も高いソリューションです。
A. バックエンドサービスをAWS Lambdaに移行します。DynamoDBの読み取りと書き込み容量を増加させます。
B. バックエンドサービスをAWS Lambdaに移行します。DynamoDBでグローバルテーブルを使用するように設定します。
C. バックエンドサービスにAuto Scalingグループを使用します。DynamoDBオートスケーリングを使用します。
D. バックエンドサービスにAuto Scalingグループを使用します。Amazon Simple Queue Service（Amazon SQS）とAWS Lambda関数を使用してDynamoDBに書き込みます。
解説
この問題は、季節的なトラフィック増加に対応するためのスケーラブルなアーキテクチャを最小限の開発努力で実現する方法を選ぶ問題です。
選択肢Cが正解である理由：
Auto Scalingグループを使用することで、EC2インスタンスをトラフィック負荷に応じて自動的にスケールイン/スケールアウトできます。DynamoDBオートスケーリングは、読み取りと書き込みの需要に応じて自動的に容量を調整します。この組み合わせにより、既存のアプリケーションコードを大幅に変更することなく、ピークシーズンの負荷に対応できるスケーラブルなソリューションを実現できます。設定の変更のみで実装でき、開発努力は最小限で済みます。
他の選択肢が適切でない理由：
A：バックエンドサービスをLambdaに移行するには、既存のEC2ベースのアプリケーションを大幅にリファクタリングする必要があります。また、手動でDynamoDBの容量を増加させる方法は、オートスケーリングと比較して効率的ではありません。
B：Lambdaへの移行には大きな開発努力が必要です。さらに、グローバルテーブルは主に複数リージョン間でのデータレプリケーション用途であり、単一リージョンでのスケーラビリティ問題の解決には適していません。
D：SQSとLambdaを組み合わせた非同期処理アーキテクチャは効果的ですが、既存のアプリケーションを大幅に変更する必要があります。読み取り処理と書き込み処理を分離し、キューイングシステムを導入するには相当な開発努力が必要です。
選択肢Cは、既存のアーキテクチャを維持しながら、AWSの管理されたオートスケーリング機能を活用することで、最小限の変更でスケーラビリティの問題を解決する最も実用的なアプローチです。
A. Aurora MySQL DBクラスターを設定して、スロークエリとエラーログをAmazon CloudWatch Logsに公開する。
B. EC2インスタンス上の受信HTTPリクエストをトレースするためにAWS X-Ray SDKを実装し、Java用X-Ray SDKを使用してSQLクエリのトレースを実装する。
C. Aurora MySQL DBクラスターを設定して、スロークエリとエラーログをAmazon Kinesisにストリーミングする。
D. EC2インスタンスにAmazon CloudWatch Logsエージェントをインストールして設定し、ApacheログをCloudWatch Logsに送信する。
E. AWS CloudTrailを有効化して設定し、Amazon EC2とAuroraからのアプリケーションアクティビティを収集・分析する。
F. Aurora MySQL DBクラスターのパフォーマンスベンチマークを有効化し、ストリームをAWS X-Rayに公開する。
正解：A、B、D
問題の根本原因は、ピークトラフィック時のアプリケーションパフォーマンスの可視性不足です。特に、ウェブサーバーログの収集不備とデータベースクエリパフォーマンスの分析不足が課題となっています。
選択肢Aは正しいです。Aurora MySQLのスロークエリとエラーログをCloudWatch Logsに公開することで、データベース層のパフォーマンス問題を詳細に分析できます。これにより、どのクエリが遅延を引き起こしているかを特定できます。
選択肢Bは正しいです。AWS X-Ray SDKを実装することで、HTTPリクエストの完全なトレースが可能になり、アプリケーション全体の処理フローを可視化できます。SQLクエリのトレースも含めることで、データベースとアプリケーション間の相互作用を詳細に監視できます。
選択肢Dは正しいです。CloudWatch LogsエージェントをEC2インスタンスに設定することで、Auto Scalingによってインスタンスが終了されてもApacheログが確実に保持されます。これにより、ピークトラフィック時の全てのログデータを分析できます。
選択肢Cは不適切です。Kinesisは主にリアルタイムデータストリーミング用であり、ログ分析にはCloudWatch Logsの方が適しています。
選択肢Eは不適切です。CloudTrailはAPIコールの監査ログを提供しますが、アプリケーションパフォーマンスの詳細分析には向いていません。
選択肢Fは存在しない機能です。Aurora Performance Insightsが正しい機能名であり、X-Rayとは直接統合されません。
A. Amazon Simple Queue Service（Amazon SQS）キューを作成する。キューをAPIのデッドレターキューとして設定する。
B. 2つのAmazon Simple Queue Service（Amazon SQS）キューを作成する：プライマリキューとセカンダリキュー。セカンダリキューをプライマリキューのデッドレターキューとして設定する。APIを更新してプライマリキューへの新しい統合を使用する。Lambda関数をプライマリキューの呼び出しターゲットとして設定する。
C. 2つのAmazon EventBridgeイベントバスを作成する：プライマリイベントバスとセカンダリイベントバス。APIを更新してプライマリイベントバスへの新しい統合を使用する。プライマリイベントバス上のすべてのイベントに反応するEventBridgeルールを設定する。Lambda関数をルールのターゲットとして指定する。セカンダリイベントバスをLambda関数の失敗先として設定する。
D. カスタムAmazon EventBridgeイベントバスを作成する。イベントバスをLambda関数の失敗先として設定する。
正解：B
この問題は、サードパーティサービスの障害によるデータ損失を防ぐためのアーキテクチャ改善に関する問題です。現在のアーキテクチャではAPI Gateway → Lambda → サードパーティサービスという同期処理のため、サードパーティサービスの障害が直接データ損失につながっています。
選択肢Bが正しい理由は、キューベースの非同期処理アーキテクチャを導入することで、データの永続化と再処理機能を実現できるからです。具体的には、API Gatewayからの気象データをまずプライマリSQSキューに格納し、Lambda関数がキューからメッセージを取得して処理します。サードパーティサービスが失敗した場合、メッセージは自動的にセカンダリキュー（デッドレターキュー）に移動され、後で再処理できます。これにより、データが失われることなく、障害回復後に処理を継続できます。
選択肢Aは不完全です。API Gatewayは直接デッドレターキューとの統合をサポートしていないため、この設定は機能しません。
選択肢Cは技術的に可能ですが、この用途には過度に複雑です。EventBridgeは主にイベント駆動アーキテクチャに適しており、単純なデータ処理とエラーハンドリングにはSQSの方が適しています。
選択肢Dは不十分です。単一のイベントバスだけではメッセージの再試行やデッドレター機能が適切に実装されず、データ損失のリスクが残ります。
SQSとデッドレターキューの組み合わせは、メッセージの確実な配信、自動再試行、エラーハンドリングを提供し、この要件に最も適したソリューションです。
A. 各アカウントに起動される共通のIAM権限を定義するパラメータ化されたAWS CloudFormationテンプレートのコレクションを使用する。すべての新規および既存のアカウントに適切なスタックを起動して最小権限モデルを強制することを要求する。
B. AWS Organizationsを使用して選択された支払いアカウントから新しい組織を作成し、組織単位階層を定義する。既存のアカウントを組織に参加するよう招待し、Organizationsを使用して新しいアカウントを作成する。
C. 各事業部門に独自のAWSアカウントの使用を要求する。各AWSアカウントに適切にタグ付けし、Cost Explorerを有効にしてチャージバックを管理する。
D. AWS Organizationsのすべての機能を有効にし、サブアカウントのIAM権限をフィルターする適切なサービスコントロールポリシーを確立する。
E. 企業のすべてのAWSアカウントを単一のAWSアカウントに統合する。請求目的でタグを使用し、IAMのAccess Advisor機能を使用して最小権限モデルを強制する。
正解：B、D
この問題は、複数のAWSアカウントを持つ大企業が、一元化された支払い管理とセキュリティ制御を最小限の労力で実現する方法を問うています。
選択肢Bが正しい理由は、AWS Organizationsが複数アカウント管理の標準的なソリューションだからです。Organizations を使用することで、既存の独立したアカウントを一つの組織に統合し、一元化された請求（統合請求）を実現できます。組織単位（OU）階層を定義することで、事業部門ごとの論理的な分離も維持できます。また、既存アカウントの招待と新規アカウント作成の両方をサポートし、最小限の労力で移行できます。
選択肢Dが正しい理由は、サービスコントロールポリシー（SCP）がIAM権限の一元制御を実現する最も効率的な方法だからです。SCPを使用することで、組織レベルまたはOU レベルでIAM権限の上限を設定し、各アカウントで実行可能なアクションを制限できます。これにより、セキュリティチームが要求する一元化されたIAM制御が実現されます。
選択肢AはCloudFormationテンプレートによる権限管理ですが、すべてのアカウントに個別に展開する必要があり、労力が大きくなります。また、一元的な制御も困難です。
選択肢Cは現状維持に近く、一元化された支払い管理やセキュリティ制御の要件を満たしません。
選択肢Eは単一アカウントへの統合ですが、事業部門間の分離が失われ、複雑性が増加します。また、大企業には推奨されないアプローチです。
AWS Organizationsと SCPの組み合わせは、マルチアカウント環境における請求管理とセキュリティ制御のベストプラクティスであり、最小限の労力で要件を満たします。
ソリューションアーキテクトは、認証されたユーザーのみがコンテンツを投稿できるようにしながら、アップロードパフォーマンスを改善するために何をすべきか？
A. Amazon API Gatewayにエッジ最適化APIエンドポイントを設定し、S3サービスプロキシとしてのリソースを追加する。このリソースのPUTメソッドを設定してS3のPutObject操作を公開する。COGNITO_USER_POOLSオーソライザーを使用してAPI Gatewayを保護する。署名付きURLの代わりにAPI Gateway経由でオブジェクトをアップロードするようにブラウザーインターフェースを変更する。
B. Amazon API GatewayにリージョナルAPIエンドポイントを設定し、S3サービスプロキシとしてのリソースを追加する。このリソースのPUTメソッドを設定してS3のPutObject操作を公開する。AWS Lambdaオーソライザーを使用してAPI Gatewayを保護する。署名付きURLの代わりにAPI Gateway経由でオブジェクトをアップロードするようにブラウザーインターフェースを変更する。
C. S3バケットでS3 Transfer Accelerationエンドポイントを有効にする。このエンドポイントを使用して署名付きURLを生成する。ブラウザーインターフェースがS3のマルチパートアップロードAPIを使用してこのURLにオブジェクトをアップロードするようにする。
D. 対象のS3バケットにAmazon CloudFrontディストリビューションを設定する。CloudFrontキャッシュ動作にPUTおよびPOSTメソッドを有効にする。CloudFrontオリジンにオリジンアクセスアイデンティティ（OAI）を使用するように設定する。OAIユーザーにバケットポリシーでS3:PutObject権限を付与する。CloudFrontディストリビューションを通じてオブジェクトをアップロードするようにブラウザーインターフェースを変更する。
ユーザーが大きなファイル（100MB以上）をアップロードする際の速度問題を抱えており、これは地理的距離やS3までのネットワーク遅延が原因である可能性があります。
C の Transfer Accelerationを利用することで、CloudFrontのエッジロケーションを経由してS3へのアップロードが最適化され、大きなファイルのアップロードパフォーマンスが大幅に向上します。
署名付きURLを生成するアプローチは既存のセキュリティ要件（認証済みユーザーのみ）を維持でき、クライアントがS3 multipart upload APIを使うことで、大きなファイルのアップロード効率も向上します。
A・B はAPI Gatewayを経由させる実装で、オーバーヘッドが増え、特に大容量ファイルの転送には不向きです。
D のCloudFrontは通常読み取り用途に使用され、PUT/POSTメソッドはサポートされていない、もしくは非推奨です。
この企業は、コンピューティングコストを削減し、部門ごとに適切にコストを管理したいと考えている。また、各部門ごとの請求に関する可視性を向上させたいと考えている。加えて、企業がコンピューティングリソースを選択する際には、運用上の柔軟性を失いたくないとも考えている。
この要件を満たすソリューションはどれか？
A. 各部門に対してAWS Budgetsを使用する。Tag Editorを使用して適切なリソースにタグを適用する。EC2インスタンスのSavings Plansを購入する。
B. AWS Organizationsで統合請求を使用するように構成する。部門を識別するタグ付け戦略を実装する。SCP（サービスコントロールポリシー）を使用して適切なリソースにタグを適用する。EC2インスタンスのSavings Plansを購入する。
C. AWS Organizationsで統合請求を使用するように構成する。部門を識別するタグ付け戦略を実装する。Tag Editorを使用して適切なリソースにタグを適用する。Compute Savings Plansを購入する。
D. 各部門に対してAWS Budgetsを使用する。SCPを使用して適切なリソースにタグを適用する。Compute Savings Plansを購入する。
統合請求（Consolidated Billing）を使用することで、複数のAWSアカウントの使用量を集約し、ボリュームディスカウントの恩恵を受けられます。これはコスト削減に直結します。
Compute Savings Plansは、EC2だけでなく、FargateやLambdaなどもカバーするため、運用上の柔軟性を維持しつつコスト削減が可能です。部門が独立して異なるサービスを利用していても柔軟に対応できます。
タグ付け戦略の実装とTag Editorの使用によって、部門ごとのコスト可視化が可能になります。
SCPはタグの適用には使用できません。SCPはサービスやアクションの制限に使うもので、タグ適用には不適です（BとDは誤り）。
AWS Budgets（AとD）は予算管理には有効ですが、直接的なコスト削減にはつながりません。
したがって、C がすべての要件（コスト削減、可視性、柔軟性）を満たす最適な選択です。
A. AWS Step Functionsを使用して、ユーザーが画像を保存したときに発生するS3イベントを処理する。画像をその場でリサイズし、S3バケット内の元のファイルを置き換えるAWS Lambda関数を実行する。保存されたすべての画像を6か月後に期限切れにするS3 Lifecycleポリシーを作成する。
B. Amazon EventBridgeを使用して、ユーザーが画像をアップロードしたときに発生するS3イベントを処理する。画像をその場でリサイズし、S3バケット内の元のファイルを置き換えるAWS Lambda関数を実行する。保存されたすべての画像を6か月後に期限切れにするS3 Lifecycleポリシーを作成する。
C. S3 Event Notificationsを使用して、ユーザーが画像を保存したときにAWS Lambda関数を呼び出す。Lambda関数を使用して画像をその場でリサイズし、元のファイルをS3バケットに保存する。保存されたすべての画像を6か月後にS3 Standard-Infrequent Access（S3 Standard-IA）に移動するS3 Lifecycleポリシーを作成する。
D. Amazon Simple Queue Service（Amazon SQS）を使用して、ユーザーが画像を保存したときに発生するS3イベントを処理する。画像をリサイズし、リサイズされたファイルをS3 Standard-Infrequent Access（S3 Standard-IA）を使用するS3バケットに保存するAWS Lambda関数を実行する。保存されたすべての画像を6か月後にS3 Glacier Deep Archiveに移動するS3 Lifecycleポリシーを作成する。
正解：D ?B
この問題は、大規模な画像処理ワークロードに対する費用対効果の高いアーキテクチャを選択する問題です。要件として、需要の大幅な変動への対応、エンタープライズ規模での信頼性、障害時の再実行機能、コスト効率性が挙げられています。
選択肢Dが正しい理由は、SQSを使用することで最も堅牢で費用対効果の高いソリューションを提供するからです。SQSは大量のメッセージを処理でき、自動的にスケーリングし、メッセージの可視性タイムアウトとデッドレターキュー機能により障害時の再処理を保証します。また、S3 Standard-IAでの初期保存とGlacier Deep Archiveへの移行により、ストレージコストを最小化できます。6か月後の完全削除ではなく、より低コストなアーカイブストレージへの移行を提案している点も費用対効果的です。
選択肢Aの Step Functionsは、複雑なワークフローには適していますが、シンプルな画像リサイズタスクには過剰で、コストも高くなります。
選択肢BのEventBridgeは、複数のターゲットへのイベントルーティングには優れていますが、単純な処理にはSQSの方がコスト効率が良く、より堅牢です。
選択肢Cは技術的には機能しますが、S3 Event Notificationsの直接Lambda呼び出しは、大量の同時実行時にスロットリングのリスクがあり、エンタープライズ規模での信頼性要件を満たしません。また、6か月後にStandard-IAに移行するのは適切ではありません（通常は30日後）。
SQSとLambdaの組み合わせは、バッチ処理、エラーハンドリング、スケーラビリティの面で最も適しており、S3のライフサイクル管理と組み合わせることで、長期的なコスト最適化も実現できます。
A. 少なくとも2つのプライベートサブネット、2つのNATゲートウェイ、および仮想プライベートゲートウェイを持つVPCを作成する
B. 少なくとも2つのパブリックサブネット、仮想プライベートゲートウェイ、およびインターネットゲートウェイを持つVPCを作成する
C. オンプレミスネットワークとターゲットのAWSネットワークの間にAWS Site-to-Site VPN接続を作成する
D. オンプレミスネットワークとターゲットのAWSネットワークの間にAWS Direct Connect接続とDirect Connectゲートウェイを作成する
E. レプリケーションサーバーの設定時に、データレプリケーションにプライベートIPアドレスを使用するオプションを選択する
F. ターゲットサーバーの起動設定時に、リカバリインスタンスのプライベートIPアドレスがソースサーバーと一致するようにするオプションを選択する
解説：
Aは、VPCに少なくとも2つのプライベートサブネットを持ち、仮想プライベートゲートウェイ（VGW）を利用することで、インターネットを通さずオンプレミスとAWS間のプライベート接続が可能になります。ただし「2つのNATゲートウェイ」は不要であり、使用しなければセキュリティと要件を満たせます。構成上の基盤として必要な部分は適切なため、正解とみなせます。
Dは、AWS Direct Connect を使用することで、オンプレミスとAWSの間で安定したプライベートネットワーク接続が確保され、パブリックインターネットを介さずにデータを転送できます。また、帯域幅も制御可能なため、他のアプリケーションへの影響を最小化できます。正解。
Eは、レプリケーショントラフィックにプライベートIPを使うことで、トラフィックがVPC内にとどまり、パブリックインターネットを避ける構成にできます。これはセキュリティ要件を満たし、正解です。
Bは、パブリックサブネットとインターネットゲートウェイの使用があるため、アプリケーションがインターネットにアクセスされる可能性がある点で不適切です。
CのSite-to-Site VPNは一見良さそうですが、実際にはインターネットを経由したIPsecトンネルを使用するため、「パブリックインターネットを通過しない」という厳格な要件を満たしません。
Fは、リカバリインスタンスのプライベートIPアドレスを固定することで一貫性は得られますが、問題文の中核的要件である「ネットワーク経路」や「帯域制御」とは無関係です。
したがって、A, D, Eが要件を満たす最適な選択肢です。
A. EC2インスタンスに予測スケーリングポリシーを使用する。自動的にスケーリングするリードレプリカを持つAmazon Aurora PostgreSQL Serverless v2 Multi-AZ DBインスタンス上でデータベースをホストする。販売イベント前にデータベースを事前ウォームアップするために並列AWS Lambda関数を実行するAWS Step Functions状態マシンを作成する。状態マシンを呼び出すAmazon EventBridgeルールを作成する。
B. EC2インスタンスにスケジュール済みスケーリングポリシーを使用する。自動的にスケーリングするリードレプリカを持つAmazon RDS for PostgreSQL Multi-AZ DBインスタンス上でデータベースをホストする。販売イベント前により大きなリードレプリカを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。より大きなリードレプリカにフェイルオーバーする。販売イベント後にリードレプリカをスケールダウンする別のLambda関数を呼び出す別のEventBridgeルールを作成する。
C. EC2インスタンスに予測スケーリングポリシーを使用する。自動的にスケーリングするリードレプリカを持つAmazon RDS for PostgreSQL Multi-AZ DBインスタンス上でデータベースをホストする。販売イベント前にデータベースを事前ウォームアップするために並列AWS Lambda関数を実行するAWS Step Functions状態マシンを作成する。状態マシンを呼び出すAmazon EventBridgeルールを作成する。
D. EC2インスタンスにスケジュール済みスケーリングポリシーを使用する。Amazon Aurora PostgreSQL Multi-AZ DBクラスター上でデータベースをホストする。販売イベント前により大きなAurora Replicaを作成するAWS Lambda関数を呼び出すAmazon EventBridgeルールを作成する。より大きなAurora Replicaにフェイルオーバーする。販売イベント後にAurora Replicaをスケールダウンする別のLambda関数を呼び出す別のEventBridgeルールを作成する。
正解：A DDDDDDDDDDD
この問題は、予定された販売イベントでの高トラフィックに対応するための最適なスケーリング戦略を選択する問題です。キーとなる要件は、スケジュールされた一回限りのイベントでの可用性最大化です。
選択肢Aが正しい理由は、最も適切な技術組み合わせを提供するからです。予測スケーリングポリシーは過去のトラフィックパターンを学習し、需要を予測してEC2インスタンスを事前にスケールアップできます。Aurora PostgreSQL Serverless v2は自動的にコンピュートリソースをスケールし、トラフィック増加に即座に対応できます。また、Step FunctionsとLambdaを使用したデータベースの事前ウォームアップにより、キャッシュの準備とパフォーマンス最適化が可能です。EventBridgeルールによるスケジュール実行で、イベント開始前の適切なタイミングでの準備が可能です。
選択肢Bは技術的な問題があります。リードレプリカへのフェイルオーバーは読み込み専用になるため、チケット販売のような書き込み処理には適していません。また、スケジュール済みスケーリングは固定時間での実行のため、需要予測による柔軟性がありません。
選択肢Cは従来のRDS PostgreSQLを使用しており、Aurora Serverless v2のような自動スケーリング機能がないため、突発的な負荷増加への対応が劣ります。
選択肢Dも選択肢Bと同様に、レプリカフェイルオーバーによる読み込み専用化の問題があります。Aurora標準版はServerless v2のような細かな自動スケーリングができません。
予測スケーリングポリシーは機械学習を活用して需要パターンを学習し、スケジュール済みスケーリングよりも精密な事前スケーリングが可能です。Aurora Serverless v2は秒単位でのスケーリングが可能で、一時的な高負荷に最適です。データベース事前ウォームアップは、コールドスタート問題を回避し、イベント開始時からの最適なパフォーマンスを保証します。
A. 拒否リスト戦略を使用する
B. AWS IAMのアクセスアドバイザーを確認して最近使用されたサービスを特定する
C. AWS Trusted Advisorレポートを確認して最近使用されたサービスを特定する
D. デフォルトのFullAWSAccess SCPを削除する
E. 組織単位（OU）を定義し、メンバーアカウントをそのOUに配置する
F. デフォルトのDenyAWSAccess SCPを削除する
解説：
まず、DevOpsチームが使用していないサービスを拒否するためには「拒否リスト戦略（Deny list strategy）」を使い、特定のサービスへのアクセスのみを制限することが効果的です。これにより、本来許可したいサービスは使えるままとなります。よってAは正解です。
次に、どのサービスが実際に使われているかを把握するために、IAMのアクセスアドバイザーを使うのが適切です。アクセスアドバイザーは、各サービスの使用履歴を確認できるため、不要サービスを正確に特定できます。よってBは正解です。
複数アカウントを単一の単位として管理するために、AWS Organizationsの機能である組織単位（OU）を定義し、アカウントを適切に分類・管理することが推奨されます。よってEも正解です。
CのTrusted Advisorは主にセキュリティ、コスト最適化、パフォーマンスに関する推奨を行いますが、サービス使用状況の詳細な把握にはIAMアクセスアドバイザーのほうが適切です。
DのFullAWSAccess SCPはデフォルトで全許可を与えており、これを削除すると誤ってアクセス制限が強まりすぎる恐れがあります。
FのDenyAWSAccess SCPはデフォルトで存在しないため、削除は不要です。
A. 追加のCloudFrontディストリビューションをデプロイする。両方のCloudFrontディストリビューション用にヘルスチェック付きの新しいRoute 53フェイルオーバーレコードセットを作成する。
B. 各リージョンのバックエンドサービスに使用されている既存のRoute 53レコードセットのTTLを4秒に設定する。
C. レイテンシルーティングポリシーを使用してバックエンドサービス用の新しいレコードセットを作成する。CloudFrontディストリビューションでこのレコードセットをオリジンとして使用する。
D. 各バックエンドサービスリージョンに1つずつ、2つのオリジンを含むCloudFrontオリジングループを作成する。CloudFrontディストリビューションのキャッシュビヘイビアとしてオリジンフェイルオーバーを設定する。
この問題の核心は、現在のRoute 53ベースのフェイルオーバーが1分以上かかっている理由を理解することです。現在の構成では、プライマリリージョンのバックエンドサービスに障害が発生した場合、以下のプロセスが必要です：
Route 53のヘルスチェックが障害を検出する（最大30秒）
DNSレコードのTTL期限切れを待つ（60秒）
新しいDNSクエリでセカンダリレコードを取得する
選択肢Dが最適な理由：
CloudFrontオリジングループは、CloudFrontレベルでフェイルオーバーを処理します。プライマリオリジンが失敗した場合、CloudFrontは即座にセカンダリオリジンにリクエストを転送します。これはDNS解決を待つ必要がなく、数秒以内にフェイルオーバーが完了します。オリジングループはHTTPステータスコード（4xx、5xx）に基づいて障害を判定し、リアルタイムでフェイルオーバーを実行します。
他の選択肢が適切でない理由：
選択肢A：追加のCloudFrontディストリビューションを作成しても、根本的にはRoute 53レベルでのフェイルオーバーに依存するため、同様の遅延が発生します。
選択肢B：TTLを4秒に短縮しても、ヘルスチェックの検出時間とDNS伝播の遅延は残り、完全な解決策にはなりません。
選択肢C：レイテンシルーティングは地理的な最適化には有効ですが、障害時のフェイルオーバー速度を改善しません。
CloudFrontオリジングループは、CDNレベルでの高速フェイルオーバーを実現する最も効率的なソリューションです。
A. ディレクトリに新しいアプリクライアントを作成する。ALB用のリスナールールを作成する。リスナールールにauthenticate-oidcアクションを指定する。Active Directoryサービスの適切な発行者、クライアントIDとシークレット、エンドポイントの詳細でリスナールールを設定する。ALBが提供するコールバックURLで新しいアプリクライアントを設定する。
B. Amazon Cognitoユーザープールを設定する。ディレクトリからのメタデータを持つフェデレーテッドアイデンティティプロバイダー（IdP）でユーザープールを設定する。アプリクライアントを作成する。アプリクライアントをユーザープールに関連付ける。ALB用のリスナールールを作成する。リスナールールにauthenticate-cognitoアクションを指定する。ユーザープールとアプリクライアントを使用するようにリスナールールを設定する。
C. ディレクトリを新しいIAMアイデンティティプロバイダー（IdP）として追加する。SAML 2.0フェデレーションのエンティティタイプを持つ新しいIAMロールを作成する。ALBへのアクセスを許可するロールポリシーを設定する。新しいロールをIdPのデフォルト認証ユーザーロールとして設定する。ALB用のリスナールールを作成する。リスナールールにauthenticate-oidcアクションを指定する。
D. AWS IAM Identity Center（AWS Single Sign-On）を有効にする。SAMLを使用する外部アイデンティティプロバイダー（IdP）としてディレクトリを設定する。自動プロビジョニング方法を使用する。SAML 2.0フェデレーションのエンティティタイプを持つ新しいIAMロールを作成する。ALBへのアクセスを許可するロールポリシーを設定する。新しいロールをすべてのグループにアタッチする。ALB用のリスナールールを作成する。リスナールールにauthenticate-cognitoアクションを指定する。
この問題は、ALBの認証機能とAWS Directory Service for Microsoft Active Directoryの統合について問われています。AWS Directory Service for Microsoft Active DirectoryはLDAP互換のディレクトリサービスです。
選択肢Bが正解である理由：
Amazon CognitoはAWS Directory Service for Microsoft Active Directoryと直接統合できます。Cognitoユーザープールは外部のLDAPディレクトリ（Active Directory含む）をフェデレーテッドアイデンティティプロバイダーとして設定できます。ALBのauthenticate-cognitoアクションは、Cognitoユーザープールと完全に統合されており、Active Directoryの認証情報を使用してユーザーを認証できます。ディレクトリ内のすべてのユーザーが自動的にアクセス権を取得し、追加の設定やプロビジョニングは不要です。
他の選択肢が不適切な理由：
選択肢A：AWS Directory Service for Microsoft Active DirectoryはネイティブなOIDCプロバイダーではありません。ALBのauthenticate-oidcアクションは直接Active Directoryと統合できません。この設定は技術的に実現不可能です。
選択肢C：IAMアイデンティティプロバイダーとしてディレクトリを追加する場合、SAML設定が必要ですが、選択肢CではOIDCアクションを指定しており、設定が矛盾しています。また、この方法ではユーザーの自動プロビジョニングが困難です。
選択肢D：IAM Identity CenterとSAMLフェデレーションを使用する方法は有効ですが、最後にauthenticate-cognitoアクションを指定しており、設定が矛盾しています。IAM Identity Centerを使用する場合は、authenticate-oidcアクションを使用する必要があります。
Amazon CognitoとAWS Directory Service for Microsoft Active Directoryの組み合わせは、最もシンプルで信頼性の高いソリューションです。
A. AWS Organizationsで組織を作成する。AWS Control Towerをセットアップし、強く推奨される統制（ガードレール）を有効にする。すべてのアカウントを組織に参加させる。AWSアカウントをOUに分類する。
B. AWS CLIを使用してすべてのAWSアカウント内のすべての暗号化されていないボリュームをリストアップする。すべての暗号化されていないボリュームをその場で暗号化するスクリプトを実行する。
C. 暗号化されていない各ボリュームのスナップショットを作成する。暗号化されていないスナップショットから新しい暗号化されたボリュームを作成する。既存のボリュームをデタッチし、暗号化されたボリュームで置き換える。
D. AWS Organizationsで組織を作成する。AWS Control Towerをセットアップし、必須の統制（ガードレール）を有効にする。すべてのアカウントを組織に参加させる。AWSアカウントをOUに分類する。
E. AWS CloudTrailを有効にする。暗号化されていないボリュームを検出し自動的に暗号化するAmazon EventBridgeルールを設定する。
この問題は既存の暗号化されていないEBSボリュームの暗号化と、将来の自動検出・管理について問われています。
選択肢Aが正解である理由：
AWS Control Towerの強く推奨される統制には、EBSボリュームの暗号化を強制するガードレールが含まれています。これにより、将来作成されるすべてのEBSボリュームが自動的に暗号化され、暗号化されていないボリュームの作成を防ぐことができます。AWS Organizationsと組み合わせることで、複数のAWSアカウントを中央管理し、コンプライアンスとセキュリティを確保できます。強く推奨される統制は、必須統制よりも包括的なセキュリティ制御を提供します。
選択肢Cが正解である理由：
EBSボリュームは作成後にその場で暗号化することができません。既存の暗号化されていないボリュームを暗号化するには、スナップショットを作成し、そのスナップショットから暗号化されたボリュームを作成して置き換える必要があります。この方法は既存のデータを保持しながら暗号化を実現する標準的な手順です。
他の選択肢が不適切な理由：
選択肢B：EBSボリュームは作成後にその場で暗号化することはできません。この操作は技術的に不可能です。
選択肢D：必須の統制だけでは、EBSボリュームの暗号化強制など、セキュリティに関する包括的な制御が含まれていない可能性があります。強く推奨される統制の方が適切です。
選択肢E：CloudTrailとEventBridgeでボリュームの作成イベントを検出することは可能ですが、自動暗号化を実現するのは複雑で、Control Towerのガードレールを使用する方が効率的です。
AWS Control Towerの強く推奨される統制とスナップショットベースの暗号化の組み合わせが、現在の問題と将来の予防の両方を解決する最適なソリューションです。
A. AWS Storage Gateway Volume Gatewayを作成する。Volume Gatewayからオンプレミスファイルサーバーにボリュームをマウントする。
B. ホームディレクトリをAmazon FSx for Windows File Serverに移行する。
C. ホームディレクトリをAmazon FSx for Lustreに移行する。
D. リモートユーザーをAWS Client VPNに移行する。
E. オンプレミスデータセンターからAWSへのAWS Direct Connect接続を作成する。
この問題は、リモートワーカーの増加による帯域幅圧迫とWindowsファイルサーバーのアクセス問題を解決することが求められています。
選択肢Bが正解である理由：
Amazon FSx for Windows File Serverは、フルマネージドなWindowsファイルシステムサービスです。既存のWindowsホームディレクトリを直接移行でき、Active Directory統合、SMBプロトコルサポート、Windows ACLなどの既存の機能をそのまま維持できます。AWSクラウドにファイルを配置することで、オンプレミスデータセンターへのファイルアクセストラフィックを大幅に削減できます。フルマネージドサービスのため、パッチ適用、バックアップ、可用性管理などの運用オーバーヘッドが最小限になります。
選択肢Dが正解である理由：
AWS Client VPNは、リモートユーザーがAWS VPC内のリソースに直接アクセスできるマネージドVPNサービスです。リモートユーザーがオンプレミスVPNを経由せずに、直接AWS上のFSx for Windows File Serverにアクセスできるようになります。これにより、オンプレミスデータセンターへの帯域幅使用量を劇的に削減し、フルマネージドサービスのため運用オーバーヘッドも最小限になります。
他の選択肢が不適切な理由：
選択肢A：Volume Gatewayはオンプレミスとクラウド間でブロックレベルストレージを提供しますが、ファイルレベルのアクセスには適していません。また、データは依然としてオンプレミスに保存されるため、帯域幅問題の根本的な解決になりません。
選択肢C：Amazon FSx for LustreはHPC（ハイパフォーマンスコンピューティング）向けのファイルシステムで、Windowsホームディレクトリには適していません。POSIXベースのファイルシステムのため、Windows環境との互換性に問題があります。
選択肢E：Direct Connect接続は帯域幅を増加させますが、根本的な問題であるリモートユーザーがオンプレミスリソースにアクセスする必要性を解決しません。また、高コストで運用オーバーヘッドも増加します。
FSx for Windows File ServerとAWS Client VPNの組み合わせにより、Windowsファイル環境をクラウドに移行し、リモートユーザーが直接AWSリソースにアクセスできる最適なソリューションを実現できます。
A. Application Load Balancerの背後にEC2 Auto Scalingグループを作成する。DBインスタンス用に追加のリードレプリカを作成する。Amazon Kinesisデータストリームを作成し、アプリケーションサービスがデータストリームを使用するように設定する。静的コンテンツをAmazon S3から直接保存・配信する。
B. Application Load Balancerの背後にEC2 Auto Scalingグループを作成する。DBインスタンスをMulti-AZモードでデプロイし、ストレージ自動スケーリングを有効にする。Amazon Kinesisデータストリームを作成し、アプリケーションサービスがデータストリームを使用するように設定する。静的コンテンツをAmazon S3から直接保存・配信する。
C. Application Load Balancerの背後のEC2インスタンス上に作成されたKubernetesクラスター上にアプリケーションをデプロイする。DBインスタンスをMulti-AZモードでデプロイし、ストレージ自動スケーリングを有効にする。Amazon Managed Streaming for Apache Kafkaクラスターを作成し、アプリケーションサービスがクラスターを使用するように設定する。Amazon CloudFrontディストリビューションの背後のAmazon S3に静的コンテンツを保存する。
D. AWS FargateでAmazon Elastic Kubernetes Service（Amazon EKS）上にアプリケーションをデプロイし、Application Load Balancerの背後で自動スケーリングを有効にする。DBインスタンス用に追加のリードレプリカを作成する。Amazon Managed Streaming for Apache Kafkaクラスターを作成し、アプリケーションサービスがクラスターを使用するように設定する。Amazon CloudFrontディストリビューションの背後のAmazon S3に静的コンテンツを保存する。
この問題は運用オーバーヘッドの削減と製品リリース時のスケーラビリティ対応について問われています。
選択肢Dが正解である理由：
Amazon EKS with Fargateは、Kubernetesクラスターの管理をAWSに委ねることで運用オーバーヘッドを大幅に削減します。サーバーレスコンテナ実行により、インフラストラクチャの管理が不要になり、自動スケーリングが容易に実現できます。Amazon Managed Streaming for Apache Kafka（MSK）は、Kafkaクラスターの運用・保守・スケーリングをAWSが管理するため、自社でKafkaクラスターを維持する必要がなくなります。リードレプリカの追加により読み取り性能を向上させ、CloudFrontを使用することで静的コンテンツの配信性能と可用性を向上させます。これらの組み合わせにより、運用オーバーヘッドを最小限に抑えながら高いスケーラビリティを実現できます。
他の選択肢が不適切な理由：
選択肢A：Kinesisに変更することでKafkaとの互換性問題が発生する可能性があります。また、EC2ベースのアプローチは運用オーバーヘッドが高くなります。CloudFrontを使用していないため、静的コンテンツの配信が最適化されていません。
選択肢B：選択肢Aと同様に、Kinesisへの変更が問題となる可能性があります。Multi-AZは可用性向上には有効ですが、読み取り性能の向上には寄与しません。
選択肢C：EC2上でのKubernetesクラスター管理は、EKSと比較して運用オーバーヘッドが大幅に高くなります。クラスターの更新、セキュリティパッチ、可用性管理などを自社で行う必要があります。
EKS with FargateとMSKの組み合わせは、コンテナ化されたアプリケーションとKafkaを使用する現在の構成を維持しながら、運用オーバーヘッドを最小限に抑える最適なソリューションです。
A. 各メンバーアカウントでOrganizationAccountAccess IAMグループを作成する。各管理者に必要なIAMロールを含める。
B. 各メンバーアカウントでOrganizationAccountAccessPolicy IAMポリシーを作成する。クロスアカウントアクセスを使用してメンバーアカウントを管理アカウントに接続する。
C. 各メンバーアカウントでOrganizationAccountAccessRole IAMロールを作成する。管理アカウントがIAMロールを引き受ける権限を付与する。
D. 管理アカウントでOrganizationAccountAccessRole IAMロールを作成する。IAMロールにAdministratorAccess AWSマネージドポリシーをアタッチする。各メンバーアカウントの管理者にIAMロールを割り当てる。
この問題はAWS Organizationsにおけるクロスアカウントアクセスの設定について問われています。
選択肢Cが正解である理由：
AWS Organizationsでは、管理アカウントがメンバーアカウントを中央管理するために、各メンバーアカウントにOrganizationAccountAccessRoleという特定の名前のIAMロールを作成する必要があります。このロールは、管理アカウントの特定のプリンシパル（通常は管理アカウントのroot）が引き受けることができるように信頼関係を設定します。管理アカウントからこのロールを引き受けることで、メンバーアカウント内のリソースに対する管理権限を取得できます。これにより、中央管理アカウントから各メンバーアカウントの請求情報の確認、アクセスポリシーの管理、リソースの監視などが可能になります。
他の選択肢が不適切な理由：
選択肢A：OrganizationAccountAccessはグループ名として標準的ではありません。また、グループは同一アカウント内でのアクセス管理に使用されるもので、クロスアカウントアクセスには適していません。
選択肢B：OrganizationAccountAccessPolicyという名前のポリシーを作成するだけでは、管理アカウントがメンバーアカウントにアクセスするための仕組みが不完全です。クロスアカウントアクセスには信頼関係を持つIAMロールが必要です。
選択肢D：管理アカウント側にロールを作成しても、メンバーアカウントのリソースにはアクセスできません。クロスアカウントアクセスを実現するには、アクセス先のアカウント（メンバーアカウント）側にロールを作成し、アクセス元のアカウント（管理アカウント）がそのロールを引き受けられるように設定する必要があります。
AWS Organizationsにおいて、OrganizationAccountAccessRoleは管理アカウントがメンバーアカウントを管理するための標準的な仕組みであり、中央集権的な管理を実現するための基本的な設定です。
A. API Gateway用のインターフェースVPCエンドポイントを作成する。apigateway:*アクションを許可するエンドポイントポリシーをアタッチする。VPCエンドポイント用のプライベートDNS命名を無効にする。VPCからのアクセスを許可するAPIリソースポリシーを設定する。VPCエンドポイントのDNS名を使用してAPIにアクセスする。
B. API Gateway用のインターフェースVPCエンドポイントを作成する。execute-api:Invokeアクションを許可するエンドポイントポリシーをアタッチする。VPCエンドポイント用のプライベートDNS命名を有効にする。VPCエンドポイントからのアクセスを許可するAPIリソースポリシーを設定する。APIエンドポイントのDNS名を使用してAPIにアクセスする。
C. Network Load Balancer（NLB）とVPCリンクを作成する。API GatewayとNLB間のプライベート統合を設定する。APIエンドポイントのDNS名を使用してAPIにアクセスする。
D. Application Load Balancer（ALB）とVPCリンクを作成する。API GatewayとALB間のプライベート統合を設定する。ALBエンドポイントのDNS名を使用してAPIにアクセスする。
この問題はプライベートAPI Gateway APIにVPC内のEC2インスタンスからアクセスするための設定について問われています。
選択肢Bが正解である理由：
プライベートAPI Gateway APIにVPC内からアクセスするには、API Gateway用のインターフェースVPCエンドポイントが必要です。execute-api:Invokeアクションを許可するエンドポイントポリシーにより、API実行権限を適切に制御します。プライベートDNS命名を有効にすることで、VPC内のリソースがAPI GatewayのパブリックDNS名（例：https://api-id.execute-api.region.amazonaws.com）を使用して、自動的にVPCエンドポイント経由でアクセスできるようになります。APIリソースポリシーでVPCエンドポイントからのアクセスを許可することで、セキュリティを確保しながらアクセスを制御します。この設定により、既存のAPIエンドポイントのDNS名をそのまま使用でき、アプリケーションコードの変更が不要になります。
他の選択肢が不適切な理由：
選択肢A：プライベートDNS命名を無効にすると、VPCエンドポイントの特定のDNS名を使用する必要があり、アプリケーションコードの変更が必要になります。また、apigateway:*は過度に広範な権限であり、セキュリティのベストプラクティスに反します。
選択肢C：VPCリンクとNLBは、パブリックAPI GatewayからVPC内のプライベートリソースにアクセスする場合に使用されます。この問題では、VPC内からプライベートAPIにアクセスする逆の状況であるため、適切ではありません。
選択肢D：ALBとVPCリンクも選択肢Cと同様の理由で適切ではありません。さらに、ALBを使用してもプライベートAPIへのアクセス問題は解決されません。
インターフェースVPCエンドポイントとプライベートDNS命名の組み合わせは、プライベートAPIへのアクセスを実現する標準的で効率的なソリューションです。
A. 既存のVPCを更新し、カスタムIPv6 CIDRブロックをVPCとすべてのサブネットに関連付ける。すべてのVPCルートテーブルを更新し、インターネットゲートウェイへの::/0のルートを追加する。
B. 既存のVPCを更新し、Amazon提供のIPv6 CIDRブロックをVPCとすべてのサブネットに関連付ける。すべてのプライベートサブネット用のVPCルートテーブルを更新し、NATゲートウェイへの::/0のルートを追加する。
C. 既存のVPCを更新し、Amazon提供のIPv6 CIDRブロックをVPCとすべてのサブネットに関連付ける。Egress-onlyインターネットゲートウェイを作成する。すべてのプライベートサブネット用のVPCルートテーブルを更新し、Egress-onlyインターネットゲートウェイへの::/0のルートを追加する。
D. 既存のVPCを更新し、カスタムIPv6 CIDRブロックをVPCとすべてのサブネットに関連付ける。新しいNATゲートウェイを作成し、IPv6サポートを有効にする。すべてのプライベートサブネット用のVPCルートテーブルを更新し、IPv6対応NATゲートウェイへの::/0のルートを追加する。
この問題はIPv6移行とプライベートサブネットのセキュリティ要件について問われています。
選択肢Cが正解である理由：
Amazon提供のIPv6 CIDRブロックを使用することで、グローバルに一意でルーティング可能なIPv6アドレスを取得できます。Egress-only インターネットゲートウェイは、IPv6専用のコンポーネントで、プライベートサブネット内のリソースがインターネットへのアウトバウンド接続（HTTPSリクエスト、ソフトウェア更新など）を行えるようにしながら、インターネットからのインバウンド接続を完全に遮断します。これにより、プライベートサブネット内のEC2インスタンスがパブリックインターネットからアクセス可能にならないという要件を満たしながら、必要なアウトバウンド通信を可能にします。IPv6ではNAT変換が不要なため、Egress-onlyインターネットゲートウェイが最適なソリューションです。
他の選択肢が不適切な理由：
選択肢A：すべてのサブネットのルートテーブルにインターネットゲートウェイへのルートを追加すると、プライベートサブネット内のインスタンスがパブリックインターネットからアクセス可能になってしまい、セキュリティ要件に違反します。また、カスタムIPv6 CIDRブロックは管理が複雑で、Amazon提供のものを使用する方が推奨されます。
選択肢B：NATゲートウェイはIPv4専用のサービスで、IPv6トラフィックをサポートしていません。IPv6では概念的にNATが不要であり、代わりにEgress-onlyインターネットゲートウェイを使用します。
選択肢D：前述の通り、NATゲートウェイはIPv6をサポートしていません。また、カスタムIPv6 CIDRブロックよりもAmazon提供のものを使用する方が管理が簡単です。
Egress-onlyインターネットゲートウェイは、IPv6環境でプライベートサブネット内のリソースが外部にアクセスしながらもセキュリティを維持するための専用コンポーネントです。
最近の監査により、一部のインスタンスでこのタグが欠落していることが判明しました。企業は手動で欠落しているタグをインスタンスに追加しました。
将来的にタグ付け要件を強制するために、ソリューションアーキテクトは何をすべきでしょうか？
A. 組織でタグポリシーを有効にする。BusinessUnitタグのタグポリシーを作成する。タグキーの大文字小文字の一致コンプライアンスをオフにする。ec2:instanceリソースタイプにタグポリシーを実装する。タグポリシーを組織のルートにアタッチする。
B. 組織でタグポリシーを有効にする。BusinessUnitタグのタグポリシーを作成する。タグキーの大文字小文字の一致コンプライアンスをオンにする。ec2:instanceリソースタイプにタグポリシーを実装する。タグポリシーを組織の管理アカウントにアタッチする。
C. SCPを作成し、組織のルートにSCPをアタッチする。SCPに以下のステートメントを含める：
```json
{
"Sid": "DenyEC2Creation",
"Effect": "Deny",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"Null": {
"aws:RequestTag/BusinessUnit": "true"
}
}
}
```
D. SCPを作成し、組織の管理アカウントにSCPをアタッチする。SCPに以下のステートメントを含める：
```json
{
"Sid": "DenyEC2Creation",
"Effect": "Deny",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
],
"Condition": {
"Null": {
"aws:RequestTag/BusinessUnit": "false"
}
}
}
```
解説
この問題は、EC2インスタンスにBusinessUnitタグが必ず付与されることを強制する仕組みについて問われています。
各選択肢を分析してみましょう：
A. タグポリシーは既存のリソースのタグを監視し、コンプライアンス違反を報告する機能ですが、新しいリソースの作成を阻止することはできません。また、大文字小文字の一致をオフにすることは、一貫性のある実装には適していません。
B. タグポリシーは監視機能のみであり、リソース作成を阻止する機能はありません。また、組織の管理アカウントのみにアタッチしても、他のアカウントには適用されません。
C. これが正解です。SCPを組織のルートにアタッチすることで、すべてのメンバーアカウントに適用されます。条件で「aws:RequestTag/BusinessUnit」が「true」（存在しない）場合にec2:RunInstancesアクションを拒否するため、BusinessUnitタグなしでEC2インスタンスを作成することを防げます。
D. SCPを管理アカウントのみにアタッチしても、他のメンバーアカウントには適用されません。また、条件で「false」を指定すると、タグが存在する場合に拒否することになり、求められる動作と逆になります。
SCPを使用することで、BusinessUnitタグが付与されていないEC2インスタンスの作成を組織全体で確実に阻止できます。
A. インプレースデプロイメント用に設定されたAWS CodeDeployを使用するデプロイステージでCodePipelineを設定する。新しくデプロイされたコードを監視し、問題がある場合は別のコード更新をプッシュする。
B. ブルー/グリーンデプロイメント用に設定されたAWS CodeDeployを使用するデプロイステージでCodePipelineを設定する。新しくデプロイされたコードを監視し、問題がある場合はCodeDeployを使用して手動ロールバックをトリガーする。
C. テストと本番スタック用のパイプラインを作成するためにAWS CloudFormationを使用するデプロイステージでCodePipelineを設定する。新しくデプロイされたコードを監視し、問題がある場合は別のコード更新をプッシュする。
D. AWS OpsWorksとインプレースデプロイメントを使用するデプロイステージでCodePipelineを設定する。新しくデプロイされたコードを監視し、問題がある場合は別のコード更新をプッシュする。
この問題では、迅速なパッチデプロイメント、最小限のダウンタイム、そして迅速なロールバック機能という3つの重要な要件があります。これらの要件を満たすためには、デプロイメント戦略の選択が極めて重要です。
インプレースデプロイメントは、既存のインスタンス上で直接アプリケーションを更新する方法です。この方法では、デプロイメント中にサービスが一時的に利用できなくなる可能性があり、問題が発生した場合のロールバックも時間がかかります。選択肢A、D、およびCの一部でこの問題があります。
ブルー/グリーンデプロイメントは、新しいバージョンのアプリケーション用に完全に新しい環境（グリーン環境）を作成し、現在の環境（ブルー環境）と並行して実行する戦略です。新しい環境でテストが完了すると、トラフィックを新しい環境に切り替えます。この方法の最大の利点は、ダウンタイムがほぼゼロであることと、問題が発生した場合に元の環境に即座に切り戻すことができることです。
CodeDeployのブルー/グリーンデプロイメント機能は、Application Load Balancerと統合されており、トラフィックの段階的な切り替えや即座のロールバックをサポートしています。これにより、新しいバージョンに問題がある場合でも、手動でトリガーすることで迅速にロールバックが可能です。
CloudFormationを使用したアプローチ（選択肢C）は、インフラストラクチャの管理には適していますが、アプリケーションコードの迅速なデプロイメントとロールバックには最適化されていません。OpsWorksを使用したアプローチ（選択肢D）も、この特定の要件には適していません。
選択肢Bが最適な理由は、CodeDeployのブルー/グリーンデプロイメント機能により、最小限のダウンタイムで迅速なデプロイメントが可能であり、問題が発生した場合の手動ロールバック機能も提供されるためです。これにより、CISOが求める迅速なパッチ適用と信頼性の高いロールバック機能の両方が実現されます。
最小の運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？
A. 各リージョンにバケットと暗号化メトリクスを追跡するための新しいS3 Storage Lensダッシュボードを作成する。両方のリージョンダッシュボードからのデータをコンプライアンスチーム用のAmazon QuickSightの単一ダッシュボードに集約する。
B. 各リージョンにAWS Lambda関数をデプロイして、バケット数とオブジェクトの暗号化ステータスをリストアップする。このデータをAmazon S3に保存する。Amazon Athenaクエリを使用して、コンプライアンスチーム用のAmazon QuickSightのカスタムダッシュボードにデータを表示する。
C. S3 Storage Lensのデフォルトダッシュボードを使用してバケットと暗号化メトリクスを追跡する。コンプライアンスチームにS3コンソール内のダッシュボードへの直接アクセスを提供する。
D. S3オブジェクト作成のAWS CloudTrailイベントを検出するAmazon EventBridgeルールを作成する。暗号化メトリクスをAmazon DynamoDBに記録するAWS Lambda関数を呼び出すようにルールを設定する。Amazon QuickSightを使用してコンプライアンスチーム用のダッシュボードにメトリクスを表示する。
解説
この問題は「最小の運用オーバーヘッド」で要件を満たすソリューションを求めています。各選択肢を分析してみましょう。
選択肢Cが正解である理由：
S3 Storage Lensはデフォルトでバケットメトリクス（バケット数、ストレージ使用量、暗号化状況など）を自動的に収集し、すべてのリージョンの情報を統合して表示します。デフォルトダッシュボードには暗号化されたオブジェクトの割合も含まれており、追加の設定や開発作業が不要です。コンプライアンスチームは直接S3コンソールからアクセスでき、運用オーバーヘッドが最小です。
他の選択肢が適切でない理由：
選択肢A：各リージョンに個別のStorage Lensダッシュボードを作成し、さらにQuickSightで集約する必要があり、複雑な設定と追加コストが発生します。
選択肢B：Lambda関数の開発・デプロイ、Athenaクエリの作成、QuickSightダッシュボードの構築など、大きな開発・運用オーバーヘッドが発生します。
選択肢D：EventBridge、Lambda、DynamoDB、QuickSightを組み合わせた複雑なアーキテクチャで、リアルタイム処理によるコストと運用負荷が高くなります。
S3 Storage Lensのデフォルトダッシュボードは、組織全体のS3使用状況を可視化するために設計されており、マルチリージョン対応で暗号化メトリクスも標準で含まれているため、この要件に最適なソリューションです。
A. us-east-1でPrivateLinkエンドポイントサービスを設定し、eu-west-2にある既存のNLBを使用する。特定のAWSアカウントにSaaSサービスへの接続アクセスを許可する。
B. us-east-1でNLBを作成する。SaaSサービスをホストするeu-west-2にある同社のインスタンスのIPアドレスを使用するIPターゲットグループを作成する。us-east-1にあるNLBを使用するPrivateLinkエンドポイントサービスを設定する。特定のAWSアカウントにSaaSサービスへの接続アクセスを許可する。
C. eu-west-2のEC2インスタンスの前にApplication Load Balancer（ALB）を作成する。us-east-1でNLBを作成する。us-east-1のNLBを、eu-west-2のALBを使用するALBターゲットグループに関連付ける。us-east-1のNLBを使用するPrivateLinkエンドポイントサービスを設定する。特定のAWSアカウントにSaaSサービスへの接続アクセスを許可する。
D. AWS Resource Access Manager（AWS RAM）を使用して、eu-west-2にあるEC2インスタンスを共有する。us-east-1で、eu-west-2からの共有EC2インスタンスを含むNLBとインスタンスターゲットグループを作成する。us-east-1のNLBを使用するPrivateLinkエンドポイントサービスを設定する。特定のAWSアカウントにSaaSサービスへの接続アクセスを許可する。
解説
この問題では、既存のeu-west-2のリソースを活用しながら、us-east-1の新しい顧客にPrivateLinkサービスを提供する必要があります。キーポイントは「us-east-1に新しいEC2リソースをすぐにデプロイしたくない」という制約です。
選択肢Bが正解である理由：
NLBはクロスリージョンのIPターゲットをサポートしています。us-east-1にNLBを作成し、eu-west-2にある既存のEC2インスタンスのIPアドレスを直接ターゲットとして指定できます。VPCピアリングが既に確立されているため、us-east-1のNLBからeu-west-2のインスタンスへの通信が可能です。このNLBを使用してPrivateLinkエンドポイントサービスを設定することで、us-east-1の顧客は同一リージョン内のPrivateLinkを通じてサービスにアクセスできます。
他の選択肢が適切でない理由：
選択肢A：PrivateLinkエンドポイントサービスは、そのサービスが作成されたリージョンでのみ利用可能です。eu-west-2のNLBを使用してus-east-1でエンドポイントサービスを作成することはできません。
選択肢C：NLBはALBをターゲットとして直接サポートしていません。ALBターゲットグループという概念は存在しないため、この設定は技術的に不可能です。
選択肢D：AWS RAMはEC2インスタンスの共有をサポートしていません。また、仮に共有できたとしても、異なるリージョンのインスタンスをターゲットグループに直接追加することはできません。
この解決策により、新しいEC2リソースをデプロイすることなく、既存のアーキテクチャを活用してクロスリージョンでPrivateLinkサービスを提供できます。
• 管理者：分析チームの要件に基づいてEMRクラスターをプロビジョニングする
• データエンジニア：ETLスクリプトを実行してデータセットの処理、変換、強化を行う
• データアナリスト：SQLおよびHiveクエリをデータに対して実行する
ソリューションアーキテクトは、すべてのユーザーペルソナが必要なリソースのみに最小権限でアクセスできるようにする必要があります。また、ユーザーは承認されたアプリケーションのみを起動できるようにする必要があります。さらに、ユーザーが作成するすべてのリソースにタグ付けを行う必要があります。
この要件を満たすソリューションはどれですか？
A. 各ユーザーペルソナにIAMロールを作成し、ロールを引き受けたユーザーが実行できるアクションを定義するIDベースのポリシーをアタッチする。非準拠リソースをチェックするAWS Configルールを作成し、非準拠リソースの修正を管理者に通知するように構成する。
B. EMRクラスターの起動時にKerberosベースの認証を設定する。Kerberosセキュリティ構成とクラスター固有のKerberosオプションを指定する。
C. AWS Service Catalogを使用して、デプロイ可能なAmazon EMRのバージョン、クラスター構成、および各ユーザーペルソナの権限を制御する。
D. AWS CloudFormationを使用してEMRクラスターを起動し、クラスター作成時にリソースベースのポリシーをアタッチする。非準拠のクラスターやAmazon S3バケットをチェックするAWS Configルールを作成し、非準拠リソースの修正を管理者に通知するように構成する。
AWS Service Catalogを使用することで、事前承認されたEMRバージョンや構成テンプレートを提供し、ユーザーが選べるオプションを制限できます。これにより、ユーザーは承認された構成のクラスターのみを起動でき、組織の標準に沿った設定（タグの強制やリソース制限など）を確実に適用できます。また、各ユーザーペルソナに応じたアクセス権限も定義可能で、最小権限の原則を実現できます。
他の選択肢について：
A はIAMとConfigによる制御ですが、クラスター構成やアプリケーションの制限、強制タグ付けの管理に関しては不十分です。
B はEMR内のユーザー認証を強化するもので、リソース制御やアクセス制限とは関係がありません。
D はCloudFormationによる制御が可能ですが、ユーザーごとのアクセス制御や承認済み構成の管理に関して柔軟性が低く、Service Catalogの方が適しています。
データのバックアップは毎日行う必要があり、指定されたソースディレクトリ内の特定のデータのみを対象に、カスタムフィルターを適用してバックアップを実行する必要があります。企業はすでにAWS Direct Connect接続を設定済みです。
最も運用負荷が少ない形でバックアップ要件を満たすソリューションはどれですか？
A. 既存のデータをAmazon S3にコピーするために、マルチパートアップロードを使用してAmazon S3のCopyObject API操作を使用する。新しいデータを毎日S3に複製するためにもCopyObject API操作を使用する。
B. AWS Backupでバックアッププランを作成し、Amazon S3にデータをバックアップする。バックアッププランを毎日実行するようにスケジュールする。
C. オンプレミスのハイパーバイザー上で動作するVMとしてAWS DataSyncエージェントをインストールする。毎日S3にデータを複製するDataSyncタスクを構成する。
D. 初回のバックアップにはAWS Snowball Edgeデバイスを使用し、日次の増分バックアップにはAWS DataSyncを使用してS3に転送する。
AWS DataSync は、オンプレミスとAmazon S3間の大容量データ転送を自動化・高速化するサービスであり、フィルタリング（インクルード/エクスクルードルール）やスケジューリングをサポートしています。DataSyncエージェントをオンプレミスに設置することで、ローカルディレクトリを指定して、特定のファイルだけを対象に日次バックアップが可能になります。また、AWS Direct Connectを利用することで転送速度とセキュリティが向上します。これにより、最小限の運用負荷で要件を満たすことができます。
他の選択肢について：
A：CopyObject APIはS3内のオブジェクトのコピーに使用されるもので、オンプレミスからのデータ移行には適していません。
B：AWS Backupは主にAWSリソース（EBS、RDSなど）のバックアップに用いられ、オンプレミスデータの直接バックアップには使えません。
D：Snowball Edgeは初期データ移行には適していますが、日次バックアップに使うには運用コストや複雑性が高くなり、最小運用負荷という条件に合致しません。
A. パーティション配置グループでメモリ最適化EC2インスタンスを起動する。
B. パーティション配置グループでコンピューティング最適化EC2インスタンスを起動する。
C. クラスター配置グループでメモリ最適化EC2インスタンスを起動する。
D. スプレッド配置グループでコンピューティング最適化EC2インスタンスを起動する。
解説
この問題では、分散インメモリデータベースに最適なEC2配置戦略を選択する必要があります。要件は「可能な限り最低のネットワークレイテンシ」です。
選択肢Cが正解である理由：
1. クラスター配置グループ：同一のアベイラビリティーゾーン内の物理的に近接したハードウェア上にインスタンスを配置し、インスタンス間で10Gbpsネットワークパフォーマンスと最低レイテンシを提供します。これは分散データベースのノード間通信に最適です。
2. メモリ最適化インスタンス：インメモリデータベースは大量のメモリを必要とするため、メモリ最適化インスタンス（R5、R6i、X1eなど）が適切です。これらのインスタンスは高いメモリ対vCPU比を提供し、インメモリワークロードに最適化されています。
他の選択肢が適切でない理由：
選択肢A・B（パーティション配置グループ）：パーティション配置グループは異なる物理ハードウェア上にインスタンスを分散配置するため、ネットワークレイテンシが高くなります。これは耐障害性を向上させますが、パフォーマンス要件には適していません。
選択肢D（スプレッド配置グループ）：各インスタンスを異なる物理ハードウェア上に配置するため、最も高いレイテンシになります。また、コンピューティング最適化インスタンスはインメモリデータベースには不適切です。
分散インメモリデータベースでは、ノード間の頻繁なデータ同期と通信が発生するため、最低レイテンシが性能に直結します。クラスター配置グループとメモリ最適化インスタンスの組み合わせが、この要件を最も効果的に満たします。
A. 新しいAWS CloudTrailトレイルを作成する。組織の管理アカウント内の既存のAmazon S3バケットを使用してログを保存する。すべてのAWSリージョンにトレイルをデプロイする。S3バケットでMFA削除と暗号化を有効にする。
B. 組織の各メンバーアカウントに新しいAWS CloudTrailトレイルを作成する。ログを保存するための新しいAmazon S3バケットを作成する。すべてのAWSリージョンにトレイルをデプロイする。S3バケットでMFA削除と暗号化を有効にする。
C. 組織の管理アカウントに新しいAWS CloudTrailトレイルを作成する。ログを保存するためにバージョニングを有効にした新しいAmazon S3バケットを作成する。組織内のすべてのアカウント用にトレイルをデプロイする。S3バケットでMFA削除と暗号化を有効にする。
D. 組織の管理アカウントに新しいAWS CloudTrailトレイルを作成する。ログを保存するための新しいAmazon S3バケットを作成する。ログを追跡する外部管理システムにログファイル配信通知を送信するAmazon Simple Notification Service（Amazon SNS）を設定する。S3バケットでMFA削除と暗号化を有効にする。
解説
この問題では、AWS Organizations環境での包括的なAPI監査ログ収集を最小の運用オーバーヘッドで実現する必要があります。
選択肢Cが正解である理由：
組織レベルのCloudTrail：管理アカウントで作成した組織トレイルは、組織内のすべてのメンバーアカウントのAPI呼び出しを自動的に収集します。これにより、各アカウントで個別にトレイルを設定する必要がなくなり、運用オーバーヘッドが大幅に削減されます。
S3バケットのバージョニング：バージョニングを有効にすることで、ログファイルの誤削除や破損からの保護が強化され、規制要件である「耐久性があり安全なデータストア」を満たします。
セキュリティ機能：MFA削除と暗号化により、ログの改ざんや不正アクセスを防止し、金融業界の厳格なセキュリティ要件を満たします。
グローバル対応：組織トレイルはデフォルトですべてのリージョンをカバーし、グローバル展開のSaaSプラットフォームに適しています。
他の選択肢が適切でない理由：
選択肢A：既存のS3バケットを使用するのは、専用のログストレージとしては適切ではなく、他の用途との混在により管理が複雑になります。
選択肢B：各メンバーアカウントで個別にトレイルを作成するのは運用オーバーヘッドが最大であり、複数のS3バケット管理も必要になり非効率的です。
選択肢D：外部管理システムへの通知は追加の複雑性を導入し、運用オーバーヘッドを増加させます。問題の要件を満たすのに必要ではありません。
組織レベルのCloudTrailは、AWS Organizations環境での監査ログ収集において最も効率的で包括的なソリューションです。
A. Migration Evaluatorを使用してAWSから環境の評価を要求する。AWS Application Discovery Service Agentless Collectorを使用して詳細をMigration Evaluator Quick Insightsレポートにインポートする。
B. AWS Migration Hubを使用し、サーバーにAWS Application Discovery Agentをインストールする。Migration Hub Strategy Recommendationsアプリケーションデータコレクターをデプロイする。Migration Hub Strategy Recommendationsを使用してレポートを生成する。
C. AWS Migration Hubを使用し、サーバーでAWS Application Discovery Service Agentless Collectorを実行する。AWS Application Migration Serviceを使用してサーバーとデータベースをグループ化する。Migration Hub Strategy Recommendationsを使用してレポートを生成する。
D. AWS Migration Hubインポートツールを使用して企業のオンプレミス環境の詳細をロードする。Migration Hub Strategy Recommendationsを使用してレポートを生成する。
解説
この問題では、正確なインベントリが不足している環境でのアプリケーション発見、ネットワーク接続、アプリケーション関係の把握、および移行計画策定が求められています。
選択肢Bが正解である理由：
1. AWS Migration Hub：移行プロセス全体を統合管理するハブとして機能し、様々な移行ツールからの情報を集約できます。
2. AWS Application Discovery Agent：サーバーにインストールするエージェント型のツールで、詳細なシステム情報、ネットワーク接続、アプリケーション依存関係を収集できます。物理サーバーと仮想サーバーの両方に対応しており、WindowsとLinuxの両方をサポートします。
3. Migration Hub Strategy Recommendations：収集されたデータを基に、各アプリケーションに最適な移行戦略（Rehost、Replatform、Refactor等）を推奨し、包括的な移行計画を策定できます。
4. アプリケーションデータコレクター：アプリケーションレベルの詳細情報を収集し、より精密な分析を可能にします。
他の選択肢が適切でない理由：
選択肢A：Migration Evaluatorは主にコスト分析に焦点を当てており、ネットワーク接続やアプリケーション関係の詳細な把握には限界があります。
選択肢C：Agentless Collectorは限定的な情報しか収集できず、詳細なアプリケーション依存関係やネットワーク接続の把握には不十分です。また、AWS Application Migration Serviceは実際の移行実行ツールであり、発見段階では不適切です。
選択肢D：インポートツールは既存のインベントリデータが前提ですが、問題文では「正確なインベントリを持っていない」と明記されており、使用できません。
エージェント型の発見ツールは、エージェントレス型と比較してより詳細で正確な情報を収集でき、特にアプリケーション間の依存関係やネットワーク通信パターンの把握に優れています。
A. アプリケーションを実行するコンテナをAmazon Elastic Kubernetes Service（Amazon EKS）に移行する。コンテナが共有するトランザクションデータを保存するためにAmazon S3を使用する。
B. アプリケーションを実行するコンテナをAmazon Elastic Container Service（Amazon ECS）のAWS Fargateに移行する。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。Fargateタスク定義を作成する。EFSファイルシステムを指すボリュームをタスク定義に追加する。
C. アプリケーションを実行するコンテナをAmazon Elastic Container Service（Amazon ECS）のAWS Fargateに移行する。Amazon Elastic Block Store（Amazon EBS）ボリュームを作成する。Fargateタスク定義を作成する。EBSボリュームを実行中の各タスクにアタッチする。
D. Amazon EC2インスタンスを起動する。EC2インスタンスにDockerをインストールする。コンテナをEC2インスタンスに移行する。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。EFSファイルシステム用のマウントポイントをEC2インスタンスに追加する。
解説
この問題では、時間に敏感なトランザクション処理、予測不可能なトランザクション量、共有ストレージの要件、そして管理負荷の軽減が求められています。
選択肢Bが正解である理由：
1. AWS Fargate：サーバーレスなコンテナオーケストレーションサービスで、インフラストラクチャの管理が不要になります。「Dockerホスティング環境の管理を続けることができない」という要件を満たします。
2. Amazon ECS：Dockerコンテナの管理に最適化されており、既存のコンテナベースアプリケーションの移行が簡単です。
3. Amazon EFS：
- 複数のコンテナ間での共有ストレージを提供
- 低レイテンシーアクセス（特にGeneral Purpose Performance Mode）
- 需要に応じて自動的にスループットがスケール（Provisioned Throughput ModeまたはBursting Throughput Mode）
- POSIX準拠のファイルシステムで、既存のアプリケーションとの互換性が高い
4. 自動スケーリング対応：Fargateは需要に応じてタスク数を自動調整でき、EFSは自動的にスループットをスケールします。
他の選択肢が適切でない理由：
選択肢A：S3はオブジェクトストレージであり、リアルタイムのトランザクション処理には適していません。ファイルシステムレベルのアクセスが必要なアプリケーションには不適切です。
選択肢C：FargateはEBSボリュームを直接アタッチできません。また、EBSは単一インスタンスにしかアタッチできないため、複数コンテナ間での共有ストレージ要件を満たせません。
選択肢D：EC2インスタンスの使用は「Dockerホスティング環境の管理を続けることができない」という制約に反します。インフラストラクチャ管理の負荷が継続します。
この構成により、管理負荷を最小化しながら、高性能で自動スケーリング可能な共有ストレージソリューションを実現できます。
A. 他のアベイラビリティーゾーンに追加のNATゲートウェイをデプロイする。適切なルートでルートテーブルを更新する。RDS for MySQL DBインスタンスをMulti-AZ構成に変更する。アベイラビリティーゾーン間でインスタンスを起動するようにAuto Scalingグループを設定する。Auto Scalingグループの最小容量と最大容量を3に設定する。
B. NATゲートウェイを仮想プライベートゲートウェイに置き換える。RDS for MySQL DBインスタンスをAmazon Aurora MySQL DBクラスターに置き換える。VPC内のすべてのサブネットでインスタンスを起動するようにAuto Scalingグループを設定する。Auto Scalingグループの最小容量と最大容量を3に設定する。
C. NATゲートウェイをNATインスタンスに置き換える。RDS for MySQL DBインスタンスをRDS for PostgreSQL DBインスタンスに移行する。他のアベイラビリティーゾーンで新しいEC2インスタンスを起動する。
D. 他のアベイラビリティーゾーンに追加のNATゲートウェイをデプロイする。適切なルートでルートテーブルを更新する。RDS for MySQL DBインスタンスで自動バックアップを有効にし、バックアップを7日間保持する。VPC内のすべてのサブネットでインスタンスを起動するようにAuto Scalingグループを設定する。Auto Scalingグループの最小容量と最大容量を1に維持する。
解説
この問題では、単一のアベイラビリティーゾーンに集中している現在の構成を、複数のアベイラビリティーゾーンで動作する高可用性構成に変更する必要があります。
選択肢Aが正解である理由：
1. 追加のNATゲートウェイ：各アベイラビリティーゾーンに独自のNATゲートウェイを配置することで、単一障害点を排除し、一つのAZで障害が発生しても他のAZのインスタンスがインターネットアクセスを維持できます。
2. RDS Multi-AZ構成：プライマリとスタンバイのDBインスタンスを異なるAZに配置することで、データベースの高可用性を実現します。自動フェイルオーバー機能により、障害時の復旧時間を最小化します。
3. Auto Scalingグループの設定：
- アベイラビリティーゾーン間でインスタンスを分散配置
- 最小・最大容量を3に設定することで、各AZに少なくとも1つのインスタンスを配置可能
- 一つのAZで障害が発生しても、他のAZでサービス継続
4. ルートテーブルの更新：各プライベートサブネットが対応するAZのNATゲートウェイを使用するよう設定
他の選択肢が適切でない理由：
選択肢B：仮想プライベートゲートウェイはVPN接続用のコンポーネントであり、インターネットアクセス用のNATゲートウェイの代替にはなりません。また、Aurora移行は問題の要件に含まれていません。
選択肢C：NATインスタンスはNATゲートウェイより管理負荷が高く、可用性も劣ります。PostgreSQLへの移行は不要で、手動でのEC2起動はAuto Scalingの利点を活用できません。
選択肢D：容量を1に維持すると、複数AZでの分散配置ができません。バックアップの設定は可用性向上には直接寄与しません。
この構成により、ネットワーク、コンピューティング、データベースの各層で高可用性を実現し、任意の単一AZの障害に対する回復力を提供できます。
A. AWS Application Discovery Service
B. AWS SMS
C. AWS X-Ray
D. AWS Cloud Adoption Readiness Tool (CART)
E. Amazon Inspector
F. AWS Migration Hub
解説
この問題では、大規模で複雑なオンプレミス環境をクラウドに移行するための計画段階で必要なツールを選択する必要があります。特に「現在の環境を理解」し「クラウドリソースコストを見積もる」ことが要求されています。
正解の選択肢の理由：
A. AWS Application Discovery Service：
現在の環境を理解するために不可欠なツールです。エージェントベースまたはエージェントレス方式で、サーバーの構成情報、パフォーマンスデータ、ネットワーク依存関係を自動収集します。技術文書が不完全で古い状況において、正確な現状把握を可能にします。
D. AWS Cloud Adoption Readiness Tool (CART)：
組織のクラウド移行準備状況を評価し、移行計画の策定を支援します。技術的な観点だけでなく、組織的な準備状況も評価でき、包括的な移行戦略を立案するのに重要です。
F. AWS Migration Hub：
移行プロセス全体を統合管理するハブとして機能します。Application Discovery Serviceで収集したデータを統合し、移行の進捗を追跡し、コスト見積もりや移行計画の策定を支援します。複数の移行ツールからの情報を一元化できます。
不正解の選択肢の理由：
B. AWS SMS（Server Migration Service）：
実際の移行実行フェーズで使用するツールであり、計画段階では不要です。VM移行の自動化を行いますが、環境理解やコスト見積もりには適していません。
C. AWS X-Ray：
アプリケーションの分散トレーシングとパフォーマンス分析を行うサービスで、移行後の運用段階で使用します。移行計画段階では不要です。
E. Amazon Inspector：
アプリケーションのセキュリティ脆弱性評価を行うサービスで、移行計画の主要な要件ではありません。セキュリティ評価は重要ですが、この問題の焦点は環境理解とコスト見積もりです。
この3つのツールの組み合わせにより、現在の環境の包括的な把握、組織の準備状況評価、統合的な移行計画策定と進捗管理が可能になります。
A. AWS DataSyncエージェントを設定して、ソースS3バケットから宛先S3バケットにプレフィックス付きデータを複製する。タスクで利用可能なすべての帯域幅を使用するように選択し、タスクがTRANSFERRING状態にあることを確認するためにタスクを監視する。このステータスが変化した場合にアラートを開始するAmazon EventBridgeルールを作成する。
B. 第二アカウントで、最も正確なデータを持つレーダーステーションからデータを受信する別のS3バケットを作成する。この新しいS3バケット用の新しい複製ルールを設定して、他のレーダーステーションからの複製を分離する。宛先への最大複製時間を監視する。時間が希望する閾値を超えた場合にアラートを開始するAmazon EventBridgeルールを作成する。
C. ソースS3バケットでAmazon S3 Transfer Accelerationを有効にし、最も正確なデータを持つレーダーステーションを新しいエンドポイントを使用するように設定する。S3宛先バケットのTotalRequestLatencyメトリクスを監視する。このステータスが変化した場合にアラートを開始するAmazon EventBridgeルールを作成する。
D. 最も正確なデータを持つレーダーステーションのプレフィックスを使用するキーをフィルタリングするソースS3バケットに新しいS3複製ルールを作成する。S3 Replication Time Control（S3 RTC）を有効にする。宛先への最大複製時間を監視する。時間が希望する閾値を超えた場合にアラートを開始するAmazon EventBridgeルールを作成する。
解説
この問題では、特定のレーダーステーションのデータ複製を30分以内に完了させ、その監視を行う必要があります。
選択肢Dが正解である理由：
1. プレフィックスフィルタリング：特定のレーダーステーションのデータのみを対象とする専用の複製ルールを作成することで、そのデータの複製を個別に管理・監視できます。
2. S3 Replication Time Control（S3 RTC）：
- オブジェクトの複製を15分以内に完了することを保証するサービス
- 30分以内という要件を満たすのに最適
- 複製時間のメトリクスを提供し、SLA違反を監視可能
- 複製時間の詳細な追跡とアラート機能を提供
3. EventBridgeによる監視：複製時間が閾値を超えた場合に自動的にアラートを発生させることができます。
4. 既存の全体複製との共存：既存の全オブジェクト複製ルールと並行して動作し、特定のレーダーステーションデータに特別な処理を適用できます。
他の選択肢が適切でない理由：
選択肢A：DataSyncは一回限りの移行や定期的な同期に適していますが、リアルタイムの継続的な複製には不適切です。また、S3の複製機能と比較して複雑で運用オーバーヘッドが高くなります。
選択肢B：新しい宛先バケットを作成する必要はなく、複製アーキテクチャを不必要に複雑にします。また、30分以内の完了を保証する機能がありません。
選択肢C：Transfer Accelerationはアップロード速度の向上に有効ですが、複製時間の保証や監視機能は提供しません。TotalRequestLatencyメトリクスは複製完了時間を直接測定しません。
S3 RTCは時間が重要なミッションクリティカルなデータ複製において、予測可能で監視可能な複製時間を提供する最適なソリューションです。
A. 新しい開発者アカウントを作成する。すべてのEC2インスタンス、ユーザー、およびアセットをus-east-2に移動する。アカウントを会社のAWS Organizationsの組織に追加する。リージョン親和性を示すタグ付けポリシーを適用する。
B. us-east-2のt3.small EC2インスタンス以外のすべてのEC2インスタンスの起動を拒否するSCPを作成する。SCPをプロジェクトのアカウントにアタッチする。
C. us-east-2の各開発者に対してt3.small EC2リザーブドインスタンスを作成して購入する。各開発者に名前をタグとして付けた特定のEC2インスタンスを割り当てる。
D. us-east-2でのt3.small EC2インスタンスのみの起動を許可するIAMポリシーを作成する。ポリシーをプロジェクトのアカウント内で開発者が使用するロールとグループにアタッチする。
解説
この問題は、特定のアカウント内でEC2インスタンスタイプとリージョンの制限を実装する方法を問うています。
問題文で重要なポイントは、プロジェクトのアカウントがポリシー制限によりAWS Organizationsの一部になれないということです。これにより、Service Control Policy（SCP）を使用することができません。
選択肢を分析すると：
A. AWS Organizationsに参加させる提案ですが、問題文でこれはポリシー制限により不可能と明記されています。
B. SCPの使用を提案していますが、アカウントがAWS Organizations外にあるため、SCPは適用できません。SCPはAWS Organizations内のアカウントにのみ適用可能です。
C. リザーブドインスタンスの購入は費用の最適化に関するものであり、インスタンスタイプやリージョンの制限を実装するものではありません。
D. IAMポリシーを使用してt3.smallインスタンスのみの起動をus-east-2リージョンで許可し、開発者のロールとグループにアタッチする方法です。これは独立したアカウント内で実装可能で、要件を完全に満たします。
IAMポリシーはアカウント内のユーザー、グループ、ロールに対して詳細な権限制御を提供し、特定のリソースタイプや地理的制限を効果的に実装できます。AWS Organizations外のアカウントでも機能するため、この状況に最適な解決策です。
-------------