type
status
date
slug
summary
tags
category
icon
password
181-AWS SAP AWS 「理論・実践・一問道場」トランジットゲートウェイ+RAM
理論
1. AWS OrganizationsとVPC管理
AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。これにより、アカウント間でのリソースの統合、ポリシー適用、およびセキュリティ管理が効率的に行えます。しかし、アカウントごとに異なるVPCを持つ場合、VPC間の通信をどのように確立するかが重要な課題となります。
2. VPC間の通信方法
VPC間で通信を行うためには、いくつかの方法があります。以下はその代表的な方法です:
- VPCピアリング接続: 直接的な接続を確立するために、異なるVPC間でピアリング接続を作成します。しかし、ピアリング接続はVPCの数が増えると管理が複雑になるため、スケーラビリティに限界があります。
- Transit Gateway: 複数のVPCを中央で接続するためのサービスで、各VPCを一元的に接続できます。Transit Gatewayは、複数のVPCを効率的に接続でき、スケーラビリティの問題を解決します。トラフィックの流れを一元管理できるため、大規模な環境に適しています。
3. AWS RAM (Resource Access Manager)
AWS RAMは、複数のアカウント間でリソースを共有するためのサービスです。これにより、VPC内のリソース(例えば、VPCピアリング接続やTransit Gatewayなど)を他のアカウントと共有できます。重要なのは、VPCそのものをRAMで共有することはできないという点です。VPC内の個別のリソースやサービスを共有することができますが、VPC全体を共有することはできません。
4. VPCの設計と運用
AWSでのVPC設計は、アカウントやリージョンごとにVPCを分けることが多いですが、これには以下のような注意点があります:
- CIDR範囲の設計: 各VPCにはCIDR(Classless Inter-Domain Routing)範囲があり、アカウント間で重複しない範囲を設計する必要があります。
- セキュリティグループとネットワークACL: VPC間の通信を制御するためには、セキュリティグループやネットワークACLを適切に設定することが重要です。特に、VPCピアリングやTransit Gatewayを使用する際は、通信を許可する設定が必要です。
5. スケーラビリティと運用負荷
- ピアリング接続は、少数のVPCであれば効果的ですが、数百以上のVPCを接続する場合、接続管理が煩雑になるため、管理負荷が高くなります。
- Transit Gatewayは、複数のVPCを一元的に接続し、運用負荷を軽減するため、規模が大きくなる場合に適しています。
6. 最適なソリューション選択
- 大規模なVPC間通信を管理する際は、Transit Gatewayを利用するのが最も効果的です。これにより、複数のVPCを簡単に接続し、管理が容易になります。
- ピアリング接続やVPN接続は、小規模な環境や特定の要件に適していますが、大規模な環境での運用には限界があります。
まとめ:
AWS上でのVPC間通信の管理は、規模が大きくなると複雑になるため、Transit Gatewayを使用することで効率的かつスケーラブルなネットワーク設計が可能になります。また、AWS RAMを使用して、特定のリソースを他のアカウントと共有することができ、運用負荷を軽減できますが、VPC全体の共有はできない点に注意が必要です。
実践
略
一問道場
問題 #181
トピック 1
ある会社がAWSクラウドでネットワーク構成を設計しています。この会社はAWS Organizationsを使用して複数のアカウントを管理しており、3つの組織単位(OU)があります。各OUには100以上のAWSアカウントが含まれており、各アカウントには単一のVPCがあります。すべてのVPCは同じAWSリージョンにあり、各アカウントのCIDR範囲は重複していません。
会社は、同じOU内のVPCは互いに通信できるが、他のOUのVPCとは通信できないようにするソリューションを実装する必要があります。
最も運用負荷が少ないソリューションはどれですか?
A. AWS CloudFormationスタックセットを作成して、各OU内のアカウント間でVPCピアリングを確立します。スタックセットを各OUに展開します。
B. VPCそのものをRAMで共有するという点は誤りです。
C. 各OUにアカウントでトランジットゲートウェイを展開し、AWS Resource Access Manager(AWS RAM)を使用してそのトランジットゲートウェイを組織全体で共有します。各VPCにトランジットゲートウェイVPCアタッチメントを作成します。
D. 各OUに専用のネットワーキングアカウントを作成し、そのアカウントに単一のVPCを作成します。VPN接続をネットワーキングアカウントとOU内の他のアカウントとの間で確立します。サードパーティ製のルーティングソフトウェアを使用して、VPC間で遷移的なトラフィックをルーティングします。
解説
正解は C です。
理由:
- C. トランジットゲートウェイは、複数のVPCを効率的に接続し、異なるOU間の通信を隔離するための最適なソリューションです。トランジットゲートウェイは、各OUのVPCを一元的に接続でき、管理の手間を最小限に抑えつつ、同じOU内でのVPC間の通信を可能にします。また、AWS Resource Access Manager(AWS RAM)を使用して、トランジットゲートウェイを組織全体で共有することにより、運用負荷を大幅に軽減できます。
他の選択肢の問題点:
- A: CloudFormationスタックセットを使ってVPCピアリングを設定する方法は可能ですが、100以上のアカウント間で個別にピアリングを設定するのは運用負荷が高く、スケーラブルではありません。
- B: ネットワーキングアカウントを作成し、VPCを共有する方法は、VPCピアリングよりも管理が簡単かもしれませんが、VPC間の接続を管理する方法としてはスケーラビリティに欠けます。
- D: VPN接続を使用してトラフィックをルーティングする方法は、設定や運用に手間がかかり、他の選択肢と比較して非効率的です。
したがって、Cが最も運用負荷が少なく、スケーラブルで効果的な方法です。
182-AWS SAP AWS 「理論・実践・一問道場」データの暗号化(静止状態および転送中)
理論
1. 高耐久性・高可用性のストレージ
AWSのストレージサービスには、耐久性と可用性を高めるために設計されたものがいくつかあります。特に、Amazon S3(Simple Storage Service)は、データの冗長性を確保するために複数のアベイラビリティゾーンにデータを保存します。これにより、災害時でもデータの可用性が保たれます。
2. データの暗号化(静止状態および転送中)
データは、保存時(静止状態)と転送時(通信中)の両方で暗号化する必要があります。AWSでは、以下の方法で暗号化を実現できます:
- 静止状態の暗号化: Amazon S3、EBS(Elastic Block Store)、DynamoDBなどのサービスでは、AWS KMS(Key Management Service)を使用してデータを暗号化できます。
- 転送中の暗号化: 通信時の暗号化は、HTTPS(SSL/TLS)を使用して実施できます。これにより、ネットワーク越しに送信されるデータも安全に保護されます。
3. 暗号化キーの管理とローテーション
AWS KMSを使用すると、暗号化キーを会社が管理でき、定期的にローテーションすることが可能です。これにより、セキュリティを保ちながら、暗号化キーの管理を自動化できます。
4. AWSのストレージオプション
- Amazon S3: 大規模なオブジェクトストレージに最適で、データの高耐久性、可用性、暗号化管理が可能です。特に大容量のファイルの保存に向いています。
- Amazon EBS: EC2インスタンスにアタッチして使用するブロックストレージで、インスタンスのストレージとして利用されます。データの暗号化にAWS KMSを使用できますが、主に仮想マシンのディスクとして利用されます。
- Amazon DynamoDB: 高速なNoSQLデータベースで、SSLによる暗号化とKMSでの静止状態の暗号化が可能です。ただし、ドキュメントや大容量ファイルのストレージには不向きです。
実践
略
一問道場
問題 #182
トピック 1
ある会社がアプリケーションをAWSに移行しています。移行中は可能な限りフルマネージドサービスを使用したいと考えています。会社はアプリケーション内で重要な大容量の文書を保存する必要があります。以下の要件があります:
- データは高い耐久性と可用性を持つ必要があります。
- データは常に静止状態および転送中に暗号化されている必要があります。
- 暗号化キーは会社によって管理され、定期的にローテーションされる必要があります。
以下のうち、ソリューションアーキテクトが推奨すべきソリューションはどれですか?
A. ストレージゲートウェイをAWSに展開し、ファイルゲートウェイモードを使用します。Amazon EBSボリューム暗号化を使用して、AWS KMSキーでストレージゲートウェイのボリュームを暗号化します。
B. Amazon S3を使用し、バケットポリシーでHTTPS接続を強制し、サーバーサイド暗号化とAWS KMSを使用してオブジェクト暗号化を強制します。
C. Amazon DynamoDBを使用し、SSLでDynamoDBに接続します。AWS KMSキーを使用してDynamoDBオブジェクトを静止状態で暗号化します。
D. インスタンスを展開し、Amazon EBSボリュームを添付してこのデータを保存します。EBSボリューム暗号化を使用して、AWS KMSキーでデータを暗号化します。
解説
この問題では、データの保存に関する要件(高耐久性、暗号化、暗号化キーの管理)が提示されています。最適なソリューションを選択するために、以下のポイントを考慮します。
- データの高耐久性と可用性: Amazon S3は、高耐久性(99.999999999%)と高可用性を提供するオブジェクトストレージサービスで、要件に最適です。
- 暗号化: S3はサーバーサイド暗号化(SSE)を提供しており、AWS KMSを利用して暗号化キーを管理・ローテーションできます。また、HTTPSを使用して転送中のデータも暗号化できます。
- 管理の簡便さ: S3はフルマネージドサービスで、運用の手間を最小限に抑えつつ、要件を満たすことができます。
そのため、B(Amazon S3の利用)が最適解です。
183-AWS SAP AWS 「理論・実践・一問道場」SQLインジェクション
理論
- SQLインジェクション攻撃:
- SQLインジェクションは、悪意のあるコードをデータベースに挿入することで機密情報を抽出する攻撃手法です。これを防ぐには、アプリケーションが受け取るリクエストを検証し、危険なクエリをブロックする必要があります。
- AWS WAFの役割:
- AWS WAFは、HTTP/Sリクエストをフィルタリングすることで、SQLインジェクションやクロスサイトスクリプティング(XSS)などの攻撃を防ぎます。WAFは、ルールを設定して特定のパターン(例えばSQLインジェクションのパターン)を検出し、リクエストをブロックできます。
- AWS WAF Web ACLとルール:
- *Web ACL (アクセス制御リスト)**は、ALBやAPI Gatewayなどのリソースに適用され、リクエストを監視・フィルタリングする役割を果たします。ルールは、特定のリクエストを許可または拒否する条件を設定できます。SQLインジェクション防止のためには、SQLインジェクションのルールグループを使用します。
- 効率的な運用:
- マネージドルールセット(例えば、AWSの標準SQLインジェクションルール)は、予め定義された攻撃パターンを自動で防ぐため、最小限の手動設定で攻撃を防ぎます。これにより、手動でIPアドレスを管理する手間(選択肢D)やボット対策の過剰な設定(選択肢B)よりも効率的に運用できます。
実践
略
一問道場
問題 #183
トピック 1
ある企業の公開APIは、Amazon Elastic Container Service (Amazon ECS) のタスクとして実行されています。これらのタスクは、AWS Fargate上で実行され、アプリケーションロードバランサー (ALB) の背後で動作し、CPU使用率に基づいてタスクのサービスオートスケーリングが設定されています。このサービスは、数ヶ月間順調に運用されていました。
最近、APIのパフォーマンスが低下し、アプリケーションが使用不能になりました。企業は、SQLインジェクション攻撃がAPIに対して多数発生しており、APIサービスが最大スケールに達していたことを発見しました。
ソリューションアーキテクトは、SQLインジェクション攻撃がECS APIサービスに到達するのを防ぎ、正当なトラフィックを通過させるソリューションを実装する必要があります。また、運用効率を最大化する必要があります。
どのソリューションがこの要件を満たしますか?
A. 新しいAWS WAFウェブACLを作成し、ECSタスクの前にあるALBに転送されるHTTPおよびHTTPSリクエストを監視します。
B. 新しいAWS WAF Bot Control実装を作成します。AWS WAF Bot Controlの管理されたルールグループにルールを追加して、トラフィックを監視し、ALBに正当なトラフィックのみを通過させます。
C. 新しいAWS WAFウェブACLを作成します。新しいルールを追加して、SQLインジェクションのルールグループに一致するリクエストをブロックします。そのウェブACLを、これらのルールに一致しない他のすべてのトラフィックを許可するように設定し、ECSタスクの前のALBにウェブACLをアタッチします。
D. 新しいAWS WAFウェブACLを作成します。新しい空のIPセットをAWS WAFに作成します。ウェブACLに新しいルールを追加して、新しいIPセットに含まれるIPアドレスからのリクエストをブロックします。AWS Lambda関数を作成してAPIログをスクレイピングし、SQLインジェクション攻撃を送信するIPアドレスを抽出して、これらのIPアドレスをIPセットに追加します。ウェブACLをALBにアタッチします。
解説
この問題では、SQLインジェクション攻撃を防ぐために、AWS WAFを使用してALBに送られるリクエストを監視する方法を問われています。SQLインジェクション攻撃は、悪意のあるコードをデータベースに挿入する攻撃手法です。
最適な解決策はCの「AWS WAF Web ACLを作成し、SQLインジェクションのルールグループを使用してリクエストをブロック」する方法です。この方法は、事前定義されたルールを利用して、SQLインジェクション攻撃を効率的に防ぎ、運用負荷を最小限に抑えることができます。
他の選択肢は、ボット対策やIPアドレスによる管理に依存しており、SQLインジェクション専用の対策としては不適切です。
選択肢Aでは、AWS WAF Web ACLを作成して、ALBに送られるHTTPおよびHTTPSリクエストを監視します。これにより、SQLインジェクションやその他の一般的なウェブ攻撃(例えばクロスサイトスクリプティングや悪意のあるボットによるリクエスト)を防ぐことができます。
AWS WAFは、事前に定義されたルールセットを使用して、リクエストに含まれる悪意のあるパターンを検出し、ブロックする機能を提供します。SQLインジェクションを含むウェブ攻撃を防ぐために、ALBに接続されているリクエストのフィルタリングと保護を行います。
184-AWS SAP AWS 「理論・実践・一問道場」IoT Coreのフェイルオーバー
理論
1. AWS IoT Core
AWS IoT Coreは、センサーやデバイスから送信されたデータをAWSクラウドに取り込むためのサービスです。デバイスとクラウドをつなぐためのデータエンドポイントが必要です。
2. Amazon Route 53
Amazon Route 53は、DNS(ドメインネームシステム)サービスで、トラフィックのルーティングポリシーを設定するために使用できます。特に、レイテンシーベースやフェイルオーバーのルーティングポリシーを使用して、トラフィックのルートを動的に決定できます。
- レイテンシーベースのルーティングポリシーは、ユーザーの場所に基づいて最も低い遅延のリージョンにトラフィックを送る方法です。
- フェイルオーバールーティングポリシーは、プライマリリージョンが利用できない場合に、バックアップリージョンに自動的にトラフィックを切り替える方法です。
3. Amazon DynamoDBのグローバルテーブル
Amazon DynamoDBは、高スループットと低レイテンシでデータを管理するNoSQLデータベースサービスです。グローバルテーブルは、複数のAWSリージョンで自動的にデータをレプリケートする機能を提供し、クロスリージョンでのデータ可用性を確保します。これにより、データが各リージョンで同期され、ユーザーはどのリージョンからでもアクセスできます。
4. AWS Lambdaとクロスリージョンデータレプリケーション
DynamoDBのストリームを利用して、データ変更を他のリージョンにレプリケートすることもできます。AWS Lambdaを使って、DynamoDBの変更をトリガーにして、他のリージョンのDynamoDBにデータをコピーすることが可能です。
クロスリージョンのビジネス継続性に関連するベストプラクティス:
- データの可用性と耐障害性を確保するために、複数のリージョンにデータを保存し、レプリケーションを利用する。
- Route 53でトラフィックルーティングを最適化し、レイテンシーを最小限に抑える。
- AWSのマネージドサービス(DynamoDB、IoT Core、Lambda)を活用し、管理の負担を軽減する。
このように、AWSのマネージドサービスをうまく活用することで、データの可用性、パフォーマンス、セキュリティ、そしてビジネス継続性を高めることができます。
実践
略
一問道場
問題 #184
トピック
ある環境関連の企業が、国内の主要都市にセンサーを設置し、空気質を測定しています。センサーはAWS IoT Coreに接続して、時系列データを取り込みます。企業はそのデータをAmazon DynamoDBに保存しています。
ビジネス継続性のため、企業はデータを2つのAWSリージョンで取り込み、保存する能力が必要です。
どのソリューションがこれらの要件を満たしますか?
A. Amazon Route 53のエイリアスフェイルオーバールーティングポリシーを作成し、両リージョンのAWS IoT Coreデータエンドポイントの値を設定します。データをAmazon Auroraのグローバルテーブルに移行します。
B. 各リージョンのAWS IoT Core用のドメイン設定を作成します。Amazon Route 53のレイテンシーベースのルーティングポリシーを作成し、両リージョンのAWS IoT Coreデータエンドポイントを値として使用します。データをAmazon MemoryDB for Redisに移行し、クロスリージョンレプリケーションを設定します。
C. 各リージョンのAWS IoT Core用のドメイン設定を作成します。Amazon Route 53のヘルスチェックを作成し、ドメイン設定の健康状態を評価します。フェイルオーバールーティングポリシーを作成し、AWS IoT Coreドメイン設定の値を設定します。DynamoDBテーブルをグローバルテーブルに更新します。
D. Amazon Route 53のレイテンシーベースのルーティングポリシーを作成します。両リージョンのAWS IoT Coreデータエンドポイントを値として使用します。DynamoDBストリームとクロスリージョンデータレプリケーションを設定します。
解説
この問題の解説では、AWS IoT Core、Amazon Route 53、DynamoDBのグローバルテーブルなどを組み合わせて、データのクロスリージョン可用性とビジネス継続性を確保する方法について説明します。
シナリオの概要:
- 企業はセンサーからデータをAWS IoT Coreに送信し、そのデータをAmazon DynamoDBに保存しています。
- ビジネス継続性を確保するため、データは2つのAWSリージョンで処理する必要があります。
選択肢の分析:
A. Route 53 Alias Failover Routing Policy と Aurora Global Tablesを使用
- AWS IoT Coreのデータエンドポイントを2つのリージョンに設定し、Route 53のフェイルオーバールーティングポリシーを使用して、異常時にバックアップリージョンにトラフィックを切り替える方法です。
- ただし、この選択肢では、Aurora Global Tablesが関与していますが、問題文で言及されているのはDynamoDBであり、Auroraは適切ではありません。
- 不適切です。
B. Route 53 Latency-Based Routing PolicyとMemoryDB for Redisを使用
- Route 53のレイテンシーベースのルーティングポリシーを使用して、最適なリージョンにトラフィックをルーティングし、MemoryDB for Redisを使用してデータを管理します。
- MemoryDBはRedis互換のデータストアですが、問題の要件にはDynamoDBが必要とされているため、これは適切ではありません。
- 不適切です。
C. AWS IoT Coreのドメイン設定とRoute 53ヘルスチェックを使用し、DynamoDB Global Tablesを設定
- AWS IoT Coreを各リージョンで設定し、Route 53のヘルスチェックを使用して、各リージョンのドメインの健全性を監視します。さらに、DynamoDB Global Tablesを使用して、データを2つのリージョンにレプリケートします。
- DynamoDB Global Tablesは、クロスリージョンでデータを同期するため、要件にぴったりです。
- 適切な解決策です。
D. Route 53 Latency-Based Routing Policy と DynamoDB Streamsを使用
- Route 53のレイテンシーベースのルーティングポリシーを使用して、トラフィックを最適なリージョンに送りますが、DynamoDB Streamsとクロスリージョンデータレプリケーションを設定してデータを同期します。
- DynamoDB Streamsを使用して、データを別のリージョンにレプリケートする方法も可能ですが、DynamoDB Global Tablesを使った方が簡潔で管理が楽です。
- 不適切です(Global Tablesの方が望ましい)。
結論:
最適な選択肢は C です。AWS IoT Coreでのデータインジェスト、Route 53でのヘルスチェックとフェイルオーバー、そしてDynamoDB Global Tablesを使用して、2つのリージョン間でデータを同期・可用性を確保できます。このアプローチは、ビジネス継続性を高め、要件に最も適しています。
185-AWS SAP AWS 「理論・実践・一問道場」信頼関係ロールの切り替え
理論
AWSのアクセス管理と細粒度アクセス制御
AWSでは、アクセス制御を適切に管理するために、複数の方法を使用できます。特に、複数のAWSアカウント間でアクセスを制御する際には、以下の概念とサービスが重要です。
- IAM (Identity and Access Management)
- IAMロール: 他のAWSアカウントやサービスにアクセスを許可するための権限を持つロールを作成できます。信頼関係を設定することで、他のアカウントからこのロールを引き受けることが可能です。
- IAMポリシー: 特定のアクションを許可または拒否する権限を定義するJSONベースのドキュメントです。ポリシー条件を追加することで、細粒度アクセス制御(特定のデータ属性に基づくアクセス)を実現できます。
- DynamoDBの細粒度アクセス制御
DynamoDBでは、テーブルの特定の項目(属性)へのアクセスを制限できます。これにより、ユーザーやロールは、データベース内のすべてのデータではなく、必要な属性にのみアクセスできます。
- リソースベースのアクセス制御
DynamoDBテーブルなどのリソースには、アクセスを制限するためのリソースベースのポリシーを設定することができます。この方法は、特定のリソースに対してアクセス権限を直接付与します。
- AWS OrganizationsとSCP (Service Control Policies)
SCPは、AWS Organizations内で複数のアカウントに対するアクセス制限を設けるために使用します。ただし、細粒度アクセス制御はIAMポリシーやリソースベースのポリシーで行うべきです。SCPは一般的にアカウントレベルのアクセス管理に使用されます。
これらを組み合わせることで、マーケティングチームにDynamoDBの特定の属性へのアクセスを許可し、機密データを保護することができます。
実践
略
一問道場
問題 #185
トピック 1
ある企業は、AWS CloudでのマルチアカウントセットアップにAWS Organizationsを使用しています。企業の財務チームは、AWS LambdaとAmazon DynamoDBを使用するデータ処理アプリケーションを運用しています。企業のマーケティングチームは、DynamoDBテーブルに格納されたデータにアクセスしたいと考えていますが、そのDynamoDBテーブルには機密データが含まれています。マーケティングチームは、DynamoDBテーブル内の特定の属性にのみアクセスできる必要があります。財務チームとマーケティングチームは別々のAWSアカウントを持っています。
ソリューションアーキテクトは、マーケティングチームにDynamoDBテーブルへの適切なアクセスを提供するために、何をすべきでしょうか?
A. マーケティングチームのAWSアカウントにDynamoDBテーブルの特定の属性へのアクセスを許可するSCPを作成し、そのSCPを財務チームのOUにアタッチします。
B. 財務チームのアカウントにIAMロールを作成し、特定のDynamoDB属性に対するIAMポリシー条件(細粒度アクセス制御)を使用します。マーケティングチームのアカウントと信頼関係を構築します。マーケティングチームのアカウントで、財務チームのアカウントで作成したIAMロールを引き受けるためのIAMロールを作成します。
C. 特定のDynamoDB属性に対する条件(細粒度アクセス制御)を含むリソースベースのIAMポリシーを作成し、そのポリシーをDynamoDBテーブルにアタッチします。マーケティングチームのアカウントで、財務チームのアカウントにあるDynamoDBテーブルにアクセスするためのIAMロールを作成します。
D. 財務チームのアカウントにDynamoDBテーブルにアクセスするIAMロールを作成し、IAM権限境界を使用して特定の属性へのアクセスを制限します。マーケティングチームのアカウントで、財務チームのアカウントで作成したIAMロールを引き受けるためのIAMロールを作成します。
解説
この問題では、異なるAWSアカウント(財務チームとマーケティングチーム)が、Amazon DynamoDBテーブルにアクセスするシナリオを扱っています。マーケティングチームには、テーブル内の特定の属性のみへのアクセスを許可し、財務チームの機密データは保護しなければなりません。
解答の分析
Bが最も適切な解答です。理由は以下の通りです。
正解: B
- IAMロールの作成: 財務チームのアカウント内で、特定のDynamoDB属性にアクセスする権限を持つIAMロールを作成します。このロールには、細粒度アクセス制御(特定のDynamoDB属性へのアクセス)を適用します。
- 信頼関係の設定: マーケティングチームのアカウントと信頼関係を確立し、マーケティングチームのアカウントで、このロールを引き受けることができるようにします。
- マーケティングチームのIAMロール: マーケティングチームのアカウントで、財務チームのIAMロールを引き受けるための権限を持つIAMロールを作成します。
この方法により、マーケティングチームは指定された属性のみにアクセスでき、機密データの保護が確保されます。
他の選択肢の分析
A: **SCP(サービス制御ポリシー)**は、アカウントレベルでのアクセス制御を行うため、細粒度なアクセス制御には不向きです。SCPは一般的なアクセス権限の管理には役立ちますが、DynamoDBの特定の属性へのアクセス制御には適していません。
C: リソースベースのIAMポリシーは、特定のリソース(DynamoDBテーブル)に対するアクセスを制御するために使用されますが、この選択肢には細粒度アクセス制御に関する記述が不足しています。また、IAMロールの引き受けに関する部分が不十分です。
D: IAMロールとIAM権限境界を組み合わせてアクセス制御を行う方法ですが、細粒度アクセス制御の実現方法としては、ポリシー条件やIAMロールの信頼関係設定がより適切です。権限境界はアクセス制限に有効ですが、細粒度アクセス制御を行うには不十分です。
まとめ
解答Bは、AWSのIAMポリシー、ロール、信頼関係を活用し、細粒度アクセス制御を効率的に実現する方法として最適です。
186-AWS SAP AWS 「理論・実践・一問道場」S3 マルチリージョンアクセスポイント
理論

