type
status
date
slug
summary
tags
category
icon
password
311-AWS SAP AWS 「理論・実践・一問道場」コンピュートセービングプラン使用量に基づく割引
理論
コンピュートセービングプランには、MemoryDB for Redisは含まれていません。
1. AWSのセービングプラン
- セービングプランは、AWSリソースの使用に対して割引を提供する長期契約プランです。セービングプランは以下の2種類に分かれます：
- EC2インスタンスセービングプラン: 特定のインスタンスファミリーに対して最大66%の割引が適用されます。
- コンピュートセービングプラン: EC2インスタンス、Lambda、Fargateなど、さまざまなコンピュータリソースに適用でき、最大54%の割引を提供します。
- セービングプランは、長期間のコミットメントによりコスト削減が可能で、使用量が予測できるリソースに最適です。
2. AWS Lambdaのコスト管理
- Lambdaはサーバーレスで、リクエスト数や実行時間に基づいて課金されます。変動するトラフィックに対しては、Lambda関数の最小使用量に応じたコスト管理が重要です。
- Lambdaのコストを削減するために、コンピュートセービングプランを利用することで、一定量のリクエストに対して割引を適用できます。
3. MemoryDB for Redisのコスト管理
- MemoryDB for Redisは、キャッシュ層として高いパフォーマンスを提供するAWSサービスで、安定的な負荷がかかるキャッシュノードに最適です。
- 予約ノードを使用することで、MemoryDBのリソースに対して長期的に割引を受けることができます。通常、予約ノードは最大55%の割引を提供します。
4. 予約インスタンス vs 予約ノード vs セービングプラン
- 予約インスタンスや予約ノードは、特定のリソースに対しての長期的な契約を前提にした割引です。これに対して、セービングプランは汎用的に利用できる割引で、特に柔軟性があります。
- セービングプランと予約インスタンスの主な違いは、セービングプランがより広範なリソースに適用可能で、インスタンスやサービスの変更に柔軟です。
5. AWSのコスト最適化戦略
- 予測可能な使用量には予約インスタンスや予約ノードを使用し、変動する使用量にはセービングプランを活用することで、効率的にコストを削減できます。
- AWSのリソースを適切に選び、割引プランを組み合わせることで、月々のコストを最小限に抑えることが可能です。
まとめ
AWSのコスト削減には、リソースの特性に応じた割引プランを選ぶことが重要です。安定的な負荷には予約プラン（EC2インスタンスセービングプランや予約ノード）を、予測不可能な変動にはコンピュートセービングプランを活用し、最適なコスト管理を行うことが推奨されます。
実践
略
一問道場
質問 #311
ある会社は、アプリケーションをAmazon EC2インスタンスとAWS Lambda関数で実行しています。EC2インスタンスには安定した継続的な負荷がかかり、Lambda関数には変動の大きい予測不可能な負荷がかかっています。アプリケーションには、Amazon MemoryDB for Redisを使用したキャッシュ層があります。
ソリューションアーキテクトは、会社の月々のコストを最小限に抑えるための解決策を提案する必要があります。
どの解決策がこれらの要件を満たしますか？
A. EC2インスタンスに対してEC2インスタンスのセービングプランを購入し、Lambdaの最小予想使用量をカバーするためにコンピュートセービングプランを購入し、MemoryDBキャッシュノードに対して予約ノードを購入する。
B. EC2インスタンスに対してコンピュートセービングプランを購入し、予想されるLambdaの使用量をカバーするためにLambdaの予約並列処理を購入し、MemoryDBキャッシュノードに対して予約ノードを購入する。
C. EC2インスタンス、Lambda関数、およびMemoryDBキャッシュノードの予想コスト全体をカバーするためにコンピュートセービングプランを購入する。
D. EC2インスタンスとMemoryDBキャッシュノードに対してコンピュートセービングプランを購入し、予想されるLambdaの使用量をカバーするためにLambdaの予約並列処理を購入する。
解説
選択肢 A が正解である理由は、各リソースの特性とそれに適したコスト削減手段に基づいています。以下に詳細な理由を説明します。
1. EC2インスタンスに対してEC2インスタンスのセービングプランを購入
- EC2インスタンスには、安定した負荷がかかるため、EC2インスタンスセービングプランが最も適切です。EC2インスタンスセービングプランは、特定のインスタンスファミリーに対して長期的に使用することを前提に提供され、最大で66%の割引が適用されます。安定した負荷に対して確実にコストを削減できるため、最も効率的な方法です。
2. Lambdaの最小予想使用量をカバーするためにコンピュートセービングプランを購入
- Lambdaは変動が大きく、予測不可能な負荷がかかりますが、コンピュートセービングプランを使用することで、Lambda関数に対するコストを削減できます。コンピュートセービングプランは、Lambdaを含むさまざまなコンピューティングリソースに適用可能で、使用量に基づいて割引を提供します。
- Lambdaはオンデマンドでリソースを使うため、最小限の使用量に対してコンピュートセービングプランを適用することが効果的です。このプランにより、リソース使用の変動に対応しながら、最適なコスト削減を実現できます。
3. MemoryDBキャッシュノードに対して予約ノードを購入
- MemoryDB for Redisはキャッシュ層として使用され、予測可能で安定した負荷がかかります。これに対しては予約ノードが適切です。予約ノードは、MemoryDBのようなリソースに対して適用され、長期間にわたり使用することを前提に最大55%の割引を受けることができます。
結論:
選択肢 A は、以下の点で最適なコスト削減戦略を提案しています：
- EC2インスタンスにはEC2インスタンスセービングプランが最も効率的で、安定した負荷を持つリソースに適しています。
- Lambda関数にはコンピュートセービングプランを使用して、予測不可能な負荷に対応しながらコストを削減します。
- MemoryDBには予約ノードを適用して、長期的なコスト削減を実現します。
これにより、各リソースに最適な割引が適用され、月々のコストを最小限に抑えることができます。
312-AWS SAP AWS 「理論・実践・一問道場」DynamoDB ゲーム
理論
1. AWSのグローバルアーキテクチャ
- AWSリージョンとアベイラビリティゾーン: AWSでは、データセンターが地理的に分散されたリージョンで運用されています。アプリケーションをグローバルに展開する場合、複数のリージョンにデプロイすることで、ユーザーに低レイテンシーのサービスを提供できます。
- リージョン間のレイテンシー: 地理的に離れたリージョン間での通信は遅延を引き起こす可能性があるため、アーキテクチャ設計時に低レイテンシーを確保するための工夫が必要です。
2. スケーラビリティと高可用性
- Auto Scaling: AWSでは、負荷の変動に応じて自動的にインスタンスをスケーリングできるAuto Scalingグループがあります。これを利用して、ゲームのトラフィックに合わせてEC2インスタンスを自動的に増減させることができます。
- スケーラブルな負荷分散: **Network Load Balancer (NLB)**は、トラフィックを効率的に分散し、高可用性を提供します。NLBは、高いスループットを必要とするアプリケーションに適しています。
3. データベースのレプリケーションと同期
- MySQLのレプリケーション: MySQLでは、主にマスタースレーブ型のレプリケーションを使用して、複数のリージョンでデータを同期することができます。しかし、リーダーレプリカ間での同期遅延が問題になる場合があるため、リアルタイム性を要求するアプリケーションには限界があることがあります。
- Amazon DynamoDBのグローバルテーブル: DynamoDBは、高速でスケーラブルなNoSQLデータベースで、グローバルテーブルを使用することで複数のリージョン間でデータを自動的に同期できます。DynamoDBは、リアルタイムでデータの整合性を保ちながら、グローバルにデータを利用可能にするため、低レイテンシーなアーキテクチャに非常に適しています。
4. DNSルーティング
- Amazon Route 53: Route 53は、DNSサービスであり、レイテンシーベースルーティングやジオプロキシミティルーティングなど、ユーザーを最適なリージョンに誘導するための機能を提供します。レイテンシーベースルーティングは、最も近いリージョンにトラフィックをルーティングし、アプリケーションのレスポンスタイムを改善します。
5. 運用の最適化と管理の簡素化
- 運用オーバーヘッドの低減: アーキテクチャを設計する際には、運用の管理を最小限に抑えることが重要です。自動化されたスケーリング、管理不要なデータベース同期（DynamoDBグローバルテーブル）、およびRoute 53による自動的なトラフィックルーティングにより、運用の簡素化が図られます。
結論：
グローバルに展開するアプリケーションでは、ユーザーの接続を最適なリージョンに自動的に誘導すること、データをリアルタイムで同期させることが重要です。DynamoDBのグローバルテーブルとRoute 53のレイテンシーベースルーティングを利用することで、低レイテンシーを保ちながらスケーラブルで高可用性なアーキテクチャを実現できます。
実践
略
一問道場
質問 #312
ある会社は、Amazon EC2インスタンスで新しいオンラインゲームをローンチしています。このゲームは世界中で利用可能でなければなりません。会社はゲームを3つのAWSリージョン（us-east-1、eu-west-1、ap-southeast-1）で実行する予定です。ゲームのリーダーボード、プレイヤーのインベントリ、イベントのステータスはリージョンを跨いで利用可能である必要があります。
ソリューションアーキテクトは、すべてのリージョンの負荷を処理できるように、どのリージョンでもスケールできるソリューションを設計する必要があります。さらに、ユーザーは自動的に最も低いレイテンシーを提供するリージョンに接続できる必要があります。
どのソリューションが最も運用のオーバーヘッドを最小限に抑えながら、これらの要件を満たしますか？
A. EC2 Spot Fleetを作成し、Spot Fleetを各リージョンのNetwork Load Balancer（NLB）に接続します。AWS Global Accelerator IPアドレスを作成し、そのIPアドレスがNLBを指すように設定します。Global Accelerator IPアドレスに対して、Amazon Route 53でレイテンシーベースのルーティングエントリを作成します。ゲームのメタデータを、各リージョンのAmazon RDS for MySQL DBインスタンスに保存します。他のリージョンにリードレプリカを設定します。
B. EC2インスタンス用にAuto Scalingグループを作成し、Auto Scalingグループを各リージョンのNetwork Load Balancer（NLB）に接続します。各リージョンごとに、Amazon Route 53エントリを作成し、ジオプロキシミティルーティングを使用してそのリージョンのNLBを指すように設定します。ゲームのメタデータを、各リージョンのEC2インスタンス上のMySQLデータベースに保存します。各リージョンのデータベースEC2インスタンス間でレプリケーションを設定します。
C. EC2インスタンス用にAuto Scalingグループを作成し、Auto Scalingグループを各リージョンのNetwork Load Balancer（NLB）に接続します。各リージョンごとに、Amazon Route 53エントリを作成し、レイテンシーベースのルーティングを使用してそのリージョンのNLBを指すように設定します。ゲームのメタデータを、Amazon DynamoDBのグローバルテーブルに保存します。
D. EC2 Global Viewを使用して、EC2インスタンスを各リージョンにデプロイします。インスタンスをNetwork Load Balancer（NLB）に接続します。各リージョンにEC2インスタンス上にDNSサーバーをデプロイします。各DNSサーバーにカスタムロジックを設定して、ユーザーを最も低いレイテンシーを提供するリージョンにリダイレクトします。ゲームのメタデータを、Amazon Auroraのグローバルデータベースに保存します。
解説
この問題では、ゲームのデータ（リーダーボード、プレイヤーのインベントリ、イベントステータス）を複数のリージョンで共有し、かつ、どのリージョンでも負荷に応じてスケールできるソリューションを求めています。また、ユーザーは最も低いレイテンシーを提供するリージョンに自動的に接続される必要があります。
各オプションを分析します：
A. EC2 Spot Fleet + Network Load Balancer + RDS for MySQL + Route 53 (レイテンシーベース)
- Spot Fleetを使用して、コスト効率の良いスケーラブルなEC2インスタンスを提供しますが、Spotインスタンスは中断される可能性があるため、ゲームのようなクリティカルなアプリケーションには必ずしも最適ではないかもしれません。
- RDS for MySQLを利用してデータを保存し、リードレプリカを各リージョンに配置することで、グローバルにデータを分散しますが、RDS MySQLは書き込み遅延を引き起こす可能性があります（特にリージョン間でのレプリケーション）。
- AWS Global Acceleratorを使用し、ユーザーを最適なリージョンに接続します。レイテンシーベースのルーティングにより、最も低いレイテンシーのリージョンにトラフィックが誘導されます。
B. Auto Scaling + Network Load Balancer + MySQL on EC2 + Route 53 (ジオプロキシミティルーティング)
- Auto Scalingグループを使用してスケーラビリティを提供し、リージョンごとのNLBで負荷を分散します。
- MySQL on EC2を使用してデータを保存し、データベース間でレプリケーションを設定しますが、EC2インスタンス上のMySQLはスケーラビリティや高可用性の面で制約があり、リージョン間のレプリケーションにも遅延が発生しやすいです。
- Route 53のジオプロキシミティルーティングは、ユーザーの地理的位置に基づいてトラフィックを最適なリージョンにルーティングしますが、レイテンシーに基づくルーティングの方がより効果的です。
C. Auto Scaling + Network Load Balancer + DynamoDB + Route 53 (レイテンシーベース)
- Auto ScalingグループとNLBで負荷分散とスケーラビリティを提供します。
- DynamoDBのグローバルテーブルを使用して、すべてのリージョンでデータを同期的に保持することで、リージョン間のレプリケーションの問題を解決します。DynamoDBは、グローバルに分散されるデータをリアルタイムで同期し、低遅延でデータを提供するため、非常にスケーラブルで高可用性のある選択肢です。
- Route 53のレイテンシーベースルーティングを使用して、最も低いレイテンシーを提供するリージョンにユーザーを自動的に接続します。
D. EC2 Global View + DNSサーバー + Aurora Global Database
- EC2 Global Viewは、EC2インスタンスのグローバルな管理を提供しますが、これは通常、グローバルなスケーラビリティや低レイテンシーのためには適していません。
- DNSサーバーを各リージョンに配置し、カスタムロジックでユーザーを低レイテンシーリージョンにリダイレクトするという方法は、運用の複雑さを増すため、管理オーバーヘッドが大きくなります。
- Aurora Global Databaseを使用して、データを複数のリージョンで同期します。これはスケーラビリティが高いですが、カスタムDNS設定とロジックを維持するのは運用が複雑になります。
結論：
最も簡単で効率的な選択肢は、Cの「Auto Scaling + Network Load Balancer + DynamoDB + Route 53（レイテンシーベース）」です。
- DynamoDBのグローバルテーブルは、低遅延かつ高可用性でデータをリアルタイムで同期できるため、グローバルなゲームデータの保存に最適です。
- Route 53のレイテンシーベースルーティングにより、ユーザーは最適なリージョンに自動的に接続されます。
- このソリューションは、運用オーバーヘッドが最も低く、スケーラビリティとパフォーマンスも高いです。
313-AWS SAP AWS 「理論・実践・一問道場」GWLBE
理論
- 高可用性と耐障害性：
- アベイラビリティゾーンの分散：リソースを複数のアベイラビリティゾーンに配置することで、単一障害点を避け、システムの耐障害性を高める。
- フェイルオーバー：障害発生時に自動的に別のインスタンスに切り替わる仕組みが必要。
- ロードバランサー：
- ゲートウェイロードバランサー（GLB）：ファイアウォールアプライアンスやトラフィック検査を行うインスタンスに最適。トラフィックを複数のアプライアンスに分散し、フェイルオーバーを自動化。
- ネットワークロードバランサー（NLB）：レイヤ4でトラフィックを分散させるが、ファイアウォールアプライアンスに適切ではない。
- VPC ルートテーブルとエンドポイント：
- ゲートウェイロードバランサーエンドポイント：VPC間でトラフィックを効率的にルーティングし、ファイアウォールアプライアンスに通す。
これらを活用し、信頼性の高い、スケーラブルなファイアウォール構成を実現できます。
実践
略
一問道場
質問 #313
ある会社が、AWS Marketplace から第三者のファイアウォールアプライアンスソリューションをデプロイして、会社の AWS 環境から外部インターネットへのトラフィックを監視し、保護したいと考えています。このアプライアンスを共有サービスの VPC にデプロイし、すべてのインターネット向けトラフィックをそのアプライアンスを経由させる必要があります。
ソリューションアーキテクトは、単一の AWS リージョン内でファイアウォールアプライアンス間の信頼性を優先し、フェイルオーバー時間を最小限に抑えるデプロイ方法を推奨する必要があります。会社は共有サービス VPC から他の VPC へのルーティングを設定しています。
ソリューションアーキテクトがこの要件を満たすために推奨する手順はどれですか？（3つ選んでください。）
A. 共有サービス VPC に2つのファイアウォールアプライアンスをデプロイし、それぞれ別々のアベイラビリティゾーンに配置する。
B. 共有サービス VPC に新しいネットワークロードバランサー（NLB）を作成し、新しいターゲットグループを作成して新しいネットワークロードバランサーにアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加する。
C. 共有サービス VPC に新しいゲートウェイロードバランサー（GLB）を作成し、新しいターゲットグループを作成して新しいゲートウェイロードバランサーにアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加する。
D. VPC インターフェイスエンドポイントを作成し、共有サービス VPC のルートテーブルにルートを追加します。新しいエンドポイントを、他の VPC から共有サービス VPC に入るトラフィックの次のホップとして指定します。
E. 共有サービス VPC に2つのファイアウォールアプライアンスをデプロイし、同じアベイラビリティゾーンに配置する。
F. VPC ゲートウェイロードバランサーエンドポイントを作成し、共有サービス VPC のルートテーブルにルートを追加します。新しいエンドポイントを、他の VPC から共有サービス VPC に入るトラフィックの次のホップとして指定します。
解説
この問題は、AWS環境でのファイアウォールアプライアンスのデプロイとトラフィックのルーティングに関するものです。特に、信頼性を優先し、フェイルオーバー時間を最小限に抑えつつ、全トラフィックがファイアウォールアプライアンスを通過するように設計されています。
解説のポイント:
A. 共有サービス VPC に2つのファイアウォールアプライアンスをデプロイし、それぞれ別々のアベイラビリティゾーンに配置する。
- 正解の一部です。ファイアウォールアプライアンスを複数のアベイラビリティゾーンに分散配置することで、アベイラビリティゾーンの障害に対する耐障害性が高まります。このアプローチにより、高可用性を確保し、トラフィックが常に利用可能なアプライアンスを通過するようにできます。
B. 共有サービス VPC に新しいネットワークロードバランサー（NLB）を作成し、新しいターゲットグループを作成して新しいネットワークロードバランサーにアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加する。
- 不正解です。ネットワークロードバランサー（NLB）はレイヤ4でトラフィックを処理しますが、ファイアウォールアプライアンスのようなインスタンスに対応するには、ターゲットグループの使い方としては不完全です。NLBでは、アプライアンス間のフェイルオーバーやスケーリングの要件に適切に対応できません。
C. 共有サービス VPC に新しいゲートウェイロードバランサー（GLB）を作成し、新しいターゲットグループを作成して新しいゲートウェイロードバランサーにアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加する。
- 正解の一部です。ゲートウェイロードバランサー（GLB）は、ファイアウォールアプライアンスのようなトラフィック検査型のインスタンスに最適です。GLBは、複数のインスタンスにトラフィックを分散させ、異常時には自動的に他のインスタンスにフェイルオーバーします。この方法により、高可用性と自動フェイルオーバーが実現します。
D. VPC インターフェイスエンドポイントを作成し、共有サービス VPC のルートテーブルにルートを追加します。新しいエンドポイントを、他の VPC から共有サービス VPC に入るトラフィックの次のホップとして指定します。
- 不正解です。インターフェイスエンドポイントは通常、サービス間通信（例：S3、DynamoDBなど）を確立するために使用されますが、ファイアウォールアプライアンスにおけるトラフィックのルーティングには適していません。
E. 共有サービス VPC に2つのファイアウォールアプライアンスをデプロイし、同じアベイラビリティゾーンに配置する。
- 不正解です。アベイラビリティゾーンを分けないと、片方のアベイラビリティゾーンに障害が発生した場合、全体の可用性が損なわれるリスクが高くなります。
F. VPC ゲートウェイロードバランサーエンドポイントを作成し、共有サービス VPC のルートテーブルにルートを追加します。新しいエンドポイントを、他の VPC から共有サービス VPC に入るトラフィックの次のホップとして指定します。
- 正解の一部です。ゲートウェイロードバランサーエンドポイント（GLBエンドポイント）を使用すると、外部からのトラフィックを最適にルーティングし、ファイアウォールアプライアンスに処理させることができます。この方法も高可用性とフェイルオーバーを確保します。
結論:
信頼性を重視し、フェイルオーバーを最小限に抑えるために、A, C, Fの組み合わせが最適です。これにより、高可用性のアプライアンス構成と効率的なトラフィック管理が実現できます。
314-AWS SAP AWS 「理論・実践・一問道場」ENIプール
理論
ENIプールとは、複数の**Elastic Network Interface（ENI）を一箇所に集めたリソースの管理単位のことを指します。AWSのEC2インスタンスにおけるENI（Elastic Network Interface）**は、仮想的なネットワークインターフェイスであり、インスタンスにアタッチされてIPアドレスやネットワーク設定を持つ役割を果たします。ENIを複数使うことで、インスタンス間でネットワーク設定を柔軟に変更したり、冗長化や高可用性を実現することが可能です。
ENIプールの使用目的
- 冗長化と高可用性の実現： ENIプールを利用することで、インスタンスのネットワークインターフェイスを別のインスタンスに切り替えることができ、障害発生時にサービスの継続を可能にします。たとえば、ENIプール内のENIを別のEC2インスタンスにアタッチすることができ、スムーズなフェイルオーバーを実現します。
- 柔軟なIP管理： ENIプールを利用すると、複数のENIを管理し、必要に応じて特定のENIを任意のEC2インスタンスに接続することができます。これにより、インスタンス間でのIPアドレスやネットワーク設定の変更を容易にします。
- ライセンス管理の簡素化： このケースでは、アプリケーションのライセンスファイルがMACアドレスに依存している場合、ENIプールを使って複数のENIに対するライセンスファイルを準備しておき、インスタンスのネットワークインターフェイスを動的に切り替えることで、ライセンスの適用を管理することが可能になります。
ENIプールの設計
ENIプールは通常、**複数のAvailability Zone（AZ）**にまたがって配置され、インスタンスが障害やメンテナンスなどの理由で停止した場合でも、別のAZに存在するインスタンスにENIを再アタッチすることができ、システムの可用性を高めます。
まとめ
- *ENI（Elastic Network Interface）**は、EC2インスタンスに付けられる仮想ネットワークインターフェイス。
- ENIプールは、複数のENIを管理して、柔軟なIP管理や冗長化、高可用性を実現するための仕組み。
- 高可用性やライセンス管理を効率化するために使用されます。
実践
略
一問道場
問題 #314
ソリューションアーキテクトは、オンプレミスのレガシーアプリケーションをAWSに移行する必要があります。このアプリケーションは、ロードバランサーの背後で2台のサーバー上で実行されています。アプリケーションには、サーバーのネットワークアダプタのMACアドレスに関連付けられたライセンスファイルが必要です。ソフトウェアベンダーが新しいライセンスファイルを送信するのに12時間かかります。アプリケーションはまた、データベースサーバーにアクセスするための構成ファイルを使用しており、ホスト名はサポートされていません。
これらの要件を考慮した場合、AWSでアプリケーションサーバーの高可用アーキテクチャを実装するために必要な手順の組み合わせはどれですか？（2つ選んでください。）
A. ENIのプールを作成し、ベンダーにライセンスファイルのリクエストを送信してプールに保存し、ライセンスファイルをダウンロードして対応するENIをAmazon EC2インスタンスにアタッチするブートストラップ自動化スクリプトを作成する。
B. ENIのプールを作成し、ベンダーにライセンスファイルのリクエストを送信してライセンスファイルをAmazon EC2インスタンスに保存し、そのインスタンスからAMIを作成して、今後のすべてのEC2インスタンスで使用する。
C. ブートストラップ自動化スクリプトを作成して、新しいライセンスファイルをベンダーからリクエストする。レスポンスが受信されると、そのライセンスファイルをAmazon EC2インスタンスに適用する。
D. ブートストラップ自動化スクリプトを編集して、データベースサーバーのIPアドレスをAWS Systems Managerパラメータストアから読み取り、その値をローカルの構成ファイルに注入する。
E. Amazon EC2インスタンスを編集して、構成ファイルにデータベースサーバーのIPアドレスを含め、そのAMIを再作成して今後のすべてのEC2インスタンスで使用する。
解説
この問題は、オンプレミスの古いアプリケーションをAWSに移行する際に必要な高可用性と運用の自動化を実現するためのステップを尋ねています。このアプリケーションには以下の特定の要件があります：
- ライセンスファイルの管理:
- アプリケーションはサーバーのMACアドレスに関連するライセンスファイルを必要とします。
- サーバーが変更されるたびにライセンスファイルを再取得する必要があり、その際に12時間の待機が発生します。
- 静的IPアドレスの設定:
- アプリケーションは、ホスト名ではなく静的なIPアドレスを使用してデータベースに接続します。
要件に基づくアーキテクチャの設計
高可用性と効率的な運用のために、以下の手順が考慮されるべきです。
選択肢の分析：
- A. ENIプールを作成してライセンスファイルをS3に保存し、ブートストラップスクリプトでEC2インスタンスに対応するENIを添付する
- このアプローチでは、**Elastic Network Interface（ENI）**をプールとして作成し、ライセンスファイルを管理します。EC2インスタンスが起動時にENIをアタッチし、ライセンスファイルをダウンロードして使用します。
- メリット：ENIを利用することで、異なるインスタンスに一貫したライセンス管理を提供できる。
- デメリット：ライセンス管理が手動で複雑になる可能性がある。
- B. ENIプールを作成し、ライセンスファイルをEC2インスタンスに保存してAMIを作成し、今後のインスタンスに利用する
- この方法では、ライセンスファイルをEC2インスタンスに保存し、そこから**Amazon Machine Image（AMI）**を作成します。新しいインスタンスは、このAMIを使って作成され、ライセンスが自動的に適用されます。
- メリット：新しいインスタンスがAMIを使って簡単に起動でき、ライセンスファイルも適用される。
- デメリット：ライセンスが変更される場合にAMIの再作成が必要になる可能性がある。
- C. ライセンスファイルを取得するために自動化スクリプトを作成し、EC2インスタンスに適用する
- この方法では、ライセンスファイルを自動でリクエストし、受け取った後にインスタンスに適用します。
- メリット：ライセンスファイルの管理が動的に行える。
- デメリット：外部に依存するため、ライセンスが届くまでの待機時間が発生します。
- D. ブートストラップスクリプトでAWS Systems Manager Parameter StoreからデータベースのIPアドレスを取得し、ローカルの設定ファイルに注入する
- この方法では、AWS Systems Manager Parameter Storeを使ってデータベースのIPアドレスを動的に管理し、EC2インスタンスの設定に自動で組み込むことができます。
- メリット：静的なIPアドレスを動的に管理できる。
- デメリット：Parameter Storeの設定やスクリプトの管理が必要。
- E. EC2インスタンスにデータベースIPアドレスを直接含めた設定ファイルを編集し、AMIを再作成して将来のインスタンスに使用する
- この方法では、静的IPアドレスを設定ファイルに直接書き込み、それをAMIに組み込んで新しいインスタンスに利用します。
- メリット：簡単で直感的だが、管理が静的になり柔軟性に欠ける。
- デメリット：IPアドレスが変更された場合に再構築が必要。
解答の選択
- AとDが最も理にかなっています。
- A（ENIプールの作成とライセンス管理）により、インスタンス間でライセンスファイルを一貫して管理できます。
- D（Parameter Storeを利用したIPアドレスの動的取得）で、データベースのIPアドレスを動的に管理でき、設定ファイルに柔軟に反映できます。
結論：
この問題では、AとDが推奨される選択肢です。
315-AWS SAP AWS 「理論・実践・一問道場」RDSデータベースのクロスリージョン読み取りレプリカ
理論
1. AWS RDS (Relational Database Service) のクロスリージョンレプリケーション
- クロスリージョン読み取りレプリカ: RDSは、異なるAWSリージョン間でデータベースの読み取り専用レプリカを作成できます。このレプリカは、読み取り専用トラフィックを処理し、オリジナルのデータベースのレイテンシーを削減します。これにより、グローバルに分散したユーザーが低レイテンシーでデータにアクセスできるようになります。
- 主な利点:
- データ整合性の保持: クロスリージョンレプリカを使用すると、各リージョンでデータベースの読み取り専用コピーを維持でき、アプリケーションのパフォーマンスが向上します。
- 耐障害性の向上: 本番リージョンに障害が発生した場合でも、他のリージョンでレプリカを使用することで、サービスの継続性が確保されます。
2. AWS Route 53のルーティングポリシー
- レイテンシーベースルーティング: Route 53では、ユーザーのリクエストを最も低いレイテンシーで応答できるリージョンに自動的にルーティングできます。この方法は、世界中のユーザーに迅速なアクセスを提供するのに最適です。
- 使用シーン: ユーザーが異なるリージョンに分散している場合や、アプリケーションのレスポンスを最適化したい場合に役立ちます。
- メリット: リージョン間での遅延を最小化し、ユーザー体験を向上させることができます。
- ジオロケーションルーティング: Route 53では、ユーザーの物理的な場所に基づいてトラフィックをルーティングできます。特定の地域のユーザーに特定のリージョンを選択させる際に有効です。
- 使用シーン: サービス提供地域を限定したい場合や、地域ごとのリソースにトラフィックを分配したい場合に使用されます。
3. AWS DMS (Database Migration Service)
- DMSのフルロードとCDC (変更データキャプチャ):
- フルロード: データベース全体のデータを一度に移行しますが、リアルタイムの更新には対応していません。
- CDC (変更データキャプチャ): データベースで行われた変更を追跡し、継続的に異なるリージョンに反映させる方法です。これにより、データ同期のリアルタイム性が保たれます。
DMSは主に、オンプレミスからクラウドへのデータ移行や、クラウド内でのデータ同期に使用されます。
4. グローバルなアプリケーションのパフォーマンス向上策
- データの読み取り専用トラフィックの最適化: 世界中のユーザーが読み取り専用のデータにアクセスする場合、クロスリージョンのレプリカを活用して、最寄りのリージョンから高速にデータを提供することが重要です。これにより、データ取得にかかる遅延を最小化できます。
- ユーザー接続の最適化: Route 53のルーティングポリシーを適切に設定することで、ユーザーが常に最適なリージョンに接続できるようにします。
結論
グローバルに分散したユーザーに対して低レイテンシーを提供し、データ同期を効率的に行うためには、RDSのクロスリージョン読み取りレプリカを使用し、Route 53でレイテンシーベースのルーティングを設定することが効果的です。これにより、世界中のユーザーに対してパフォーマンスの最適化が可能になります。
実践
略
一問道場
問題 #315
ある企業は、アメリカ合衆国のAWSリージョンで売上報告アプリケーションを実行しています。このアプリケーションは、Amazon API Gateway Regional APIとAWS Lambda関数を使用して、Amazon RDS for MySQLデータベースからオンデマンドでレポートを生成します。アプリケーションのフロントエンドはAmazon S3でホストされており、Amazon CloudFrontディストリビューションを通じてユーザーがアクセスします。企業は、ドメインのDNSサービスとしてAmazon Route 53を使用しています。Route 53はシンプルなルーティングポリシーで設定され、API Gateway APIへのトラフィックをルーティングしています。
今後6ヶ月以内に、企業は欧州に事業を拡大する予定です。データベーストラフィックの90%以上は読み取り専用トラフィックです。企業はすでに新しいリージョンにAPI Gateway APIとLambda関数をデプロイしています。
ソリューションアーキテクトは、レポートをダウンロードするユーザーのレイテンシーを最小限に抑えるソリューションを設計する必要があります。
どのソリューションが要件を満たしますか？
A. AWS Database Migration Service (AWS DMS)タスクを使用して、元のリージョンの主データベースを新しいリージョンのデータベースにフルロードで複製します。その後、Route 53レコードをレイテンシーベースのルーティングに変更してAPI Gateway APIに接続します。
B. AWS Database Migration Service (AWS DMS)タスクを使用して、元のリージョンの主データベースを新しいリージョンのデータベースにフルロードと変更データキャプチャ（CDC）で複製します。その後、Route 53レコードをジオロケーションルーティングに変更してAPI Gateway APIに接続します。
C. 新しいリージョンでRDSデータベースのクロスリージョン読み取りレプリカを設定します。その後、Route 53レコードをレイテンシーベースのルーティングに変更してAPI Gateway APIに接続します。
D. 新しいリージョンでRDSデータベースのクロスリージョン読み取りレプリカを設定します。その後、Route 53レコードをジオロケーションルーティングに変更してAPI Gateway APIに接続します。
解説
この問題の解説では、要求された要件（レイテンシーの最小化と読み取り専用トラフィックの効率的な取り扱い）を満たすために最適な方法を選択することが求められています。
要件
- レイテンシーの最小化: ユーザーがレポートをダウンロードする際の遅延を減らし、できるだけ迅速にレポートにアクセスできるようにする。
- データベースの90%以上が読み取り専用トラフィック: 読み取り専用のデータにアクセスする場合、データの複製を行い、他のリージョンでも効率的にアクセスできるようにする。
解説
A. AWS DMSタスクをフルロードで実行し、Route 53のレイテンシーベースルーティングに変更
- AWS DMS (Database Migration Service) はデータベースの移行を支援するサービスです。フルロードを使うと、データを一度に全て複製できますが、変更のトラッキングは行わないため、継続的なデータ同期には向いていません。
- レイテンシーベースのルーティングを使うことで、ユーザーの地理的な位置に基づいて最もレイテンシーが低いリージョンにトラフィックをルーティングできます。しかし、この方法はリアルタイムのデータ同期が必要な場合には最適ではないため、この解決策はあまり適切ではありません。
B. AWS DMSタスクをフルロード＋CDCで使用し、Route 53のジオロケーションルーティングに変更
- フルロード＋CDC (変更データキャプチャ) はデータを全量でコピーした後、データの変更を継続的に追跡して同期します。これにより、データの整合性を保ちながら、異なるリージョン間で同期を維持できます。
- ジオロケーションルーティング は、ユーザーの物理的な場所に基づいて最適なリージョンを選択するため、レイテンシーの低減には効果的です。ただし、リアルタイムの同期が必要な場合に、CDCの実装を適切に管理しないと問題が発生する可能性があります。この解決策は機能しますが、要件に完全に一致しない可能性があります。
C. RDSのクロスリージョン読み取りレプリカを使用し、Route 53のレイテンシーベースルーティングに変更
- RDSのクロスリージョン読み取りレプリカ を使うことで、異なるリージョンにデータベースの読み取り専用のコピーを作成できます。これにより、各リージョンのユーザーはローカルのデータベースレプリカにアクセスでき、レイテンシーを減少させます。
- レイテンシーベースのルーティング を使用することで、ユーザーは自分の地理的な場所に基づいて、最適なリージョンでサービスを受けられます。これにより、レイテンシーが最小化され、要求に適した解決策となります。
D. RDSのクロスリージョン読み取りレプリカを使用し、Route 53のジオロケーションルーティングに変更
- クロスリージョンの読み取りレプリカを使用し、ジオロケーションルーティングを設定することで、ユーザーの位置に基づいて最適なリージョンにルーティングできます。ただし、ジオロケーションルーティングは必ずしもレイテンシーを最小化するわけではなく、位置に基づいたルーティングが中心となります。
- この方法は、レイテンシーの最適化という観点では、レイテンシーベースのルーティング の方が効果的です。
結論
最適な解決策は、C です。
理由:
- RDSのクロスリージョン読み取りレプリカ を使うことで、データの整合性を保ちつつ、異なるリージョンにまたがる読み取り専用のトラフィックを効率的に分散できます。
- レイテンシーベースのルーティング を使用することで、ユーザーが最も低いレイテンシーを持つリージョンに自動的に接続されるため、パフォーマンスが向上します。
よって、C が最適な解決策です。
316-AWS SAP AWS 「理論・実践・一問道場」
理論
プルリクエスト（pull request）とは、
ソフトウェア開発において、コードの変更を他の開発者に通知し、レビューやマージを依頼する機能
です。
プルリクエストの主な目的は、コードの質を維持しつつ、異なる開発者が作業しやすい環境を整えることです。プルリクエストを使用することで、次のようなメリットがあります。
- コードレビューする文化を根付かせることができる
- 開発者がオープンソース開発に参加しやすくなる
- 品質の高いコードを作ることが可能になる
レビュー担当者の負担を減らすことができる
- レビュー担当者の負担を減らすことができる
プルリクエストは、GitHub、BitBucket などの主要な Git ホスティングサービスやツールで利用できます。
プルリクエストの作成や閲覧、編集などの操作は、次のとおりです。
GitHub でプルリクエストを作成するには、リポジトリ内のブランチにプッシュした変更を他のユーザーに知らせる
- GitHub でプルリクエストを作成するには、リポジトリ内のブランチにプッシュした変更を他のユーザーに知らせる
GitHub Desktop でプルリクエストを表示するには、[現在のブランチ] をクリックし、ドロップダウン メニューの上部にある [Pull Requests] をクリックする
- GitHub Desktop でプルリクエストを表示するには、[現在のブランチ] をクリックし、ドロップダウン メニューの上部にある [Pull Requests] をクリックする
プルリクエストでは、ソースコードの変更箇所をわかりやすく表示したり、コードについて意見や質問をコメントしたりすることができます
- プルリクエストでは、ソースコードの変更箇所をわかりやすく表示したり、コードについて意見や質問をコメントしたりすることができます
実践
略
一問道場
質問 #316
ソフトウェア会社は、開発プロセスの一環としてプルリクエストをテストするために、短期間で使用されるテスト環境を作成する必要があります。各テスト環境は、オートスケーリンググループ内の単一の Amazon EC2 インスタンスで構成されています。テスト環境は、テスト結果を報告するために中央サーバーと通信できる必要があります。この中央サーバーはオンプレミスのデータセンターに配置されています。ソリューションアーキテクトは、テスト環境を手動の介入なしに作成および削除できるようにするソリューションを実装する必要があります。会社はトランジットゲートウェイとオンプレミスネットワークへの VPN アタッチメントを作成しました。
最小限の運用負荷でこれらの要件を満たすソリューションはどれですか？
A. AWS CloudFormation テンプレートを作成し、このテンプレートにトランジットゲートウェイのアタッチメントおよび関連するルーティング構成を含めます。このテンプレートを含む CloudFormation スタックセットを作成します。アカウント内の各 VPC に新しいスタックをデプロイするために、CloudFormation StackSets を使用します。各テスト環境に新しい VPC をデプロイします。
B. テスト環境用に単一の VPC を作成します。この VPC にトランジットゲートウェイのアタッチメントおよび関連するルーティング構成を含めます。AWS CloudFormation を使用して、すべてのテスト環境をこの VPC にデプロイします。
C. テスト用に AWS Organizations に新しい OU を作成します。VPC、必要なネットワークリソース、トランジットゲートウェイのアタッチメント、および関連するルーティング構成を含む AWS CloudFormation テンプレートを作成します。このテンプレートを含む CloudFormation スタックセットを作成します。テスト用 OU の各アカウントにデプロイするために CloudFormation StackSets を使用します。各テスト環境用に新しいアカウントを作成します。
D. テスト環境の EC2 インスタンスを Docker イメージに変換します。AWS CloudFormation を使用して、新しい VPC に Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを構成し、トランジットゲートウェイのアタッチメントと関連するルーティング構成を作成します。Kubernetes を使用して、テスト環境のデプロイとライフサイクルを管理します。
解説
この質問では、テスト環境を効率的に作成および削除しつつ、オンプレミスの中央サーバーとの通信を確保するソリューションを選ぶ必要があります。重要なポイントは「最小限の運用負荷で要件を満たす」という条件です。
各選択肢の解説を以下に示します。
A. CloudFormation を使用して各 VPC を独立管理
解説:
- 各テスト環境ごとに新しい VPC を作成し、トランジットゲートウェイの接続設定を行います。
- CloudFormation StackSets を利用することで、テンプレートを基に効率的にリソースを作成できますが、環境ごとに新しい VPC を作成するため、リソース管理が煩雑になり、運用負荷が増加します。評価: 運用負荷が高いため不適切。
B. 単一の VPC を使用してすべてのテスト環境を管理
解説:
- すべてのテスト環境を単一の VPC にまとめ、トランジットゲートウェイ接続を共有します。
- CloudFormation を使用することで、インフラのデプロイと管理を簡素化できます。
- テスト環境ごとに VPC を分ける必要がないため、管理コストが削減され、運用負荷が軽減します。評価: 最小限の運用負荷で要件を満たす適切なソリューション。
C. 各テスト環境ごとに新しいアカウントを作成し、専用の VPC を使用
解説:
- テスト環境ごとに新しいアカウントを作成し、独立したリソースを管理します。
- 各アカウントに専用の VPC を作成するため、トランジットゲートウェイの接続設定やアカウント管理が複雑になります。
- 運用負荷が非常に高く、管理の手間も大きいです。評価: 運用負荷が高すぎるため不適切。
D. EKS を使用してテスト環境を管理
解説:
- テスト環境を Docker イメージ化し、EKS を使用してコンテナとして管理します。
- Kubernetes を使用してデプロイとライフサイクルを管理できますが、EKS のセットアップや運用には専門知識が必要です。
- 単一の VPC にまとめられるためリソース効率は良いですが、EKS の運用が運用負荷を高める可能性があります。評価: 運用負荷は中程度ですが、EKS の運用が不要であればより簡単な解決策を選ぶべきです。
正解: B
単一の VPC を使用することで、最小限の運用負荷で要件を満たしつつ、簡素で効率的な運用が可能になります。
317-AWS SAP AWS 「理論・実践・一問道場」Secrets Manager KMS
理論
複数リージョンでのAPI展開とアーキテクチャ設計
現代のクラウドアーキテクチャでは、アプリケーションの可用性やスケーラビリティを高めるために、複数のリージョンにまたがる展開が一般的です。特に、グローバルに分散したシステムでは、アクティブ-アクティブ構成を採用し、トラフィックの分散や障害耐性を向上させることが重要です。このようなアーキテクチャ設計において、特に API Gateway や AWS Lambda、DynamoDB Global Tables を使ったシステムがどのように機能するかについての汎用的な知識を紹介します。
1. アクティブ-アクティブ構成のメリット
アクティブ-アクティブ構成は、複数のリージョンでシステムを同時に稼働させることで、以下のようなメリットを提供します：
- 高可用性：1つのリージョンがダウンしても、他のリージョンでシステムが稼働しているため、サービスの中断を最小化できます。
- 低レイテンシー：ユーザーが最寄りのリージョンにリクエストを送信することで、低遅延でのアクセスが可能になります。
- 耐障害性：リージョン間でトラフィックが自動的に切り替わり、システム全体の耐障害性が向上します。
2. 複数リージョンにおけるAPI Gatewayの使用
API Gatewayは、クラウドベースのアプリケーションのエンドポイントとして機能します。複数リージョンにまたがるAPIを設計する際には、次のようなポイントが重要です：
- Regional APIエンドポイント：API Gatewayは、各リージョンで独立して設定する必要があります。これにより、ユーザーのリクエストが最寄りのリージョンにルーティングされ、遅延が最小限に抑えられます。
- Route 53によるトラフィックの分散：AWSのDNSサービスであるRoute 53を利用して、各リージョンのAPIエンドポイントへのトラフィックを分散させます。これにより、ヘルスチェックを基に健全なリージョンにリクエストを振り分けることが可能になります。
- カスタムドメイン名：複数リージョンにまたがるAPIを管理するために、Route 53を使ってカスタムドメイン名を設定し、グローバルにアクセス可能なAPIを提供できます。
3. AWS Lambdaの多地域展開
AWS Lambdaは、サーバーレスでコードを実行できるサービスですが、リージョン固有で動作します。そのため、複数リージョンに対応するためには、各リージョンに同じLambda関数をデプロイする必要があります。
- Lambdaの手動デプロイ：各リージョンにLambda関数を手動でデプロイする方法。これには少し手間がかかりますが、小規模なシステムでは十分に機能します。
- CI/CDパイプラインの活用：より効率的に複数リージョンにデプロイするためには、AWS CodePipelineやTerraformなどのインフラ管理ツールを使って、Lambda関数を複数リージョンに自動デプロイする方法が一般的です。
- Lambda関数の役割：API Gatewayからのリクエストを受けて、外部APIからのデータ取得やDynamoDBへのデータ書き込み・取得を担当します。Lambda関数は、API Gatewayからリクエストを受けて、ビジネスロジックを実行します。
4. DynamoDB Global Tables
DynamoDB Global Tablesは、複数のAWSリージョンでデータを同期させるための機能です。これにより、複数リージョンにまたがるデータの読み書きが可能になります。
- 自動データ同期：DynamoDB Global Tablesは、データの変更を各リージョンに自動的に反映させます。これにより、複数のリージョンで一貫性のあるデータを保持できます。
- 高可用性の確保：Global Tablesを使うことで、どのリージョンでもデータが利用でき、障害発生時にも他のリージョンからデータにアクセスできます。
5. Secrets Managerの複数リージョンでの管理
Secrets Managerは、機密情報を安全に管理するためのサービスです。複数リージョンでシステムを運用する場合、次のような構成が考えられます：
- Secretsの複製：機密情報（APIキーなど）は、各リージョンに複製しておくことが一般的です。これにより、リージョン間で同期を取り、システムがダウンしないようにします。
- KMSキーの管理：Secrets Managerでは、**KMS（Key Management Service）**を使って機密情報を暗号化します。複数リージョンで使用する場合、マルチリージョンKMSキーを使用することで、異なるリージョンでも同じキーで暗号化・復号化を行えます。
6. 運用上の考慮点
複数リージョン構成では、以下の運用上のポイントも重要です：
- 監視とアラート：AWS CloudWatchを使って、複数リージョンのシステムを監視し、問題が発生した際には即座にアラートを受け取ることが重要です。
- 障害対応計画：障害発生時にどのリージョンでトラフィックを受け入れるか、どのようにデータの整合性を保つかなど、障害対応の計画を事前に立てておく必要があります。
まとめ
複数リージョンでのシステム展開は、高可用性と低遅延を実現するために不可欠なアーキテクチャの1つです。API Gateway、AWS Lambda、DynamoDB Global Tables、Secrets Managerなどのサービスを組み合わせて、アクティブ-アクティブ構成を作成することで、システム全体の信頼性とスケーラビリティを大幅に向上させることができます。
実践
略
一問道場
Question #317
ある企業が新しいAPIをAWSにデプロイしています。このAPIは、Regional APIエンドポイントを持つAmazon API GatewayとAWS Lambda関数を使用しています。APIは外部ベンダーのAPIからデータを取得し、Amazon DynamoDBグローバルテーブルにデータを保存し、そのテーブルからデータを取得します。ベンダーAPIのAPIキーはAWS Secrets Managerに保存されており、AWS Key Management Service（AWS KMS）のカスタマーマネージドキーで暗号化されています。企業は自社のAPIを単一のAWSリージョンにデプロイしています。
ソリューションアーキテクトは、APIコンポーネントを変更して、複数リージョンでアクティブ-アクティブ構成で実行できるようにする必要があります。
運用負荷を最小限に抑えながら、この要件を満たすためにどの変更の組み合わせを行うべきでしょうか？（3つ選択してください）
選択肢:
A. APIを複数のリージョンにデプロイします。Amazon Route 53にカスタムドメイン名を設定し、各Regional APIエンドポイントにトラフィックをルーティングします。Route 53のマルチバリューアンサールーティングポリシーを実装します。
B. 新しいKMSマルチリージョンカスタマーマネージドキーを作成します。対象となる各リージョンに新しいKMSカスタマーマネージドレプリカキーを作成します。
C. 既存のSecrets Managerシークレットを他のリージョンにレプリケートします。対象となる各リージョンのレプリケートされたシークレットに適切なKMSキーを選択します。
D. 各対象リージョンに新しいAWSマネージドKMSキーを作成します。既存のキーをマルチリージョンキーに変換します。他のリージョンでマルチリージョンキーを使用します。
E. 各対象リージョンに新しいSecrets Managerシークレットを作成します。既存のリージョンからシークレット値をコピーして、各対象リージョンの新しいシークレットに入力します。
F. Lambda関数のデプロイプロセスを変更し、対象となる各リージョンにデプロイを繰り返します。既存のAPIのマルチリージョンオプションをオンにします。各リージョンにデプロイされたLambda関数を、マルチリージョンAPIのバックエンドとして選択します。
解説
この質問は、企業のAPIを複数のリージョンでアクティブ-アクティブ構成にするための方法を問うものです。解決策としては、AWSサービスを活用して運用負荷を最小限に抑えながら、リージョン間での冗長性と可用性を確保することが求められています。
必要な変更のポイント:
- API Gatewayのデプロイ: 複数のリージョンでAPIを提供するために、APIを他のリージョンにもデプロイする必要があります。
- Secrets ManagerとKMSキーの管理: 複数リージョンでAPIが利用できるように、Secrets Managerに保存されているAPIキーを複数のリージョンにレプリケートし、KMSキーもマルチリージョンに対応させる必要があります。
- Lambda関数のデプロイ: APIが複数のリージョンで動作するためには、Lambda関数も複数のリージョンにデプロイする必要があります。
各選択肢の解説:
A. APIを複数のリージョンにデプロイし、Route 53でトラフィックをルーティングする
- 理由: API Gatewayを複数のリージョンにデプロイすることで、アクティブ-アクティブ構成を実現できます。Route 53でカスタムドメイン名を設定し、マルチバリューアンサールーティングポリシーを使用することで、トラフィックを各リージョンに均等に分散させることができます。この構成により、高可用性とスケーラビリティが確保されます。
- 適切な理由: この設定により、APIが複数のリージョンで同時に稼働し、リージョン間での冗長性が確保されます。
B. 新しいKMSマルチリージョンカスタマーマネージドキーを作成し、各リージョンにレプリケートキーを作成
- 理由: KMSのキーは、複数リージョンで使用するために「マルチリージョンキー」を作成する必要があります。これにより、複数のリージョンで同じKMSキーを使ってデータを暗号化および復号化できます。マルチリージョンキーを使うことで、運用管理が容易になります。
- 適切な理由: KMSのマルチリージョンキーを使用することで、シークレットの暗号化と復号化の一貫性が確保され、リージョン間でのキー管理が簡素化されます。
C. Secrets Managerシークレットを他のリージョンにレプリケートし、適切なKMSキーを選択
- 理由: Secrets Managerのシークレットは複数のリージョンにレプリケートできます。これにより、各リージョンで同じAPIキーが利用でき、リージョン間での可用性が向上します。また、適切なKMSキーを選択することで、セキュリティも確保できます。
- 適切な理由: シークレットのレプリケーションによって、リージョン間でAPIキーを共有でき、マルチリージョンで一貫性を持たせることができます。
D. 新しいAWSマネージドKMSキーを作成し、マルチリージョンキーに変換
- 理由: 新しいKMSキーを作成し、それをマルチリージョンキーに変換する方法もありますが、これよりも「マルチリージョンカスタマーマネージドキー」の作成の方が運用負荷が低く、AWSによる管理が容易です。
- 不適切な理由: AWSマネージドキーを使用することは推奨されません。セキュリティと管理の柔軟性が低く、カスタマーマネージドキーの方が適切です。
E. 各リージョンに新しいSecrets Managerシークレットを作成し、既存のリージョンからコピー
- 理由: シークレットを手動でコピーする方法は、運用の効率性が低く、複数リージョンでの管理が煩雑になります。また、この方法ではシークレットの整合性を保つのが難しく、運用負荷が高くなります。
- 不適切な理由: 手動でシークレットをコピーするのは、管理が面倒でエラーが発生しやすい方法です。
F. Lambda関数のデプロイプロセスを変更し、マルチリージョンオプションをオンにする
- 理由: Lambda関数のデプロイを複数のリージョンに展開することで、各リージョンにデプロイされたLambda関数をAPIのバックエンドとして使用できます。これにより、APIとLambda関数がリージョン間で冗長化され、可用性が向上します。
- 適切な理由: Lambda関数を複数のリージョンにデプロイすることで、マルチリージョン構成が実現できます。
結論:
運用負荷を最小限に抑えながら、APIを複数のリージョンでアクティブ-アクティブ構成にするためには、以下の選択肢が最適です：
- A: APIを複数のリージョンにデプロイし、Route 53を利用してトラフィックを分散
- B: KMSのマルチリージョンカスタマーマネージドキーを使用
- C: Secrets Managerシークレットをレプリケートし、各リージョンで適切なKMSキーを選択
これらを組み合わせることで、運用負荷が最小限で済み、APIと関連リソースが高可用性とスケーラビリティを確保できます。
318-AWS SAP AWS 「理論・実践・一問道場」Amazon Neptune
理論
Amazon Neptuneは、AWSが提供するグラフデータベースサービスです。グラフデータベースは、データ同士の「関係性」を効率的に保存・検索・分析するためのデータベースです。
1. グラフデータベースとは？
- グラフデータベースは、ノード（点）とエッジ（線）という「グラフ構造」を使ってデータを表現します。例えば、ソーシャルネットワークのように、人（ノード）とその間の友達関係（エッジ）を表現するのに適しています。
- 一般的なリレーショナルデータベースは、テーブル形式でデータを管理しますが、グラフデータベースは「データ同士の関係」を重視します。これにより、複雑なデータの関連性を直感的に扱えるようになります。
2. Amazon Neptuneの特徴
- 高性能: 複雑なグラフデータのクエリを高速に実行できます。
- スケーラブル: 大規模なデータセットにも対応可能で、負荷の増加に合わせて自動的にスケールします。
- 互換性: Apache TinkerPopやW3C's SPARQLといった、一般的なグラフデータベースのクエリ言語に対応しています。
- 可用性: 高可用性を提供するため、AWSの複数のアベイラビリティゾーン（AZ）に分散してデータを保存し、障害発生時には自動的に復旧できます。
3. 使用例
- ソーシャルネットワーク: ユーザー同士の友達関係やフォロワー関係を表現する。
- 推奨エンジン: ユーザーが好む商品やコンテンツを他のユーザーの行動から予測する。
- 金融ネットワーク: 取引先同士の関係を追跡して、詐欺行為を発見する。
- 知識グラフ: さまざまな情報間の関連性を整理し、検索や分析に役立てる。
4. 使うべき場面
- データ間の関係性を重視するシステム（例：ソーシャルネットワーク、推奨システム）を構築する場合に非常に有効です。
簡単に言うと、Amazon Neptuneは「データ間のつながり」を効率的に管理したいときに使うグラフデータベースサービスです。
1. 高可用性を提供するためのアーキテクチャ設計
- Auto Scaling: アプリケーションを自動的にスケールイン/スケールアウトさせ、需要に応じてリソースを調整できます。これにより、アプリケーションの可用性と性能が確保されます。
- 負荷分散（Load Balancer）: Amazonの**Application Load Balancer (ALB)やNetwork Load Balancer (NLB)**は、アプリケーションへのトラフィックを複数のインスタンスに分散させ、負荷を均等にし、障害が発生しても他のインスタンスがトラフィックを処理できるようにします。
2. データベースの信頼性
- RDS Multi-AZ: Amazon RDSのMulti-AZデプロイメントは、データベースの高可用性を実現するために、メインのDBインスタンスと同期されたバックアップインスタンスを異なるアベイラビリティゾーン（AZ）に配置します。障害発生時には自動的にバックアップインスタンスにフェイルオーバーします。
- Amazon Aurora: AuroraはRDSの一部であり、デフォルトで高可用性を提供し、データの冗長性を確保します。特に、Aurora MySQLは高いスケーラビリティとパフォーマンスを持ちながら、RDSよりも高可用性の機能を提供します。
3. セッションの管理
- ElastiCache: Amazon ElastiCacheはメモリキャッシュサービスで、セッションデータをインメモリに保存することで、アプリケーションの性能を向上させ、データベースに負荷をかけません。特にRedisは高いパフォーマンスとスケーラビリティを提供します。
4. 適切なストレージソリューション
- Amazon NeptuneやKinesis Data Firehoseはそれぞれ異なる用途に使われます。Neptuneはグラフデータベースとして、Kinesisはリアルタイムのデータストリーム処理に使用されますが、一般的なセッション管理には適していません。
5. DBの選択
- MySQL: MySQLは広く使用されているリレーショナルデータベースですが、Amazon Aurora MySQLは高可用性とパフォーマンス向上のために最適化されており、より優れた選択肢と言えます。
- MariaDB: MariaDBはMySQLのフォークであり、同様の機能を持ちますが、AuroraやMySQLの方がスケーラビリティとパフォーマンスに優れている場合が多いです。
結論
信頼性が最も高い構成は、Amazon Aurora MySQLとElastiCache for Redisを組み合わせることです。これにより、高可用性、スケーラビリティ、パフォーマンスが確保され、セッション管理も効率的に行えます。
実践
略
一問道場
オンライン小売企業が、オンプレミスのデータセンターでホストされている状態のWebベースのアプリケーションとMySQLデータベースをAWSに移行し、アーキテクチャの信頼性を高めることで、マーケティングキャンペーンやプロモーションを通じて顧客基盤を拡大したいと考えています。
最も高い信頼性を提供するソリューションはどれですか？
A. データベースをAmazon RDS MySQL Multi-AZ DBインスタンスに移行し、アプリケーションをAuto Scalingグループ内のAmazon EC2インスタンスでApplication Load Balancerの背後にデプロイします。セッションはAmazon Neptuneに保存します。
B. データベースをAmazon Aurora MySQLに移行し、アプリケーションをAuto Scalingグループ内のAmazon EC2インスタンスでApplication Load Balancerの背後にデプロイします。セッションはAmazon ElastiCache for Redisのレプリケーショングループに保存します。
C. データベースをAmazon DocumentDB（MongoDB互換）に移行し、アプリケーションをAuto Scalingグループ内のAmazon EC2インスタンスでNetwork Load Balancerの背後にデプロイします。セッションはAmazon Kinesis Data Firehoseに保存します。
D. データベースをAmazon RDS MariaDB Multi-AZ DBインスタンスに移行し、アプリケーションをAuto Scalingグループ内のAmazon EC2インスタンスでApplication Load Balancerの背後にデプロイします。セッションはAmazon ElastiCache for Memcachedに保存します。
解説
最適な選択肢：
Bが最も高い信頼性を提供します。その理由は以下の通りです：
- *データベースの選択：**
- Amazon Aurora MySQLは、MySQL互換のリレーショナルデータベースサービスで、高いパフォーマンスと可用性を提供します。
- Multi-AZ配置により、プライマリインスタンスと同期されたスタンバイインスタンスが異なるアベイラビリティゾーンに配置され、障害時の自動フェイルオーバーが可能です。
- *アプリケーションのデプロイ：**
- Auto ScalingグループとApplication Load Balancerを組み合わせることで、トラフィックの増減に応じてEC2インスタンスを自動的にスケールし、負荷分散を行います。
- *セッション管理：**
- Amazon ElastiCache for Redisは、インメモリデータストアであり、セッション情報の高速な読み書きをサポートします。
- レプリケーショングループを使用することで、データの冗長性と高可用性を確保できます。
他の選択肢の評価：
- *A.**
- Amazon Neptuneはグラフデータベースサービスであり、セッション情報の保存には適していません。
- *C.**
- Amazon DocumentDBはNoSQLデータベースであり、MySQL互換のデータベースを使用する場合には適切ではありません。
- Network Load BalancerはTCPトラフィックに最適化されており、HTTP/HTTPSトラフィックにはApplication Load Balancerの方が適しています。
- *D.**
- Amazon RDS MariaDBは高可用性を提供しますが、Amazon Aurora MySQLの方がパフォーマンスと可用性の面で優れています。
- Amazon ElastiCache for Memcachedはシンプルなキャッシュサービスであり、セッション管理にはElastiCache for Redisの方が適しています。
結論：
Bの選択肢が、データベース、アプリケーションのデプロイ、セッション管理の各要素において高い可用性と信頼性を提供する最適な構成です。
319-AWS SAP AWS 「理論・実践・一問道場」AD Connect SSO
理論
- AWS Directory Service (AD Connector): オンプレミスのActive DirectoryとAWS環境を接続し、ユーザー情報を提供。
- AWS IAM Identity Center: オンプレミスのADから同期したユーザー情報を使ってAWS内でのアクセス権限を管理し、シングルサインオンを提供。
このように、AWS Directory Serviceが「接続」する役割を担い、AWS IAM Identity Centerが「同期」とその後の「アクセス管理」を行うという役割分担になります。
1. AWS Directory Service
AWS Directory Serviceは、AWS上でActive Directory環境を提供するサービスです。主に以下の2つのタイプがあります：
- AWS Managed Microsoft AD: AWS上でフルマネージドのActive Directoryを提供。オンプレミスのActive Directoryと連携可能。
- AD Connector: オンプレミスのActive DirectoryとAWSを統合するためのハイブリッドソリューション。
これにより、ユーザーはAWS環境内で統一されたユーザー認証、アクセス制御を実現できます。
2. リモートデスクトップ接続 (RDP)
AWS EC2インスタンスへのリモートデスクトップ接続を管理するために、以下の方法がよく使用されます：
- バスチオンホスト: セキュリティを高めるために、特定のインスタンス（バスチオンホスト）を経由してリモート接続を実行します。これにより、インスタンスへの直接的なアクセスを制限します。
- Remote Desktop Gateway: RDP接続を集中的に管理するゲートウェイとして利用し、インスタンスへのアクセスをセキュアに保つ手法です。
3. AWS Systems Manager
AWS Systems Managerは、EC2インスタンスの管理を簡素化するツールで、リモート接続を行うためのセッションマネージャー機能を提供します。これを使用することで、インターネット経由で直接EC2インスタンスにアクセスでき、SSHやRDPを使わずに管理が可能です。これにより、セキュリティを向上させ、インスタンスに対するアクセスコントロールを強化できます。
4. VPN接続とセキュリティ
AWSでのリモート接続に際して、VPN接続を使用することで、オンプレミスのネットワークとAWS環境間にセキュアな通信経路を確立できます。これにより、データ転送がインターネットを経由せず、セキュリティが強化されます。
5. コスト管理と最適化
リモートデスクトップ接続のインフラ（例えば、バスチオンホストやRDPゲートウェイ）を維持する際、コスト最適化が重要です。適切なインスタンスタイプを選択し、必要に応じてスケーリングを行うことが推奨されます。また、AWSのコスト管理ツール（AWS Cost Explorerなど）を使って、リソースの使用状況をモニタリングし、無駄なコストを避けることができます。
6. セキュリティベストプラクティス
リモートデスクトップ接続に関しては、以下のセキュリティ対策を講じることが重要です：
- 最小権限の原則: ユーザーやサービスに最低限必要な権限のみを付与します。
- 多要素認証（MFA）: セキュリティを強化するため、RDP接続やAWS管理コンソールへのアクセスにMFAを導入します。
- ログ管理: CloudTrailやCloudWatch Logsを使用して、アクセスログやセキュリティイベントを監視し、異常を検知します。
これらの知識を活用することで、AWS環境でのリモートデスクトップ接続をセキュアに、効率的に管理することができます。
実践
略
一問道場
問題 #319
ある企業のソリューションアーキテクトは、Amazon EC2 Windowsインスタンスに対してリモートデスクトップ接続を安全に提供する必要があります。インスタンスはVPC内にホストされています。ソリューションは、企業のオンプレミスActive Directoryと集中管理されたユーザー管理を統合する必要があります。VPCへの接続はインターネット経由です。企業には、AWS Site-to-Site VPN接続を確立するためのハードウェアがあります。
どのソリューションが最もコスト効果の高い方法でこの要件を満たしますか？
A. AWS Directory Service for Microsoft Active Directoryを使用して管理されたActive Directoryを展開し、オンプレミスのActive Directoryと信頼関係を確立します。VPCにEC2インスタンスをバスチオンホストとして展開し、そのEC2インスタンスをドメインに参加させます。バスチオンホストを使用してターゲットインスタンスにRDP経由でアクセスします。
B. AWS IAM Identity Center (AWS Single Sign-On) を設定して、AWS Directory Service for Microsoft Active Directory AD Connector を使用してオンプレミスのActive Directoryと統合します。ユーザーグループに対してアクセス権限セットを設定し、AWS Systems Managerを使用してターゲットインスタンスにRDP経由でアクセスします。
C. オンプレミス環境とターゲットVPC間でVPNを実装し、VPN接続を介してターゲットインスタンスをオンプレミスのActive Directoryドメインに参加させます。VPN経由でRDPアクセスを設定し、企業のネットワークからターゲットインスタンスにアクセスします。
D. AWS Directory Service for Microsoft Active Directoryを使用して管理されたActive Directoryを展開し、オンプレミスのActive Directoryと信頼関係を確立します。AWS Quick Startを使用してAWS上にリモートデスクトップゲートウェイを展開し、リモートデスクトップゲートウェイをドメインに参加させます。リモートデスクトップゲートウェイを使用してターゲットインスタンスにRDP経由でアクセスします。
解説
この問題では、Amazon EC2 Windowsインスタンスへのリモートデスクトップ接続を安全に提供し、オンプレミスのActive Directoryと統合する方法を求めています。最もコスト効果の高いソリューションを選択する必要があります。
選択肢の分析:
- A. AWS Directory Service for Microsoft Active Directoryを使用して管理されたActive Directoryを展開し、オンプレミスのActive Directoryと信頼関係を確立します。VPCにEC2インスタンスをバスチオンホストとして展開し、そのEC2インスタンスをドメインに参加させます。バスチオンホストを使用してターゲットインスタンスにRDP経由でアクセスします。
- 評価: この方法では、バスチオンホストを使用してターゲットインスタンスにアクセスしますが、バスチオンホスト自体の管理やセキュリティの維持が必要です。
- B. AWS IAM Identity Center (AWS Single Sign-On)を設定して、AWS Directory Service for Microsoft Active Directory AD Connectorを使用してオンプレミスのActive Directoryと統合します。ユーザーグループに対してアクセス権限セットを設定し、AWS Systems Managerを使用してターゲットインスタンスにRDP経由でアクセスします。
- 評価: AWS Systems Managerを使用することで、バスチオンホストを使用せずに直接ターゲットインスタンスにアクセスできます。
- C. オンプレミス環境とターゲットVPC間でVPNを実装し、VPN接続を介してターゲットインスタンスをオンプレミスのActive Directoryドメインに参加させます。VPN経由でRDPアクセスを設定し、企業のネットワークからターゲットインスタンスにアクセスします。
- 評価: VPN接続を使用することで、オンプレミスのActive Directoryと直接統合できますが、VPNの設定や管理が必要です。
- D. AWS Directory Service for Microsoft Active Directoryを使用して管理されたActive Directoryを展開し、オンプレミスのActive Directoryと信頼関係を確立します。AWS Quick Startを使用してAWS上にリモートデスクトップゲートウェイを展開し、リモートデスクトップゲートウェイをドメインに参加させます。リモートデスクトップゲートウェイを使用してターゲットインスタンスにRDP経由でアクセスします。
- 評価: リモートデスクトップゲートウェイを使用することで、セキュアなRDPアクセスを提供できますが、ゲートウェイの管理やコストが増加します。
最適な選択肢:
Bが最もコスト効果が高いと考えられます。AWS Systems Managerを使用することで、バスチオンホストやVPN接続を使用せずに、直接ターゲットインスタンスにアクセスできます。これにより、管理の手間やコストを削減できます。
参考情報:
320-AWS SAP AWS 「理論・実践・一問道場」EBSボリュームの暗号化
理論
Amazon Elastic Block Store（Amazon EBS）ボリュームの暗号化は、データの保護とコンプライアンス要件を満たすために重要です。
EBSボリュームの暗号化方法：
- デフォルトでの暗号化の有効化：
- AWSアカウントで新規に作成されるEBSボリュームを自動的に暗号化する設定です。
- これにより、手動で暗号化を設定する手間が省け、セキュリティポリシーの遵守が容易になります。
- 設定方法は、AWSマネジメントコンソールの「アカウントの属性」から「EBS暗号化」を選択し、「常に新しいEBSボリュームを暗号化」を有効化します。
- 詳細な手順は、AWS公式ドキュメントをご参照ください。
- 既存のEBSボリュームの暗号化：
- 既存の非暗号化ボリュームを暗号化するには、スナップショットを利用します。
- 手順は以下の通りです：
- 非暗号化ボリュームのスナップショットを作成します。
- そのスナップショットをコピーし、コピー時に暗号化を有効にします。
- 暗号化されたスナップショットから新しいEBSボリュームを作成します。
- 新しい暗号化されたボリュームをEC2インスタンスにアタッチします。
- この方法により、既存のデータを暗号化された状態で保護できます。
注意点：
- デフォルトでの暗号化はリージョン固有の設定であり、各リージョンごとに有効化する必要があります。
- 暗号化されたEBSボリュームから作成されたスナップショットも暗号化されますが、暗号化されていないスナップショットからは暗号化されたボリュームを直接作成することはできません。
- 暗号化されたEBSボリュームのパブリックスナップショットはサポートされていませんが、暗号化されたスナップショットを特定のアカウントと共有することは可能です。
これらの方法を活用することで、EBSボリュームの暗号化を効果的に管理し、データのセキュリティを強化できます。
実践
略
一問道場
ある企業のコンプライアンス監査により、AWSアカウントで作成された一部のAmazon Elastic Block Store（Amazon EBS）ボリュームが暗号化されていないことが判明しました。ソリューションアーキテクトは、新規作成されるすべてのEBSボリュームを暗号化するソリューションを実装する必要があります。最も労力をかけずにこの要件を満たすソリューションはどれですか？
A. Amazon EventBridgeルールを作成して、暗号化されていないEBSボリュームの作成を検出します。非準拠のボリュームを削除するAWS Lambda関数を呼び出します。
B. AWS Audit Managerをデータ暗号化とともに使用します。
C. AWS Configルールを作成して、新しいEBSボリュームの作成を検出します。AWS Systems Manager Automationを使用してボリュームを暗号化します。
D. すべてのAWSリージョンでEBSのデフォルト暗号化をオンにします。
解説
最も労力をかけずにこの要件を満たすソリューションは、Dの「すべてのAWSリージョンでEBSのデフォルト暗号化をオンにする」です。
EBSのデフォルト暗号化を有効にすると、新規に作成されるすべてのEBSボリュームが自動的に暗号化されます。
この設定はリージョンごとに行う必要があります。
設定方法は以下の通りです：
- EC2ダッシュボードにアクセスします。
- 右上の「アカウントの属性」から「EBS暗号化」を選択します。
- 「管理」をクリックします。
- 「常に新しいEBSボリュームを暗号化」のチェックボックスをオンにし、デフォルトの暗号化キーを設定します。
- 「EBS暗号化を更新する」をクリックして設定を保存します。
この設定により、以降に作成されるEBSボリュームはすべて指定したKMSキーで暗号化されます。
既存の非暗号化ボリュームに対しては、手動で暗号化を行う必要があります。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/176d7ae8-88e2-80c9-9a2d-cc52f00de8b9
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
