type
status
date
slug
summary
tags
category
icon
password
190-AWS SAP AWS 「理論・実践・一問道場」S3にエラーページ
理論
1. CloudFrontとオリジンフェイルオーバー
- Amazon CloudFrontは、エンドユーザーにコンテンツを低レイテンシーで配信するためのCDN（コンテンツ配信ネットワーク）です。CloudFrontは複数のオリジン（ソース）を設定でき、オリジンフェイルオーバー機能を使って、プライマリのオリジンが利用できない場合に自動的にバックアップのオリジンに切り替えることができます。
- オリジングループを使用すると、メインのオリジンがダウンした場合に、事前に設定されたセカンダリのオリジン（例えば、S3バケット）にリクエストをフォールバックさせ、カスタムエラーページなどを表示できます。これにより、サービスの中断を最小限に抑えることができます。
2. Application Load Balancer (ALB)と503エラー
- *ALB (Application Load Balancer)**は、アプリケーション層でのトラフィック分散を行うサービスです。通常、アプリケーションが高負荷で応答できない場合やインスタンスの健康状態が悪化すると、HTTP 503 Service Unavailableエラーが発生します。
- 503エラーが発生した場合、ユーザーがそのページにアクセスできない状態になるため、エラーハンドリングが重要です。ユーザーに適切なエラーページを表示することで、利用者体験を改善できます。
3. Route 53とフェイルオーバールーティング
- Amazon Route 53は、AWSのDNSサービスで、トラフィックのルーティングを行います。フェイルオーバールーティングポリシーを使用することで、ALBがダウンした際に他のエンドポイントにトラフィックを切り替えることができます。
- ただし、Route 53によるフェイルオーバーは、設定によっては切り替えに時間がかかることがあり、即座のエラーページ表示には不向きな場合があります。
4. S3静的ウェブサイトとカスタムエラーページ
- S3バケットを静的ウェブサイトホスティングとして使用することで、エラーページをホストできます。これにより、503エラー発生時にCloudFrontがS3のカスタムエラーページを返すことができます。S3は高可用性と耐障害性を備えているため、エラーページのホスティングに適しています。
まとめ：
この問題では、CloudFrontオリジングループとS3静的ウェブサイトの組み合わせが最適な解決策です。ALBの503エラーが発生した場合に、S3バケットにホストされたカスタムエラーページに迅速にフォールバックし、エラーをユーザーに即座に通知できます。
実践
略
一問道場
問題 #190
トピック
ある企業がAWSでウェブアプリケーションを実行しています。このウェブアプリケーションは、Amazon S3バケットから静的コンテンツを配信し、Amazon CloudFrontディストリビューションを通じて提供されています。動的コンテンツは、アプリケーションロードバランサー（ALB）を使用して配信され、ALBはAmazon EC2インスタンスのAuto Scalingグループにリクエストを分散します。アプリケーションはAmazon Route 53で設定されたドメイン名を使用しています。
ピーク時にユーザーがウェブサイトにアクセスしようとするときに、時折問題が発生するという報告があります。オペレーションチームは、ALBが時折HTTP 503 Service Unavailableエラーを返すことがあると確認しました。企業は、これらのエラーが発生したときにカスタムエラーページを表示したいと考えています。このページは、エラーコードが発生した際に即座に表示される必要があります。
どのソリューションが最も運用上の負担を少なくして、この要件を満たすでしょうか？
A. Route 53のフェイルオーバールーティングポリシーを設定し、ALBエンドポイントの状態を確認するためのヘルスチェックを構成し、フェイルオーバー先としてS3バケットのエンドポイントに切り替えます。
B. 2つ目のCloudFrontディストリビューションを作成し、カスタムエラーページをホストするためのS3静的ウェブサイトを設定します。Route 53でフェイルオーバールーティングポリシーを設定し、2つのディストリビューション間でアクティブ-パッシブ構成を使用します。
C. CloudFrontオリジングループを作成し、2つのオリジンを設定します。ALBエンドポイントをプライマリオリジンとして設定し、セカンダリオリジンとして静的ウェブサイトをホストするS3バケットを設定します。CloudFrontディストリビューションに対してオリジンフェイルオーバーを設定し、S3静的ウェブサイトを更新してカスタムエラーページを組み込みます。
D. CloudFront関数を作成して、ALBが返す各HTTPレスポンスコードを検証します。S3バケットにS3静的ウェブサイトを作成し、カスタムエラーページをアップロードします。関数を更新してS3バケットから読み込み、エラーページをエンドユーザーに提供します。
解説
この問題では、HTTP 503 Service Unavailableエラーが発生したときに、最小限の運用負荷でカスタムエラーページを表示する方法を選択する必要があります。
以下、選択肢ごとの解説です：
A. Route 53のフェイルオーバールーティングポリシーを設定し、ALBエンドポイントの状態を確認するためのヘルスチェックを構成し、フェイルオーバー先としてS3バケットのエンドポイントに切り替えます。
- Route 53のフェイルオーバールーティングポリシーは、ALBのステータスに基づいてリクエストを切り替える方法ですが、503エラーが発生した場合に即座にエラーページを表示するという要件には直接対応していません。エラーページを即座に表示するには、フェイルオーバーの遅延を最小化する方法が必要ですが、Route 53の切り替えにはタイムラグが生じることがあります。したがって、この選択肢は不適切です。
B. 2つ目のCloudFrontディストリビューションを作成し、カスタムエラーページをホストするためのS3静的ウェブサイトを設定します。Route 53でフェイルオーバールーティングポリシーを設定し、2つのディストリビューション間でアクティブ-パッシブ構成を使用します。
- これはカスタムエラーページのホスティングのための方法として有効ですが、アクティブ-パッシブ構成には複雑さと追加の管理負荷が伴います。さらに、CloudFrontを2つ設定する必要があり、管理のオーバーヘッドが増加します。このため、最小の運用負荷でエラー時に即座に対応するという要件には適していません。
C. CloudFrontオリジングループを作成し、2つのオリジンを設定します。ALBエンドポイントをプライマリオリジンとして設定し、セカンダリオリジンとして静的ウェブサイトをホストするS3バケットを設定します。CloudFrontディストリビューションに対してオリジンフェイルオーバーを設定し、S3静的ウェブサイトを更新してカスタムエラーページを組み込みます。
- オリジンフェイルオーバーは、CloudFrontがALBの応答がない場合に自動的にS3バケットに切り替える方法です。これにより、ALBが503エラーを返したときに、即座にS3バケットのカスタムエラーページが表示されます。この方法は、最も簡潔で運用負荷も少なく、要件を満たします。エラーページが即座に表示され、運用の管理も比較的少なくて済みます。
D. CloudFront関数を作成して、ALBが返す各HTTPレスポンスコードを検証します。S3バケットにS3静的ウェブサイトを作成し、カスタムエラーページをアップロードします。関数を更新してS3バケットから読み込み、エラーページをエンドユーザーに提供します。
- CloudFront関数を使ってレスポンスコードを検証し、エラーページを提供する方法ですが、このアプローチは他のオプションに比べて実装が複雑で、関数の管理が追加されるため、運用負荷が増えます。即座にエラーページを表示するという要件に対しても、他の方法に比べて最適ではありません。
結論：
最も運用負荷が少なく、503エラー発生時に即座にエラーページを表示するための最適解は、選択肢 C です。
CloudFrontオリジングループを利用することで、ALBがダウンした際に自動的にS3バケットにフォールバックし、エラーページを即座に表示することが可能です。191-AWS SAP AWS 「理論・実践・一問道場」Fargate起動タイプ
理論
1. Amazon ECS (Elastic Container Service)
- ECSは、コンテナを管理するサービスで、コンテナのデプロイやスケーリングを簡単に実行できます。Fargate起動タイプを使用することで、ユーザーがインフラストラクチャを管理せずに、コンテナをサーバーレスで実行できます。
- EC2起動タイプを使用すると、ユーザーはEC2インスタンスを管理し、オートスケーリングや容量の管理が必要になります。
2. Amazon EFS (Elastic File System)
- EFSは、複数のEC2インスタンスやコンテナがアクセスできる、スケーラブルなネットワークファイルシステムです。NFSプロトコルを使用しており、アプリケーションに必要な共有ストレージとして最適です。EFSは自動的にスケーリングし、管理が簡単で、コンテナ環境でも高い柔軟性を発揮します。
3. Amazon FSx for Lustre
- FSx for Lustreは、高性能な分散ファイルシステムを提供し、大規模なデータ分析やHPC（高性能コンピューティング）に適しています。EFSよりもパフォーマンス重視ですが、コストが高くなる場合があります。アプリケーションが大量のデータを処理する場合に使用されますが、一般的なWebアプリケーションには過剰な選択肢となります。
4. Amazon EBS (Elastic Block Store)
- EBSは、EC2インスタンス専用のブロックストレージです。マルチアタッチを使用して複数のインスタンスにアタッチすることは可能ですが、EFSやFSxのようにスケーラブルなファイルシステムとして使用するのは困難です。EBSは主にデータベースやアプリケーションの永続ストレージに利用されます。
結論
コンテナ化されたアプリケーションにおいて、インフラ管理の負担を軽減しつつ、スケーラブルかつ高可用性のある共有ストレージが求められる場合、Amazon EFSは最適な選択肢です。特に、**Amazon ECS（Fargate起動タイプ）**との組み合わせは、インフラの管理不要で、簡単にスケーラブルなソリューションを提供するため、コスト効率も高いです。
実践
略
一問道場
質問 #191
トピック 1
ある企業がアプリケーションをAWSに移行する計画を立てています。このアプリケーションはDockerコンテナとして実行され、NFSバージョン4のファイル共有を使用しています。
ソリューションアーキテクトは、基盤となるインフラストラクチャのプロビジョニングや管理を必要とせず、安全でスケーラブルなコンテナ化されたソリューションを設計する必要があります。
どのソリューションがこれらの要件を満たすでしょうか？
A. **Amazon Elastic Container Service (Amazon ECS)を使用してアプリケーションコンテナをデプロイし、Fargate起動タイプを選択します。共有ストレージにはAmazon Elastic File System (Amazon EFS)**を使用します。EFSファイルシステムID、コンテナのマウントポイント、およびEFS認証IAMロールをECSタスク定義に参照します。
B. Amazon Elastic Container Service (Amazon ECS)を使用してアプリケーションコンテナをデプロイし、Fargate起動タイプを選択します。共有ストレージにはAmazon FSx for Lustreを使用します。FSx for LustreファイルシステムID、コンテナのマウントポイント、およびFSx for Lustre認証IAMロールをECSタスク定義に参照します。
C. **Amazon Elastic Container Service (Amazon ECS)を使用してアプリケーションコンテナをデプロイし、Amazon EC2起動タイプとオートスケーリングをオンにします。共有ストレージにはAmazon Elastic File System (Amazon EFS)**を使用します。EFSファイルシステムをECSコンテナインスタンスにマウントし、EFS認証IAMロールをEC2インスタンスプロファイルに追加します。
D. Amazon Elastic Container Service (Amazon ECS)を使用してアプリケーションコンテナをデプロイし、Amazon EC2起動タイプとオートスケーリングをオンにします。共有ストレージにはAmazon Elastic Block Store (Amazon EBS)のマルチアタッチを有効にしたボリュームを使用します。EBSボリュームをECSコンテナインスタンスにアタッチし、EBS認証IAMロールをEC2インスタンスプロファイルに追加します。
解説
この問題では、アプリケーションをAWSに移行する際のセキュアでスケーラブルなコンテナ化されたソリューションを設計する必要があります。要件としては、インフラストラクチャの管理不要で、コンテナ間での共有ストレージが必要です。
それぞれの選択肢について解説します。
A. Amazon ECS (Fargate起動タイプ) と Amazon EFS
- Amazon ECSのFargate起動タイプを使用することで、インフラの管理は不要になります。Fargateはサーバーレスのコンテナ実行環境で、インフラのプロビジョニングや管理を自動で行ってくれるため、最小限の運用オーバーヘッドでアプリケーションをスケーリングできます。
- Amazon EFSは、複数のEC2インスタンスやコンテナ間で共有可能なファイルストレージを提供します。EFSはスケーラブルで、NFSをサポートしているため、既存のアプリケーションでも利用できます。EFSをECSタスク定義に組み込むことで、共有ストレージを簡単に設定できます。
このアプローチは、最もシンプルかつコスト効率よく要件を満たす方法です。
B. Amazon ECS (Fargate起動タイプ) と Amazon FSx for Lustre
- Amazon FSx for Lustreは、高性能な分散ファイルシステムを提供します。大規模なデータ分析やHPC（高性能コンピューティング）に使用されることが多いです。これは、NFSの代替としては高コストになる可能性があります。
- 一般的なWebアプリケーションには必要ない可能性があり、コストが高くなる可能性があります。
C. Amazon ECS (EC2起動タイプ) と Amazon EFS
- EC2起動タイプでは、インフラ管理が必要です。EC2インスタンスを管理し、オートスケーリングを設定する必要があります。これにより、運用負担が増えます。
- EFS自体は適切ですが、EC2の管理が発生するため、Fargateに比べて運用の手間が増えます。
D. Amazon ECS (EC2起動タイプ) と Amazon EBS
- Amazon EBSはEC2インスタンスのローカルストレージです。マルチアタッチを使用して複数のEC2インスタンスで共有できますが、EBSはストレージ容量が固定であり、EFSやFSxのようにファイルシステムとしてスケーラブルに使用することは難しいです。EBSを複数のインスタンスで共有するのは複雑であり、運用が難しくなります。
結論
最も簡単でコスト効率の良い解決策は、A. Amazon ECS (Fargate起動タイプ) と Amazon EFSです。この方法であれば、インフラ管理が不要で、共有ストレージとしてEFSを使用でき、スケーラブルでセキュアなソリューションが実現できます。
192-AWS SAP AWS 「理論・実践・一問道場」
理論
1. 段階的なデプロイメントとカナリアリリース
新しいアプリケーションのバージョンを展開する際、カナリアリリース（canary release）戦略を使用して、最初に一部のユーザーに新しいバージョンを提供し、その後のフィードバックを基にリリースを進める方法が有効です。この戦略により、リリース後の問題を早期に検出し、全ユーザーへの展開を進める前に修正することができます。
AWSでは、次のような方法を使って段階的なデプロイメントを実現できます：
- ターゲットグループの重み付け: ALB（Application Load Balancer）でターゲットグループを重み付けして、新しいバージョンのアプリケーションに一定の割合（例：10%）のトラフィックを分配します。この方法により、テストウィンドウ中のユーザーにのみ新しいロジックを提供できます。
- ALBのターゲットグループスティッキネス: スティッキネスを設定することで、顧客はテスト期間中に同じバージョンのアプリケーションを使い続けることが保証されます。セッションごとに特定のターゲットにトラフィックを送るため、一貫した体験が提供されます。
2. AWSのターゲットグループとALBの利用
ALBでは、複数のターゲットグループにトラフィックを分配することができます。この仕組みを活用して、異なるバージョンのアプリケーションを異なるターゲットグループにデプロイし、トラフィックを重み付けで分割することが可能です。
- ターゲットグループの管理: ALBのリスナーでターゲットグループに基づくルーティングを設定することで、トラフィックを特定のインスタンス群に分配できます。
- ルールの設定: ALBリスナーで、特定の条件（HTTPステータスコード、パスベースルーティングなど）に基づいて、ターゲットグループを動的に切り替えることもできます。
3. Route 53とWeighted Routing
Amazon Route 53の重み付けルーティングを使用すると、トラフィックの配分を細かく管理できます。例えば、特定のドメイン（api.example.com）に対して、トラフィックを10%ずつ分けて、新しいバージョンのアプリケーションに切り替えることが可能です。
- Weighted Routing Policy: これにより、特定のエンドポイントにトラフィックを動的に振り分け、徐々に新しいロジックに切り替えることができます。
4. ローリングアップデート
Auto Scalingグループのローリングアップデート機能を使用して、EC2インスタンスの更新を段階的に行うことも可能です。これにより、アプリケーションの更新が全インスタンスに一度に適用されることを避け、負荷を軽減しながら新しいバージョンを展開できます。
- MaxBatchSizeを設定することで、一度に更新されるインスタンス数を制御し、段階的にリリースを進めることができます。
5. セッションの一貫性
新しいバージョンに移行する際、ユーザーのセッションが中断されることなく、同じバージョンを使用し続けられるようにするために、セッションスティッキネスを活用することが重要です。これにより、同じユーザーは常に同じバックエンドインスタンスにリダイレクトされ、セッション状態を維持できます。
結論
この問題に関連する本質的な知識は、AWSのALB（Application Load Balancer）やRoute 53を活用して、段階的なデプロイメントやトラフィックの分割、セッション管理を行う方法です。AWSのこれらのツールをうまく組み合わせることで、リスクを最小化し、柔軟でスケーラブルな更新を実現できます。
実践
略
一問道場
質問 #192
トピック 1
ある会社はAWSクラウドでアプリケーションを実行しています。コアビジネスロジックは、Auto Scalingグループ内の一連のAmazon EC2インスタンスで実行されています。Application Load Balancer（ALB）がEC2インスタンスにトラフィックを分配しています。Amazon Route 53のレコード「api.example.com」はALBを指しています。
会社の開発チームはビジネスロジックの主要な更新を行います。会社には、変更がデプロイされる際、テストウィンドウ中に新しいロジックを受け取るのは顧客の10%のみとするというルールがあります。また、テストウィンドウ中、顧客は同じバージョンのビジネスロジックを使用し続ける必要があります。
この要件を満たすように更新をどのようにデプロイすべきですか？
A. 2番目のALBを作成し、新しいロジックを新しいAuto Scalingグループ内のEC2インスタンスにデプロイします。ALBがEC2インスタンスにトラフィックを分配するように設定します。Route 53のレコードを更新して、重み付けルーティングを使用し、2つのALBの両方を指すようにします。
B. 2番目のターゲットグループを作成し、そのターゲットグループをALBで参照します。この新しいターゲットグループに新しいロジックをデプロイします。ALBリスナーのルールを更新して、重み付けターゲットグループを使用するようにし、ALBターゲットグループのスティッキネスを設定します。
C. Auto Scalingグループのために新しいローンチ設定を作成します。ローンチ設定を使用してAuto Scalingのローリングアップデートポリシーを指定し、MaxBatchSizeオプションを10に設定します。ローンチ設定をAuto Scalingグループに置き換え、変更をデプロイします。
D. 2番目のAuto Scalingグループを作成し、ALBで参照します。この新しいAuto Scalingグループに新しいロジックをデプロイします。ALBのルーティングアルゴリズムを最小の未処理リクエスト（LOR）に変更します。ALBのセッションスティッキネスを設定します。
解説
この質問では、アプリケーションの更新を段階的に、かつ特定のルールに従って配信する方法を問うています。要件は、顧客がテストウィンドウ中に一貫して同じバージョンのビジネスロジックを使用し、10%の顧客にのみ新しいロジックが配信されるようにすることです。各選択肢の解説を行います。
A. 2番目のALBを作成して重み付けルーティングを使用
- 2番目のALBを作成し、新しいロジックを新しいAuto Scalingグループにデプロイする方法です。このALBにトラフィックを分配させ、Route 53の重み付けルーティングを使って、新しいALBと既存のALBの間で10%/90%のトラフィック配分を実現するという方法です。
- メリット: 重み付けルーティングによって、顧客の10%に新しいロジックを配信することができます。また、ALBがトラフィックを処理するため、スケーラビリティと可用性も確保できます。
- デメリット: 2つのALBを管理する必要があるため、運用のオーバーヘッドが増えます。
B. 2番目のターゲットグループとスティッキネス
- 2番目のターゲットグループを作成し、新しいロジックをそのターゲットグループにデプロイします。その後、ALBリスナーのルールを設定して、重み付けターゲットグループを使用し、スティッキネスを設定します。
- メリット: ALBを1つだけ使用し、ターゲットグループを分けて、テスト中のトラフィックを10%に制限できます。スティッキネスを設定することで、顧客が同じバージョンを使い続けることが保証されます。
- デメリット: ALBリスナーの設定とターゲットグループの管理が必要ですが、ALB自体は1つで済むため、Aよりは簡便です。
C. Auto Scalingのローリングアップデートポリシー
- Auto Scalingのローリングアップデートポリシーを使用して、新しいロジックを段階的にデプロイします。MaxBatchSizeを10に設定し、更新を10%ずつ進めます。
- メリット: EC2インスタンスの更新を段階的に行うため、ダウンタイムを最小限に抑えることができます。
- デメリット: ただし、この方法では、顧客に特定のバージョンを保証することが難しく、テストウィンドウ中に同じバージョンのロジックを使い続ける保証がありません。
D. 最小の未処理リクエスト（LOR）とセッションスティッキネス
- *最小の未処理リクエスト（LOR）**を使用してトラフィックを分配します。この方法では、ALBが現在処理中のリクエスト数が少ないインスタンスに新しいリクエストを割り当てます。セッションスティッキネスを使用することで、顧客は同じインスタンスで処理され続けます。
- メリット: スケーラビリティとセッションの一貫性を確保できます。
- デメリット: 10%の顧客に新しいロジックを提供するという要件を確実に満たすためには、より細かい制御が必要です。LORとセッションスティッキネスだけでは、目標通りにトラフィックを分けることは難しいです。
正解
Bが最も適切な選択肢です。
- 重み付けターゲットグループとスティッキネスを利用することで、顧客がテスト中に一貫して同じバージョンを使用できることを保証し、10%の顧客に新しいロジックを配信する要件を満たすことができます。また、ALBを1つだけ使用するため、運用負荷も最小限に抑えることができます。
193-AWS SAP AWS 「理論・実践・一問道場」Amazon FSx for Windows File Server 直接変更
理論
- ストレージ性能のボトルネック:
- 現在使用している HDDストレージは、SSDに比べて読み書き速度が遅いため、ファイルアクセスが遅くなり、ログイン時間が長くなります。
- スループットの制限:
- 現在のファイルシステムのスループットは16 MBpsで、ユーザー数の増加や高いアクセス頻度に対応するには不十分な場合があります。スループットが低いと、複数のユーザーが同時にアクセスする際に遅延が発生します。
- Active Directoryとのインタラクション:
- ログイン時に Active Directory と連携してユーザー認証を行うため、ファイルシステムの性能が悪化すると、認証や設定ファイルの読み込みが遅くなり、全体的なログイン時間に影響を与えます。
- ユーザー数の増加:
- ユーザー数が増加すると、ファイルシステムへのアクセス負荷も増し、性能が低いストレージでは ログイン処理が遅くなる 可能性があります。
Amazon FSx for Windows File Server のスループット容量とストレージタイプは直接変更可能です。
この問題を解決するためには、SSDへの変更 と スループットの向上 を行うことで、ログイン時間を改善することができます。
実践
略
一問道場
問題 #193
トピック 1
ある大手教育会社は、複数の大学で内部アプリケーションへのアクセスを提供するために Amazon Workspaces を導入しました。会社はユーザープロファイルを Amazon FSx for Windows File Server に保存しています。このファイルシステムは DNS エイリアス で構成され、自己管理の Active Directory に接続されています。ユーザーが Workspaces を使用し始めると、ログイン時間が許容できないレベルに増加しました。調査の結果、ファイルシステムのパフォーマンスが低下していることが判明しました。会社は、16 MBps のスループットで HDD ストレージ を使用してファイルシステムを作成しました。ソリューションアーキテクトは、定義されたメンテナンスウィンドウ内でファイルシステムのパフォーマンスを改善する必要があります。最小限の管理作業でこの要件を満たすには、ソリューションアーキテクトは何をすべきですか？
A.
AWS Backup を使用してファイルシステムの時点バックアップを作成し、バックアップを新しい FSx for Windows File Server ファイルシステムに復元します。
ストレージタイプとして SSD を選択し、スループット容量を 32 MBps に設定します。
バックアップと復元プロセスが完了したら、DNS エイリアス を調整し、元のファイルシステムを削除します。
B.
ユーザーをファイルシステムから切断し、Amazon FSx コンソールでスループット容量を 32 MBps に更新し、ストレージタイプを SSD に変更します。
ユーザーをファイルシステムに再接続します。
C.
新しい Amazon EC2 インスタンス に AWS DataSync エージェント を展開し、タスクを作成します。
既存のファイルシステムをソースとして設定し、新しい FSx for Windows File Server ファイルシステムを SSD ストレージ と 32 MBps のスループット容量でターゲットとして設定します。
タスクをスケジュールします。タスクが完了したら、DNS エイリアス を調整し、元のファイルシステムを削除します。
D.
Windows PowerShell コマンド を使用して既存のファイルシステムで シャドウコピー を有効にします。
シャドウコピージョブをスケジュールして、ファイルシステムの時点バックアップを作成します。
以前のバージョンを復元することを選択します。
新しい FSx for Windows File Server ファイルシステムを SSD ストレージ と 32 MBps のスループット容量で作成します。
コピージョブが完了したら、DNS エイリアス を調整し、元のファイルシステムを削除します。
解説
この問題の最適な解決策は オプションB です。理由は以下の通りです：
オプションB:
- 内容: ユーザーを一時的に切断し、Amazon FSxの管理コンソールでスループットを 32 MBps に変更し、ストレージタイプを SSD に変更します。変更後、ユーザーを再接続します。
- 利点: これが最も簡単で効率的な方法です。管理作業が少なく、ダウンタイムも最小限に抑えることができます。最小限の管理作業で性能向上が実現できるため、要求に最適です。
他の選択肢:
- オプションA: バックアップを作成し、新しいファイルシステムにリストアする方法ですが、手間がかかり、ダウンタイムが長くなります。
- オプションC: AWS DataSyncを使って新しいファイルシステムにデータを転送する方法ですが、設定が複雑で管理が増えます。
- オプションD: シャドウコピーを利用する方法ですが、これも手間がかかり、管理が複雑です。
したがって、オプションB が最も効率的で適切な選択です。
194-AWS SAP AWS 「理論・実践・一問道場」S3 マルチリージョンアクセスポイント
理論
- Amazon S3 クロスリージョンレプリケーション (CRR):
- S3バケット間でデータを自動的にコピーし、複数のリージョンにデータを保持できる機能です。
- 高可用性と冗長性を確保するために使用され、アプリケーションが複数のリージョンでアクセスする場合に有効です。
- S3 マルチリージョンアクセスポイント:
- 複数のS3バケットをシームレスに統合して、一つのアクセスポイントからアクセスできるようにする機能です。
- 複数リージョンにデータを分散させてアクセスする際、簡単に管理できるようになります。
- CloudFront と Global Accelerator:
- CloudFrontはコンテンツ配信ネットワーク（CDN）で、キャッシュを活用し、低遅延でコンテンツを提供しますが、動的データの更新には向いていません。
- Global Acceleratorは、アプリケーションのネットワークパフォーマンスを最適化しますが、直接S3データの同期を管理することはありません。
これらの知識を基に、複数リージョンでのS3データの管理や効率的なアプリケーション展開を行う際には、S3のクロスリージョンレプリケーションやマルチリージョンアクセスポイントが最も簡単で運用負荷が少ない方法です。
実践
略
一問道場
問題 #194
トピック 1
ある企業がAWS上でアプリケーションをホストしています。このアプリケーションは、1つのAmazon S3バケットに保存されたオブジェクトを読み書きします。企業は、アプリケーションを2つのAWSリージョンで展開できるようにアプリケーションを変更する必要があります。
最小の運用負荷でこの要件を満たす解決策はどれですか？
A. Amazon CloudFrontディストリビューションを設定し、S3バケットをオリジンとして指定します。アプリケーションを第二リージョンに展開し、アプリケーションをCloudFrontディストリビューションを使用するように変更します。AWS Global Acceleratorを使用してS3バケットのデータにアクセスします。
B. 第二リージョンに新しいS3バケットを作成します。元のS3バケットと新しいS3バケットの間で双方向のS3クロスリージョンレプリケーション(CRR)を設定します。S3マルチリージョンアクセスポイントを設定し、両方のS3バケットを使用します。変更されたアプリケーションを両方のリージョンに展開します。
C. 第二リージョンに新しいS3バケットを作成します。アプリケーションを第二リージョンに展開し、新しいS3バケットを使用するようにアプリケーションを構成します。元のS3バケットから新しいS3バケットにS3クロスリージョンレプリケーション(CRR)を設定します。
D. S3ゲートウェイエンドポイントを設定し、S3バケットをオリジンとして指定します。アプリケーションを第二リージョンに展開し、新しいS3ゲートウェイエンドポイントを使用するようにアプリケーションを変更します。S3インテリジェントティアリングをS3バケットで使用します。
解説
この問題では、アプリケーションを複数のAWSリージョンに展開し、S3バケットのデータを効率的に利用する方法を求めています。最小の運用負荷で要件を満たす方法を選ぶ必要があります。
A.
CloudFrontとGlobal Acceleratorを使用してS3バケットにアクセスする方法ですが、CloudFrontはキャッシュを使用するため、データの整合性が問題になる可能性があります。また、Global Acceleratorは主にアプリケーションアクセスの最適化に使用され、S3データの取り扱いには最適ではありません。運用負荷が高くなる可能性があります。
B.
新しいS3バケットを作成し、S3クロスリージョンレプリケーション(CRR) を設定して、データの整合性を保ちながら複数のリージョンで使用できます。さらに、S3マルチリージョンアクセスポイントを使うことで、2つのS3バケットをシームレスに使用できます。この方法は、運用負荷が最も低く、最適な選択です。
C.
新しいS3バケットを作成し、S3クロスリージョンレプリケーションを設定する方法ですが、Bと同様のレプリケーション設定が必要ですが、マルチリージョンアクセスポイントを使わず、バケットを個別に扱うため、管理が少し複雑になります。
D.
S3ゲートウェイエンドポイントを使用する方法ですが、S3アクセスを最適化するには使い勝手が悪く、特にマルチリージョン展開の要求に対して最適ではありません。
最適解はBで、最小の運用負荷で複数リージョンでのデータアクセスとアプリケーション展開を実現できます。
195-AWS SAP AWS 「理論・実践・一問道場」C5
理論
1. 高パフォーマンスコンピューティング (HPC)
- HPCは、非常に計算能力を要求するタスク、例えばリアルタイムでのデータ処理やゲームのレンダリングに使用されます。AWSでは、C5やM5インスタンスがHPC向けに最適化されています。
- C5インスタンスは計算処理向け、M5インスタンスはバランスの取れた性能を提供します。
2. Amazon EC2インスタンス
- On-Demandインスタンスは、必要なときに利用し、使用していないときには支払わない料金体系です。安定性が必要なアプリケーションに適しています。
- Spotインスタンスは余剰キャパシティを利用し、低コストで提供されますが、突然中断されるリスクがあります。リアルタイム性が要求されるアプリケーションには不向きです。
3. ElastiCache for Redis
- ElastiCache for Redisはインメモリキャッシュサービスで、特にリアルタイムで頻繁に更新されるデータ（リーダーボードなど）の管理に最適です。低レイテンシで高いスループットを提供し、データの読み書き速度が非常に速いため、ゲームのようなアプリケーションに最適です。
4. データベースとストレージ
- DynamoDBはフルマネージドなNoSQLデータベースで、高いスケーラビリティを持ちますが、低レイテンシが求められるリアルタイムのデータ更新にはElastiCacheの方が優れています。
- OpenSearchは検索エンジンに特化しており、ゲームのようなリアルタイム更新には不向きです。
5. オートスケーリング
- オートスケーリングを使用することで、負荷の増加に対応してインスタンス数を自動的に調整できます。これにより、ピーク時のトラフィックにも柔軟に対応可能となります。
結論
ゲームプラットフォームなど、リアルタイムでデータの更新が頻繁に行われる場合、低レイテンシでキャッシュ機能を提供するElastiCache for Redisの使用が重要です。また、計算リソースとしてはOn-Demand EC2インスタンスを選択することで、安定したパフォーマンスが保証されます。
実践
略
一問道場
オンラインゲーム会社は、ゲームプラットフォームをAWSに再ホストする必要があります。この会社のゲームアプリケーションは高性能コンピューティング（HPC）処理が必要で、リーダーボードは頻繁に変更されます。ゲーム表示用のNode.jsアプリケーションをホストするために、Ubuntuインスタンスが計算最適化されて実行されています。ゲームの状態は、オンプレミスのRedisインスタンスで追跡されています。この会社は、アプリケーションのパフォーマンスを最適化するための移行戦略が必要です。
どのソリューションがこの要件を満たしますか？
A.
m5.largeのAmazon EC2 SpotインスタンスをAuto Scalingグループで作成し、アプリケーションロードバランサーの背後で使用します。リーダーボードを維持するために、Amazon ElastiCache for Redisクラスターを使用します。
B.
c5.largeのAmazon EC2 SpotインスタンスをAuto Scalingグループで作成し、アプリケーションロードバランサーの背後で使用します。リーダーボードを維持するために、Amazon OpenSearch Serviceクラスターを使用します。
C.
c5.largeのAmazon EC2 On-DemandインスタンスをAuto Scalingグループで作成し、アプリケーションロードバランサーの背後で使用します。リーダーボードを維持するために、Amazon ElastiCache for Redisクラスターを使用します。
D.
m5.largeのAmazon EC2 On-DemandインスタンスをAuto Scalingグループで作成し、アプリケーションロードバランサーの背後で使用します。リーダーボードを維持するために、Amazon DynamoDBテーブルを使用します。
解説
この問題では、ゲームプラットフォームのAWSへの再ホストにおける最適な移行戦略を選ぶ必要があります。以下でそれぞれの選択肢について解説します。
A. m5.largeのEC2 Spotインスタンス + ElastiCache for Redis
- m5.largeのEC2 Spotインスタンスは、コスト効率が高く、計算処理が多いゲームアプリケーションに適している選択肢です。ただし、Spotインスタンスは一時的に中断される可能性があるため、ゲームのリアルタイム性が要求される場合には注意が必要です。
- ElastiCache for Redisは、低レイテンシでの高速なデータアクセスが可能で、ゲームのリーダーボードのような頻繁に更新されるデータに適しています。Redisはインメモリデータベースであり、リーダーボードを高パフォーマンスで維持できます。
- 利点: 高パフォーマンス、コスト効率、頻繁なデータ更新に対応できる。
- 欠点: Spotインスタンスは中断のリスクがあるため、安定性を重視する場合には、On-Demandインスタンスの方が適している場合があります。
B. c5.largeのEC2 Spotインスタンス + OpenSearch Service
- c5.largeのEC2 Spotインスタンスは、計算性能に特化したインスタンスであり、ゲームアプリケーションに適しています。ただし、Spotインスタンスの不安定さが懸念されます。
- Amazon OpenSearch Serviceは、検索エンジンとしては優れていますが、リーダーボードのような頻繁なデータ更新や高頻度の書き込みにはRedisの方が適しています。
- 利点: 高い計算能力と検索機能。
- 欠点: リーダーボードの管理には不向き（Redisの方が適切）。OpenSearchは主に検索エンジン用途です。
C. c5.largeのEC2 On-Demandインスタンス + ElastiCache for Redis
- c5.largeのEC2 On-Demandインスタンスは、安定した計算能力を提供します。On-DemandインスタンスはSpotインスタンスより高価ですが、安定性が求められるゲームアプリケーションには適しています。
- ElastiCache for Redisは、頻繁に更新されるデータ（リーダーボード）に最適で、低レイテンシのアクセスが可能です。
- 利点: 安定したインスタンスと高パフォーマンスなデータストレージ（Redis）。
- 欠点: コストが高くなる可能性がありますが、安定性を重視する場合には適切な選択です。
D. m5.largeのEC2 On-Demandインスタンス + DynamoDB
- m5.largeのEC2 On-Demandインスタンスは、安定した計算能力を提供しますが、コストが高くなる場合があります。
- DynamoDBはスケーラブルでフルマネージドなNoSQLデータベースですが、リーダーボードのような頻繁に更新されるデータには適していない可能性があります。Redisの方が低レイテンシで、ゲームのようなリアルタイムなデータ更新に適しています。
- 利点: 高いスケーラビリティと管理の簡便さ。
- 欠点: リーダーボードのようなリアルタイム性が求められるデータに対しては、Redisよりパフォーマンスが劣る場合があります。
結論
最適なソリューションは C です。理由としては、安定した On-Demandインスタンス と、リーダーボードの頻繁な更新を効率的に処理できる ElastiCache for Redis を組み合わせることで、アプリケーションのパフォーマンスを最大化できるからです。また、EC2のOn-Demandインスタンスを使用することで、安定性を確保できます。
196-AWS SAP AWS 「理論・実践・一問道場」
理論
Amazon Redshift は、SaaS（Software as a Service） ではなく、PaaS（Platform as a Service） に分類されるサービスです。具体的には、AWSのフルマネージド型のデータウェアハウスサービスで、ビッグデータのクエリや分析を効率的に行うために最適化されています。
Amazon Redshiftの特徴
- フルマネージド: AWSがインフラの管理、スケーリング、バックアップなどを行うため、ユーザーはデータベースの運用管理から解放されます。
- 高速なデータ分析: 大量のデータに対して、高速にSQLクエリを実行できるよう設計されています。特に、カラム型ストレージと並列処理を活用したアーキテクチャが特徴です。
- 拡張性: 必要に応じて、コンピューティングリソースやストレージを柔軟にスケールすることができます。
- コスト効率: 定期的に発生する分析作業や大量のデータ処理に対して、低コストで提供されています。ユーザーは、必要なリソースのみを使用することでコストを最適化できます。
SaaSとの違い
- SaaS (Software as a Service): ユーザーはアプリケーションソフトウェアをインターネット経由で利用するサービス。例: Google Drive, Microsoft 365。
- PaaS (Platform as a Service): インフラの管理をAWSが行い、ユーザーがアプリケーションを構築・実行するためのプラットフォームを提供するサービス。RedshiftのようなデータベースはPaaSに分類されます。
したがって、Amazon Redshiftはデータ分析用のPaaSサービスであり、SaaSではありません。
1. スケーラビリティと可用性
- スケーラビリティは、アプリケーションが増加するトラフィックやデータに対応するために、リソースを効率的に追加できる能力を意味します。AWSでは、Auto ScalingやElastic Load Balancing (ELB)、AWS Lambdaを使用して、必要に応じてシステムがスケールアップまたはスケールダウンします。
- 可用性は、システムの稼働率が高いこと、つまりアプリケーションが常に利用可能であることを指します。これを実現するためには、複数のアベイラビリティゾーンにデプロイすることが重要です。
2. サーバーレスアーキテクチャ
- API GatewayとAWS Lambdaを使用したサーバーレスアーキテクチャは、インフラ管理のオーバーヘッドを最小化する方法です。Lambdaは、イベント駆動型でコードを実行し、インフラのスケーリングを自動的に行います。この方法は特に、トラフィックの急増に対応する場合に有効です。
3. データストレージと分析
- Amazon S3は、オブジェクトストレージサービスで、静的なデータを効率的に保存できます。Amazon Athenaは、S3に保存されたデータに対してSQLクエリを実行できるサービスで、大量のデータを効率的に分析できます。
- Amazon QuickSightは、視覚化ツールとして、S3やAthenaからデータを取得し、インタラクティブなダッシュボードを作成できます。
4. データレポートの生成
- 月次レポートを生成する場合、データが大きくなることを考慮して、AthenaやQuickSightを活用することが推奨されます。これにより、大規模なデータを効率的にクエリし、レポートを生成できます。
5. 運用オーバーヘッドの最小化
- サーバーレスアーキテクチャ（Lambda、API Gateway）や、管理が簡単なサービス（S3、Athena）を使用することで、運用オーバーヘッドを最小限に抑えることができます。これにより、インフラ管理にかかる手間を減らし、開発に集中できるようになります。
まとめ：
- スケーラビリティと可用性を確保するために、サーバーレスアーキテクチャ（API Gateway + Lambda）や、S3 + Athena + QuickSightを使ったデータ分析手法が有効です。これにより、効率的な運用と最小限のオーバーヘッドで、高いパフォーマンスを発揮できます。
実践
略
一問道場
問題 #196
トピック 1
ソリューションアーキテクトは、従業員のモバイルデバイスからタイムシートの入力を受け付けるアプリケーションを設計しています。タイムシートは毎週提出され、ほとんどの提出は金曜日に行われます。データは給与管理者が月次レポートを実行できる形式で保存する必要があります。インフラストラクチャは高可用性があり、データの受信レートやレポートリクエストに合わせてスケールできる必要があります。
運用オーバーヘッドを最小化しつつ、これらの要件を満たすために必要な手順の組み合わせはどれですか？（2つ選んでください。）
A. アプリケーションを Amazon EC2 On-Demand インスタンスに展開し、複数のアベイラビリティゾーンにまたがるロードバランシングを使用します。金曜日の提出が多い前に容量を追加するために、スケジュールされた Amazon EC2 Auto Scaling を使用します。
B. アプリケーションをコンテナとして Amazon Elastic Container Service (Amazon ECS) に展開し、複数のアベイラビリティゾーンにまたがるロードバランシングを使用します。金曜日の提出が多い前に容量を追加するために、スケジュールされたサービス Auto Scaling を使用します。
C. アプリケーションのフロントエンドを Amazon S3 バケットにデプロイし、Amazon CloudFront を使用して提供します。アプリケーションのバックエンドを Amazon API Gateway と AWS Lambda プロキシ統合を使用してデプロイします。
D. タイムシート提出データを Amazon Redshift に保存し、Amazon QuickSight を使用して Amazon Redshift をデータソースとしてレポートを生成します。
E. タイムシート提出データを Amazon S3 に保存し、Amazon Athena と Amazon QuickSight を使用して Amazon S3 をデータソースとしてレポートを生成します。
解説
この問題のポイントは、高可用性、スケーラビリティ、データ保存形式、および最小の運用オーバーヘッドに関する要件です。解説します。
A と B
A と B は EC2 インスタンスや ECS を使用してアプリケーションをデプロイし、スケジュールされた Auto Scaling を使用して金曜日の高負荷に対応しようとしています。
- A は EC2 インスタンスを使用し、B は ECS を使用しています。両方とも、負荷に合わせてスケールを調整するために Auto Scaling を利用します。
- ただし、これらはインスタンスやコンテナの管理が必要で、運用のオーバーヘッドが発生します。また、月次レポートやデータ集計のためには別のストレージとレポート生成ツールが必要です。
C
C は API Gateway と Lambda を使用してバックエンドをデプロイし、フロントエンドを S3 と CloudFront で提供します。
- API Gateway と Lambda の組み合わせは サーバーレスアーキテクチャ で、インフラ管理のオーバーヘッドを最小化できます。
- フロントエンドを S3 と CloudFront に配置することで、静的コンテンツの配信が高速でスケーラブルになります。
D と E
D と E は、データを保存するストレージとして S3 や Redshift を使用し、QuickSight でレポートを生成しようとしています。
- D では、Redshift にデータを保存し、QuickSight を使用してレポートを生成しますが、Redshift は高可用性やスケーラビリティを提供しますが、運用オーバーヘッドが高いです。
- E は、S3 にデータを保存し、Athena と QuickSight を使用してデータをクエリし、レポートを生成するアーキテクチャです。このアーキテクチャは、S3 と Athena を使ったサーバーレスアプローチで、管理が最小限となり、データ分析の効率性が高いです。
正解
- C と E が正解です。
- C はサーバーレスアーキテクチャで運用オーバーヘッドが少なく、スケーラブルで高可用性も備えています。
- E は、S3 にデータを保存し、Athena と QuickSight でレポートを生成することで、データ保存と分析が効率的で、運用オーバーヘッドも最小限です。
まとめ：
- C と E は、アプリケーションの可用性を高めつつ、スケーラビリティと最小の運用オーバーヘッドを実現できます。
197-AWS SAP AWS 「理論・実践・一問道場」trail
理論
1. AWS CloudTrail
CloudTrailは、AWSアカウント内のAPIリクエストを記録するサービスです。S3バケットのデータイベント（オブジェクトの作成、削除、アクセスなど）をログとして保存できます。これにより、誰がどのような操作を行ったかを追跡でき、監査やコンプライアンスに役立ちます。
2. S3 サーバーアクセスログ
S3バケットのサーバーアクセスログは、バケットに対するリクエスト（GET、PUT、DELETEなど）の詳細を記録します。これを使用して、誰がどのファイルにアクセスしたか、何時にアクセスしたかなどを分析できます。このログはセキュリティと監査において重要です。
3. EventBridge と SNS
Amazon EventBridgeは、AWSサービス間でイベントをリアルタイムで伝送できるサービスです。SNSは、通知をメールやSMSで送信するために使用されます。S3でオブジェクト削除イベントが発生した場合、EventBridgeを使用してSNSをトリガーし、即座に通知を受け取ることができます。
4. S3 ライフサイクルポリシー
S3バケットに保存されたオブジェクトの保存期間や移行ルールを自動化する方法です。例えば、特定の期間後にオブジェクトをアーカイブしたり削除したりすることができます。ログデータを一定期間保存するために、ライフサイクルポリシーを活用できます。
5. ログデータの長期保存
ログデータを長期間保存する必要がある場合、コスト効率の良いストレージソリューションを選択することが重要です。S3バケットに保存することが一般的で、特に低コストのストレージクラス（例：S3 Glacier）を利用することができます。
これらを組み合わせて、AWS環境で効率的なセキュリティ監視とログ管理を実現できます。
実践
略
一問道場
問題 #197
トピック 1
ある企業が、Amazon S3 バケットに機密データを保存しています。企業は、その S3 バケット内のオブジェクトに対するすべてのアクティビティをログとして記録し、5年間そのログを保持する必要があります。また、企業のセキュリティチームは、S3 バケット内のデータが削除されるたびに、メール通知を受け取る必要があります。
最もコスト効率の良い方法でこの要件を満たすために必要な手順の組み合わせはどれですか？（3つ選択してください。）
A. AWS CloudTrail を設定して、S3 データイベントをログに記録する。
B. S3 サーバーアクセスログを設定して、S3 バケットのログを記録する。
C. Amazon S3 を設定して、オブジェクト削除イベントを Amazon Simple Email Service (Amazon SES) に送信する。
D. Amazon S3 を設定して、オブジェクト削除イベントを Amazon EventBridge イベントバスに送信し、そこから Amazon Simple Notification Service (Amazon SNS) トピックに通知する。
E. Amazon S3 を設定して、ログを Amazon Timestream に送信し、データストレージ階層を適用する。
F. 新しい S3 バケットを設定して、ログを保存し、S3 ライフサイクルポリシーを適用する。
解説
この問題の解決策は、以下のように最もコスト効率よく要件を満たす手順です。
- A. AWS CloudTrail を設定して、S3 データイベントをログに記録する
CloudTrailは、S3のデータイベント（例: オブジェクトの作成や削除）を追跡するために使用します。このログは、セキュリティとコンプライアンスに役立ちます。
- B. S3 サーバーアクセスログを設定して、S3 バケットのログを記録する
サーバーアクセスログは、S3バケットへのすべてのリクエスト（データの読み書きや削除）を記録します。これにより、アクセス履歴を詳細に確認できます。
- D. Amazon S3 を設定して、オブジェクト削除イベントを Amazon EventBridge イベントバスに送信し、そこから Amazon SNS に通知を送る
EventBridgeとSNSを使用して、オブジェクト削除イベントが発生した際にリアルタイムで通知を受け取ることができます。これにより、削除アクションを迅速にモニタリングできます。
これらの手順を組み合わせることで、S3バケットのセキュリティと監視要件を満たしつつ、コスト効率よく管理できます。他の選択肢は不要なサービスや機能を含んでおり、コストが高くなる可能性があります。
198-AWS SAP AWS 「理論・実践・一問道場」
理論
実践
略
一問道場
問題 #198
トピック 1
ある企業が、オンプレミスのデータセンターとAWSクラウドにサーバーを配置したハイブリッド環境を構築しています。この企業は、3つのVPCにAmazon EC2インスタンスをデプロイしています。各VPCは異なるAWSリージョンに配置されています。また、企業はデータセンターに最も近いリージョンにAWS Direct Connect接続を確立しています。
企業は、オンプレミスのデータセンターにあるサーバーがすべての3つのVPCにあるEC2インスタンスにアクセスできるようにする必要があります。また、オンプレミスのデータセンターにあるサーバーがAWSのパブリックサービスにもアクセスできるようにする必要があります。
最もコストを抑えた方法でこの要件を満たすために必要な手順はどれですか？（2つ選んでください。）
A. データセンターに最も近いリージョンにDirect Connectゲートウェイを作成する。Direct Connect接続をDirect Connectゲートウェイに接続する。Direct Connectゲートウェイを使用して、他の2つのリージョンのVPCと接続する。
B. オンプレミスのデータセンターから他の2つのリージョンに追加のDirect Connect接続を設定する。
C. プライベートVIFを作成し、プライベートVIF経由でAWS Site-to-Site VPN接続を確立して、他の2つのリージョンのVPCに接続する。
D. パブリックVIFを作成し、パブリックVIF経由でAWS Site-to-Site VPN接続を確立して、他の2つのリージョンのVPCに接続する。
E. VPCピアリングを使用して、リージョン間でVPC同士を接続する。既存のDirect Connect接続を使用してプライベートVIFを作成し、ピアリングしたVPCに接続する。
200-AWS SAP AWS 「理論・実践・一問道場」AWS Firewall Manager
理論
AWS WAF（Web Application Firewall）は、ウェブアプリケーションの脆弱性から保護するための強力なツールです。特に、OWASPトップ10に代表されるウェブアプリケーション脆弱性（例：SQLインジェクション、クロスサイトスクリプティング）に対する防御を提供します。これを効率的に管理・適用するために、以下のAWSのサービスが役立ちます。
- AWS WAF: SQLインジェクションやクロスサイトスクリプティングなどの攻撃を防ぐためのカスタムルールを作成して、CloudFrontやApplication Load Balancerに適用します。
- AWS Firewall Manager: 複数のAWSアカウントにまたがって、AWS WAFルールを一元的に設定・管理するためのサービスです。これにより、大規模な環境でも一貫したセキュリティポリシーを適用できます。
- AWS Organizations: 複数のAWSアカウントを管理するためのサービスで、組織全体でセキュリティの設定を統一できます。これにより、AWS Firewall Managerを使用してセキュリティルールを全アカウントに展開できます。
- HTTPSによる暗号化: CloudFrontでHTTPリクエストをHTTPSにリダイレクトすることで、データがインターネットを通じて安全に送信されるように暗号化します。
これらのサービスを組み合わせて使用することで、ウェブアプリケーションのセキュリティを強化し、OWASPトップ10の脆弱性に対する効果的な防御を提供できます。
実践
略
一問道場
問題 #199
トピック 1
ある企業が、AWS Organizationsを使用して数百のAWSアカウントを管理しています。ソリューションアーキテクトは、Open Web Application Security Project（OWASP）トップ10のウェブアプリケーション脆弱性に対して基本的な保護を提供するソリューションに取り組んでいます。ソリューションアーキテクトは、AWS WAFを使用して、組織内のすべての既存および新規のAmazon CloudFrontディストリビューションに保護を提供しています。
基本的な保護を提供するために、ソリューションアーキテクトが実行すべき手順の組み合わせはどれですか？（3つ選んでください。）
A. すべてのアカウントでAWS Configを有効にする
B. すべてのアカウントでAmazon GuardDutyを有効にする
C. 組織のすべての機能を有効にする
D. AWS Firewall Managerを使用して、すべてのアカウントでCloudFrontディストリビューションにAWS WAFルールをデプロイする
E. AWS Shield Advancedを使用して、すべてのアカウントでCloudFrontディストリビューションにAWS WAFルールをデプロイする
F. AWS Security Hubを使用して、すべてのアカウントでCloudFrontディストリビューションにAWS WAFルールをデプロイする
解説
CDE
以下は、OWASPトップ10のウェブアプリケーション脆弱性に対する基本的な保護を提供するための手順についての説明です：
- 組織のすべての機能を有効にする（オプションC）:
- このステップは、AWS Organizationsで組織レベルの機能を有効にすることを指します。すべての機能を有効にすることで、AWS Firewall Managerを使って、複数のアカウントで一元的にセキュリティポリシーを管理できるようになります。これにより、AWS WAFルールを簡単に展開できます。
- AWS Firewall Managerを使用して、すべてのアカウントでCloudFrontディストリビューションにAWS WAFルールをデプロイする（オプションD）:
- AWS Firewall Managerを使用すると、AWS WAF（Web Application Firewall）ルールを複数のアカウントにわたって一元的に管理・展開できます。これにより、CloudFrontディストリビューションに対してOWASPトップ10に含まれるSQLインジェクションやクロスサイトスクリプティング（XSS）などの一般的なウェブ脆弱性に対する保護を提供できます。
- HTTPリクエストをHTTPSリクエストにリダイレクトする設定を行う:
- CloudFrontでHTTPリクエストをHTTPSにリダイレクトする設定を行うことで、データの送信中にSSL/TLSを使用して暗号化を行い、通信の安全性を確保できます。これにより、データが不正に盗聴されるリスクを減少させることができます。
これらの手順を組み合わせることで、OWASPトップ10の脆弱性に対する基本的な保護が提供され、セキュリティが強化されます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/171d7ae8-88e2-8015-b5be-d0834b4b07d5
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