Amazon S3 のクロスリージョンレプリケーション (CRR) とマルチリージョンアクセスポイント
クラウドアーキテクチャを設計する際、データの可用性、耐障害性、低レイテンシを確保するために、複数のAWSリージョンにデータを分散させることは重要な戦略です。この記事では、Amazon S3 を利用して複数リージョンにまたがるデータ同期を効率的に行うための本質的な知識を解説します。
1. Amazon S3 のクロスリージョンレプリケーション (CRR)
CRR の概要
クロスリージョンレプリケーション (CRR) は、1つの Amazon S3 バケットにアップロードされたオブジェクトを別のリージョンにある別の S3 バケットに自動的にコピーする機能です。これにより、データが地理的に離れたリージョンに複製され、障害耐性が向上します。
CRR を使用するメリット
- データの耐障害性: リージョン障害が発生した場合でも、別のリージョンでデータにアクセス可能。
- 規制遵守: 地域ごとのデータ保存要件に対応可能。
- 低レイテンシ: ユーザーの地理的な場所に近いリージョンからデータを提供。
設定要件
- S3 バージョニングを有効化: CRR を設定するすべてのバケットで必要です。
- 適切な IAM ポリシー: レプリケーション操作を許可するために IAM ロールを設定します。
- レプリケーションルール: 特定のプレフィックスやタグを使用して同期するデータを制御可能。
CRR の限界
- 一方向レプリケーション: デフォルトでは一方向のデータコピーに対応。双方向レプリケーションを設定するには複数のルールが必要です。
- リアルタイム性の限界: レプリケーションにはわずかな遅延が発生することがあります。
2. S3 マルチリージョンアクセスポイント
概要
マルチリージョンアクセスポイントは、複数のリージョンに存在する S3 バケットへのアクセスを統合し、1つのエンドポイントを通じてデータを利用可能にする機能です。AWS Global Accelerator を活用して、最適なリージョンに自動的にルーティングされます。
利点
- 簡易化されたアクセス: アプリケーションは複数のリージョンに対応するロジックを実装する必要がありません。
- 低レイテンシ: ユーザーの場所に応じて最適なリージョンにリクエストがルーティングされるため、応答速度が向上します。
- 高可用性: 複数のリージョンでデータを保持することで、障害に強い設計が可能。
主なユースケース
- グローバルなアプリケーション: ユーザーが複数の地域からアクセスするアプリケーションに最適。
- マルチリージョンのデータ同期: 複数のバケット間のデータ同期を簡略化。
3. 実装におけるベストプラクティス
1. バージョニングの活用
S3 バージョニングを有効にすると、オブジェクトの変更履歴が保持され、誤操作やデータの損失を防ぐことができます。CRR を設定する際には必須の要件です。
2. レプリケーション監査
CRR の設定後、レプリケーションステータスを監視することで、エラーや未レプリケートのオブジェクトを特定できます。
3. Lambda とイベント通知の活用
CRR だけではなく、Lambda 関数を使用して特定のイベントに応じたカスタム同期ロジックを構築することも可能です。ただし、運用負荷が増加する可能性があるため、要件に応じて選択するべきです。
4. コストの考慮
CRR やマルチリージョンアクセスポイントには、データ転送やストレージの追加コストが発生します。要件を満たしつつ、コストを最小化する設定を心がけましょう。
4. まとめ
複数のAWSリージョンにデータを同期する際の選択肢として、クロスリージョンレプリケーション (CRR) と マルチリージョンアクセスポイント はそれぞれ異なる特徴と利点を持っています。
- 運用負荷を抑えつつ同期を自動化したい場合: CRR を活用。
- 複数リージョンでのデータアクセスを簡略化したい場合: マルチリージョンアクセスポイントを活用。
運用要件とシステム要件に応じて、これらの機能を適切に組み合わせることで、効率的で信頼性の高いクラウドアーキテクチャを構築することが可能です。
実践
略
一問道場
質問 #186
トピック 1
ソリューションアーキテクトは、Amazon S3 バケットにオブジェクトを保存するアプリケーションを作成しています。このソリューションアーキテクトは、同時に使用される 2 つの AWS リージョンにアプリケーションをデプロイする必要があります。2 つの S3 バケットに保存されるオブジェクトは、お互いに同期された状態を保つ必要があります。
運用負荷を最小限に抑えつつ、これらの要件を満たすために必要な手順の組み合わせはどれですか?(3 つ選択してください。)
A. S3 マルチリージョンアクセスポイントを作成する。アプリケーションを変更して、マルチリージョンアクセスポイントを参照するようにする。
B. 2 つの S3 バケット間で双方向の S3 クロスリージョンレプリケーション (CRR) を設定する。
C. アプリケーションを変更して、各 S3 バケットにオブジェクトを保存するようにする。
D. 各 S3 バケットに S3 ライフサイクルルールを作成し、片方の S3 バケットからもう片方の S3 バケットにオブジェクトをコピーする。
E. 各 S3 バケットで S3 バージョニングを有効にする。
F. 各 S3 バケットにイベント通知を設定して、1 つの S3 バケットからもう片方の S3 バケットにオブジェクトをコピーする AWS Lambda 関数を呼び出すようにする。
解説
この問題では、2つのAWSリージョンにデプロイされたアプリケーションが、2つのS3バケット間でオブジェクトを同期させる必要があるという要件を、最小限の運用負荷で満たす方法を問われています。それぞれの選択肢を検討し、適切な解決策を選びます。
A. S3 マルチリージョンアクセスポイントを作成する
- 説明: S3 マルチリージョンアクセスポイントを使用すると、複数のリージョンにまたがるバケットにアクセスを集約できます。これにより、アプリケーション側の複雑な設定を削減でき、運用負荷が低減します。
- 有効性: 適切な解決策です。これにより、アプリケーションはシンプルにバケットを利用できるようになります。
B. 双方向の S3 クロスリージョンレプリケーション (CRR) を設定する
- 説明: CRR は、S3 バケット間でオブジェクトを自動的にレプリケーションします。双方向レプリケーションを設定することで、どちらのバケットに書き込んだデータも自動的に同期されます。
- 有効性: 適切な解決策です。CRR は、同期の自動化を提供し、運用負荷を低減します。
C. アプリケーションを変更して、各 S3 バケットにオブジェクトを保存するようにする
- 説明: アプリケーションが直接両方のバケットにデータを書き込むように変更する手法です。
- 有効性: 不適切です。アプリケーションのコード変更が必要であり、運用負荷が増加します。
D. S3 ライフサイクルルールを使用してバケット間でオブジェクトをコピーする
- 説明: ライフサイクルルールは、バケット間でオブジェクトをコピーするように設定できます。ただし、これはレプリケーションではなく、タイムラグが生じます。
- 有効性: 不適切です。同期がリアルタイムではなく、運用負荷が増加します。
E. 各 S3 バケットで S3 バージョニングを有効にする
- 説明: バージョニングは、データのバージョン管理を提供します。CRR の前提条件として必要です。
- 有効性: 適切な解決策です。CRR を使用する場合に必須です。
F. イベント通知と Lambda を使用してオブジェクトをコピーする
- 説明: S3 のイベント通知と Lambda 関数を使用して、1つのバケットからもう1つのバケットにオブジェクトをコピーします。これはカスタムの実装が必要で、運用負荷が高いです。
- 有効性: 不適切です。運用負荷が高く、設計が複雑になります。
最適な組み合わせ (A, B, E)
- A (S3 マルチリージョンアクセスポイント) 運用を簡略化するために有効。
- B (双方向 CRR) バケット間の同期を自動化するために必要。
- E (S3 バージョニング) CRR の動作に必要な前提条件。
まとめ:
正解は A, B, E です。
これにより、2つのリージョンにまたがるS3バケット間で効率的かつ自動的に同期を維持でき、運用負荷を最小限に抑えることができます。
187-AWS SAP AWS 「理論・実践・一問道場」IoT Core
理論
IoTプラットフォームをAWSに移行する際の知識
1. AWS IoT Core
- 役割: IoTデバイスとの接続を簡素化し、スケーラブルなメッセージブローカーを提供。デバイスデータの収集・管理が容易になる。
- 利点:
- 常時接続やMQTTプロトコルのネイティブサポート。
- 他のAWSサービス(Lambda、S3など)と簡単に統合可能。
2. Amazon DocumentDB(MongoDB互換)
- 役割: IoTデバイスからのメタデータを保存するためのマネージドデータベース。
- 利点:
- 自動スケーリング、高可用性、バックアップのサポート。
- MongoDBの既存コードやドライバをそのまま利用可能。
3. AWS LambdaとStep Functions
- 役割: 定期ジョブの自動化とサーバーレスなデータ処理を実現。
- 利点:
- サーバー管理不要でコスト効率が高い。
- 非同期処理やワークフロー管理に最適。
4. Amazon S3とCloudFront
- 役割: レポートや静的ファイルの保存・配信を効率化。
- 利点:
- S3は高耐久性と低コストを提供。
- CloudFrontを組み合わせることで、グローバルに低遅延で配信可能。
5. EKS vs サーバーレス
- EKS: Kubernetesクラスターの管理が必要で運用負荷が高い。
- サーバーレス(Lambda, S3): 運用負荷が少なく、小規模のIoTプラットフォームに最適。
結論
AWS IoT Core、DocumentDB、Step Functions、Lambda、S3、CloudFrontを組み合わせることで、運用負荷を最小限に抑えつつ、スケーラブルで効率的なIoTプラットフォームを構築可能です。
実践
略
一問道場
質問 #187
トピック 1
ある会社が、オンプレミス環境でIoTプラットフォームを運用しています。このプラットフォームは、MQTTプロトコルを使ってIoTデバイスと接続するサーバーで構成されています。プラットフォームは5分ごとにデバイスからテレメトリーデータを収集し、デバイスのメタデータをMongoDBクラスターに保存しています。
また、オンプレミスのマシンにインストールされたアプリケーションが、定期的にジョブを実行してテレメトリーデータやメタデータを集計・変換しています。このアプリケーションは、ユーザーが別のウェブアプリを通じて閲覧できるレポートを作成しています。このウェブアプリも同じオンプレミス環境で常に稼働しています。
定期ジョブの実行時間は120~600秒ですが、ウェブアプリ自体は常時稼働しています。
会社はこのプラットフォームをAWSに移行し、運用負荷をできるだけ軽減したいと考えています。
最小の運用負荷でこの要件を満たすためには、以下の手順の組み合わせのうちどれを選ぶべきですか?(3つ選択してください)
- A. AWS Lambdaを使ってIoTデバイスに接続する
- B. IoTデバイスがAWS IoT Coreにデータを送信するよう設定する
- C. メタデータをAmazon EC2上の自己管理型MongoDBデータベースに保存する
- D. メタデータをAmazon DocumentDB(MongoDB互換)に保存する
- E. AWS Step FunctionsとAWS Lambdaを使ってレポートを作成し、Amazon S3に保存する。そのレポートをAmazon CloudFrontを使って配信する
- F. Amazon Elastic Kubernetes Service(Amazon EKS)とAmazon EC2を使ってレポートを作成し、Ingressコントローラーを使って配信する
解説
選択肢の評価
A. AWS Lambdaを使ってIoTデバイスに接続する
- 評価: 不適切
- Lambdaはイベント駆動型で短時間実行に適しており、常時接続を維持するMQTTプロトコルには不向きです。
- AWS IoT Coreを使用することで、デバイス接続を効率的に管理できます。
B. IoTデバイスがAWS IoT Coreにデータを送信するよう設定する
- 評価: 適切
- AWS IoT Coreは、デバイスからのデータ収集と管理を簡素化し、常時接続やスケーリングも自動で行います。
- 運用負荷を大幅に削減できるため、この選択は必要です。
C. メタデータをAmazon EC2上の自己管理型MongoDBデータベースに保存する
- 評価: 不適切
- EC2でMongoDBを自己管理する場合、パッチ適用やスケーリングなど運用負荷が高くなります。
- AWSのマネージドサービスであるDocumentDBを利用する方が運用負荷が軽減されます。
D. メタデータをAmazon DocumentDB(MongoDB互換)に保存する
- 評価: 適切
- DocumentDBはマネージドサービスで、スケーラビリティや高可用性を簡単に確保できるため、運用負荷が大幅に削減されます。
E. AWS Step FunctionsとAWS Lambdaを使ってレポートを作成し、Amazon S3に保存する。そのレポートをAmazon CloudFrontを使って配信する
- 評価: 適切
- Step FunctionsとLambdaを組み合わせることで、非同期で定期ジョブを管理できます。
- レポートをS3に保存し、CloudFrontで配信する構成はコスト効率が高く、運用負荷も低いです。
F. Amazon Elastic Kubernetes Service(Amazon EKS)とAmazon EC2を使ってレポートを作成し、Ingressコントローラーを使って配信する
- 評価: 不適切
- EKSを利用すると、コンテナ管理やクラスター運用が必要になり、運用負荷が高くなります。
- このユースケースではサーバーレス構成(LambdaやS3)が適しています。
最適な選択肢
- B. IoTデバイスがAWS IoT Coreにデータを送信するよう設定する
- D. メタデータをAmazon DocumentDB(MongoDB互換)に保存する
- E. AWS Step FunctionsとAWS Lambdaを使ってレポートを作成し、Amazon S3に保存する。そのレポートをAmazon CloudFrontを使って配信する
選択の理由
この組み合わせにより、次のようなメリットが得られます:
- IoT Coreで接続を管理:IoTデバイスの接続管理をAWSに任せることで、手動の設定やスケーリングが不要になります。
- DocumentDBでデータ管理を簡略化:マネージドデータベースを利用することで、データの保存・取得の運用負荷を削減します。
- S3とCloudFrontでレポート配信を最適化:S3はコスト効率が高く、CloudFrontでの配信によりユーザー体験を向上させます。
これにより、最小の運用負荷で要求を満たすプラットフォームを実現できます。
188-AWS SAP AWS 「理論・実践・一問道場」AWS Outposts
理論
AWSにおけるハイブリッドクラウドソリューションの基本知識
企業がAWSに移行する際、データ規制や低レイテンシー要件、ネットワークインフラの制約など、オンプレミス環境を必要とするケースがあります。これらの要件に対応するために、AWSは一貫したハイブリッド体験を提供するソリューションを提供しています。以下では、それぞれの選択肢に関連する本質的な知識を解説します。
1. AWS Outposts
- 概要: AWS Outpostsは、AWSが提供するフルマネージド型のハイブリッドクラウドソリューションで、オンプレミスにAWSのインフラストラクチャを導入します。
- 特徴:
- 同じAWSサービス(EC2、S3、EKSなど)がオンプレミスでも利用可能。
- AWSリージョンとのシームレスな統合が可能。
- 特にデータ規制や単一桁ミリ秒のレイテンシーが必要なアプリケーションに適している。
- 適用例: 金融、医療、製造業などのデータ規制が厳しい業界。
2. AWS Snowball Edge
- 概要: AWS Snowball Edgeは、物理デバイスを使用してコンピューティングやストレージ機能を提供するソリューションです。ネットワークが制限されている環境でも利用可能です。
- 特徴:
- データ収集、処理、移行に利用可能。
- Compute Optimizedモデルではローカルでのデータ処理が可能。
- ネットワーク接続が限られている遠隔地や工場で効果的。
- 適用例: 工場のIoTデータ収集やリモートサイトでのデータ処理。
3. AWS Local Zones
- 概要: AWS Local Zonesは、AWSのサービスを特定の地域に配置し、超低レイテンシーが必要なワークロードをサポートします。
- 特徴:
- EC2、EBSなどの主要なAWSサービスをローカルに展開可能。
- ユーザーとアプリケーション間のレイテンシーを最小化。
- メインリージョンとの接続も可能。
- 適用例: ゲーム、メディア、ライブストリーミング。
4. AWS Wavelength
- 概要: AWS Wavelengthは、5GネットワークのエッジにAWSサービスを展開し、超低レイテンシーを提供します。
- 特徴:
- モバイルアプリやIoTアプリに適した超低レイテンシー環境。
- 通信事業者との統合で5Gエッジに直接展開。
- 適用例: モバイルゲーム、AR/VR、リアルタイムデータ処理。
選択肢の比較と適用
ソリューション | 強み | 適用例 |
AWS Outposts | フルマネージドでオンプレミスに展開可能 | データ規制や低レイテンシーが必要なアプリ |
AWS Snowball Edge | ネットワークが制限された環境で活用可能 | 工場や遠隔地でのデータ収集と処理 |
AWS Local Zones | ローカルで超低レイテンシーを実現 | ストリーミングやリアルタイム分析 |
AWS Wavelength | 5Gエッジで超低レイテンシーを提供 | モバイルゲームやIoTアプリ |
まとめ
企業がAWSへの移行を計画する際、ハイブリッドクラウドソリューションを利用することで、オンプレミス、クラウド、ハイブリッド環境間で一貫した開発者体験を実現できます。AWS Outposts、Snowball Edge、Local Zones、Wavelengthの各ソリューションは、それぞれ特定のニーズに応じて柔軟に選択可能です。これにより、データ規制、レイテンシー、ネットワーク制約といった課題を効率的に克服することができます。
実践
略
一問道場
質問 #188
トピック 1
あるグローバル製造会社が、多くのアプリケーションをAWSに移行する計画を立てています。しかし、データ規制の要件や単一桁ミリ秒のレイテンシー要件のために、特定の国や中央オンプレミスデータセンターに残す必要があるアプリケーションについて懸念を抱えています。また、一部の工場サイトでホストされているアプリケーションについても懸念があります。これらのサイトではネットワークインフラが制限されている場合があります。
会社は、一貫した開発者体験を求めており、開発者が一度アプリケーションを構築すれば、オンプレミス、クラウド、またはハイブリッド環境に展開できるようにしたいと考えています。また、開発者が使い慣れたツールやAPI、サービスを引き続き利用できることが求められています。
この要件を満たし、一貫したハイブリッド体験を提供するソリューションはどれでしょうか?
A.
規制を遵守する最寄りのAWSリージョンにすべてのアプリケーションを移行し、中央オンプレミスデータセンターとAWSをAWS Direct Connectで接続します。また、Direct Connectゲートウェイをデプロイします。
B.
データ規制や単一桁ミリ秒のレイテンシー要件を持つアプリケーションには、AWS Snowball Edge Storage Optimizedデバイスを使用し、それらをオンプレミスに設置します。工場サイトのワークロードにはAWS Wavelengthをデプロイして対応します。
C.
データ規制や単一桁ミリ秒のレイテンシー要件を持つアプリケーションには、AWS Outpostsを設置します。工場サイトのワークロードにはAWS Snowball Edge Compute Optimizedデバイスを使用します。
D.
データ規制や単一桁ミリ秒のレイテンシー要件を持つアプリケーションをAWS Local Zoneに移行します。工場サイトのワークロードにはAWS Wavelengthをデプロイして対応します。
解説
この質問では、グローバル製造会社がAWSにアプリケーションを移行する際に直面するさまざまな要件を満たすソリューションを選択する必要があります。具体的な要件には、データ規制、レイテンシー、ネットワーク制限、そして開発者が一貫した開発環境を維持できることが求められています。
要件の整理:
- データ規制の遵守: 特定の国や地域でデータを保持しなければならない。
- 単一桁ミリ秒のレイテンシー要件: 高速なレスポンスが必要。
- 開発者体験: 一貫した開発者体験が求められ、開発者は自分のツールやAPIを使い続ける必要がある。
各ソリューションの分析:
A. AWS Direct Connect + Direct Connectゲートウェイの使用
- AWSリージョンにアプリケーションを移行し、AWS Direct Connectを用いて中央オンプレミスデータセンターと接続する方法です。
- 欠点: データ規制に対応するためには、地域別にアプリケーションを管理する必要があるため、全てのアプリケーションを移行するのは難しい可能性があります。また、工場サイトのネットワークインフラが制限されている場合、十分なネットワーク接続が確保できない可能性があります。
B. AWS Snowball Edge Storage Optimized + AWS Wavelength
- データ規制やレイテンシー要件を満たすために、AWS Snowball Edgeをオンプレミスに設置し、工場サイトにはAWS Wavelengthを利用する方法です。
- メリット: 特に工場サイトのようなネットワーク制限がある場所に適したソリューションです。また、AWS Wavelengthは通信遅延を低減できるため、レイテンシー要件にも対応できます。
- デメリット: Snowball Edgeは主にデータ移行や一時的なストレージのために使われるため、完全なアプリケーション展開には他のオプションが有効です。
C. AWS Outposts + Snowball Edge Compute Optimized
- AWS Outpostsをオンプレミスに設置して、完全に一貫した開発者体験を提供し、工場サイトにはSnowball Edge Compute Optimizedを使用します。
- メリット: AWS OutpostsはAWSインフラをオンプレミスに展開できるため、クラウドとオンプレミスの間で一貫した環境を提供します。また、Snowball Edge Compute Optimizedは工場サイトでの計算リソースを提供し、ネットワーク制限に対処できます。
- デメリット: 高価なコストが発生する可能性があり、全てのアプリケーションに適用できるかは要検討です。
D. AWS Local Zone + AWS Wavelength
- AWS Local Zoneにアプリケーションを移行し、工場サイトにはAWS Wavelengthを利用する方法です。
- メリット: AWS Local Zoneは、特定の地域で低レイテンシーを提供し、データ規制の遵守が可能です。また、AWS Wavelengthはネットワーク制限がある場所でも高速な接続が提供されます。
- デメリット: Local Zoneは特定の地域でしか提供されていないため、すべての場所で対応できるわけではありません。
結論:
最も適切なソリューションは、C. AWS Outposts + Snowball Edge Compute Optimizedです。
- 理由: AWS Outpostsは、クラウド環境と一貫した開発体験を提供し、オンプレミスでアプリケーションを運用する際にクラウドとの統合を可能にします。さらに、Snowball Edge Compute Optimizedは、ネットワーク制限がある工場サイトでも効果的に計算リソースを提供し、ミリ秒単位の低レイテンシーを実現できます。
189-AWS SAP AWS 「理論・実践・一問道場」WAF
理論
1. Webアプリケーションファイアウォール (WAF)
WAFは、アプリケーションへの不正アクセスや攻撃(SQLインジェクションやクロスサイトスクリプティングなど)を防ぐために使用されます。AWS WAFは、カスタムルールを設定することで、悪意のあるリクエストを検出し、遮断することができます。
2. コンテンツ配信ネットワーク (CDN) とCloudFront
CloudFrontは、CDNサービスであり、アプリケーションのトラフィックを分散させ、地理的に分散したエッジロケーションから配信することで、攻撃トラフィックを早期に処理します。これにより、アプリケーションの負荷を軽減し、悪意のあるリクエストを先にブロックできます。
実践
略
一問道場
質問 #189
トピック 1
ある会社が、顧客がオンライン注文を行うために使用するアプリケーションを更新しています。最近、悪意のある攻撃者によるアプリケーションへの攻撃が増加しています。
会社は更新されたアプリケーションをAmazon Elastic Container Service (Amazon ECS) クラスターでホストします。アプリケーションデータはAmazon DynamoDBに保存され、パブリックなApplication Load Balancer (ALB) がエンドユーザーにアプリケーションへのアクセスを提供します。
会社は攻撃を防ぎ、攻撃が進行中でも最小限のサービス中断でビジネスの継続性を確保する必要があります。
これらの要件を最もコスト効率良く満たすためのステップの組み合わせはどれですか?(2つ選択してください。)
A. Amazon CloudFrontディストリビューションを作成し、ALBをオリジンとして設定します。CloudFrontドメインにカスタムヘッダーとランダムな値を追加し、ALBを設定して、ヘッダーと値が一致する場合のみ条件付きでトラフィックを転送します。
B. アプリケーションを2つのAWSリージョンにデプロイし、Amazon Route 53を使用して両方のリージョンに均等にルーティングするように設定します。
C. Amazon ECSタスクの自動スケーリングを設定し、DynamoDB Accelerator (DAX) クラスターを作成します。
D. DynamoDBのオーバーヘッドを削減するためにAmazon ElastiCacheを設定します。
E. 適切なルールグループを含むAWS WAFウェブACLをデプロイし、CloudFrontディストリビューションにウェブACLを関連付けます。
解説
この問題では、アプリケーションが増加する攻撃から保護され、ビジネス継続性が確保されることが求められています。さらに、最小限のサービス中断でコスト効率よく対応することも重視されています。これらの要件を満たすためには、以下の対策が重要です。
要件:
- 攻撃の防止:アプリケーションへの攻撃を防ぐ。
- ビジネスの継続性:攻撃中でもサービスを継続できるようにする。
- コスト効率:リソースを無駄にせず、最小限のコストで対処する。
各選択肢の解説:
A. Amazon CloudFrontディストリビューションを作成し、ALBをオリジンとして設定する
- 解説:CloudFrontを使用して、ALBの前にCDN(コンテンツ配信ネットワーク)を配置することで、攻撃トラフィックをCloudFrontで処理し、ALBへの負荷を減らします。また、カスタムヘッダーとランダムな値を使って、不正なリクエストをブロックすることができます。これにより、悪意のあるリクエストをフィルタリングし、攻撃を減らすことが可能です。
- 効果:攻撃のトラフィックを早期にキャッチし、サービスを保護できます。
B. アプリケーションを2つのAWSリージョンにデプロイし、Route 53で両方のリージョンに均等にルーティングする
- 解説:複数のAWSリージョンでアプリケーションを稼働させることで、1つのリージョンが攻撃を受けた場合でも、別のリージョンでサービスを継続できます。Route 53でリージョン間のトラフィックを均等に分散し、高可用性を確保します。
- 効果:リージョン間の冗長性を持たせることで、攻撃によるダウンタイムを防ぎ、ビジネス継続性を確保できます。
C. Amazon ECSタスクの自動スケーリングとDynamoDB Accelerator (DAX)の使用
- 解説:ECSタスクの自動スケーリングは、アプリケーションの負荷に応じてリソースを増減させ、攻撃時でも柔軟に対応できます。しかし、DAXはDynamoDBのパフォーマンスを向上させるためのキャッシュサービスであり、攻撃防止には直接的な効果はありません。
- 効果:負荷に対応するための自動スケーリングは有効ですが、DAXの導入はこのシナリオでは直接的な効果を見込めません。
D. Amazon ElastiCacheを使用してDynamoDBのオーバーヘッドを削減
- 解説:ElastiCacheはDynamoDBの読み取り性能を向上させるためにキャッシュを提供しますが、攻撃を防ぐための直接的な対策にはなりません。DynamoDBのパフォーマンスを向上させるために有効ではありますが、攻撃に対する対策としては不十分です。
- 効果:DynamoDBのオーバーヘッド削減に役立ちますが、攻撃を防ぐための最適解ではありません。
E. AWS WAFウェブACLをデプロイし、CloudFrontディストリビューションに関連付ける
- 解説:AWS WAFはWebアプリケーションファイアウォールとして、悪意のあるリクエストをフィルタリングできます。CloudFrontと連携させることで、攻撃トラフィックを早期にブロックし、アプリケーションを守ることができます。適切なルールを設定することで、攻撃を検出し、リクエストを拒否できます。
- 効果:攻撃を直接ブロックし、ビジネス継続性を確保できます。
最もコスト効率が良く効果的な組み合わせ:
- A と E が最もコスト効率よく攻撃からアプリケーションを守り、ビジネスの継続性を確保できます。
- A ではCloudFrontとカスタムヘッダーを使い、攻撃トラフィックをフィルタリング。
- E ではAWS WAFで不正なリクエストをブロックします。
結論:
最も適切な組み合わせは、A と E です。これにより、攻撃からの保護を強化し、ビジネス継続性を最小限のコストで確保できます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/170d7ae8-88e2-8094-9f40-d58aed864008
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts