type
status
date
slug
summary
tags
category
icon
password
书籍
131-アカウント間基本はスイッチロール
理論
アカウント間でのアクセスにおいては、通常、**スイッチロール（ロールの引き受け）**が使用されます。具体的には、あるアカウントのIAMロールを別のアカウントで「引き受ける（assume）」ことによって、リソースにアクセスする仕組みです。
スイッチロール（ロールの引き受け）の仕組み：
- ロール作成:
- アカウントA（例えばアプリケーションアカウント）に、アクセスを許可したいリソースに関連するロール（例えば、
DBA-Secretロール）を作成します。 - アカウントB（DBAアカウント）には、そのロールを引き受けるための権限を持つ別のIAMロール（例えば、
DBA-Adminロール）を作成します。
- 引き受けの許可:
- アカウントBのIAMロール（
DBA-Admin）に、アカウントAのDBA-Secretロールを引き受ける権限（sts:AssumeRole）を付与します。
- ロールの引き受け:
- アカウントB（DBAアカウント）のユーザーやEC2インスタンスが
DBA-Adminロールを引き受け、アカウントA内のSecrets Managerやその他のリソースにアクセスできるようになります。
このように、スイッチロール（ロールの引き受け）を利用することで、アカウント間で安全にリソースを共有し、アクセスを管理できます。
まとめ：
- アカウント間のアクセスは、通常、スイッチロール（
sts:AssumeRole）を使って実現します。
- ロールを引き受けることで、別アカウントのリソースにアクセスする権限を付与し、安全にリソースの共有が可能になります。
一問道場
問題 #131
トピック 1
会社は、AWS Cloud の マルチアカウント設定 に AWS Organizations を使用しています。会社は AWS Control Tower を使用してガバナンスを行い、アカウント間での VPC 接続には AWS Transit Gateway を使用しています。
AWS アプリケーションアカウントでは、アプリケーションチームが AWS Lambda と Amazon RDS を使用してウェブアプリケーションをデプロイしています。会社のデータベース管理者は別の DBA アカウント を使用し、組織全体のデータベースを中央管理しています。データベース管理者は DBA アカウントにデプロイされた Amazon EC2 インスタンスを使用して、アプリケーションアカウントにデプロイされた RDS データベースにアクセスしています。
アプリケーションチームは、データベースの資格情報を AWS Secrets Manager に保存し、アプリケーションアカウント内で管理しています。アプリケーションチームは、手動でデータベース管理者と資格情報を共有しています。資格情報は、アプリケーションアカウント内で Secrets Manager のデフォルトの AWS 管理キーによって暗号化されています。
ソリューションアーキテクトは、データベース管理者にデータベースへのアクセスを提供し、資格情報を手動で共有する必要がないようなソリューションを実装する必要があります。
どのソリューションがこの要件を満たしますか？
A. AWS Resource Access Manager (AWS RAM) を使用して、アプリケーションアカウントから DBA アカウントに資格情報を共有します。DBA アカウント内で、DBA-Admin という名前の IAM ロールを作成し、ロールに必要な資格情報へのアクセス権を付与します。DBA-Admin ロールを EC2 インスタンスにアタッチして、アカウント間の資格情報にアクセスします。
B. アプリケーションアカウント内で、DBA-Secret という名前の IAM ロールを作成し、ロールに資格情報へのアクセス権を付与します。DBA アカウント内で、DBA-Admin という名前の IAM ロールを作成し、DBA-Admin ロールにアプリケーションアカウントの DBA-Secret ロールを引き受けるための権限を付与します。DBA-Admin ロールを EC2 インスタンスにアタッチして、アカウント間の資格情報にアクセスします。
C. DBA アカウント内で DBA-Admin という名前の IAM ロールを作成し、ロールに資格情報およびアプリケーションアカウント内のデフォルトの AWS 管理キーへのアクセス権を付与します。アプリケーションアカウント内で、リソースベースのポリシーをキーにアタッチして、DBA アカウントからのアクセスを許可します。DBA-Admin ロールを EC2 インスタンスにアタッチして、アカウント間の資格情報にアクセスします。
D. DBA アカウント内で DBA-Admin という名前の IAM ロールを作成し、ロールにアプリケーションアカウント内の資格情報へのアクセス権を付与します。アプリケーションアカウントに SCP をアタッチして、DBA アカウントからの資格情報へのアクセスを許可します。DBA-Admin ロールを EC2 インスタンスにアタッチして、アカウント間の資格情報にアクセスします。
解説
この問題では、アプリケーションアカウント内の AWS Secrets Manager に保存されている資格情報を DBA アカウント にアクセスさせるための最適なソリューションを求めています。データベース管理者（DBA）が手動で資格情報を共有せず、アクセスを自動化する方法を選ばなければなりません。
各選択肢の分析:
A. AWS Resource Access Manager (AWS RAM) を使用して、アプリケーションアカウントから DBA アカウントに資格情報を共有します。
- AWS RAM はリソースを他の AWS アカウントと共有するためのサービスですが、Secrets Manager の資格情報を直接共有するためには適していません。AWS RAMは主にVPCピアリングやAMI、S3バケットなどのリソースを共有するのに使われますが、Secrets Managerの資格情報をアクセスするための最適な方法ではありません。
- このソリューションは要件に適していません。
B. アプリケーションアカウント内で、DBA-Secret という名前の IAM ロールを作成し、ロールに資格情報へのアクセス権を付与します。
- これは IAM ロール の引き受けを使ってアカウント間で資格情報を共有する方法です。DBA アカウント内に DBA-Admin という IAM ロールを作成し、アプリケーションアカウントの DBA-Secret ロールを引き受ける権限を付与します。
- IAMロール を引き受ける権限を設定することで、資格情報を適切に共有でき、手動で資格情報を共有する必要がなくなります。
- この方法は要件に合致しており、適切です。
C. DBA アカウント内で DBA-Admin という名前の IAM ロールを作成し、ロールに資格情報およびアプリケーションアカウント内のデフォルトの AWS 管理キーへのアクセス権を付与します。
- ここでは DBA-Admin ロール に資格情報へのアクセス権を付与し、さらに AWS 管理キー へのアクセス権も付与しています。しかし、AWS 管理キー へのアクセス権は直接的な資格情報のアクセスには必要ありません。
- さらに、アプリケーションアカウント内でリソースベースのポリシーを設定してアクセス権を付与する方法は、Secrets Manager での資格情報管理に関しては適切でない可能性があります。ポリシーでのアクセス設定には他の方法（例：IAMロールの引き受け）がより適切です。
- この方法も要件に合致していません。
D. DBA アカウント内で DBA-Admin という名前の IAM ロールを作成し、ロールにアプリケーションアカウント内の資格情報へのアクセス権を付与します。
- このアプローチでは SCP（サービスコントロールポリシー）を使ってアプリケーションアカウントからのアクセスを許可しようとしています。SCPは、AWS Organizationsでアカウントに適用されるポリシーですが、Secrets Managerの資格情報アクセスに関してはこの方法が最適ではありません。
- SCPは、特にリソースアクセスを制限または許可するためには使用しません。
- この方法は要件に適していません。
結論:
最も適切な選択肢は B です。IAMロールの引き受けによって、アプリケーションアカウントとDBAアカウント間で資格情報を安全に共有できるため、手動での共有を回避できます。
132-SCP
理論
1. AWS Organizationsの利用
AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。組織単位（OU）やサービスコントロールポリシー（SCP）を使用して、リソースやアカウントに対するアクセス制御を効率的に管理できます。AWS Organizationsを使用すると、異なる部門やプロジェクトごとにアカウントを分け、それぞれに異なる制限をかけることが可能です。
2. サービスコントロールポリシー（SCP）
SCPは、AWS Organizations内でアカウントやOUに適用できるポリシーです。SCPは、各アカウントが実行できるアクションを制御します。これにより、組織全体で統一的なセキュリティポリシーやリソース制限を設定できます。例えば、リージョン制限やインスタンスタイプ制限などが可能です。
リージョン制限:
SCPで
aws:RequestedRegionを使用して、特定のリージョンへのアクセスを制限できます。この条件は、リソースがどのリージョンに展開されるかを制御する際に非常に重要です。例えば、ap-northeast-1リージョンにリソースを集中させる場合、他のリージョンへのアクセスをブロックすることができます。インスタンスタイプ制限:
EC2インスタンスのインスタンスタイプを制限するためには、
ec2:InstanceType条件キーを使用します。これにより、指定したインスタンスタイプのみが許可され、他のタイプのインスタンスの作成がブロックされます。この制限は、コスト管理や性能要件を遵守するために有効です。3. インラインポリシーとIAMロール
IAMポリシーは、特定のリソースやアクションに対するアクセス権限を設定するために使用されます。IAMロールは、他のアカウントやサービスが特定のリソースにアクセスするために使います。インラインポリシーは、IAMロールやIAMユーザーに直接付与するポリシーで、特定の条件（例えば、インスタンスタイプやリージョン）を基にアクセス制限を行います。
4. 実行時のアクセス制御のベストプラクティス
- リージョン制限：複数のリージョンにまたがるリソース展開を防ぐために、リージョン制限をSCPやIAMポリシーで強制します。これにより、規制要件を遵守し、コンプライアンスを確保できます。
- インスタンスタイプ制限：特定のインスタンスタイプの使用を制限することで、コスト管理やパフォーマンス要件を満たすインスタンスのみを展開できます。この制限をIAMロールやSCPで適用することが推奨されます。
5. 運用効率とメンテナンスの最小化
AWS OrganizationsとSCPを活用することで、組織全体で一貫した制限を簡単に適用できます。また、IAMロールやインラインポリシーを適切に使用することで、細かい制御を各アカウントやOUに対して実施できます。これにより、運用の効率が向上し、手動によるメンテナンスの負担を最小限に抑えることができます。
まとめ
AWS Organizationsを利用して、SCPを適用することで、組織内のアカウントやOUに対して効率的に制限をかけ、運用効率を向上させることができます。リージョンやインスタンスタイプの制限を適切に設定することは、規制遵守やコスト管理、パフォーマンス最適化に重要な要素となります。
一問道場
問題 #132
トピック 1
ある会社は、AWS Organizationsを使用して複数のAWSアカウントを管理しています。ルートOUの下に、ResearchとDataOpsという2つのOUがあります。規制要件により、会社が組織で展開するすべてのリソースは、ap-northeast-1リージョンに配置する必要があります。さらに、DataOps OUで展開されるEC2インスタンスは、あらかじめ定義されたインスタンスタイプのリストを使用する必要があります。
ソリューションアーキテクトは、これらの制限を適用するソリューションを実装する必要があります。ソリューションは、運用効率を最大化し、継続的なメンテナンスを最小限に抑える必要があります。
この要件を満たす手順の組み合わせはどれですか？（2つ選んでください。）
A. DataOps OUの1つのアカウントにIAMロールを作成します。インラインポリシーでec2:InstanceType条件キーを使用し、特定のインスタンスタイプへのアクセスを制限します。
B. ルートOUのすべてのアカウントにIAMユーザーを作成します。各ユーザーにインラインポリシーでaws:RequestedRegion条件キーを使用し、ap-northeast-1以外のすべてのAWSリージョンへのアクセスを制限します。
C. SCPを作成します。aws:RequestedRegion条件キーを使用して、ap-northeast-1以外のすべてのAWSリージョンへのアクセスを制限します。このSCPをルートOUに適用します。
D. SCPを作成します。ec2:Region条件キーを使用して、ap-northeast-1以外のすべてのAWSリージョンへのアクセスを制限します。このSCPをルートOU、DataOps OU、Research OUに適用します。
E. SCPを作成します。ec2:InstanceType条件キーを使用して、特定のインスタンスタイプへのアクセスを制限します。このSCPをDataOps OUに適用します。
解説
この問題では、複数の制限をAWS Organizationsで適用する方法を問うものです。解説は以下の通りです。
- リージョン制限:
aws:RequestedRegion条件キーを使用することで、特定のリージョン（この場合はap-northeast-1）以外のリージョンへのアクセスを制限できます。- CとDがリージョン制限を適用する選択肢です。CはルートOUに適用し、DはルートOU、DataOps OU、Research OU全体に適用する方法です。両者ともリージョン制限を強制しますが、Dは範囲を広げているため、より包括的です。
- インスタンスタイプ制限:
- EC2インスタンスに対して特定のインスタンスタイプを制限する場合、
ec2:InstanceType条件キーを使います。 - Eがこの条件を適用する選択肢で、DataOps OUに対してインスタンスタイプを制限します。
まとめ：
- C（リージョン制限、ルートOU）とE（インスタンスタイプ制限、DataOps OU）を選ぶことで、要求されている制限を最大限に効率よく適用できます。
133-地域ごとにURLでメタデータを抽出
理論
企業は、外部ウェブサイトのURLを処理して、地域ごとの表示差異（例：言語、通貨）を比較したいと考えています。目的は、異なるAWSリージョン（例：東京とバージニア）でURLを処理し、その結果を1つのS3バケットに保存することです。
実装方法：
- SNSでURLを公開し、複数のリージョンのSQSキューに送信。
- 各リージョンにLambda関数をデプロイし、SQSからURLを処理。
- 結果はすべて同じS3バケットに保存。
これにより、地域ごとのローカライズ差異を比較し、結果を集中管理できます。
一問道場
質問 #133
トピック 1
ある会社は、単一のAWSリージョンでサーバーレスアプリケーションを実行しています。このアプリケーションは外部URLにアクセスし、サイトからメタデータを抽出します。会社は、URLをAmazon Simple Queue Service（Amazon SQS）キューに公開するために、Amazon Simple Notification Service（Amazon SNS）トピックを使用しています。AWS Lambda関数は、キューをイベントソースとして使用し、キューからURLを処理します。結果はAmazon S3バケットに保存されます。
会社は、各URLを他のリージョンで処理し、サイトのローカリゼーションの違いを比較したいと考えています。URLは既存のリージョンから公開する必要があります。結果は現在のリージョンのS3バケットに書き込まれる必要があります。
この要件を満たすために、どの変更の組み合わせを行うべきですか？（2つ選んでください。）
A. SQSキューとLambda関数を他のリージョンに展開する。
B. 各リージョンでSNSトピックをSQSキューにサブスクライブする。
C. 各リージョンでSQSキューをSNSトピックにサブスクライブする。
D. SQSキューを設定して、URLを各リージョンのSNSトピックに公開する。
E. SNSトピックとLambda関数を他のリージョンに展開する。
解説
この問題では、会社がURLを他のリージョンで処理し、サイトのローカリゼーションの違いを比較する必要があります。URLは既存のリージョンから公開され、結果はそのリージョンのS3バケットに保存するという要件です。
要件を満たすためには、以下の2つの変更が必要です：
- C. 各リージョンでSQSキューをSNSトピックにサブスクライブする
SNSトピックからURLを各リージョンのSQSキューに配信する必要があるため、SQSキューをSNSトピックにサブスクライブする必要があります。
- E. SNSトピックとLambda関数を他のリージョンに展開する
Lambda関数はSQSキューからURLを処理するため、他のリージョンに展開してURLを処理する必要があります。これにより、各リージョンで処理が行われ、結果が同じS3バケットに書き込まれます。
これにより、複数のリージョンでURLを処理し、結果を1つのS3バケットに統合できます。
134-AWS Fargate
理論
1. AWS Lambdaとその制約
AWS Lambdaはサーバーレスコンピューティングサービスで、コードを実行するためにインフラを管理する必要がありません。Lambdaは、短期間のタスクに非常に適しており、最大15分の実行時間制限があります。したがって、実行時間が20分に及ぶアプリケーションには不向きです。Lambdaの主な利点は、リソースのスケーリングが自動的に行われること、つまり高トラフィックや多くのリクエストにも柔軟に対応できる点です。
適用ケース
- ショートライフサイクルの処理（例：データの変換や小規模なAPI呼び出し）。
- イベントドリブンなアプリケーション（例：SNSトピックやS3バケットの変更をトリガーにする処理）。
2. AWS Batchとバッチ処理
AWS Batchは、大規模なバッチ処理を管理するためのサービスで、特に長時間の計算集約的なジョブに適しています。AWS Batchでは、コンピュータリソース（EC2インスタンスやFargate）を動的にスケールし、バッチジョブの管理を行います。ただし、非常に軽量で短期間の実行が要求されるアプリケーションに対しては、AWS Batchはオーバーヘッドが大きく、コストがかさむ可能性があります。
適用ケース
- 高度な計算リソースを必要とするジョブ（例：シミュレーションやデータ分析）。
- 定期的なバッチジョブ（例：データベースのバックアップやデータ集計）。
3. AWS Fargateとコンテナ化アプリケーション
AWS Fargateは、コンテナ化されたアプリケーションをサーバーレスで実行するためのサービスです。Fargateは、コンテナの管理やインフラの設定なしで、アプリケーションをスケーラブルに実行できます。シングルスレッドのCPU集中的なアプリケーションには最適で、リソース（CPUやメモリ）を細かく指定して実行できます。また、Amazon EventBridgeを使用して、指定したスケジュールでコンテナを起動することができます。
適用ケース
- 短時間でのコンテナ実行（例：軽量なETLジョブやAPIバックエンド）。
- イベント駆動型のタスク（例：定期的なジョブ実行や通知処理）。
4. EC2スポットインスタンスとコスト効率
Amazon EC2スポットインスタンスは、余剰容量を利用して提供されるインスタンスです。通常のオンデマンドインスタンスよりもコストが安く、長期間の計算処理を行うのに最適ですが、インスタンスは予告なく停止する可能性があるため、信頼性が低くなります。特に高い可用性や一貫性が求められるアプリケーションには不向きです。
適用ケース
- コストを最適化したいが、ジョブが停止しても問題ない場合（例：バックグラウンドの非重要な計算）。
- 高い可用性が不要な長時間実行するバッチ処理。
5. Amazon EventBridge（CloudWatch Events）によるスケジューリング
Amazon EventBridge（旧CloudWatch Events）は、AWSサービスを使ったイベントドリブンアーキテクチャの構築を簡単にするサービスです。スケジュールされたタスクを設定することで、定期的にアクションを実行できます。例えば、FargateタスクやLambda関数を4時間ごとに起動することができます。
適用ケース
- 定期的なタスクの実行（例：データ転送、ETL処理）。
- イベントに基づくトリガー（例：特定の時間やAWSリソースの変更に応じたアクション）。
ETL処理
ETL処理とは、Extract（抽出）、Transform（変換）、Load（ロード） の3つのプロセスから成るデータ処理の一連の流れを指します。主に、異なるソースからのデータを統合し、分析や報告のために整形してデータベースやデータウェアハウスにロードするために使用されます。ETL処理は、データウェアハウスやデータ分析システムの構築において重要な役割を果たします。
一問道場
質問 #134
トピック 1
ある会社は、Amazon EC2 Linuxインスタンス上でプロプライエタリなステートレスETLアプリケーションを実行しています。このアプリケーションはLinuxバイナリで、ソースコードは変更できません。アプリケーションはシングルスレッドで、2GBのRAMを使用し、CPU集中的です。アプリケーションは4時間ごとに実行され、最大20分間実行されます。ソリューションアーキテクトは、ソリューションのアーキテクチャを見直したいと考えています。
ソリューションアーキテクトはどの戦略を使用すべきですか？
A. AWS Lambdaを使用してアプリケーションを実行します。Amazon CloudWatch Logsを使用してLambda関数を4時間ごとに呼び出します。
B. AWS Batchを使用してアプリケーションを実行します。AWS Step Functionsステートマシンを使用して、AWS Batchジョブを4時間ごとに呼び出します。
C. AWS Fargateを使用してアプリケーションを実行します。Amazon EventBridge（Amazon CloudWatch Events）を使用してFargateタスクを4時間ごとに呼び出します。
D. Amazon EC2スポットインスタンスを使用してアプリケーションを実行します。AWS CodeDeployを使用して、4時間ごとにアプリケーションをデプロイして実行します。
解説
この質問では、あるETLアプリケーションの実行環境を最適化するために、適切なAWSサービスを選択する必要があります。アプリケーションの特徴としては、シングルスレッドでCPU集中的な処理を行い、2GBのRAMを使用し、最大20分間の実行時間を持つことが挙げられます。また、4時間ごとに実行されるという条件も重要です。
各選択肢を評価してみましょう。
A. AWS Lambdaを使用してアプリケーションを実行します。Amazon CloudWatch Logsを使用してLambda関数を4時間ごとに呼び出します。
- 問題点: AWS Lambdaは短期間のタスクを処理するのに適しており、最大実行時間が15分に制限されています。このアプリケーションは最大20分間実行されるため、Lambdaでは処理できません。このため、この選択肢は適切ではありません。
B. AWS Batchを使用してアプリケーションを実行します。AWS Step Functionsステートマシンを使用して、AWS Batchジョブを4時間ごとに呼び出します。
- 問題点: AWS Batchはバッチ処理に適したサービスであり、長時間の実行やリソース管理に適しています。しかし、このアプリケーションは非常に軽量で、最大20分間の処理時間のため、AWS Batchのオーバーヘッドを引き起こす可能性があり、コストやパフォーマンス面で効率的とは言えません。このため、最適な選択肢ではありません。
C. AWS Fargateを使用してアプリケーションを実行します。Amazon EventBridge（Amazon CloudWatch Events）を使用してFargateタスクを4時間ごとに呼び出します。
- 適切な選択肢: AWS Fargateは、コンテナ化されたアプリケーションをサーバーレスで実行するためのサービスです。シングルスレッドのアプリケーションであっても、Fargateは適切にリソースを管理できます。また、4時間ごとに実行するためのスケジューリングを、Amazon EventBridge（以前のCloudWatch Events）で行うことができます。これにより、アプリケーションを効率的に実行することができます。
D. Amazon EC2スポットインスタンスを使用してアプリケーションを実行します。AWS CodeDeployを使用して、4時間ごとにアプリケーションをデプロイして実行します。
- 問題点: EC2スポットインスタンスはコスト効率的ですが、突然停止する可能性があり、信頼性が低くなります。さらに、CodeDeployを使用して4時間ごとにデプロイするのは過剰な管理を必要とし、他の方法に比べて手間がかかります。このため、Fargateの方がより簡単で効率的です。
結論:
最適な選択肢は C です。AWS Fargateを使用してアプリケーションを実行し、Amazon EventBridgeを使用してスケジュールされたタスクを効率的に実行する方法が、最も適しています。FargateはシングルスレッドでCPU集中的なアプリケーションに適しており、リソース管理が簡単で、スケジュール設定も容易です。
135-オンラインゲームマルチリジョン
理論
ゲームアセットとは、ゲーム内で使用されるすべてのコンテンツやリソースのことを指します。これには、以下のようなものが含まれます：
- グラフィックス: キャラクター、背景、アイテムなどの画像やアニメーション。
- 音楽と効果音: ゲーム内の音楽、効果音、キャラクターのセリフなど。
- 3Dモデル: ゲーム内で使用される3Dオブジェクトやキャラクターのデータ。
- テキスト: ゲーム内のストーリー、ダイアログ、メニュー項目など。
- ゲームのコードやスクリプト: ゲームの動作を決定するプログラムコード。
これらのゲームアセットは、ゲームのグラフィックや動作に直接影響を与え、プレイヤーにゲームの体験を提供します。オンラインゲームでは、これらのアセットがしばしば**クラウドストレージ（例: S3バケット）**に保存され、インターネットを介してユーザーに提供されます。
マルチリージョンアーキテクチャとその設計原則です。以下はその主要なポイントです：
1. マルチリージョンアーキテクチャの利点:
- 可用性: 障害が発生した際に、他のリージョンでサービスを維持できるため、システムの可用性が向上します。
- レイテンシの削減: ユーザーに最寄りのリージョンからデータを配信することで、アクセス速度が向上します。
- 冗長性: データを複数のリージョンに分散させることで、災害や障害があってもデータ損失を防ぎます。
2. Amazon S3 クロスリージョンレプリケーション (CRR):
- 複数のリージョンにデータを自動的にレプリケートする機能です。これにより、グローバルに分散されたユーザーに対して、低レイテンシでデータを提供できます。
3. CloudFront とオリジンフェイルオーバー:
- Amazon CloudFront は、グローバルCDNサービスとして、コンテンツ配信の速度を加速します。
- オリジンフェイルオーバー機能により、1つのオリジンサーバーがダウンした場合でも、他のリージョンから自動的にデータが提供されるため、サービスの継続性が保証されます。
4. DynamoDB グローバルテーブル:
- DynamoDB グローバルテーブルは、複数のリージョンでデータを同期し、高可用性とデータの一貫性を保ちます。これにより、ユーザーがどのリージョンにいても同じデータにアクセスできます。
結論：
マルチリージョンアーキテクチャは、グローバルなスケールで高可用性、低レイテンシ、データの冗長性を実現するための重要な設計原則です。S3 クロスリージョンレプリケーション、CloudFront のオリジンフェイルオーバー、DynamoDB グローバルテーブルなどの技術を組み合わせることで、堅牢で信頼性の高いシステムを構築できます。
一問道場
質問 #135
トピック 1
ある会社が、人気のオンラインゲームの続編を作成しています。ゲームのローンチ後の最初の1週間で、世界中の多くのユーザーがゲームをプレイする予定です。現在、ゲームは以下のコンポーネントが単一のAWSリージョンにデプロイされています：
- ゲームアセットを保存する Amazon S3 バケット
- プレイヤーのスコアを保存する Amazon DynamoDB テーブル
ソリューションアーキテクトは、レイテンシを削減し、信頼性を向上させ、実装の手間を最小限に抑えるための マルチリージョンソリューションを設計する必要があります。
ソリューションアーキテクトは、どのように設計するべきですか？
A. Amazon CloudFront ディストリビューションを作成して、S3バケットからアセットを配信します。S3の クロスリージョンレプリケーションを設定します。新しいリージョンに新しい DynamoDB テーブル を作成し、そのテーブルを DynamoDB グローバルテーブル のレプリカターゲットとして使用します。
B. Amazon CloudFront ディストリビューションを作成して、S3バケットからアセットを配信します。S3の 同一リージョンレプリケーション を設定します。新しいリージョンに新しい DynamoDB テーブル を作成し、AWS DMS（AWSデータベース移行サービス）を使って、DynamoDBテーブル間で非同期レプリケーションを構成します。 変更データキャプチャ（CDC） を使用します。
C. 新しいリージョンに 別のS3バケット を作成し、バケット間で S3クロスリージョンレプリケーション を設定します。Amazon CloudFront ディストリビューションを作成し、オリジンフェイルオーバー を設定して、2つのオリジンからそれぞれのリージョンにあるS3バケットにアクセスできるようにします。DynamoDB グローバルテーブル を設定し、Amazon DynamoDB Streams を有効にして、新しいリージョンのレプリカテーブル を追加します。
D. 同じリージョンに 別のS3バケット を作成し、バケット間で S3同一リージョンレプリケーション を設定します。Amazon CloudFront ディストリビューションを作成し、オリジンフェイルオーバー を設定して、2つのオリジンからそれぞれのS3バケットにアクセスできるようにします。新しいリージョンに新しい DynamoDB テーブル を作成し、そのテーブルを DynamoDB グローバルテーブル のレプリカターゲットとして使用します。
解説
正解は C です。
理由：
C の設計は、マルチリージョンソリューションの要件を最も適切に満たしており、以下の理由から最適です。
- S3 クロスリージョンレプリケーション (CRR): ゲームアセットが複数のリージョンにレプリケートされ、ユーザーがどのリージョンからでも素早くアセットにアクセスできるようになります。
- オリジンフェイルオーバー: CloudFront のオリジンフェイルオーバー機能を使用して、1つのリージョンで障害が発生した場合に、別のリージョンからコンテンツが提供されるようになります。これにより、信頼性と可用性が向上します。
- DynamoDB グローバルテーブル: プレイヤーのスコアを複数のリージョンで同期し、データの一貫性と可用性を保ちながら、ユーザーがどのリージョンからでもアクセスできるようにします。
他の選択肢：
- A もマルチリージョンソリューションですが、オリジンフェイルオーバーが含まれていないため、冗長性が少し欠けるといえます。
したがって、C が最も適切で正解です。
136-Amazon DocumentDB
理論
DocumentDBとMongoDBの違い
DocumentDBは、AWSが提供する完全マネージド型のドキュメントデータベースで、MongoDB互換のAPIを提供します。スキーマレスでJSON形式のデータを格納し、パフォーマンス、スケーラビリティ、可用性に優れた環境を提供します。自動的なストレージ拡張や高可用性、データリカバリ機能が特徴です。また、Amazon DocumentDBは、MongoDB 3.6および4.0との互換性を持ち、アプリケーションの移行を容易にします。
一方、MongoDBはNoSQLドキュメント指向データベースで、高速なデータ処理やシャーディング、レプリカセットによる負荷分散、冗長化が可能です。JSONに似た形式でデータを扱い、外部システムとの連携が簡単です。
主な違い
- API互換性：DocumentDBはMongoDBと互換性があり、AWSのマネージドサービスで運用されます。MongoDBは一般的に自前で管理されます。
- ストレージエンジン：DocumentDBは独自のエンジンを採用し、MongoDBはWiredTigerエンジンを使用します。
- バックアップ：DocumentDBはRDSと同様に簡単にバックアップが可能で、ポイントインタイムリカバリをサポートします。MongoDBは専用ツールや手動によるバックアップが必要です。
まとめ
両者の主な違いはストレージエンジンとクラスタアーキテクチャであり、運用面で異なる影響を及ぼします。互換性を活かして、それぞれの特性に最適な活用方法を選ぶことが重要です。
オンデマンドキャパシティモードとは
オンデマンドキャパシティモードは、Amazon Web Services (AWS) のデータベースサービス、特に Amazon DocumentDB や Amazon DynamoDB などのサービスで利用できるキャパシティモードの一つです。このモードでは、リソースのスケーリングや管理をAWSが自動で行い、アプリケーションが要求する容量に合わせて処理能力を自動的に調整します。
具体的には、オンデマンドキャパシティモードでは、事前にプロビジョニングを行う必要がなく、リクエストに基づいて自動的にスケールイン・スケールアウトします。これにより、負荷の変動が激しい場合でも柔軟に対応でき、容量の過不足を気にすることなく運用することができます。特にトラフィックが予測できない、または急激に変動するアプリケーションに適しています。
主な特徴:
- スケーラビリティ: システムがトラフィックの増減に応じて自動的にスケーリングするため、事前に容量を設定する必要がない。
- コスト効率: 実際に使った分だけ支払うモデルなので、無駄なコストを削減できる。
- 簡単な管理: 管理者は容量のプロビジョニングや調整を行う必要がなく、AWSがリソースを自動で最適化。
他のキャパシティモード:
- プロビジョンドキャパシティモード: 使用するリソース量を事前に設定するモード。安定したトラフィックが見込まれる場合に最適で、リソースのオーバープロビジョニングを防ぐために調整が必要。
- サーバーレスモード（DynamoDBの場合）: ユーザーがリソースを管理することなく、アプリケーションがリクエストに応じて必要な容量を自動的にスケーリングできるモード。
一問道場
質問 #136
トピック 1
ある会社が、賃貸希望者や購入希望者向けに不動産情報を提供するオンプレミスのウェブサイトアプリケーションを運用しています。このウェブサイトは、JavaバックエンドとNoSQLのMongoDBデータベースを使用して、購読者データを保存しています。
会社は、このアプリケーション全体をAWSに移行する必要があり、同様の構成を維持したいと考えています。アプリケーションは高可用性でデプロイする必要があり、アプリケーションに変更を加えることはできません。
どのソリューションがこれらの要件を満たしますか？
A. 購読者データのデータベースとしてAmazon Aurora DBクラスターを使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。
B. 購読者データのデータベースとしてAmazon EC2インスタンス上のMongoDBを使用し、Javaバックエンドアプリケーション用に、単一のアベイラビリティゾーン内のAuto ScalingグループでEC2インスタンスをデプロイします。
C. 購読者データのデータベースとして、適切にサイズ設定されたインスタンスで複数のアベイラビリティゾーンに展開されたAmazon DocumentDB（MongoDB互換）を使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。
D. 購読者データのデータベースとして、オンデマンドキャパシティモードで複数のアベイラビリティゾーンに展開されたAmazon DocumentDB（MongoDB互換）を使用し、Javaバックエンドアプリケーション用に、複数のアベイラビリティゾーンにまたがるAuto ScalingグループでAmazon EC2インスタンスをデプロイします。
解説
この問題の解説を行います。
問題概要
会社が提供している不動産情報を扱うウェブサイトアプリケーションが、JavaバックエンドとNoSQLのMongoDBデータベースを使用しています。現在、アプリケーションはオンプレミス環境で運用されていますが、AWSに移行する必要があります。移行後は、高可用性を確保する必要があり、アプリケーションに変更を加えることはできません。
選択肢の検討
A. Amazon Aurora DBクラスターを使用して、JavaバックエンドアプリケーションのためにAuto Scalingグループを複数のアベイラビリティゾーンに展開する。
- 問題点: Amazon Auroraはリレーショナルデータベースであり、MongoDBのようなNoSQLデータベースとは異なります。問題の要件にはMongoDB互換性が必要ですが、AuroraはNoSQLに対応していません。そのため、この選択肢は適していません。
B. MongoDBをAmazon EC2インスタンスで使用し、JavaバックエンドアプリケーションのためにAuto Scalingグループを単一のアベイラビリティゾーンで展開する。
- 問題点: MongoDBをEC2インスタンスで使用することは可能ですが、アベイラビリティゾーンが1つだけの場合、高可用性を確保することができません。この問題では「高可用性」が求められているため、この選択肢も適していません。
C. Amazon DocumentDB（MongoDB互換）を使用し、複数のアベイラビリティゾーンにインスタンスを配置して、JavaバックエンドアプリケーションのためにAuto Scalingグループを展開する。
- 正解: Amazon DocumentDBはMongoDBと互換性があり、高可用性を提供するマネージドサービスです。複数のアベイラビリティゾーンにインスタンスを配置することによって、高可用性を確保できます。また、AWSが自動的にスケーリングを管理し、バックエンドアプリケーションを高可用性で運用できるため、この選択肢は要件に合致します。
D. Amazon DocumentDB（MongoDB互換）をオンデマンドキャパシティモードで使用し、複数のアベイラビリティゾーンにインスタンスを配置して、JavaバックエンドアプリケーションのためにAuto Scalingグループを展開する。
- 問題点: オンデマンドキャパシティモードは、通常、トラフィックの予測が難しい場合や、使用量が不規則な場合に有効ですが、この場合のアプリケーションは明確に定義されたワークロードを持っている可能性が高いです。また、オンデマンドキャパシティモードは負荷が急激に増加した際にスケールできる一方で、コスト管理が難しくなることがあります。したがって、この選択肢はやや過剰なリソース管理のアプローチかもしれません。
結論
C が最適な選択肢です。Amazon DocumentDBはMongoDB互換であり、複数のアベイラビリティゾーンに展開することで高可用性を確保できます。
137-アカウント間 暗号化S3 共有
理論
アカウント間で暗号化されたS3バケットへのアクセス方法
異なるAWSアカウント間で、暗号化されたS3バケットにアクセスするためには、適切な設定が必要です。以下の2つのポリシー設定を行うことで、他のアカウントのユーザーに必要なアクセス権を付与できます。
- KMSキーのポリシーと対キーIAMロールの設定:
- カスタムAWS Key Management Service（KMS）キーのポリシーを設定し、他のアカウントのIAMロールに復号（decrypt）権限を付与する必要があります。この設定により、戦略アカウントのユーザーが暗号化されたS3オブジェクトを復号してアクセスできるようになります。
- S3バケットポリシーと対バケットIAMロールの設定:
- S3バケットのポリシーで、読み取り（read）権限を戦略アカウントのIAMロールに付与します。これにより、戦略アカウントのユーザーはS3バケット内のオブジェクトにアクセスできるようになります。
これらの設定が行われていない場合、戦略アカウントのユーザーはAccess Deniedエラーを受け取ることになります。S3バケットのアクセス権とKMSキーの復号権限を適切に設定することで、他のアカウント間で安全にデータを共有できます。
一問道場
問題#137
トピック1
あるデジタルマーケティング会社には、さまざまなチームに属する複数のAWSアカウントがあります。クリエイティブチームは、会社のマーケティングキャンペーン用のコンテンツとして使用する画像やメディアファイルを安全に保存するために、自分たちのAWSアカウントでAmazon S3バケットを使用しています。クリエイティブチームは、戦略チームがS3バケットのオブジェクトを表示できるように、S3バケットを戦略チームと共有したいと考えています。
ソリューションアーキテクトは、戦略アカウントに「strategy_reviewer」というIAMロールを作成しました。さらに、クリエイティブアカウントでカスタムAWS Key Management Service（AWS KMS）キーを設定し、そのキーをS3バケットに関連付けました。しかし、戦略アカウントのユーザーがIAMロールを引き受けてS3バケットのオブジェクトにアクセスしようとすると、「Access Denied（アクセス拒否）」エラーが表示されます。
ソリューションアーキテクトは、戦略アカウントのユーザーがS3バケットにアクセスできるようにする必要があります。ソリューションは、これらのユーザーに最小限の権限のみを付与する必要があります。
これらの要件を満たすために、ソリューションアーキテクトが実施すべきステップの組み合わせはどれですか？（3つ選んでください。）
A. S3バケットに対する読み取り権限を含むバケットポリシーを作成します。バケットポリシーのプリンシパルを戦略アカウントのアカウントIDに設定します。
B. strategy_reviewer IAMロールを更新して、S3バケットへのフルアクセス権限と、カスタムKMSキーに対する復号権限を付与します。
C. クリエイティブアカウントのカスタムKMSキーのポリシーを更新して、strategy_reviewer IAMロールに復号権限を付与します。
D. S3バケットに対する読み取り権限を含むバケットポリシーを作成します。バケットポリシーのプリンシパルを匿名ユーザーに設定します。
E. クリエイティブアカウントのカスタムKMSキーのポリシーを更新して、strategy_reviewer IAMロールに暗号化権限を付与します。
F. strategy_reviewer IAMロールを更新して、S3バケットへの読み取り権限と、カスタムKMSキーに対する復号権限を付与します。
解説
この問題は、異なるAWSアカウント間でS3バケットとKMSキーを共有する際に適切な権限を設定する方法に関するものです。
解決策として以下のステップを取る必要があります：
- A: 戦略アカウントがS3バケットにアクセスできるようにするために、バケットポリシーに読み取り権限を追加します。プリンシパルは戦略アカウントのアカウントIDです。
- C: クリエイティブアカウントで使用されているカスタムKMSキーに対し、戦略アカウントのIAMロールに復号権限を付与します。これにより、戦略アカウントのユーザーが暗号化されたオブジェクトを復号できます。
- F: IAMロール自体にS3バケットへの読み取り権限とKMSキーの復号権限を付与します。
選ばれない理由：
- BやEは、必要以上の権限（例えば、暗号化やフルアクセス権限）を付与してしまうため、最小権限の原則に反します。
- Dは、匿名ユーザーにアクセス権を与えてしまうため不適切です。
138-クラウドへデータ転送
理論
SAN（Storage Area Network）とは、複数のサーバーとストレージデバイス（例：ハードディスク、テープライブラリなど）を接続する専用の高速ネットワークのことです。SANは、ストレージリソースをネットワーク越しにサーバーに提供するため、各サーバーは直接接続されたローカルディスクを使用するような感覚で、リモートストレージを利用できます。
SANの主な特徴は次の通りです：
- 高速なデータ転送：SANは、通常、Fibre ChannelやiSCSIなどの高速プロトコルを使用してデータを転送します。
- 拡張性：複数のサーバーが共有するストレージリソースを提供するため、大規模なシステムで効率的に利用できます。
- データ管理の効率化：ストレージを集中管理できるため、バックアップやリカバリ、データのスナップショットなどの管理が効率的に行えます。
SANは、特に大規模なデータセンターやストレージを大量に扱う環境（例えば、ビッグデータ解析やデータベース）で使用されることが多いです。
1. データ転送とオンプレミスからのクラウド移行
- AWS DataSync: AWS DataSyncは、オンプレミスのデータセンターやネットワークアタッチドストレージ（NAS）からAWSへのデータ転送を効率化するサービスです。高速で安全な転送を可能にし、大量のデータをAWSにシームレスに移行する際に役立ちます。DataSyncは、バッチ処理や定期的なデータ移行を簡単に自動化できるため、特に大容量のデータ転送が必要な場合に効果的です。
- AWS Snowball: AWS Snowballは、データセンターからクラウドへの大量のデータ転送を物理的にサポートするサービスです。特に大容量のデータ（数百TB単位）を移行する際に有効です。ただし、Snowballはデータ転送後の処理の自動化に関してはLambdaなどとの連携が必要です。
- AWS Storage Gateway: Storage Gatewayは、オンプレミスのストレージをクラウドに接続するためのサービスです。ファイルゲートウェイ、テープゲートウェイ、ボリュームゲートウェイといった異なるゲートウェイタイプを使い分けることで、データ転送だけでなく、バックアップやアーカイブの管理も行えます。
2. コンテナ技術とスケーラブルなデータ処理
- Amazon Elastic Container Registry (Amazon ECR): Dockerイメージを格納するための完全マネージド型のコンテナレジストリサービスです。これを使用することで、DockerコンテナをAWS上で効率的に管理し、異なるサービスで実行できます。Genomicsデータの処理には、大規模で計算負荷が高いため、コンテナ技術はスケーラブルなリソース提供に有効です。
- AWS Batch: AWS Batchは、バッチ処理をスケーラブルに実行するためのサービスです。大量のデータを並列で処理するために、コンテナ化されたジョブを効率的に実行できます。これは、遺伝子解析や他のバイオインフォマティクスのように大量の計算資源を必要とするワークロードに最適です。
- Amazon EC2 Auto Scaling: 自動的にEC2インスタンスの数をスケールアップ・スケールダウンする機能で、需要に応じてコンピューティングリソースを柔軟に調整できます。これにより、特定のワークロードのリソース不足を防ぎ、処理能力を確保します。
3. イベント駆動型アーキテクチャとAWS Lambda
- AWS Lambda: AWS Lambdaはサーバーレスコンピューティングサービスで、イベント駆動型の処理を実現できます。S3のオブジェクトがアップロードされた際にトリガーを設定し、Lambda関数を呼び出してデータ処理を開始することが可能です。しかし、大きなデータ処理や計算には向かないため、Lambdaは主に軽量な処理に使用します。
- Amazon S3 イベント: Amazon S3はデータストレージサービスで、オブジェクトがアップロードされた際にイベントをトリガーできます。このイベントにより、LambdaやStep Functions、Batchなどの他のAWSサービスを呼び出すことができます。これにより、データ転送後の処理を自動化できます。
一問道場
質問 #138
トピック 1
あるライフサイエンス企業は、オンプレミスのデータセンターでデータ分析ワークフローを管理するために、オープンソースツールとDockerコンテナを組み合わせて使用しています。シーケンシングデータはローカルのストレージエリアネットワーク（SAN）に生成・保存され、その後データが処理されます。研究開発チームはキャパシティの問題に直面しており、ワークロードの需要に基づいてスケーラブルな新しい遺伝子解析プラットフォームをAWSに再構築し、ターンアラウンドタイムを数週間から数日へと短縮することに決定しました。同社は高速なAWS Direct Connect接続を利用しています。シーケンサーは各ゲノムについて約200GBのデータを生成し、個々のジョブは理想的な計算リソースでデータを処理するのに数時間かかります。最終的な結果はAmazon S3に保存されます。同社は毎日10〜15件のジョブリクエストを予想しています。
どのソリューションがこれらの要件を満たしますか？
A. AWS Snowball Edgeデバイスを定期的に使用して、シーケンシングデータをAWSに転送します。AWSがSnowball Edgeデバイスを受け取ってデータがAmazon S3にロードされると、S3イベントを使用してAWS Lambda関数をトリガーし、データを処理します。
B. AWS Data Pipelineを使用して、シーケンシングデータをAmazon S3に転送します。S3イベントを使用して、Amazon EC2 Auto Scalingグループをトリガーし、カスタムAMIのEC2インスタンスを起動してDockerコンテナを実行し、データを処理します。
C. AWS DataSyncを使用して、シーケンシングデータをAmazon S3に転送します。S3イベントを使用して、AWS Lambda関数がAWS Step Functionsワークフローを開始します。DockerイメージはAmazon Elastic Container Registry（Amazon ECR）に保存し、AWS Batchをトリガーしてコンテナを実行し、シーケンシングデータを処理します。
D. AWS Storage Gatewayのファイルゲートウェイを使用して、シーケンシングデータをAmazon S3に転送します。S3イベントを使用して、AWS Batchジョブをトリガーし、Amazon EC2インスタンス上でDockerコンテナを実行してデータを処理します。
解説
この問題では、ライフサイエンス企業がゲノム解析のワークフローをオンプレミスからAWSに移行し、スケーラブルで効率的なデータ処理を実現したいという要件です。特に、200GBのデータを毎日処理する必要があり、計算リソースのスケーリングが重要です。また、データは最終的にAmazon S3に保存されます。
各選択肢の詳細とその適切性を見ていきましょう。
A: AWS Snowball Edge と Lambda を使用する
- AWS Snowball Edge は、大量のデータをオンプレミスからAWSに転送するための物理デバイスです。しかし、データ転送後にLambda関数を使って処理を始めるという流れは、200GBという大きなデータサイズには適していません。Lambdaは短期間での処理を得意としますが、非常に大きなデータを扱うのには不向きです。したがって、この方法は最適ではありません。
B: AWS Data Pipeline と EC2 Auto Scaling を使用する
- AWS Data Pipeline はデータ転送とデータフローの自動化に使用されますが、EC2 Auto Scalingを使用して、Dockerコンテナを起動する方法は一見適切に見えます。これは、大規模なデータ処理のスケーリングに適しており、ユーザーの要求に応じて動的にスケールすることができます。このアプローチは、問題の要件に合致する可能性が高いです。
C: AWS DataSync と AWS Step Functions を使用する
- AWS DataSync はオンプレミスのデータセンターからAWSにデータを効率的に転送できるサービスです。この方法では、転送後にAWS LambdaがStep Functionsワークフローを開始し、その後、AWS Batchを使ってデータ処理を行います。AWS Batchはコンテナ化されたジョブをスケーラブルに処理できるため、大規模なデータ処理に非常に適しています。さらに、AWS ECRに格納されたDockerコンテナを使って解析を行うため、このアプローチは200GBのデータ処理に適しています。
D: AWS Storage Gateway と AWS Batch を使用する
- AWS Storage Gateway は、オンプレミスのストレージとAWS間のシームレスな統合を提供するサービスですが、AWS Batchを使用する点ではCと似ています。データ転送後、AWS Batchを使ってEC2インスタンス上でコンテナ処理を実行します。AWS Storage Gatewayは、特にSANやNASと統合する際に役立ちますが、AWSに移行するためには他の方法（例えばAWS DataSync）の方が効率的です。
結論
最も適切な解決策は、Cの方法です。AWS DataSyncを使ってデータを迅速に転送し、その後、AWS Step FunctionsとAWS Batchを組み合わせて、Dockerコンテナを使って大規模なデータ処理を行う方法が、スケーラビリティと効率を兼ね備えています。この方法は、要件に最も合致しており、処理時間を短縮することができます。
139-Amazon FSx for Windows File Server
理論
AWSでWindows環境の高可用性と一貫性を実現する設計ガイド
1. 高可用性とフォールトトレランスの基本概念
- 高可用性（High Availability）: システムのダウンタイムを最小限に抑えることを目的とした設計。複数のアベイラビリティゾーン（AZ）にわたるインフラ分散が一般的。
- フォールトトレランス（Fault Tolerance）: システム障害が発生しても、継続して稼働できる仕組み。
AWSでは、これらを実現するために以下の構成要素が活用されます：
- Auto Scaling: 負荷に応じてインスタンスをスケールアウト/スケールイン。
- Elastic Load Balancer（ELB）: トラフィックを複数のインスタンスに分散。
- マルチAZ配置: 災害や障害時の影響を最小限に抑える。
2. Windows環境の要件
Windows特有の要件として、以下の点が重要です：
- Active Directory（AD）との統合:
ADドメインへの参加は、ユーザー認証やアクセス制御において重要。AWSでは、Managed Microsoft ADを活用することで簡単に統合可能。
- Windows ACL（アクセス制御リスト）:
ファイルアクセス制御のため、Windows ACLのサポートが必須。このため、ストレージソリューションはWindows ACLに対応している必要があります。
- ストレージの共有と一貫性:
複数のインスタンス間で同じファイルを共有し、一貫性を保つための仕組みが求められます。
3. AWSのストレージソリューション
AWSは、Windows環境向けにいくつかのストレージオプションを提供しています。要件に応じた選択が必要です。
ストレージサービス | 特徴 | 適用シナリオ |
Amazon EFS | - POSIX互換の共有ファイルシステム- 複数インスタンスでの共有が容易 | Linux向けが主。Windows ACLは非対応 |
Amazon FSx for Windows File Server | - Windows環境専用- Windows ACLおよびAD統合をサポート | Windowsアプリケーション向けの最適な選択肢 |
Amazon FSx for Lustre | - 高スループットと低レイテンシ- 一時的なデータ共有に最適 | HPCやビッグデータ処理向け |
4. シームレスドメイン参加（Seamless Domain Join）
AWSでは、Windowsインスタンスを簡単にActive Directoryに参加させるために「シームレスドメイン参加」を提供しています。この機能を利用することで、管理者の手動作業を最小限に抑えられます。
- 動作概要:
- AWS Systems Managerを活用してEC2インスタンスを構成。
- 起動時にドメイン参加を自動化するスクリプトを実行。
- 利点:
- 一貫した設定を確保。
- 大規模環境でも簡単に展開可能。
5. AWSでの推奨構成
今回の問題に関連する推奨構成例：
- ストレージ: Amazon FSx for Windows File Server
- Windows ACLとAD統合をサポート。
- 複数インスタンス間でファイルの一貫性を確保。
- Auto Scalingグループ:
- 最小サイズ3のインスタンスで高可用性を確保。
- 必要に応じてスケールアウト/スケールイン。
- ELB:
- トラフィック分散で障害時のリカバリーを支援。
- ユーザーデータスクリプト:
- アプリケーションのインストールと構成。
- ADへの自動参加とFSxマウント。
まとめ
AWSでWindows環境を高可用性・一貫性を持つ形で設計するには、適切なストレージ選択（Amazon FSx for Windows File Server）と、自動化ツール（シームレスドメイン参加やユーザーデータスクリプト）を活用することが重要です。これにより、管理負担を軽減しつつ、要求を満たす柔軟なインフラを構築できます。
一問道場
質問 #139
AIに質問する
ある企業が開発環境で、コンテンツ管理アプリケーションを単一のWindows Amazon EC2インスタンス上で実行しています。このアプリケーションは、ルートデバイスとしてインスタンスにアタッチされた2TBのAmazon Elastic Block Store（Amazon EBS）ボリュームに静的コンテンツを読み書きします。
企業は、このアプリケーションを本番環境にデプロイし、複数のアベイラビリティゾーンにまたがる少なくとも3つのEC2インスタンス上で動作する、高可用性かつフォールトトレラントなソリューションとして展開する計画です。
ソリューションアーキテクトは、アクティブディレクトリ（Active Directory）ドメインにアプリケーションを実行するすべてのインスタンスを参加させるソリューションを設計する必要があります。このソリューションでは、ファイルコンテンツへのアクセスを制御するためにWindows ACLを実装する必要があります。また、アプリケーションは常にすべての実行中のインスタンスでまったく同じコンテンツを維持する必要があります。
管理作業を最小限に抑えつつ、これらの要件を満たすソリューションはどれですか？
A.
Amazon Elastic File System（Amazon EFS）ファイル共有を作成します。3つのアベイラビリティゾーンにまたがり、最小サイズが3のAuto Scalingグループを作成します。ユーザーデータスクリプトを実装して、アプリケーションをインストールし、インスタンスをADドメインに参加させ、EFSファイル共有をマウントします。
B.
現在実行中のEC2インスタンスから新しいAMIを作成します。Amazon FSx for Lustreファイルシステムを作成します。3つのアベイラビリティゾーンにまたがり、最小サイズが3のAuto Scalingグループを作成します。ユーザーデータスクリプトを実装して、インスタンスをADドメインに参加させ、FSx for Lustreファイルシステムをマウントします。
C.
Amazon FSx for Windows File Serverファイルシステムを作成します。3つのアベイラビリティゾーンにまたがり、最小サイズが3のAuto Scalingグループを作成します。ユーザーデータスクリプトを実装して、アプリケーションをインストールし、FSx for Windows File Serverファイルシステムをマウントします。シームレスドメイン参加を実行して、インスタンスをADドメインに参加させます。
D.
現在実行中のEC2インスタンスから新しいAMIを作成します。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成します。3つのアベイラビリティゾーンにまたがり、最小サイズが3のAuto Scalingグループを作成します。シームレスドメイン参加を実行して、インスタンスをADドメインに参加させます。
解説
要件の整理
この問題の要件を以下のように整理できます：
- 高可用性: 最低3つのEC2インスタンスを複数のAZに分散して稼働させる。
- ファイル一貫性: すべてのインスタンスで同じファイル内容を常に保持する。
- Active Directory（AD）統合: ドメイン参加が必要。
- Windows ACL: ファイルアクセス制御を実現する必要がある。
- 管理負担の最小化: 可能な限り簡素な構成が求められる。
各選択肢の分析
A. Amazon EFS（Elastic File System）を使用する
- 利点:
- 複数のEC2インスタンス間で共有可能。
- 自動スケーリングで簡単に容量を増減可能。
- 欠点:
- EFSは主にLinux環境向けであり、Windows ACLやAD統合をサポートしない。
- Windows環境の要件（ACLとAD統合）を満たせないため不適切。
B. FSx for Lustreを使用する
- 利点:
- 高スループットでファイル共有が可能。
- データ処理やHPC用途に適している。
- 欠点:
- Windows ACLやAD統合をサポートしない。
- ファイルの永続性よりも一時的なデータ処理が目的であるため、今回の要件には適合しない。
C. FSx for Windows File Serverを使用する（正解）
- 利点:
- Windows専用のファイル共有ソリューションであり、Windows ACLとAD統合をネイティブでサポート。
- ファイルの一貫性を保証し、複数インスタンス間での共有に最適。
- シームレスドメイン参加を利用することで、管理負担を軽減。
- 欠点:
- 他のオプションに比べて初期コストが若干高い。
- ただし、今回の要件を最も効率的に満たすため、正解となる。
D. Amazon EFSを再利用する
- 利点:
- Auto Scalingグループと組み合わせることでスケーラブルな構成が可能。
- 欠点:
- Aと同様、EFSはWindows ACLやAD統合をサポートしない。
- Windows環境の要件を満たせないため不適切。
正解：C. FSx for Windows File Serverを使用する
理由
- Windows ACLとAD統合: Windows ACLをサポートし、ADドメインにシームレスに統合できるのはFSx for Windows File Serverだけです。
- ファイルの一貫性: FSx for Windows File Serverは複数インスタンス間で共有されるファイルの整合性を保証します。
- 管理負担: シームレスドメイン参加やユーザーデータスクリプトを活用することで、自動化された簡素な管理が可能です。
学べるポイント
- 要件とAWSサービスの対応関係を把握: 各AWSサービスの特徴を理解し、要件に適合するものを選ぶ。
- Windows環境特有の要件を意識する: ACLやAD統合など、Linux環境にはない独自の要件を考慮する。
- 管理負担を最小化する設計: 自動化やネイティブな統合機能を活用することで、運用の効率化を図る。
この解説を元に、AWS設計の基礎を深めてください！
140-コスト効率の高いメール送信設計
理論
AWSによるメール送信ソリューションの本質的理解
AWS環境でのメール送信を設計する際、重要なポイントは「運用負荷の削減」「コスト効率」「スケーラビリティ」「柔軟な統合性」です。これらを達成するために、AWSのサービスを正確に理解し、適切に組み合わせることが成功の鍵となります。
1. メール送信の本質的課題
メール送信機能をクラウドに移行する際、以下の課題を解決する必要があります：
- 高可用性と信頼性: メールが確実に送信され、受信者に届く必要がある。
- 運用コストの削減: サーバーの管理や障害対応の負荷を最小限に抑える。
- 柔軟なテンプレート管理: 個別の顧客データを動的に統合して、パーソナライズされたメールを生成。
- 拡張性: メール送信量の増加に対応できるスケーラブルな設計。
AWSでは、これらの課題を解決するために、Amazon SESを中心としたアプローチが推奨されます。
2. Amazon SES: フルマネージドなメール送信サービス
- *Amazon Simple Email Service (SES)**は、AWSが提供する高可用性かつコスト効率の高いメール送信サービスです。
本質的な特徴:
- フルマネージドサービス:
- インフラ管理が不要で、運用負荷を大幅に削減。
- 高可用性と信頼性が組み込まれているため、メール送信失敗のリスクを最小化。
- 柔軟な統合性:
- SMTPインターフェイスまたはAWS SDK/APIを利用して簡単にアプリケーションと統合可能。
- 動的なテンプレート機能:
- メールテンプレートを事前にSESに保存し、顧客データを埋め込むことが可能。
- SendTemplatedEmail APIを使用して、動的なメール送信を簡素化。
- コスト効率:
- 送信量に応じた従量課金制で、他のSMTPサーバー運用に比べて大幅に安価。
3. AWS Lambdaとの連携: パーソナライズされたメールの動的生成
AWS Lambdaを活用することで、SESをさらに強力なメール送信ソリューションに変えることができます。
本質的な役割:
- データ統合: Lambda関数を使用して、外部データベースやS3バケットから顧客データを取得し、メールテンプレートに埋め込む。
- イベント駆動: DynamoDBやS3イベントをトリガーとしてLambda関数を実行し、リアルタイムでメール送信を開始。
- API統合: Lambda関数内でSESのSendTemplatedEmail APIを呼び出し、動的にメール送信。
5. SMTPサーバー運用との比較
AWSにおけるSMTPサーバー（EC2上に構築）とSESの違いを本質的に理解することで、最適な選択が可能です。
項目 | SMTPサーバー（EC2） | Amazon SES |
運用負荷 | 高い: インフラ管理や障害対応が必要 | 低い: フルマネージドでインフラ管理不要 |
コスト | 高い: EC2インスタンス料金が継続的に発生 | 低い: 従量課金制でコスト効率が良い |
スケーラビリティ | 手動でスケールアップが必要 | 自動スケーリングで対応可能 |
テンプレート管理 | 外部システムで管理する必要あり | SES内で直接管理可能 |
6. 最適解の選択: Amazon SES + AWS Lambda
AWSでメール送信機能を構築する際、最もコスト効率が高く、運用負荷が少ないソリューションは次のようなアーキテクチャです：
- Amazon SESをメール送信サービスとして利用。
- Lambdaで顧客データとテンプレートの統合を動的に処理。
- テンプレートをSES内に保存し、動的パラメータを活用して柔軟にパーソナライズされたメールを生成。
まとめ: AWSメール送信ソリューションの本質
AWSでは、Amazon SESを活用することで、コスト効率の高いフルマネージドなメール送信ソリューションを構築できます。LambdaやS3と組み合わせることで、柔軟性とスケーラビリティを持つ設計が可能です。
この知識をもとに、アプリケーションの要件に最適な設計を選択しましょう。
一問道場
質問 #140
Topic 1
ソフトウェア・アズ・ア・サービス（SaaS）ベースの会社が顧客向けにケース管理ソリューションを提供しています。このソリューションの一環として、会社はスタンドアロンのSMTP（Simple Mail Transfer Protocol）サーバーを使用してアプリケーションからメールメッセージを送信しています。また、アプリケーションは、顧客データを埋め込んで送信するための確認メールテンプレートも保存しています。
会社は、このメッセージング機能をAWSクラウドに移行する計画を立てており、運用負荷を最小限に抑えたいと考えています。
この要件を最もコスト効率よく満たすソリューションはどれですか？
選択肢:
A.
AWS MarketplaceのAMIを使用してAmazon EC2インスタンス上にSMTPサーバーを設定する。メールテンプレートをAmazon S3バケットに保存する。AWS Lambda関数を作成して、S3バケットからテンプレートを取得し、アプリケーションからの顧客データをテンプレートに統合する。Lambda関数でSDKを使用してメールメッセージを送信する。
B.
Amazon Simple Email Service（Amazon SES）を設定してメールメッセージを送信する。メールテンプレートをAmazon S3バケットに保存する。AWS Lambda関数を作成して、S3バケットからテンプレートを取得し、アプリケーションからの顧客データをテンプレートに統合する。Lambda関数でSDKを使用してメールメッセージを送信する。
C.
AWS MarketplaceのAMIを使用してAmazon EC2インスタンス上にSMTPサーバーを設定する。メールテンプレートをAmazon Simple Email Service（Amazon SES）に顧客データのパラメータとともに保存する。AWS Lambda関数を作成してSESテンプレートを呼び出し、パラメータに顧客データを渡す。AWS MarketplaceのSMTPサーバーを使用してメールメッセージを送信する。
D.
Amazon Simple Email Service（Amazon SES）を設定してメールメッセージを送信する。メールテンプレートをAmazon SESに顧客データのパラメータとともに保存する。AWS Lambda関数を作成してSendTemplatedEmail API操作を呼び出し、パラメータに顧客データを渡し、メールの宛先を指定する。
正確
問題の解説: AWSでのコスト効率の高いメール送信設計
設問概要
SaaS企業が、現在使用しているスタンドアロンのSMTPサーバーをAWSクラウドに移行したいと考えています。この移行にあたって以下の要件があります：
- メール送信機能をクラウドで実現。
- 顧客データを使用して動的なメールテンプレートを作成。
- 運用負荷を最小限に抑え、コスト効率の高いソリューションを構築。
各選択肢の中から、これらの要件を満たす最適解を選ぶ問題です。
選択肢の分析
選択肢 A
- 内容: AWS MarketplaceのSMTPサーバーをEC2上にセットアップ。テンプレートはS3に保存し、Lambdaで顧客データを統合してメールを送信。
- 欠点:
- SMTPサーバーを運用する必要があるため、インフラ管理の負担が増加。
- EC2インスタンスの運用コストが高くなる。
- SESを利用していないため、AWSのコスト効率の良いメール送信機能を活用できていない。
- 結論: 運用負荷が高く、コスト効率が劣る。
選択肢 B
- 内容: Amazon SESを利用してメール送信。テンプレートはS3に保存し、Lambdaで顧客データを統合してSESを使用して送信。
- 欠点:
- テンプレートがSESに直接保存されておらず、S3からの取得が必要なため、追加の処理が発生。
- テンプレート管理が分散され、運用負荷が増加する可能性。
- 結論: SESの一部機能を活用しているが、テンプレート管理が最適化されていない。
選択肢 C
- 内容: AWS MarketplaceのSMTPサーバーをEC2上にセットアップ。テンプレートはSESに保存し、Lambdaで顧客データをSESに渡してメール送信。
- 欠点:
- EC2でSMTPサーバーを運用するため、インフラ管理負担が発生。
- SESを利用しているが、SMTPサーバー運用の必要性がコスト効率を下げる。
- 結論: 運用負荷が高く、SESを十分に活用していない。
選択肢 D (正解)
- 内容: Amazon SESを利用してメール送信。テンプレートをSES内に保存し、Lambdaを使ってSendTemplatedEmail APIを呼び出して動的メールを送信。
- 利点:
- 運用負荷の削減:
- SESがフルマネージドサービスであり、インフラ管理が不要。
- テンプレート管理がSES内に完結し、運用が簡素化。
- コスト効率:
- SESの従量課金制により、コストが最適化される。
- 柔軟性:
- SendTemplatedEmail APIで顧客データを動的にテンプレートに統合可能。
- Lambdaでトリガーやデータ統合を実現。
- 結論: 最も運用負荷が少なく、コスト効率に優れた解決策。
正解: D
選択理由
選択肢 Dは、以下の理由から問題の要件を最も効率的に満たします：
- 最小限の管理負担: SESはフルマネージドであり、インフラの運用が不要。
- コスト効率: SMTPサーバー運用やEC2インスタンスのコストが発生しない。
- シンプルな設計: テンプレート管理とメール送信がSES内で完結。
- 動的なメール送信: Lambdaを活用して顧客データをSESテンプレートに埋め込み、動的メールを送信可能。
学びのポイント
- Amazon SES:
- AWSのメール送信に特化したコスト効率の高いサービス。
- テンプレート管理や動的メール送信が可能。
- AWS Lambdaとの連携:
- イベント駆動でリアルタイム処理を実現。
- SESとの組み合わせで動的メール生成が簡単。
- フルマネージドサービスの利点:
- 運用負荷を軽減し、アプリケーション開発に集中できる。
これらを理解することで、AWS環境でのメール送信ソリューション設計が効率化できます。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16ed7ae8-88e2-80e2-bb6f-cfe4d19ad6fc
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
