type
status
date
slug
summary
tags
category
icon
password
381-AWS SAP AWS 「理論・実践・一問道場」X-Ray APPパフォーマンス
理論
1. Amazon Aurora MySQLのパフォーマンス監視
- CloudWatch Logs: Aurora MySQLの遅いクエリやエラーログをAmazon CloudWatch Logsに送信することで、パフォーマンスの問題をトラブルシューティングできます。CloudWatch Logsでは、アプリケーションログ、データベースログなどを集中的に管理し、アラートを設定することができます。
- Slow Query Log: 長時間実行されるクエリを特定するために、遅いクエリログを有効にすると、パフォーマンスボトルネックを特定する手助けになります。
2. AWS X-Rayによるトレース
- X-Rayの使用: AWS X-Rayは、アプリケーション全体のトレースを提供し、リクエストの遅延や失敗の原因を詳細に調査するためのツールです。特に、EC2インスタンスやLambda関数のリクエストトレースに役立ち、SQLクエリをトレースすることも可能です。
- 分散トレーシング: X-Rayを使用することで、分散システムの各コンポーネント間でのリクエストの流れを視覚化でき、ボトルネックやエラーの発生場所を特定しやすくなります。
3. CloudWatch Logsによるログ収集
- Apacheログの収集: EC2インスタンス上で稼働しているApacheウェブサーバーのログをCloudWatch Logsに送信することで、ウェブサーバーのリクエストやエラーログを集中管理できます。これにより、特にトラフィックが多いピーク時に発生した問題を後から調査しやすくなります。
- CloudWatchエージェント: EC2インスタンスにCloudWatch Logsエージェントをインストールすることで、サーバーのログを自動的に収集し、リアルタイムでモニタリングできます。
4. Kinesis vs CloudWatch
- Kinesis: 主にリアルタイムデータのストリーミング処理に使用されるサービスで、ログのリアルタイム分析やデータのフィードを配信する際に役立ちます。しかし、パフォーマンス監視やトラブルシューティングにはCloudWatch Logsがより適しています。
- CloudWatch: 長期的なメトリクスの保存、ログの集約、アラートの設定、ダッシュボードの作成が可能で、アプリケーションの健康状態やパフォーマンスを継続的に監視できます。
5. CloudTrail vs パフォーマンス監視
- CloudTrail: AWSリソースのAPIコールの履歴を記録するサービスで、管理アクションの監視に役立ちますが、アプリケーションのパフォーマンスやクエリの遅延などを監視するには適していません。
- パフォーマンス監視: 実際のアプリケーションのパフォーマンス監視には、CloudWatch Logs、X-Ray、Auroraのクエリログなどの使用が推奨されます。
6. パフォーマンスベンチマーキング
- パフォーマンスベンチマーキング: システムのスループット、応答時間、リソースの利用状況を測定することで、ピーク時のパフォーマンスを事前に把握し、改善点を見つけることができます。ただし、実際のトラフィックの影響を受ける問題の解析には、トレースとログ収集がより効果的です。
結論
アプリケーションのパフォーマンス監視とトラブルシューティングには、CloudWatch LogsやAWS X-Rayなどのツールを使用することが重要です。特に、ウェブサーバーやデータベースのログを収集し、リクエストやクエリのトレースを行うことで、ピークトラフィック時に発生する問題を迅速に特定できます。
実践
略
一問道場
問題 #381
ある企業が、AWS上で3階層のウェブアーキテクチャを使用してeコマースウェブサイトを構築しました。アプリケーションはJavaベースで、Amazon CloudFrontディストリビューション、Amazon EC2インスタンスのAuto Scalingグループ内のApacheウェブサーバーレイヤー、そしてバックエンドのAmazon Aurora MySQLデータベースで構成されています。
先月、プロモーションセールイベント中に、ユーザーからショッピングカートにアイテムを追加する際にエラーやタイムアウトが発生したと報告されました。運用チームは、ウェブサーバーが生成したログを回収し、Aurora DBクラスタのパフォーマンスメトリクスを確認しましたが、いくつかのウェブサーバーはログを収集する前に終了しており、Auroraのメトリクスではクエリパフォーマンス分析には十分ではありませんでした。
ピークトラフィック時にアプリケーションパフォーマンスの可視性を向上させるために、ソリューションアーキテクトはどのステップを実施する必要がありますか？（3つ選んでください。）
A. Aurora MySQL DBクラスタを構成して、遅いクエリおよびエラーログをAmazon CloudWatch Logsに公開する。
B. AWS X-Ray SDKを実装して、EC2インスタンスでのHTTPリクエストのトレースを行い、X-Ray SDK for Javaを使用して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に公開する。
解説
この問題では、ピークトラフィック時にアプリケーションのパフォーマンス可視性を向上させるための手順を選択することが求められています。問題の背景として、ウェブサーバーが負荷がかかるときにログが失われたり、Aurora DBのパフォーマンスメトリクスが不十分であるという状況があります。これらの問題を解決するために、以下のステップが推奨されます。
正解のステップ：
A. Aurora MySQL DBクラスタを構成して、遅いクエリおよびエラーログをAmazon CloudWatch Logsに公開する。
- 解説: Aurora MySQLのパフォーマンスに関する可視性を向上させるために、遅いクエリやエラーログをCloudWatch Logsに公開することで、データベースのパフォーマンスを詳細に監視できます。これにより、パフォーマンス問題の診断が容易になります。
B. AWS X-Ray SDKを実装して、EC2インスタンスでのHTTPリクエストのトレースを行い、X-Ray SDK for Javaを使用してSQLクエリのトレースを実装する。
- 解説: X-Rayは、アプリケーションのパフォーマンスのボトルネックを特定するためのツールです。HTTPリクエストとSQLクエリの両方をトレースすることで、どこで遅延が発生しているかを詳細に分析できます。これにより、EC2インスタンスとAurora DBの相互作用を追跡でき、問題の根本原因を特定できます。
D. EC2インスタンスにAmazon CloudWatch Logsエージェントをインストールおよび構成して、ApacheログをCloudWatch Logsに送信する。
- 解説: ApacheログをCloudWatch Logsに送信することで、ウェブサーバーのパフォーマンスやエラーを詳細にモニタリングできます。これにより、サーバーがリクエストを処理している際に発生した問題を追跡し、特にトラフィックの多いピーク時にどのような問題が発生したかを確認できます。
不正解のステップ：
C. Aurora MySQL DBクラスタを構成して、遅いクエリおよびエラーログをAmazon Kinesisにストリームする。
- 解説: Kinesisはリアルタイムデータストリーミングサービスであり、データを流し続ける用途に適していますが、Auroraのパフォーマンスログをリアルタイムにストリーミングすることは、可視性の向上にはあまり適していません。代わりに、CloudWatch Logsを使用してログを集中的に収集・分析する方が効率的です。
E. AWS CloudTrailを有効にして、Amazon EC2とAuroraのアプリケーションアクティビティを収集および分析する。
- 解説: CloudTrailは、AWSサービスのAPIコールの履歴を記録するためのサービスです。しかし、アプリケーションのパフォーマンスやトラフィックのモニタリングには不十分です。CloudTrailは主に管理アクションの監視に適しており、直接的なアプリケーションパフォーマンスの可視化には役立ちません。
F. Aurora MySQL DBクラスタでパフォーマンスベンチマーキングを有効にし、そのストリームをAWS X-Rayに公開する。
- 解説: Auroraのパフォーマンスベンチマーキングはシステムの負荷や性能をテストするためのもので、実際のトラフィック下で発生した問題を追跡するためには直接的なログ収集やトレースが必要です。X-Rayにストリームを送る方法は一般的に推奨されません。Auroraのパフォーマンスデータは、CloudWatchを使用して監視する方が効果的です。
結論
- A, B, Dの選択肢は、パフォーマンスの可視化と障害の検出に役立つ手順です。CloudWatch Logsを使ったログ収集、X-Rayを使ったリクエストとデータベースクエリのトレース、Apacheログの収集が、ピークトラフィック時に役立ちます。
- その他の選択肢（C、E、F）は、直接的なパフォーマンスの分析には最適ではありません。
382-AWS SAP AWS 「理論・実践・一問道場」DynamoDBにオートスケーリング
理論
1. Auto Scaling
Auto Scalingは、アプリケーションやサービスが需要の増減に応じて自動的にインスタンスを追加または削除できるAWSの機能です。これにより、ピーク時のリソース不足を防ぎ、非ピーク時のコストを削減できます。特に、EC2インスタンスや他のサービス（例：Amazon ECS）でスケーラビリティを確保するために使用されます。
- オートスケーリングの設定: スケーリングポリシーやターゲットのCPU使用率、メモリ使用率などのメトリクスを基にインスタンスの数を自動調整します。
- 負荷に応じたインスタンス管理: トラフィックの増加に対応するために、インスタンス数を増やし、トラフィックが落ち着いたらインスタンス数を減らすことができます。
2. Amazon DynamoDBのオートスケーリング
DynamoDBは、AWSが提供するフルマネージド型のNoSQLデータベースです。DynamoDBのオートスケーリングは、リクエストの負荷に応じて読み取りおよび書き込みキャパシティを自動的に調整する機能です。
- キャパシティモード: DynamoDBには「プロビジョニング」および「オンデマンド」の2つのキャパシティモードがあります。オートスケーリングはプロビジョニングモードで使用されます。
- オートスケーリングの利点: トラフィックの急増時に自動的にキャパシティを増加させ、過剰なリソース使用を防ぎます。これにより、過負荷による遅延やスロットリングを回避できます。
3. Amazon SQS (Simple Queue Service) とAWS Lambda
Amazon SQSは、メッセージキューサービスで、分散システムやマイクロサービス間のメッセージングをサポートします。負荷が高いときに一時的にメッセージをキューに保持し、システムが処理できる速度で順次処理することができます。
- キューによる負荷分散: SQSを使うことで、システムがピーク時でも安定してメッセージを処理できるようになります。高負荷時にメッセージを一時的に保持し、処理できるタイミングでLambda関数などで処理を行います。
- 非同期処理: Lambda関数は非同期でメッセージを処理できるため、同期的な負荷の高い処理を遅延させて、システム全体の負荷を軽減します。
4. システムアーキテクチャのスケーラビリティとコスト管理
- スケーラビリティ: 負荷に応じて自動的にリソースを増減させることで、システムが高負荷に耐え、トラフィックの急増に対応できます。
- コスト効率: オートスケーリングやオンデマンドのリソース利用は、ピーク時にのみリソースを増加させ、非ピーク時には削減するため、リソースの無駄を省きます。
結論
- Auto Scaling と DynamoDBのオートスケーリング の組み合わせは、スケーラブルでコスト効率の良いアーキテクチャを提供します。
- SQSとLambda の使用により、ピーク時におけるリソース負荷を分散し、システム全体の可用性とパフォーマンスを向上させます。
これらの技術を適切に利用することで、高負荷時でもシステムの安定性を保ちながら、コスト効率よく運用することができます。
実践
略
一問道場
問題 #382
季節労働者向けの求人ボードを提供する企業が、トラフィックと使用量の増加を見ています。バックエンドサービスは、Amazon EC2インスタンス2台をApplication Load Balancerの背後で実行し、データストアとしてAmazon DynamoDBを使用しています。ピークシーズン中、読み取りおよび書き込みのトラフィックが遅くなっています。
ピークシーズンを処理するためのスケーラブルなアプリケーションアーキテクチャを、最小の開発労力で提供するオプションはどれですか？
A. バックエンドサービスをAWS Lambdaに移行し、DynamoDBの読み取りおよび書き込みキャパシティを増加させる。
B. バックエンドサービスをAWS Lambdaに移行し、DynamoDBをグローバルテーブルを使用するように設定する。
C. バックエンドサービスにAuto Scalingグループを使用し、DynamoDBにオートスケーリングを設定する。
D. バックエンドサービスにAuto Scalingグループを使用し、Amazon Simple Queue Service (Amazon SQS) と AWS Lambda関数を使用してDynamoDBに書き込む。
解説
この問題に関連する解説は、アーキテクチャのスケーラビリティとパフォーマンス向上に関連しています。特に、ピークシーズン中の負荷に対応するための方法を考えることが求められます。以下に各選択肢を説明します。
A. バックエンドサービスをAWS Lambdaに移行し、DynamoDBの読み取りおよび書き込みキャパシティを増加させる
- AWS Lambdaへの移行: AWS Lambdaはサーバーレスコンピューティングサービスで、リソースの自動スケーリングが可能ですが、バックエンドサービスがどれほど複雑かによっては、Lambdaへの移行には多くの開発が必要になる場合があります。特に、ステートレスでないアプリケーションをLambdaに移行するには、再設計が必要です。
- DynamoDBのキャパシティ増加: DynamoDBは、リード/ライトキャパシティのスケールを手動で増加させることができますが、これを過剰に行うとコストがかかりますし、DynamoDBのオートスケーリング機能を活用しない場合、リソースの過不足が発生するリスクもあります。
このオプションは、開発に手間がかかり、特にDynamoDBのキャパシティを手動で増加させることは最適ではありません。
B. バックエンドサービスをAWS Lambdaに移行し、DynamoDBをグローバルテーブルを使用するように設定する
- グローバルテーブルの使用: DynamoDBのグローバルテーブルは、複数リージョンにまたがるアプリケーションのデータの複製を自動的に管理し、グローバルにスケーラブルなデータアクセスを提供します。ただし、この方法は、マルチリージョンに分散されたデータの読み書きが必要な場合に最適ですが、単一リージョン内でのパフォーマンス改善には必ずしも効果的ではありません。
- Lambdaへの移行: 再度、バックエンドサービスがLambdaに適しているかの評価が必要で、サービスの設計によっては、再開発が大規模に必要になるかもしれません。
このオプションは、特にグローバルテーブルが必須でない場合にはオーバーエンジニアリングとなり、開発の負担が大きいです。
C. バックエンドサービスにAuto Scalingグループを使用し、DynamoDBにオートスケーリングを設定する
- Auto Scalingグループの使用: Auto Scalingは、EC2インスタンスの数をトラフィックに応じて自動的に調整する機能です。これにより、ピーク時のリソースを動的に増減させることができ、安定したパフォーマンスを維持できます。
- DynamoDBのオートスケーリング: DynamoDBにはオートスケーリング機能があり、トラフィックに応じて読み書きキャパシティが自動的に調整されます。これにより、負荷の変動に対応でき、コストを抑えつつスケーラビリティが向上します。
このオプションは、最小の開発努力でシステムのスケーラビリティを向上させる方法であり、特にシンプルで効率的です。
D. バックエンドサービスにAuto Scalingグループを使用し、Amazon Simple Queue Service (Amazon SQS) と AWS Lambda関数を使用してDynamoDBに書き込む
- SQSとLambdaの使用: SQSはメッセージキューサービスで、トラフィックのピーク時にメッセージをキューに積み、Lambda関数を使って処理することができます。この方法は、ピーク時の一時的なトラフィックを緩和し、処理を非同期で行うことができます。ただし、これは追加のレイテンシーを導入する可能性があり、Lambda関数の実行時間が長い場合、コストが増加することがあります。
このオプションは、スケーラブルで効果的な方法ですが、最小の開発努力で達成できるものではありません。
結論
Cのオプションが最も適しています。理由は、Auto Scaling と DynamoDBオートスケーリング を活用することで、最小限の開発努力でシステムのスケーラビリティを大幅に向上させることができるからです。この方法は、リソースの効率的なスケーリングを実現し、ピークシーズンに対応するのに最も簡単で効果的な方法です。
383-AWS SAP AWS 「理論・実践・一問道場」AWS Application Discovery Service
理論
1. AWS Application Discovery Serviceの役割
AWS Application Discovery Serviceは、オンプレミスのデータセンターからクラウドへの移行を支援するツールです。これを利用することで、仮想マシン、サーバー、アプリケーションの詳細なパフォーマンスメトリクス（CPU、メモリ、ディスク使用量）や、実行中のプロセス、ネットワーク接続の情報を収集することができます。このデータは、クラウドへの移行を計画する際に非常に有用です。
特徴:
- エージェントベースのデータ収集: Application Discovery Serviceでは、各サーバーにエージェントをデプロイして、詳細なメトリクスを収集します。
- エージェントレスディスカバリ: ネットワークベースで、エージェントをインストールせずに情報を収集する方法も提供しますが、エージェントを使用する方が精度が高くなります。
2. AWS CloudWatchエージェントとの違い
- CloudWatchエージェント: 主にメトリクスの収集とログ管理に使用されます。CloudWatchエージェントは、システムパフォーマンス（CPU、メモリ、ディスクなど）の監視や、ログデータの収集に特化しています。ただし、プロセスの詳細やネットワーク接続の情報を収集するには、AWS Application Discovery Serviceが適しています。
3. エージェントのデプロイ方法
AWS Application Discovery Serviceでは、エージェントを仮想マシンにインストールして、詳細なシステムパフォーマンスデータを収集します。この方法は、クラウド移行の準備において重要な役割を果たします。
利点:
- 詳細なデータ収集: CPU、メモリ、ディスク、ネットワーク接続、プロセスの状態を収集。
- クラウド移行計画: クラウド環境への適切なインスタンスのサイズやリソースの割り当てを決定するために必要なデータを提供。
4. エージェントレスディスカバリの限界
- エージェントレスディスカバリでは、ネットワークを介してスキャンを実行しますが、収集できる情報には限りがあります。特に、アプリケーションやプロセスの詳細な状態を追跡するのには、エージェントを使用する方が優れています。
5. 実際のクラウド移行の計画
クラウド移行において、仮想マシンのパフォーマンスやリソースの利用状況を理解することは重要です。これにより、適切なクラウドインスタンスのタイプやサイズを選定できます。AWS Application Discovery Serviceは、これらの詳細なデータを提供するため、移行作業の精度を高め、後のパフォーマンス最適化を助けます。
6. その他のツールと比較
- AWS Migration Hub: 移行の進捗を管理し、複数のツールからの情報を統合するためのサービス。
- AWS Cost Explorer: クラウドコストの予測と最適化を支援しますが、データセンターのリソース使用状況を収集するにはAWS Application Discovery Serviceがより適しています。
結論:
クラウド移行を計画する際に、AWS Application Discovery Service は、オンプレミスの環境でどのようにアプリケーションやサーバーが動作しているかを正確に把握するための有力なツールです。エージェントを使用することで、クラウドインスタンスに移行する際のリソース割り当てや最適化のために必要な情報を収集でき、移行計画の精度を向上させます。
実践
略
一問道場
質問 #383
ある企業がクラウドへの移行を進めています。新しいAmazon EC2インスタンスを正確にサイズ設定できるように、既存のデータセンター環境の仮想マシンの構成を評価したいと考えています。企業は、CPU、メモリ、ディスク使用率などのメトリクスを収集し、各インスタンスで実行されているプロセスのインベントリも必要としています。また、サーバー間の通信をマッピングするためにネットワーク接続も監視したいと考えています。
最もコスト効率よくこのデータを収集する方法はどれですか？
A. AWS Application Discovery Serviceを使用し、データセンター内の各仮想マシンにデータ収集エージェントを展開する。
B. Amazon CloudWatchエージェントをすべてのサーバーに設定し、メトリクスをAmazon CloudWatch Logsに公開する。
C. AWS Application Discovery Serviceを使用し、既存の仮想化環境でエージェントレスディスカバリを有効にする。
D. AWS Management ConsoleでAWS Application Discovery Serviceを有効にし、企業のファイアウォールを設定してVPN経由でスキャンを許可する。
解説
正解は、A. AWS Application Discovery Serviceを使用し、データセンターの各仮想マシンにデータ収集エージェントをデプロイするです。
解説
このシナリオでは、企業が既存のデータセンターからクラウドへの移行を計画しており、仮想マシンのパフォーマンスメトリクスやプロセス情報、ネットワーク接続情報を収集する必要があります。この目的に最も適しているのが AWS Application Discovery Service です。
各選択肢の解説
A. AWS Application Discovery Serviceを使用し、データセンターの各仮想マシンにデータ収集エージェントをデプロイする。
- エージェントのデプロイは、パフォーマンスメトリクス（CPU、メモリ、ディスク使用率など）、実行中のプロセス、ネットワーク接続を集中的に収集できる方法です。この方法により、データセンター内のインスタンスに関する非常に詳細な情報を収集でき、クラウド移行の準備に役立ちます。特に移行先のEC2インスタンスのサイズや設計を適切に決定するために必要な情報を集めるために適切です。
B. Amazon CloudWatchエージェントを使用してメトリクスをCloudWatch Logsに公開する。
- CloudWatchエージェントは、メトリクス収集に便利ですが、プロセス情報やネットワーク接続情報を収集するのには限界があります。CloudWatch Logsは主にログ収集に使用されるため、詳細なパフォーマンスデータの収集には他のツール（例えばApplication Discovery Service）を使用する方が効果的です。
C. AWS Application Discovery Serviceを使用し、既存の仮想化環境でエージェントレスディスカバリを有効にする。
- エージェントレスディスカバリは、インフラにエージェントを追加せずに、ネットワーク経由で情報を収集します。これも便利な方法ですが、エージェントを使う方法に比べて、情報収集の精度がやや劣る可能性があります。特にプロセスやメモリ使用量など、詳細なパフォーマンス情報を収集するには、エージェントを使用した方が信頼性が高くなります。
D. AWS Application Discovery Serviceを使用して、企業のファイアウォールを設定し、VPN経由でスキャンを許可する。
- VPN経由でのスキャンは、ネットワーク設定やセキュリティ要件に手間がかかる可能性があり、環境によっては管理が複雑になることがあります。特に、エージェントを使用して直接データ収集する方が、手間が少なく効率的です。
結論:
最も適切な選択肢は、A の「AWS Application Discovery Serviceを使用し、データセンターの各仮想マシンにデータ収集エージェントをデプロイする」です。この方法が、パフォーマンスメトリクスやプロセス情報を収集する最も効果的で信頼性の高い手段となります。
384-AWS SAP AWS 「理論・実践・一問道場」AWS Global Accelerator
理論
1. AWS Global Accelerator
AWS Global Acceleratorは、ユーザーのトラフィックを最適なAWSリージョンに自動的にルーティングするためのサービスです。これにより、アプリケーションの可用性、パフォーマンス、および耐障害性を向上させることができます。
- 静的IPアドレスの提供: Global Acceleratorは、1つまたは複数の静的IPアドレスを提供します。これにより、顧客は動的IPアドレスの変更を気にすることなく、アプリケーションにアクセスできます。
- 最寄りのリージョンへのトラフィックルーティング: Global Acceleratorは、ユーザーのリクエストを最も低遅延で処理できるAWSリージョンにルーティングします。これにより、ユーザーのパフォーマンスが向上します。
- リージョンの冗長性: 複数のリージョンにデプロイされたエンドポイントを使用して、トラフィックを自動的に健康なエンドポイントにルーティングします。
2. Amazon CloudFront
CloudFrontは、コンテンツ配信ネットワーク（CDN）サービスで、エッジロケーションを使用してコンテンツを高速に配信します。通常は静的コンテンツの配信に使用され、静的IPアドレスの提供や最適なリージョンへのルーティングには向いていません。
- エッジロケーション: CloudFrontは、AWSグローバルネットワークを使用して、ユーザーに近いエッジロケーションからコンテンツを配信しますが、最適なリージョンへのトラフィックルーティングはGlobal Acceleratorの方が適しています。
3. Network Load Balancer (NLB)
NLBは、TCPトラフィックを効率的に処理するための負荷分散サービスで、静的IPアドレスをサポートします。Global Acceleratorと組み合わせて使用することができますが、単体ではリージョン間の自動ルーティング機能はありません。
- 静的IPアドレス: NLBは、特定のIPアドレス（静的）を提供し、トラフィックをターゲットにルーティングします。
結論
静的IPアドレスを提供し、地理的に最適なリージョンへのトラフィックルーティングを自動化する場合、AWS Global Acceleratorが最適なソリューションです。CloudFrontやNLBは他の用途で有用ですが、Global Acceleratorは最寄りのリージョンに自動でトラフィックをルーティングする機能を提供し、要件に最も合致します。
実践
略
一問道場
質問 #384
ある企業は、AWSクラウド上で動作するソフトウェア・アズ・ア・サービス（SaaS）アプリケーションを提供しています。このアプリケーションは、ネットワークロードバランサー（NLB）の背後で、Amazon EC2 インスタンス上で実行されています。インスタンスは、オートスケーリンググループ内で、1つのAWSリージョン内の3つのアベイラビリティゾーンに分散しています。
企業はアプリケーションを追加のリージョンにデプロイしようとしています。企業は、顧客がIPアドレスを許可リストに追加できるよう、顧客に静的IPアドレスを提供する必要があります。このソリューションは、顧客を地理的に最も近いリージョンに自動的にルーティングする必要があります。
どのソリューションがこれらの要件を満たすでしょうか？
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アドレスを提供する。
解説
この問題の要点は、静的IPアドレスを提供し、地理的に最も近いリージョンへのルーティングを自動的に行うことです。これには、顧客が許可リストに追加できる静的IPアドレスを提供し、そのIPアドレスを基に最適なリージョンに自動的に接続させる必要があります。
各選択肢の分析:
A. Amazon CloudFrontディストリビューションを作成する。CloudFrontオリジングループを作成し、各追加リージョンのNLBをオリジングループに追加する。顧客にディストリビューションのエッジロケーションのIPアドレス範囲を提供する。
- 誤り: CloudFrontはコンテンツ配信に特化しており、静的IPアドレスの提供やリージョン間の自動ルーティングには最適ではありません。エッジロケーションのIPアドレス範囲を提供することはできますが、最も近いリージョンへのルーティングには向いていません。
B. AWS Global Acceleratorスタンダードアクセルレータを作成する。各追加リージョンのNLBに対してスタンダードアクセルレータのエンドポイントを作成する。顧客にGlobal AcceleratorのIPアドレスを提供する。
- 正解: AWS Global Acceleratorは、複数のリージョンに分散されたアプリケーションに対して静的IPアドレスを提供し、最も近いリージョンへのルーティングを自動的に行うサービスです。これにより、顧客は1つのIPアドレスを使い、Global Acceleratorが地理的に最適なリージョンにトラフィックをルーティングします。これが要件に最も適しています。
C. Amazon CloudFrontディストリビューションを作成する。各追加リージョンのNLBにカスタムオリジンを作成する。顧客にディストリビューションのエッジロケーションのIPアドレス範囲を提供する。
- 誤り: CloudFrontはオリジンとしてNLBをサポートできますが、Static IPアドレスを提供することはできません。また、最適なリージョンへの自動ルーティング機能はGlobal Acceleratorの方が適しています。
D. AWS Global Acceleratorカスタムルーティングアクセルレータを作成する。カスタムルーティングアクセルレータにリスナーを作成し、各追加リージョンのNLBのIPアドレスとポートを追加する。顧客にGlobal AcceleratorのIPアドレスを提供する。
- 誤り: カスタムルーティングアクセルレータは、リクエストを特定のIPアドレスやポートに基づいてルーティングするためのものです。静的IPアドレスを提供し、最適なリージョンへの自動ルーティングを行うという要件には、スタンダードアクセルレータが適しています。
結論:
Bが最適な解決策です。AWS Global Acceleratorのスタンダードアクセルレータを使用することで、顧客に静的IPアドレスを提供し、トラフィックを最寄りのリージョンに自動的にルーティングできます。
385-AWS SAP AWS 「理論・実践・一問道場」AWS STS（Security Token Service）とセッションタグ
理論
1. AWS Organizationsとサービス制御ポリシー（SCP）
- AWS Organizations を使用すると、複数のアカウントを管理できます。アカウントを 組織単位（OU） に分けて、それぞれに対して サービス制御ポリシー（SCP） を適用できます。
- SCPは、アカウント内で実行できるアクションを制限するもので、アカウント単位またはOU単位で権限を設定できます。しかし、細かいリソースレベルでのアクセス制御には適していません。
2. IAMポリシーとリソースレベルアクセス制御
- IAMポリシー は、ユーザーやロールに対してリソースへのアクセスを制御するための最も基本的な方法です。ポリシーでは 条件付きアクセス を設定でき、リソースタグを使用することで、より細かい制御が可能です。
- たとえば、特定のタグ（例：
DevelopmentUnit）をリソースに設定し、ユーザーやロールがそのタグに基づいてリソースを操作できるようにすることができます。
3. AWS STS（Security Token Service）とセッションタグ
- AWS STS を使用して、一時的なセキュリティ認証情報（セッショントークン）を提供することができます。この認証情報に セッションタグ を付与し、ユーザーが認証される際にそのタグ情報を付加できます。
- セッションタグを使用することで、IAMポリシーやリソースタグと連携し、ユーザーの権限を 動的に設定 することができます。この方法は、特に 一時的な認証 を管理する場合に役立ちます。
4. タグによるリソース管理
- AWSでは、リソースに タグ を付与することができ、これを基にアクセス制御を行うことが可能です。リソースタグは、開発環境や運用環境、さらには特定の開発ユニットやプロジェクトに基づいて、リソースを分類・識別するために役立ちます。
- IAMポリシー内で、リソースタグに基づいてアクセス制御を行うために StringEquals や StringNotEquals 条件を使用します。
5. 細粒度のアクセス制御とセキュリティ
- 細粒度のアクセス制御 は、リソース単位でアクセスを制限することで、誤操作やセキュリティリスクを最小化するために重要です。タグやSTSセッションタグを使って、リソースごとに異なるアクセス権限を設定することで、必要最小限のアクセス権限だけを付与できます。
- 最小権限の原則（Principle of Least Privilege）を守るために、アクセス制御を細かく設定し、不要な権限を与えないようにすることが推奨されます。
まとめ
- SCP は組織全体の制御に適しており、リソースレベルのアクセス制御には IAMポリシー と タグ を活用することが重要です。
- AWS STSセッションタグ を利用することで、開発ユニットごとのアクセスを柔軟に管理できます。これにより、ユーザーが自分の開発ユニットに関連するリソースのみを操作することができます。
実践
略
一問道場
質問 #385
ある会社がAWSクラウドで複数のワークロードを実行しています。この会社にはソフトウェア開発用の別々のユニットがあり、AWS OrganizationsとSAMLによるフェデレーションを使用して、開発者にAWSアカウント内のリソース管理権限を付与しています。各開発ユニットは、共通のプロダクションアカウントにプロダクションワークロードをデプロイしています。
最近、プロダクションアカウントでインシデントが発生し、ある開発ユニットのメンバーが別の開発ユニットに所属するEC2インスタンスを誤って終了させました。ソリューションアーキテクトは、今後同様のインシデントが発生しないようにする解決策を作成しなければなりません。この解決策は、開発者が自分のワークロードで使用するインスタンスを管理できるようにもする必要があります。
どの戦略がこれらの要件を満たしますか？
A. AWS Organizationsで各開発ユニットのために別々のOU（組織単位）を作成します。作成したOUを会社のAWSアカウントに割り当てます。開発ユニット名に一致するDevelopmentUnitリソースタグに対して、拒否アクションとStringNotEquals条件を含むSCP（サービスコントロールポリシー）を作成します。対応するOUにSCPを割り当てます。
B. SAMLフェデレーション中にAWS Security Token Service（AWS STS）セッショントークンとしてDevelopmentUnit属性を渡します。開発者のIAMロールのポリシーを更新し、DevelopmentUnitリソースタグとaws:PrincipalTag/DevelopmentUnitに対して、拒否アクションとStringNotEquals条件を設定します。
C. SAMLフェデレーション中にAWS Security Token Service（AWS STS）セッショントークンとしてDevelopmentUnit属性を渡します。開発ユニットリソースタグとaws:PrincipalTag/DevelopmentUnitに対して、許可アクションとStringEquals条件を含むSCPを作成します。このSCPをルートOUに割り当てます。
D. 各開発ユニットに対して別々のIAMポリシーを作成します。各IAMポリシーには、DevelopmentUnitリソースタグと開発ユニット名に対して許可アクションとStringEquals条件を追加します。SAMLフェデレーション中にAWS Security Token Service（AWS STS）を使用してIAMポリシーを割り当て、開発ユニット名をIAMロールに一致させます。
解説
この問題の解説について、どのようにして B選択肢 が正解となるかを詳しく説明します。
問題の背景と要求
会社は複数の開発ユニットがあり、それぞれが独立して作業を行っていますが、 共通の本番アカウント に対して EC2インスタンス などのリソースを操作しています。最近、ある開発ユニットのメンバーが 他の開発ユニットのEC2インスタンスを誤って終了させてしまった というインシデントが発生しました。
この問題を防ぐためには、以下の要件が求められています：
- 各開発ユニットは、 自分の作業に関連するリソースのみ を操作できるようにすること。
- それでも、開発者が自分のリソースを管理できる権限を持つようにすること。
解説
1. リソース間での誤操作を防ぐために
開発ユニット間でリソースの誤操作を防ぐためには、 リソースに対するアクセス制御 が必須です。それぞれの開発ユニットが自分のリソースだけにアクセスできるようにする必要があります。
2. SAML認証とSTSセッションタグの利用
開発者のアクセス制御を柔軟に行うために、 SAML認証 と AWS STSセッションタグ を利用するのが効果的です。これにより、開発者がシステムにアクセスする際、どの 開発ユニット に所属しているかを識別できます。この情報を元に、リソースのアクセス制御を行います。
3. IAMポリシーの利用
次に、IAMポリシー を用いて、開発者が操作できるリソースを制限します。具体的には、 StringNotEquals 条件を使って、開発者が 自分の開発ユニットのリソースだけ にアクセスできるようにします。リソースのタグと開発者のセッションタグが一致しない場合、アクセスが拒否される仕組みです。
各選択肢の評価
A選択肢：SCPを使ったリソースのアクセス制御
- 概要：AWS Organizationsの サービス制御ポリシー（SCP） を使い、開発ユニットごとにOU（組織単位）を分け、リソースへのアクセスを制限します。
- 問題点：SCPは主に組織全体のポリシー管理に使用されるため、 細かいリソース単位でのアクセス制御 には不向きです。タグを使って個別のアクセス制御を行う柔軟性がありません。
B選択肢：STSセッションタグとIAMポリシー
- 概要：SAML認証でSTSセッションタグを使い、開発者の所属する開発ユニットを識別。その情報を基にIAMポリシーでリソースへのアクセスを制御します。
- 正解理由：この方法は リソースタグとセッションタグを照合 し、 アクセスできるリソースを明確に制限 できます。これにより、開発者は自分のユニットのリソースのみ操作可能になり、他の開発ユニットのリソースを誤って操作することを防げます。
C選択肢：SCPを使ったタグによるアクセス制御
- 概要：SCPを使って、開発ユニットに合わせたアクセス許可を設定します。条件として、タグとセッションタグを照合します。
- 問題点：SCPは アクセスを許可 する条件で設定されているため、誤って他のユニットのリソースにアクセスできてしまう可能性があります。誤操作を防ぐためには 明示的な拒否 の方が安全です。
D選択肢：IAMポリシーを使ったアクセス制御
- 概要：開発ユニットごとに個別のIAMポリシーを作成し、それをSAML認証を通じて適用します。
- 問題点：IAMポリシーを各ユニットごとに作成するのは 管理が複雑 で、運用の負担が大きくなります。リソースの管理やポリシーの更新が増えるため、スケーラビリティに欠けます。
結論
B選択肢 は、 SAML認証 と STSセッションタグ を活用し、開発者が自分の開発ユニットに関連するリソースのみ操作できるようにする方法です。このアプローチは、リソースレベルでアクセス制御を 柔軟 に行うことができ、誤操作を防ぐために非常に効果的です。他の選択肢は、管理の複雑さやアクセス制御の精度において不十分であるため、B選択肢が最適 となります。
AWS STS（Security Token Service）とセッションタグを使う理由は、アクセス権限を一時的かつ柔軟に管理できるためです。特に削除防止には、動的に権限を変更できる点が重要です。
- STSとセッションタグ:
- 一時的なアクセス制御: 特定の時間や状況でのみアクセスを許可。
- タグによる制御: ユーザーにタグを付与して、どのリソースにアクセスできるかを動的に決める。
- IAMポリシーとリソースレベルアクセス制御:
- 静的な設定: 一度設定したら変更が必要な場合が多く、動的な権限変更には不向き。
簡単に言うと、STSとセッションタグは、一時的かつ柔軟なアクセス管理が可能で、特に削除防止には有効です。
386-AWS SAP AWS 「理論・実践・一問道場」AWS Service Catalog
理論
AWSでのインフラ管理に関する重要ポイント
AWSで大規模な企業がインフラを管理する際、セキュリティ、集中管理、効率性が重要です。以下に汎用的な知識をまとめます。
1. 最小特権アクセスの実現
- IAMポリシー: 必要最低限の権限をIAMユーザーやロールに付与する。
- Service Control Policies (SCP): AWS OrganizationsでSCPを使用し、特定のサービスやアクションを制限する。
2. インフラテンプレートの集中管理
- AWS CloudFormation:
- インフラをコード（IaC）として記述し、再利用可能なテンプレートを作成。
- 一貫性と自動化を向上させる。
- AWS Service Catalog:
- CloudFormationテンプレートを製品として管理。
- 組織全体で標準化されたテンプレートを配布可能。
3. マルチアカウント構成の管理
- AWS Organizations:
- 複数のAWSアカウントを一元管理。
- ポートフォリオやポリシーを各アカウントに共有可能。
4. タグ付けの強制
- AWS Service Catalog TagOption Library:
- 組織で必要なタグを定義し、製品やポートフォリオに適用。
- 例: コストセンターや環境（
Environment=Production）を指定。
- CloudFormationのResource Tags:
- テンプレートにタグを明示的に記述することで、リソース作成時に自動適用。
5. 自動化による効率向上
- スクリプトと自動化:
- AWS CLIやAWS SDKを使用してポートフォリオやTagOptionのインポートを自動化。
- 運用の手間を削減。
まとめ: 効率的なAWSインフラ管理
- 最小特権アクセス: IAMポリシーとSCPを適切に設計。
- 集中管理: Service Catalogを活用してテンプレートを一元化。
- タグ付け: TagOption Libraryでコスト管理や監査を強化。
- 自動化: スクリプトで反復作業を軽減し、スケーラブルな管理を実現。
この知識を活用することで、セキュリティと効率性を保ちながら、AWSリソースの運用を最適化できます。
実践
略
一問道場
質問 #386
あるエンタープライズ企業が、ユーザー向けのインフラサービスプラットフォームを構築しようとしています。この企業には以下の要件があります：
- ユーザーがAWSインフラを起動する際に、最小特権アクセスを提供し、承認されていないサービスをプロビジョニングできないようにする。
- インフラサービスの作成を管理するための中央アカウントを使用する。
- AWS Organizations内の複数アカウントにインフラサービスを配布できるようにする。
- ユーザーが開始するすべてのインフラにタグを適用することを強制できるようにする。
これらの要件を満たすためにAWSサービスを使用して実行するアクションの組み合わせはどれですか？（3つ選択してください）
A. AWS CloudFormationテンプレートを使用してインフラサービスを開発する。テンプレートを中央のAmazon S3バケットに追加し、S3バケットポリシーでアクセス権を必要とするIAMロールやユーザーを追加する。
B. AWS CloudFormationテンプレートを使用してインフラサービスを開発する。各テンプレートをAWS Service Catalogの製品として中央AWSアカウント内のポートフォリオにアップロードする。このポートフォリオを会社のOrganizations構造と共有する。
C. ユーザーIAMロールにAWSCloudFormationFullAccessとAmazonS3ReadOnlyAccessの権限を付与する。Organizations SCPをAWSアカウントのルートユーザーレベルで追加し、AWS CloudFormationとAmazon S3以外のすべてのサービスを拒否する。
D. ユーザーIAMロールにServiceCatalogEndUserAccess権限のみを付与する。自動化スクリプトを使用して中央ポートフォリオをローカルAWSアカウントにインポートし、TagOptionをコピーして、ユーザーアクセスを割り当て、起動制約を適用する。
E. AWS Service Catalog TagOption Libraryを使用して、会社で必要なタグのリストを管理する。TagOptionをAWS Service Catalogの製品やポートフォリオに適用する。
F. AWS CloudFormation Resource Tagsプロパティを使用して、ユーザー向けに作成されるすべてのCloudFormationテンプレートにタグの適用を強制する。
解説
要件に対する考察
- 最小特権アクセスの提供：
- ユーザーが承認されていないサービスをプロビジョニングできないようにする必要があります。
- この要件を満たすには、特定のサービスにアクセスを限定する仕組み（IAMポリシーやSCPの活用）が必要です。
- 中央アカウントでの管理：
- インフラサービスの作成や配布は、中央アカウントで管理されなければなりません。
- AWS Service Catalogなどの集中管理ツールが役立ちます。
- 複数アカウントへの配布：
- AWS Organizationsを活用して複数アカウントにサービスを共有する必要があります。
- タグの強制適用：
- 作成されるインフラにタグ付けを義務付ける仕組みが必要です。
- AWS Service CatalogやCloudFormationのタグプロパティを利用できます。
選択肢ごとの分析
A.
- 内容: CloudFormationテンプレートを中央S3バケットに保存し、IAMロールやユーザーをS3バケットポリシーで管理する。
- メリット: インフラテンプレートを中央管理できる。
- 不足点: タグの強制や最小特権アクセス、Organizationsの連携が考慮されていない。
- 評価: 不適切
B.
- 内容: CloudFormationテンプレートをService Catalog製品として中央アカウントにアップロードし、Organizations構造と共有する。
- メリット: Service Catalogを利用して、中央管理と複数アカウントへの配布が可能。
- 評価: 適切
C.
- 内容: ユーザーにCloudFormationとS3のアクセス権を与え、SCPで他のサービスを制限する。
- メリット: 最小特権アクセスを提供可能。
- 不足点: タグの強制適用が考慮されていない。管理の中央化やService Catalogの活用がない。
- 評価: 不適切
D.
- 内容: Service Catalogのエンドユーザー権限を付与し、自動化スクリプトでポートフォリオをインポートし、TagOptionや起動制約を適用する。
- メリット: Service Catalogを活用し、タグ付けや起動制約が可能。自動化により管理負荷が軽減。
- 評価: 適切
E.
- 内容: Service Catalog TagOption Libraryで必要なタグを管理し、製品やポートフォリオに適用する。
- メリット: 必要なタグの一貫性を保証。Service Catalogと連携。
- 評価: 適切
F.
- 内容: CloudFormationのResource Tagsプロパティでタグ適用を強制する。
- メリット: CloudFormationテンプレート単位でタグ付けが可能。
- 不足点: Service Catalogのような中央管理や複数アカウントの配布が考慮されていない。
- 評価: 不適切
正解
B, D, E
これらの組み合わせで、以下の要件を満たします：
- 中央管理: Service Catalogでテンプレートを中央管理（B）。
- 最小特権アクセス: Service Catalogのエンドユーザー権限（D）。
- タグ強制: TagOption Libraryを使用したタグ管理（E）。
- 複数アカウント配布: Service Catalogのポートフォリオ共有（B）。
387-AWS SAP AWS 「理論・実践・一問道場」Athena
理論
Amazon AthenaとS3の効率的なデータ管理に関する知識
AWSで大規模なログデータを扱う際、クエリパフォーマンスとコストを最適化するためには、データ管理戦略が重要です。以下に汎用的なポイントをまとめます。
1. パーティション化の重要性
- 概要: データを特定のキー（例: 日付、時間）で分割することで、クエリが必要なデータだけをスキャンするように制限できる。
- メリット:
- クエリの実行速度が大幅に向上。
- スキャンするデータ量が減少し、Athenaのコストを削減可能。
- 実装例:
- Kinesis Data Firehoseでデータを日付や時間でパーティション化し、S3に保存。
- Athenaテーブル定義で
PARTITIONED BY句を使用。
2. コンパクション（データの統合）
- 概要: 小さなファイルが多数存在すると、Athenaクエリの効率が低下する。複数の小さいファイルを1つの大きなファイルに統合することで、クエリパフォーマンスを向上させる。
- 実装: AWS GlueまたはAWS Lambdaを使用して、定期的にファイルを統合。
3. 適切なファイル形式の選択
- 推奨形式:
- ParquetやORCなどの列指向形式を使用することで、データスキャン量をさらに削減可能。
- 理由:
- 列指向形式は特定の列だけを読み込むため効率的。
- データサイズが圧縮され、ストレージコストも削減。
4. ログのライフサイクル管理
- 概要: S3バケットに保存されたログのライフサイクルポリシーを設定し、古いログを自動的に削除またはGlacierに移動。
- メリット:
- ストレージコストを削減。
- S3バケットの管理を簡素化。
5. データカタログの活用
- AWS Glue Data Catalog:
- データスキーマを管理するためのサービス。
- Athenaクエリの前にカタログを更新することで、最新のパーティションをクエリに含められる。
まとめ
- パーティション化: データ量を減らし、クエリ速度とコストを最適化。
- ファイル形式: Parquetなどの列指向形式で効率化。
- データ統合: 小さなファイルをまとめてクエリ性能を向上。
- ログ管理: ライフサイクルポリシーで不要なデータを削減。
- データカタログ: Glueを活用してパーティション情報を管理。
これらのベストプラクティスを活用することで、Athenaを効率的に運用し、大量データの管理を最適化できます。
実践
略
一問道場
質問 #387
ある会社が新しいウェブアプリケーションをデプロイしました。そのセットアップの一環として、AWS WAFを設定し、Amazon Kinesis Data Firehoseを介してログをAmazon S3に送信しています。会社はAmazon Athenaクエリを開発し、毎日1回実行して、過去24時間のAWS WAFログデータを返すようにしています。
ログの毎日のボリュームは一定ですが、時間が経つにつれて、同じクエリの実行時間が増加しています。
ソリューションアーキテクトは、クエリ時間の増加を防ぐソリューションを設計する必要があります。このソリューションは、運用のオーバーヘッドを最小限に抑える必要があります。
次のうち、要件を満たすソリューションはどれですか？
選択肢：
A. AWS Lambda関数を作成し、毎日のAWS WAFログを1つのログファイルに統合する。
B. AWS WAFが毎日異なるS3バケットにログを送信するように設定し、スキャンするデータ量を削減する。
C. Kinesis Data Firehoseの設定を更新して、Amazon S3内のデータを日付と時刻でパーティション化する。Amazon Redshiftの外部テーブルを作成し、Amazon Redshift Spectrumを設定してデータソースをクエリする。
D. Kinesis Data Firehoseの設定とAthenaテーブルの定義を変更して、データを日付と時刻でパーティション化する。Athenaクエリを変更して、関連するパーティションを参照するようにする。
解説
問題の解説
問題の背景
- 課題: 過去24時間のAWS WAFログをAmazon Athenaで毎日クエリする際、クエリの実行時間が増加している。これは、Amazon S3に蓄積されたログデータ量が増加し、Athenaクエリがより多くのデータをスキャンするようになったため。
- 要件: クエリ時間の増加を防ぎつつ、運用のオーバーヘッドを最小限に抑えるソリューションが必要。
選択肢の評価
- A. AWS Lambda関数を作成し、毎日のAWS WAFログを1つのログファイルに統合する
- ログを1つのファイルに統合しても、Athenaクエリがスキャンするデータ量自体は減らない。
- クエリ時間の増加を防ぐ効果は期待できない。
- 不適切。
- B. AWS WAFが毎日異なるS3バケットにログを送信するように設定する
- データのスキャン量を削減するように見えるが、毎日異なるバケットを作成すると管理が煩雑になる。
- 運用のオーバーヘッドが増加するため、要件を満たさない。
- 不適切。
- C. Kinesis Data Firehoseの設定を更新して、Amazon S3内のデータを日付と時刻でパーティション化する。Amazon Redshift Spectrumを設定してデータをクエリする
- 日付と時刻でデータをパーティション化することで、AthenaまたはRedshift Spectrumがスキャンするデータ量を大幅に削減できる。
- Redshift Spectrumを導入すると追加のコストと設定の負担が発生し、運用のオーバーヘッドが増加する。
- 適切だが、運用負担の増加が懸念される。
- D. Kinesis Data Firehoseの設定とAthenaテーブルの定義を変更して、データを日付と時刻でパーティション化する
- 日付と時刻でデータをパーティション化することで、Athenaクエリがスキャンするデータ量を削減可能。
- Athenaはパーティション分けされたデータに対して効率的にクエリを実行できる。
- 運用のオーバーヘッドが少なく、要件を完全に満たす。
- 最適な選択肢。
結論
- 最適なソリューションは D. Kinesis Data Firehoseの設定とAthenaテーブルの定義を変更して、データを日付と時刻でパーティション化する です。
- 理由:
- パーティション化により、Athenaクエリの対象データ量が減少し、クエリ時間が増加しない。
- 設定変更の影響範囲が限定的で、運用負担が少ない。
388-AWS SAP AWS 「理論・実践・一問道場」GeoMatch
理論
特定の国や地域に基づいたアクセス制御とログ記録のベストプラクティス
クラウド環境で特定の国や地域に基づいたアクセス制御を行い、さらにログ記録を維持することは、セキュリティやコンプライアンスの観点から重要です。このような要件に対応するための一般的な知識と手法を以下にまとめます。
1. AWS WAFを活用した地理的フィルタリング（GeoMatch）
AWS WAFのGeoMatch機能は、リクエストの送信元IPアドレスを解析し、特定の国や地域を基にアクセスを許可または拒否するルールを設定できます。
- 主な特徴:
- 許可または拒否する国や地域を簡単に指定可能。
- WAFのルールで設定した条件に一致するリクエストをブロックしたり、カウントすることが可能。
- ブロックされたリクエストはAWS WAFのログに記録され、Amazon S3やCloudWatch Logsに保存できる。
- 利点:
- メンテナンス負荷が少ない（国や地域のIP範囲の更新はAWSが管理）。
- ALBやAPI Gatewayなどのリソースに簡単に適用可能。
- コンプライアンス要件（例えば、地域限定のアクセス制御）を満たすのに有効。
2. ログ記録の設定
ブロックされたリクエストや許可されたリクエストのログ記録は、トラブルシューティングや監査に役立ちます。AWS WAFを使用する場合、以下の方法でログを保持できます。
- Amazon S3: 長期的なログ保存に適しており、Athenaを使ったクエリ解析が可能。
- CloudWatch Logs: リアルタイム監視やカスタムメトリクス作成に適している。
- Kinesis Data Firehose: 高スループットのログ処理や分析パイプラインに適用可能。
3. セキュリティグループの役割と制限
セキュリティグループは、AWSリソースへのネットワークアクセスを制御するための基本機能ですが、次のような制限があります。
- 制限:
- 国や地域ベースでのフィルタリングは直接サポートしていない（IPアドレスを手動で指定する必要がある）。
- ログ記録機能がないため、拒否されたリクエストの記録には別途CloudTrailやVPCフローログを使用する必要がある。
- 推奨シナリオ:
- 小規模な環境や、特定のIPアドレス範囲だけを許可する場合には有効。
4. IPアドレスベースのフィルタリング
特定の国や地域に基づいたIPアドレス範囲をフィルタリングする場合、以下の方法が考えられます。
- IPSet（AWS WAF）: IPアドレスのリストを作成し、特定の範囲を許可または拒否するルールを設定可能。
- メンテナンス: 手動でIPアドレスリストを管理する場合、IP範囲の変更に応じて更新が必要。
5. 選択すべき解決策
- AWS WAF GeoMatch: ログ記録機能が組み込まれており、メンテナンス負荷が低い。
- IPSet（AWS WAF）: IPアドレス範囲を細かく制御する必要がある場合に有効。
- セキュリティグループ: 簡易的なIP制御に適しているが、国ベースの管理には不向き。
まとめ
- 特定の国や地域に基づいたアクセス制御にはAWS WAFのGeoMatch機能を使用するのが最適。
- ログ記録には、CloudWatch LogsやAmazon S3を活用する。
- セキュリティグループはIP制御には適しているが、国ベースの管理やログ記録には適さない。
最適な設計を選ぶことで、運用負荷を軽減しつつセキュリティとコンプライアンス要件を満たせます。
実践
略
一問道場
質問 #388
ある企業が、パブリックなApplication Load Balancer（ALB）の背後でAuto Scalingグループ内のAmazon EC2インスタンスで実行されるWebアプリケーションを開発しています。特定の国のユーザーのみがアプリケーションにアクセスできるようにする必要があります。また、ブロックされたアクセスリクエストをログに記録できる機能が必要です。解決策は可能な限りメンテナンスが少なくて済むものでなければなりません。
以下のどの解決策がこれらの要件を満たしますか？
A. 指定された国に属するIPレンジを含むIPSetを作成します。AWS WAFウェブACLを作成し、IPSetに含まれないIPレンジからのリクエストをブロックするルールを設定します。そのルールをウェブACLに関連付け、ウェブACLをALBに関連付けます。
B. AWS WAFウェブACLを作成し、指定された国に属さないリクエストをブロックするルールを設定します。そのルールをウェブACLに関連付け、ウェブACLをALBに関連付けます。
C. AWS Shieldを構成して、指定された国に属さないリクエストをブロックします。AWS ShieldをALBに関連付けます。
D. 指定された国に属するIPレンジからのポート80および443の通信を許可するセキュリティグループルールを作成します。そのセキュリティグループをALBに関連付けます。
解説
この問題では、特定の国のユーザーのみを許可し、それ以外のリクエストをブロックしながら、ブロックされたアクセスリクエストをログに記録する方法を検討します。以下、選択肢ごとの解説です。
A.
「指定された国に属するIPレンジをIPSetに追加し、AWS WAFウェブACLを構成してブロックする」
- AWS WAFを使用することで、リクエストのIPアドレスや地理的な場所を基にルールを設定できます。
- ブロックされたリクエストはAWS WAFによってログに記録されるため、この要件を満たします。
- ただし、IPSetを手動で管理する必要があり、指定された国のIP範囲が変更されるたびにメンテナンスが必要になる点がデメリットです。
B.
「AWS WAFウェブACLを使用して、指定された国に属さないリクエストをブロックする」
- AWS WAFには地理的フィルタリング（GeoMatch）機能があり、国ベースでのルール作成が可能です。
- この方法では、特定の国以外のリクエストを簡単にブロックできます。
- AWS WAFのログ機能を利用することで、ブロックされたリクエストを記録することも可能です。
- IPアドレスリスト（IPSet）のメンテナンスが不要で、AWS WAFのGeoMatchルールだけで対応できるため、最もメンテナンスの負担が少ない解決策です。
C.
「AWS Shieldを使用して、特定の国以外のリクエストをブロックする」
- AWS Shieldは主に分散型サービス拒否（DDoS）攻撃を防ぐためのサービスであり、リクエストの国別ブロックやログ機能は提供していません。
- このため、この選択肢は要件を満たしません。
D.
「セキュリティグループを使用して、特定の国のIPレンジだけを許可する」
- セキュリティグループはIPアドレスベースのフィルタリングが可能ですが、特定の国に基づいたルール設定は直接サポートしていません。
- また、セキュリティグループにはログ機能がなく、ブロックされたリクエストを記録することはできません。
- このため、この選択肢も要件を満たしません。
正解:
B. AWS WAFのGeoMatch機能を使用したルール設定が最適解です。
理由:
- ログ記録: AWS WAFはブロックされたリクエストを自動的にログに記録可能。
- 低メンテナンス: 国ベースのフィルタリングはAWS WAFのGeoMatchルールで簡単に実現でき、IPアドレスの管理が不要。
- 拡張性: ALBに関連付けることで、複数のEC2インスタンスへの適用が容易。
389-AWS SAP AWS 「理論・実践・一問道場」（DR）戦略
理論
AWSでの災害復旧（Disaster Recovery, DR）の基本知識
AWSで災害復旧を設計する際、以下のポイントを押さえることが重要です。
1. 災害復旧（DR）戦略の主要要素
- RTO (Recovery Time Objective): システム復旧にかかる時間の目標。
- RPO (Recovery Point Objective): データ損失を許容できる最大の時間幅。
- コストと運用性: 予算と運用負荷を考慮し、適切な戦略を選択する。
2. AWS DRアーキテクチャの選択肢
AWSでは要件に応じて以下のDR戦略を採用できます：
- バックアップ & リストア:
- データを定期的にAmazon S3やS3 Glacierに保存し、障害発生時にリストアする。
- コストが低いが、RTOが長い。
- パイロットライト:
- 最小限のインフラをDRリージョンに構築しておき、障害時に拡張する。
- バランスが良い。
- ウォームスタンバイ:
- DRリージョンで縮小版システムを常時稼働させる。
- RTOが短いがコストが高い。
- マルチサイト:
- 本番とDRの両リージョンでシステムを完全稼働させる。
- 最高の可用性を確保するが、コストが非常に高い。
3. ファイルサーバーの災害復旧
Amazon FSx for Windows File ServerのDR設計には以下の方法が推奨されます：
- AWS DataSync: ファイルシステム間の効率的なデータ同期を実現。
- VPCピアリングまたはAWS PrivateLink: DRリージョン間で安全な通信を確保。
- AWS Transit Gateway: 複数のVPCやオンプレミスを効率的に接続。
4. セキュリティ要件
- データをAWS内で移動させる際はAWSバックボーンネットワークを利用し、インターネットを介さない。
- 暗号化とアクセス管理ポリシーを徹底する。
5. AWSサービスの役割
- Amazon FSx: Windowsファイルサーバーをクラウド上で提供。
- AWS DataSync: 大容量データの移行や同期に特化。
- AWS PrivateLink: プライベートネットワーク内でサービスへのアクセスを可能にする。
- AWS Transit Gateway: 複数リージョンやVPCの統合管理を可能にする。
AWSでの災害復旧を効果的に設計するには、要件に応じて適切なサービスとアーキテクチャを組み合わせることが鍵です。
実践
略
一問道場
質問 #389
ある企業がオンプレミスのインフラからAWSクラウドへアプリケーションを移行しようとしています。移行設計の会議で、企業はレガシーのWindowsファイルサーバーの可用性やリカバリオプションに関して懸念を示しました。このファイルサーバーには、データが破損したり失われたりした場合に再作成できない、重要で機密性の高いビジネスデータが含まれています。また、コンプライアンスの要件により、データがインターネットを経由することは許されていません。企業としては、できるだけAWSのマネージドサービスを活用したいと考えています。
そこで企業は、データをAmazon FSx for Windows File Serverのファイルシステムに保存することを決めました。ソリューションアーキテクトは、このデータを災害復旧（DR）のために別のAWSリージョンにコピーするソリューションを設計する必要があります。
この要件を満たすソリューションはどれですか？
A. DRリージョンにAmazon S3バケットを作成します。プライマリリージョンのFSx for Windows File ServerとDRリージョンのS3バケット間をAmazon FSx File Gatewayで接続します。その後、S3バケットをFSx File Gatewayの連続バックアップ用のソースとして設定します。
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 PrivateLinkを使用したインターフェースVPCエンドポイントを設定し、AWS DataSyncが通信できるようにします。
D. DRリージョンにFSx for Windows File Serverファイルシステムを作成します。AWS Transit Gatewayを使ってプライマリリージョンのVPCとDRリージョンのVPC間を接続します。その後、AWS Transfer Familyを活用してAWSのプライベートバックボーンネットワークを介し、プライマリリージョンのFSx for Windows File ServerとDRリージョンのFSx for Windows File Server間でファイルをコピーします。
解説
この質問は、**「AWSクラウドへの移行と災害復旧 (DR) ソリューションの設計」**に関する問題で、要件を満たす最適なソリューションを選択するものです。以下で各選択肢を解説します。
A.
DRリージョンにS3バケットを作成し、Amazon FSx File Gatewayを使用する案
- メリット: S3は耐久性が高く、バックアップストレージとして適しています。
- デメリット: FSx for Windows File Serverに直接バックアップを作成する場合、FSx File Gatewayは利用できません。この案はFSxの災害復旧に不適です。
- 結論: 要件を満たしていないため不適切。
B.
AWS Site-to-Site VPNを利用し、AWS DataSyncを使ってDRリージョンにデータを転送する案
- メリット: Site-to-Site VPNにより、オンプレミスや他のAWSリージョン間でセキュアに接続できます。DataSyncは効率的なデータ移行ツールです。
- デメリット: VPN接続はインターネットを介する可能性があり、データが「インターネットを通らない」という要件を満たしません。
- 結論: データの転送方法が要件を満たしていないため不適切。
C.
VPCピアリングとAWS PrivateLinkを利用し、AWS DataSyncを使う案
- メリット: VPCピアリングによりプライマリリージョンとDRリージョン間で直接接続が可能です。AWS PrivateLinkはインターネットを使用せず、安全な通信を実現します。DataSyncはFSx間のデータ同期を効率的に行えます。
- デメリット: 特に目立った欠点はなく、要件を満たしています。
- 結論: 正解候補。
D.
AWS Transit GatewayとAWS Transfer Familyを利用する案
- メリット: Transit Gatewayは複数のVPCを効率的に接続でき、AWSバックボーンネットワークを利用して安全なデータ転送が可能です。AWS Transfer Familyもデータ転送の選択肢となります。
- デメリット: Transfer Familyは主にSFTPやFTPプロトコルをサポートし、FSx for Windows File Serverの災害復旧用途には最適ではありません。また、構成が複雑です。
- 結論: 構成が要件に対して複雑すぎるため不適切。
正解: C
選択肢Cは以下の理由で最適です：
- VPCピアリングとAWS PrivateLinkにより、データがインターネットを通過しない要件を満たします。
- AWS DataSyncはFSx間のデータ移行や同期を効率的に行うツールです。
- シンプルかつ実現可能なソリューション設計で、要件全てを満たしています。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/178d7ae8-88e2-802c-ada5-c1dd12874ac9
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
