type
status
date
slug
summary
tags
category
icon
password
351-AWS SAP AWS 「理論・実践・一問道場」IAMポリシー
理論
1. IAMポリシーを使用してリソースのアクセス制御を行う
IAMポリシーを使用することで、AWSリソースへのアクセスを細かく制御できます。特にEC2インスタンスの起動に関しては、ポリシーで以下のような制限を設けることができます：
- インスタンスタイプの制限: IAMポリシーを使って、特定のインスタンスタイプ（例えば、t3.small）のみを起動できるように制限することが可能です。
ec2:RunInstancesアクションを使用して、特定のインスタンスタイプに対するアクセスを制限できます。
- リージョンの制限: IAMポリシーには、特定のリージョンに対する制限も設定できます。これにより、開発者がインスタンスを指定されたリージョン（例えば、us-east-2）でのみ起動できるように制御できます。
2. IAMポリシーの構成方法
IAMポリシーはJSON形式で記述され、具体的な許可や拒否のルールを設定します。例えば、以下のようなポリシーを使用して、
t3.small のみを許可し、他のインスタンスタイプの起動を拒否することができます。このポリシーは、
ec2:RunInstances アクションを許可し、インスタンスタイプが t3.small であり、リージョンが us-east-2 である場合にのみインスタンスを起動できるように制限します。3. AWS Organizationsとサービスコントロールポリシー（SCP）
AWS Organizationsを使用して、複数のアカウントを一元管理することができます。SCP（サービスコントロールポリシー）は、組織全体でリソースへのアクセス制御を行うために使用しますが、特定のアカウントに対して個別に制限を加えたい場合にはIAMポリシーの方が適切です。SCPは、AWS Organizations内の複数のアカウントに共通のポリシーを適用するため、個別のアカウントに詳細な制限を加える場合にはIAMポリシーが有効です。
4. EC2インスタンスの種類と起動制限
EC2インスタンスには、様々なインスタンスタイプがあります。インスタンスタイプの制限は、コスト管理やパフォーマンスの最適化に役立ちます。特定のインスタンスタイプに制限を加えることで、開発者や運用チームが予算内でリソースを効率的に管理できるようになります。
結論:
IAMポリシーを使って、EC2インスタンスの起動に対する制限を設けることは、特定のインスタンスタイプやリージョンに制限をかけるための最も効果的な方法です。これにより、開発者が所定のインスタンスタイプ（例えば
t3.small）でのみインスタンスを起動し、指定されたリージョン（例：us-east-2）での実行を確保することができます。実践
略
一問道場
問題 #351
ある会社には、Amazon EC2 インスタンスが必要以上に大きく起動されているプロジェクトがあります。このプロジェクトのアカウントは、ポリシー制限により会社の AWS Organizations には参加できません。会社は、プロジェクトのアカウントで開発者が t3.small EC2 インスタンスのみを起動できるようにし、その EC2 インスタンスは us-east-2 リージョンに制限する必要があります。
この要件を満たすために、ソリューションアーキテクトはどのような対応をすべきでしょうか？
A. 新しい開発者アカウントを作成し、すべての EC2 インスタンス、ユーザー、リソースを us-east-2 に移動します。そのアカウントを会社の AWS Organizations に追加します。リージョンに関連するタグ付けポリシーを強制します。
B. サービスコントロールポリシー（SCP）を作成し、us-east-2 で t3.small EC2 インスタンス以外のインスタンスの起動を拒否します。この SCP をプロジェクトのアカウントに適用します。
C. 各開発者に対して、us-east-2 の t3.small EC2 リザーブドインスタンスを作成して購入し、各開発者に名前タグを付けてインスタンスを割り当てます。
D. t3.small EC2 インスタンスのみを us-east-2 で起動できるようにする IAM ポリシーを作成し、そのポリシーをプロジェクトのアカウントで開発者が使用するロールやグループに適用します。
解説
この問題では、プロジェクトのアカウントで開発者が特定の Amazon EC2 インスタンスタイプ（t3.small）のみを起動し、そのインスタンスを特定のリージョン（us-east-2）で制限する要件を満たす方法を求めています。以下が解説です。
A. 新しい開発者アカウントを作成し、すべての EC2 インスタンス、ユーザー、リソースを us-east-2 に移動します。そのアカウントを会社の AWS Organizations に追加します。リージョンに関連するタグ付けポリシーを強制します。
- 理由: この方法は手間が多く、直接的に要件を満たす方法ではありません。新しいアカウントを作成してリソースを移動する必要があり、タグ付けポリシーの強制も求められますが、最初に必要な制限を簡単に設定できるわけではありません。
B. サービスコントロールポリシー（SCP）を作成し、us-east-2 で t3.small EC2 インスタンス以外のインスタンスの起動を拒否します。この SCP をプロジェクトのアカウントに適用します。
- 理由: これは問題の要件を満たす方法ではありません。SCP は AWS Organizations 内で組織単位で適用されるため、プロジェクトアカウントが AWS Organizations に参加していないと適用できません。したがって、この解決策は不適切です。
C. 各開発者に対して、us-east-2 の t3.small EC2 リザーブドインスタンスを作成して購入し、各開発者に名前タグを付けてインスタンスを割り当てます。
- 理由: リザーブドインスタンスを購入する方法は、コスト効率が良いとはいえ、開発者ごとに個別のインスタンスを割り当てる必要があるため、管理が煩雑になります。また、この方法はプロジェクト全体の自動化された制限管理には向いていません。
D. t3.small EC2 インスタンスのみを us-east-2 で起動できるようにする IAM ポリシーを作成し、そのポリシーをプロジェクトのアカウントで開発者が使用するロールやグループに適用します。
- 理由: これは最も適切な方法です。IAM ポリシーを使用することで、開発者が t3.small EC2 インスタンスのみを起動できるように制限できます。ポリシーで
ec2:RunInstancesアクションに対する制限を設定し、t3.smallインスタンスの起動を許可することができます。また、ポリシーは特定のリージョン（us-east-2）にも制限できます。この方法は、管理が簡単で、要件を正確に満たす方法です。
結論:
最適な解決策は D です。この方法は、最も効率的かつ簡単に指定されたインスタンスタイプ（t3.small）の起動を制限し、指定されたリージョンでのみインスタンスを作成できるようにするためです。
352-AWS SAP AWS 「理論・実践・一問道場」S3 RTC
理論
1. Amazon S3レプリケーション
Amazon S3レプリケーションは、データを複数のS3バケット間で自動的に複製する機能です。これにより、データの冗長性を高め、リージョン間のデータ複製が可能になります。主に次の2種類のレプリケーションがあります：
- クロスリージョンレプリケーション（CRR）：S3バケット内のデータを異なるリージョンに複製します。例えば、
us-east-1からap-northeast-1にデータをコピーすることができます。
- 同一リージョンレプリケーション（SRR）：同じリージョン内でS3バケット間のデータを複製します。
2. S3 Replication Time Control（RTC）
S3 RTCは、S3レプリケーションが完了する最大時間を制御および監視する機能です。RTCを有効にすると、特定のS3バケットに対するレプリケーションの遅延を監視し、所定の時間内にレプリケーションが完了しなかった場合に通知を受けることができます。RTCは、特にタイムクリティカルなデータ（例えば、ライブストリーミングやミッション・クリティカルなデータ）の処理において非常に重要です。
3. S3のイベント通知とAmazon EventBridge
- S3イベント通知：S3バケット内で発生したイベント（アップロード、削除、レプリケーションなど）に基づいて通知を受け取ることができます。これにより、データの処理や同期に関するリアルタイムな監視が可能となります。
- Amazon EventBridge：AWSサービス間でのイベントをトリガーに、Lambda関数やSNSトピック、Step Functionsなどを実行できます。S3のレプリケーション完了時間を監視する際に、EventBridgeを使用して通知を設定することができます。
4. S3 Transfer Acceleration
S3 Transfer Accelerationは、データをAmazon S3に高速でアップロードするためのオプション機能です。グローバルなエッジロケーションを使用してデータ転送の速度を向上させるため、特に大規模なデータの転送が迅速に行えるメリットがあります。しかし、これはS3レプリケーションや監視には直接関連しません。S3 Transfer Accelerationは主にデータアップロード速度を向上させるために使用されます。
まとめ
- S3 RTCを利用して、レプリケーションの完了時間を監視し、一定時間内にデータがレプリケーションされていることを確認することができます。
- S3レプリケーションは、データの冗長性やリージョン間での可用性を確保するために重要です。
- Amazon EventBridgeを活用して、特定のイベント（例：レプリケーションの遅延）を監視し、アラートを発行できます。
このように、S3レプリケーションとS3 RTCを駆使することで、タイムクリティカルなデータのレプリケーションを効率的に管理・監視することが可能です。
実践
略
一問道場
ある科学会社が、複数のレーダー基地から収集したテキストと画像データをAmazon S3バケットで処理する必要があります。このデータは、深宇宙ミッションのライブで時間制限がある重要なフェーズ中にアップロードされます。レーダー基地はデータをソースS3バケットにアップロードし、データにはレーダー基地の識別番号が接頭辞として付けられます。
会社は、別のアカウントにデスティネーションS3バケットを作成しました。データはコンプライアンス目標を満たすために、ソースS3バケットからデスティネーションS3バケットにコピーされる必要があります。このレプリケーションは、ソースS3バケット内のすべてのオブジェクトを対象とするS3レプリケーションルールを使用して行われます。
一部のレーダー基地が最も正確なデータを提供することが特定されており、そのデータのレプリケーションは、レーダー基地がオブジェクトをソースS3バケットにアップロードしてから30分以内に完了する必要があります。
要件を満たすためにソリューションアーキテクトが行うべきことは何でしょうか？
A. AWS DataSyncエージェントを設定して、ソースS3バケットからデスティネーションS3バケットへ接頭辞付きのデータをレプリケートします。タスクに利用可能なすべての帯域幅を使用し、タスクが「TRANSFERING」状態であることを監視します。ステータスが変更された場合にアラートを発生させるため、Amazon EventBridgeルールを作成します。
B. 2番目のアカウントで新しいS3バケットを作成し、最も正確なデータを提供するレーダー基地からのデータを受け取ります。この新しいS3バケットに対して新たにレプリケーションルールを設定し、他のレーダー基地からのレプリケーションと分離します。デスティネーションへの最大レプリケーション時間を監視し、所定の時間を超えた場合にアラートを発生させるため、Amazon EventBridgeルールを作成します。
C. ソースS3バケットでAmazon S3 Transfer Accelerationを有効にし、最も正確なデータを提供するレーダー基地が新しいエンドポイントを使用するように設定します。S3デスティネーションバケットの「TotalRequestLatency」メトリックを監視し、このステータスが変化した場合にアラートを発生させるために、Amazon EventBridgeルールを作成します。
D. ソースS3バケットに新しいS3レプリケーションルールを作成し、最も正確なデータを提供するレーダー基地の接頭辞を使ったキーでフィルタリングします。S3レプリケーションタイムコントロール（S3 RTC）を有効にし、デスティネーションへの最大レプリケーション時間を監視します。所定の時間を超えた場合にアラートを発生させるため、Amazon EventBridgeルールを作成します。
解説
この問題では、科学会社が深宇宙ミッション中に複数のレーダーステーションから収集したデータを処理する方法について述べています。特に、1つのレーダーステーションが最も正確なデータを提供するため、そのデータのS3バケット間のレプリケーションを30分以内に完了させる必要があります。問題は、S3のデータレプリケーションを監視し、30分以内にデータがコピーされているか確認する方法を選ぶというものです。
各選択肢の詳細解説
A. AWS DataSyncを使用する
- AWS DataSyncは、データ転送を迅速かつ効率的に行うためのサービスです。このオプションでは、DataSyncを使ってS3バケット間でデータを転送し、転送のステータスが「転送中」（TRANSFERRING）であることを監視するというものです。転送が正常に進行しているかどうかを監視するためにAmazon EventBridgeルールを設定する方法ですが、DataSyncは通常、バッチ転送や大規模データの移動に適しており、このようなリアルタイムのデータ同期に適していません。
- したがって、これは最適な解決策とは言えません。
B. 2つ目のS3バケットを作成し、レプリケーションを別管理
- このオプションでは、最も正確なデータを提供するレーダーステーション用に新しいS3バケットを作成し、そのデータのレプリケーションを別に管理します。EventBridgeルールを使用してレプリケーション時間を監視し、30分を超えた場合にアラートを発行します。
- ただし、これは新しいバケットの作成が不要な場合、余分な管理を増やす可能性があり、最も正確なデータに特化して監視する点では不必要に複雑になります。
C. S3 Transfer Accelerationを有効化
- S3 Transfer Accelerationを有効にすると、データ転送速度が向上しますが、これはS3の転送にかかる時間を短縮するための方法です。しかし、このオプションはレーダーステーションのデータを30分以内にコピーする目的には必ずしも最適ではありません。転送速度の向上が目的であって、特定のレプリケーション時間の監視という要求には対応していません。
- したがって、この選択肢も適切とは言えません。
D. S3レプリケーションルールを設定し、S3 RTC（Replication Time Control）を使用する
- このオプションでは、最も正確なデータを提供するレーダーステーションのデータにフィルタをかけ、S3 RTC（Replication Time Control）を有効にして、レプリケーションが所定の時間内に完了しているかを監視します。S3 RTCは、レプリケーションがどれだけ迅速に行われたかを追跡し、時間制限を超えた場合にアラートを出すことができます。
- これにより、特定のレーダーステーションに関するレプリケーションの完了時間を厳密に監視することができ、要求を満たす最も適切な解決策となります。
結論
最適な解決策は D です。S3 RTCを有効にし、特定のレーダーステーションのデータにフィルタをかけることで、レプリケーションが30分以内に完了することを確実に監視できます。
353-AWS SAP AWS 「理論・実践・一問道場」サーバ移行事前準備
理論
1. AWS Application Discovery Service
- 概要: AWS Application Discovery Serviceは、オンプレミス環境の分析ツールです。このツールは、サーバー、アプリケーション、ネットワークの依存関係など、インフラ全体を調査して、移行計画を立てるためのデータを提供します。特に、移行対象のインフラを理解し、必要なリソースや依存関係を正確に把握するために不可欠です。
- 利用シーン: 既存のデータセンターで稼働しているアプリケーションやサーバーのリストを取得し、移行後にどのリソースが必要になるかを見積もります。
2. AWS Cloud Adoption Readiness Tool (CART)
- 概要: CARTは、組織のクラウド移行に対する準備状況を評価するツールです。クラウド導入の準備が整っているか、どの分野で追加のリソースやスキルが必要かを分析します。移行の進行状況やリスクを可視化し、移行の計画を具体化します。
- 利用シーン: クラウド移行の計画段階で、企業が準備できているかどうかを評価し、必要な改善点を特定します。
3. AWS Migration Hub
- 概要: AWS Migration Hubは、複数の移行ツールとサービスを管理する中心的なプラットフォームです。移行プロセスを追跡し、進捗を一元管理できます。これにより、移行の状態や次のステップを可視化し、移行作業が円滑に進むようにサポートします。
- 利用シーン: 複数のツールを使用して進めている移行作業を統合的に追跡し、移行作業の効率を向上させます。
4. AWS SMS (Server Migration Service)
- 概要: AWS SMSは、オンプレミスの仮想マシンをAWSへ移行するためのサービスです。特に、既存の仮想化された環境からAWSへ大量のサーバーを迅速に移行する場合に有用です。移行中のダウンタイムを最小限に抑えることができます。
- 利用シーン: 大規模なサーバーの移行や、仮想化された環境からの移行に使用します。
5. AWS X-Ray
- 概要: AWS X-Rayは、分散アプリケーションのデバッグと分析を行うためのツールで、移行には直接関与しません。アプリケーションのパフォーマンスやボトルネックを調査するために使われます。
- 利用シーン: アプリケーション移行後のパフォーマンス監視やトラブルシューティングに使用されます。
6. Amazon Inspector
- 概要: Amazon Inspectorは、AWS環境のセキュリティ評価を行うサービスです。移行の際に、セキュリティの脆弱性を検出し、修正策を提案します。
- 利用シーン: 移行後のセキュリティ評価やコンプライアンスの確認に使用します。
まとめ
AWSでは、オンプレミス環境からクラウドへの移行を支援するための強力なツール群を提供しています。特に、AWS Application Discovery Serviceは移行の初期段階で必要な情報を収集するために不可欠であり、**AWS Cloud Adoption Readiness Tool (CART)**は準備状況を把握し、移行計画を明確化するために役立ちます。また、AWS Migration Hubは移行全体を監視するための中心的なツールとして非常に重要です。これらのツールを適切に活用することで、移行を円滑に進めることができます。
実践
略
一問道場
問題 #353
ある会社は、オンプレミスのデータセンターをAWSクラウドに移行したいと考えています。この移行には、数千台の仮想化されたLinuxおよびMicrosoft Windowsサーバー、SANストレージ、JavaおよびPHPアプリケーション、MySQLおよびOracleデータベースが含まれています。多くの依存サービスが同じデータセンターまたは外部にホストされています。技術的なドキュメントは不完全で古いものです。ソリューションアーキテクトは、現在の環境を理解し、移行後のクラウドリソースコストを見積もる必要があります。
どのツールまたはサービスを使用してクラウド移行の計画を立てるべきですか？（3つ選んでください。）
A. AWS Application Discovery Service
B. AWS SMS
C. AWS X-Ray
D. AWS Cloud Adoption Readiness Tool (CART)
E. Amazon Inspector
F. AWS Migration Hub
解説
この問題では、オンプレミスのデータセンターをAWSに移行するために必要な情報を収集し、クラウドリソースコストを見積もるためにどのツールやサービスを使うべきかを問われています。以下は各ツールやサービスの解説です：
A. AWS Application Discovery Service
- 用途: オンプレミス環境のリソースと依存関係を自動的に発見し、移行計画を作成するために役立つツールです。サーバー、アプリケーション、ストレージの構成を把握し、移行後の計画を立てる際に有用です。
- 理由: このサービスは移行元の環境を正確に把握し、移行後のリソース要件やコストを見積もるために非常に役立ちます。
B. AWS SMS (Server Migration Service)
- 用途: 物理または仮想マシンをAWSに移行するためのツールで、移行プロセスを自動化します。特に複数のサーバーを移行する際に便利です。
- 理由: サーバー移行を簡素化するため、移行計画を立てる際に有用ですが、事前の環境理解には限界があるため、計画段階ではAWS Application Discovery Serviceの方が適していることが多いです。
D. AWS Cloud Adoption Readiness Tool (CART)
- 用途: AWSクラウドの採用準備状況を評価するツールです。組織のクラウド移行に必要なプロセスや準備状況を評価し、移行のロードマップを作成します。
- 理由: クラウドへの移行準備状況を評価し、必要なリソースやスキルセットを理解するために役立ちます。特に移行の初期段階で有用です。
F. AWS Migration Hub
- 用途: AWSに移行するプロジェクトを一元的に管理し、進捗状況をトラッキングするツールです。複数の移行ツールやサービスを統合して管理できます。
- 理由: 移行全体の進行状況を把握するのに役立ちます。移行プロセスを管理し、どのサービスがどの段階にいるかを追跡するために有効です。
その他のツール：
- C. AWS X-Ray: 主にアプリケーションのパフォーマンス分析やトラブルシューティングに使用され、移行計画の策定にはあまり関与しません。
- E. Amazon Inspector: セキュリティやコンプライアンスチェックに使用されるサービスで、移行計画のためのリソース評価には必ずしも必要ではありません。
結論：
この問題では、移行元の環境を正確に把握し、リソースの要件を見積もるために、A (AWS Application Discovery Service)、D (AWS Cloud Adoption Readiness Tool)、F (AWS Migration Hub) が最も適切なツールとなります。
354-AWS SAP AWS 「理論・実践・一問道場」高可用性のためのアーキテクチャ
理論
1. 高可用性のためのアーキテクチャ
高可用性を確保するためには、複数のアベイラビリティゾーン（AZ）にまたがるリソースの配置が重要です。AWSでは、以下の方法で高可用性を確保できます：
- Auto Scalingグループ：Auto Scalingグループを複数のAZにまたがって設定することで、インスタンスの高可用性を確保します。インスタンスが1つのAZに依存することなく、障害発生時でも他のAZでリソースをスケールできます。
- NATゲートウェイ：NATゲートウェイを複数のAZに配置することで、インターネットアクセスの可用性を向上させ、障害発生時でもアクセスを維持できます。
2. RDSの高可用性
- Multi-AZ構成：Amazon RDS for MySQLやPostgreSQLなどのデータベースは、Multi-AZ構成を使用して高可用性を提供します。これにより、プライマリインスタンスが故障した場合、自動的にスタンバイインスタンスにフェイルオーバーしてサービスを継続できます。
- 自動バックアップ：RDSでは、自動バックアップを設定して、データの保護や復旧のための手段を提供しますが、可用性を高めるためにはMulti-AZ構成が優れています。
3. VPC設計のベストプラクティス
VPCを設計する際は、複数のアベイラビリティゾーンにまたがるサブネットを作成することが推奨されます。これにより、障害発生時に他のAZのサーバーが正常に動作することを保証できます。
4. AWSリソースの冗長性とスケーラビリティ
- インスタンスの分散配置：複数のAZにインスタンスを分散することで、ゾーン障害に対する耐性が強化されます。AWSでは、アプリケーションやインスタンスが複数のAZで冗長化されるように設計することが一般的です。
- スケーリング：Auto Scalingグループは、サーバーの数を動的に変更できるため、トラフィックや負荷に応じて最適なリソースを提供します。
5. NATゲートウェイとNATインスタンス
- NATゲートウェイは、可用性が高く、インターネットとの通信を支えるために使用されます。複数のAZに配置して冗長性を確保できます。
- NATインスタンスは、低コストですが可用性が低く、スケーリングも手動で行う必要があります。高可用性を確保するためにはNATゲートウェイが推奨されます。
6. セキュリティとスケーラビリティ
セキュリティを考慮した設計として、VPC内のサブネット分けやセキュリティグループ、NACL（Network Access Control List）を適切に設定することが重要です。また、スケーラビリティを高めるために、ロードバランサーやAuto Scalingを利用するのが一般的です。
結論
AWSのインフラで高可用性やスケーラビリティを実現するためには、複数のアベイラビリティゾーンを利用し、Auto ScalingやNATゲートウェイ、RDSのMulti-AZなどを組み合わせて設計することが重要です。このようにして、障害発生時でもサービスの継続性を保ち、負荷に応じてリソースを最適化できます。
実践
略
一問道場
問題 #354
ソリューションアーキテクトが、アプリケーションのローンチ前にそのレジリエンスを確認しています。このアプリケーションは、VPC内のプライベートサブネットにデプロイされたAmazon EC2インスタンスで動作しています。EC2インスタンスは、最小容量1、最大容量1のAuto Scalingグループによってプロビジョニングされています。アプリケーションは、Amazon RDS for MySQL DBインスタンスにデータを保存しています。VPCには3つのアベイラビリティゾーンに設定されたサブネットがあり、1つのNATゲートウェイが設定されています。
ソリューションアーキテクトは、アプリケーションが複数のアベイラビリティゾーンで動作することを保証するための解決策を推奨する必要があります。
次の解決策のうち、どれがこの要件を満たしますか？
A.
追加のNATゲートウェイを他のアベイラビリティゾーンにデプロイし、適切なルートを設定したルートテーブルを更新します。
RDS for MySQL DBインスタンスをMulti-AZ構成に変更します。
Auto Scalingグループを設定して、アベイラビリティゾーン全体にインスタンスを起動します。
Auto Scalingグループの最小容量と最大容量を3に設定します。
B.
NATゲートウェイを仮想プライベートゲートウェイに置き換え、RDS for MySQL DBインスタンスをAmazon Aurora MySQL DBクラスターに置き換えます。
Auto Scalingグループを設定して、VPC内のすべてのサブネットにインスタンスを起動します。
Auto Scalingグループの最小容量と最大容量を3に設定します。
C.
NATゲートウェイをNATインスタンスに置き換え、RDS for MySQL DBインスタンスをRDS for PostgreSQL DBインスタンスに移行します。
新しいEC2インスタンスを他のアベイラビリティゾーンに起動します。
D.
追加のNATゲートウェイを他のアベイラビリティゾーンにデプロイし、適切なルートを設定したルートテーブルを更新します。
RDS for MySQL DBインスタンスを自動バックアップを有効にしてバックアップを7日間保持するように変更します。
Auto Scalingグループを設定して、VPC内のすべてのサブネットにインスタンスを起動します。
Auto Scalingグループの最小容量と最大容量は1のままにします。
解説
この問題では、アプリケーションが複数のアベイラビリティゾーンで動作するようにするための解決策を選ぶ必要があります。各選択肢について、要件を満たすかどうかを評価してみましょう。
選択肢 A:
- 追加のNATゲートウェイを他のアベイラビリティゾーンにデプロイ
- 複数のアベイラビリティゾーンにNATゲートウェイをデプロイすることで、インターネットアクセスが各ゾーンから可能になり、可用性が向上します。
- RDS for MySQL DBインスタンスをMulti-AZ構成に変更
- RDSインスタンスをMulti-AZ構成にすることで、高可用性が確保され、障害時に自動的に他のゾーンにフェイルオーバーします。
- Auto Scalingグループを設定して、アベイラビリティゾーン全体にインスタンスを起動
- インスタンスを複数のアベイラビリティゾーンに分散させることで、1つのゾーンがダウンした場合でも、他のゾーンでアプリケーションが稼働し続けます。
結論: この選択肢は、アプリケーションが複数のアベイラビリティゾーンで動作するための要件を満たします。NATゲートウェイ、Multi-AZ RDS、Auto Scalingグループによるゾーン全体の分散を利用して、可用性とスケーラビリティが確保されます。
選択肢 B:
- NATゲートウェイを仮想プライベートゲートウェイに置き換え
- 仮想プライベートゲートウェイは、VPN接続やVPCピアリング接続を使用して、オンプレミスのネットワークとAWSの間の通信を行いますが、インターネット接続の要件には関係ありません。
- RDS for MySQL DBインスタンスをAmazon Aurora MySQL DBクラスターに置き換え
- Auroraは高可用性を持っているものの、MySQLとの互換性があり、必要に応じて利用できますが、この場合にはMySQLでも十分にMulti-AZの構成が可能です。
- Auto Scalingグループを設定して、VPC内のすべてのサブネットにインスタンスを起動
- これは良いアプローチですが、NATゲートウェイを仮想プライベートゲートウェイに置き換えるのは不必要です。
結論: 仮想プライベートゲートウェイはNATゲートウェイの置き換えには適しておらず、この選択肢は過剰であり、最適な解決策ではありません。
選択肢 C:
- NATゲートウェイをNATインスタンスに置き換え
- NATインスタンスはNATゲートウェイよりも管理が複雑で、可用性が低いため、推奨されません。
- RDS for MySQL DBインスタンスをRDS for PostgreSQL DBインスタンスに移行
- この変更は不要です。MySQLでもMulti-AZ構成で高可用性を確保できるため、DBの移行は無駄です。
- 新しいEC2インスタンスを他のアベイラビリティゾーンに起動
- EC2インスタンスを別のゾーンに起動するのは良いアプローチですが、その他の設定に問題があります。
結論: NATインスタンスやデータベースの変更は、要件を満たすために必要ない変更です。この選択肢は最適ではありません。
選択肢 D:
- 追加のNATゲートウェイを他のアベイラビリティゾーンにデプロイ
- これ自体は良い選択です。
- RDS for MySQL DBインスタンスを自動バックアップを有効にしてバックアップを7日間保持するように変更
- バックアップの設定は重要ですが、要件で求められているのは高可用性の確保であり、Multi-AZ構成にすることが必要です。
- Auto Scalingグループを設定して、VPC内のすべてのサブネットにインスタンスを起動
- これも適切なアプローチですが、最小・最大容量を1のままにするのは、要件を満たさない可能性があります。
結論: バックアップの設定は高可用性のためには重要ですが、Multi-AZ構成とゾーン間でのインスタンス起動が最優先です。最小・最大容量を1のままにするのは不適切です。
結論:
最適な選択肢は A です。複数のアベイラビリティゾーンでの動作を保証するために、NATゲートウェイ、Multi-AZ RDS、Auto Scalingグループを使用するアプローチが最も効果的です。
355-AWS SAP AWS 「理論・実践・一問道場」Amazon ECS
理論
1. コンテナベースのアプリケーションの移行
- コンテナ化されたアプリケーションは、インフラの管理負担を減らし、移行をスムーズにします。AWSにはコンテナを管理するためのサービスがいくつかあり、最も代表的なのは Amazon ECS (Elastic Container Service) と Amazon EKS (Elastic Kubernetes Service) です。
- AWS Fargate は、ECSおよびEKSと連携し、サーバーレスでコンテナを実行するためのサービスです。Fargateを使用すると、インフラストラクチャの管理をAWSに任せることができ、アプリケーションに集中できます。
2. ストレージソリューションの選定
- アプリケーションがデータを保存するために使用するストレージの選定は、アプリケーションの要求に基づいて行います。特に、低レイテンシ、スケーラビリティ、共有アクセスが必要な場合、以下のストレージオプションが考えられます：
- Amazon EFS (Elastic File System): 複数のインスタンスからの共有アクセスを提供するスケーラブルなファイルシステム。高い可用性と耐障害性を持ち、コンテナ化されたアプリケーションに適しています。EFSはファイルシステムインターフェースを提供し、アプリケーションが既存のファイル操作に依存している場合に最適です。
- Amazon EBS (Elastic Block Store): 個々のEC2インスタンスにアタッチするブロックストレージですが、EBSは単一インスタンスでしか共有できません。従って、スケーラブルなコンテナアプリケーションにはEBSは不向きです。
3. AWS FargateとEFSの組み合わせ
- AWS Fargate と EFS の組み合わせは、コンテナ化されたアプリケーションにとって理想的なソリューションです。Fargateは、コンテナの実行をマネージドサービスとして提供し、EFSは複数のコンテナから同時にアクセス可能なファイルストレージを提供します。これにより、インフラストラクチャの管理が不要になり、アプリケーションのスケーリングも簡単に行えます。
4. AWSサービスの選定基準
- EFS vs. EBS: アプリケーションのデータが複数のインスタンスやコンテナによって共有される場合、EFSが最適です。一方、EBSは単一のインスタンスに対するストレージを提供するため、共有アクセスが必要ない場合に適しています。
- Fargate vs. EC2: EC2はインフラストラクチャの管理が必要ですが、Fargateはサーバーレスでコンテナを実行でき、インフラ管理の負担を軽減します。Fargateを使用すると、アプリケーション開発者はインフラの管理から解放され、アプリケーションの開発に集中できます。
5. スケーラビリティと低レイテンシ
- ストレージがスケールする能力と低レイテンシを提供することが重要です。EFSは必要に応じて自動的にスケールするため、トランザクションデータなど高負荷なデータ処理に適しています。また、EFSは数ミリ秒のレイテンシでアクセスでき、コンテナ間でのデータ共有に優れたパフォーマンスを発揮します。
結論
この問題の解答で最適な選択肢は、AWS Fargate for ECS と EFSの組み合わせです。Fargateはサーバーレスで管理が不要なコンテナ環境を提供し、EFSはスケーラブルで低レイテンシのファイルシステムを提供するため、コンテナ間での共有ストレージに最適です。この組み合わせにより、インフラストラクチャの管理負担を軽減し、アプリケーションのスケーリングを自動化することができます。
実践
略
一問道場
ある会社が、オンプレミスのトランザクション処理アプリケーションをAWSに移行する計画をしています。このアプリケーションは、会社のデータセンター内の仮想マシン（VM）上でホストされるDockerコンテナ内で動作しています。Dockerコンテナには、アプリケーションがトランザクションデータを記録するための共有ストレージがあります。このトランザクションは時間に敏感であり、アプリケーション内のトランザクション量は予測できません。会社は、需要の増加に対応してスループットを自動的にスケールできる低遅延のストレージソリューションを実装する必要があります。会社はアプリケーションのさらなる開発を行えず、Dockerホスティング環境の管理も続けることができません。
会社はこの要件を満たすためにどのようにアプリケーションをAWSに移行すべきですか？
A. アプリケーションを実行するコンテナをAmazon Elastic Kubernetes Service（Amazon EKS）に移行します。トランザクションデータをコンテナが共有するためにAmazon S3を使用します。
B. アプリケーションを実行するコンテナをAWS Fargate for Amazon Elastic Container Service（Amazon ECS）に移行します。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成します。Fargateタスク定義を作成し、タスク定義にボリュームを追加してEFSファイルシステムを指すようにします。
C. アプリケーションを実行するコンテナをAWS Fargate for Amazon Elastic Container Service（Amazon ECS）に移行します。Amazon Elastic Block Store（Amazon EBS）ボリュームを作成します。Fargateタスク定義を作成し、EBSボリュームを各実行中のタスクにアタッチします。
D. Amazon EC2インスタンスを起動し、EC2インスタンスにDockerをインストールします。コンテナをEC2インスタンスに移行します。Amazon Elastic File System（Amazon EFS）ファイルシステムを作成し、EFSファイルシステムのマウントポイントをEC2インスタンスに追加します。
解説
この問題では、オンプレミスのトランザクション処理アプリケーションをAWSに移行する方法を選択する必要があります。アプリケーションはDockerコンテナで実行され、トランザクションデータを共有ストレージに保存しています。また、トランザクションの処理は時間に敏感であり、スループットを自動的にスケールできるストレージが必要です。加えて、会社はアプリケーションの開発を続けられないため、管理負担を軽減する方法を選ばなければなりません。
各選択肢の詳細な解説は以下の通りです：
A. Amazon EKSとS3を使用
- 不適切。Amazon EKSはKubernetesを使用してコンテナを管理するサービスです。しかし、トランザクションデータのストレージにAmazon S3を使用する提案は、低遅延のアクセスが必要な状況には適していません。S3はオブジェクトストレージであり、ファイルシステムのように直接的な低レイテンシのアクセスを提供するものではないため、トランザクションデータの格納には不向きです。
B. EFSを使用
- 適切。AWS Fargate for Amazon ECSを使用してコンテナをホストし、Amazon Elastic File System（EFS）をストレージとして使用する選択肢です。EFSは、複数のコンテナインスタンスで共有可能なスケーラブルなファイルシステムを提供します。EFSは、低レイテンシでスケール可能なストレージソリューションであり、このシナリオに最適です。Fargateは、インフラ管理を不要にし、完全にマネージドなコンテナ環境を提供します。
C. EBSを使用
- 不適切。Amazon EBS（Elastic Block Store）は、EC2インスタンスに接続するブロックレベルのストレージですが、EBSは1つのEC2インスタンスにアタッチされるため、複数のコンテナインスタンスで共有することができません。アプリケーションが複数のコンテナでスケールする場合、EBSは適切ではありません。さらに、EBSのスケールは自動的に行われませんので、手動での管理が必要となる場合があります。
D. EC2インスタンスとEFSを使用
- 不適切。EC2インスタンスにDockerをインストールしてコンテナを管理する方法は、EFSとの組み合わせで機能しますが、Fargateの方が管理のオーバーヘッドを減らせるため、より好ましい選択肢です。EC2で直接コンテナを管理する場合、インフラストラクチャの管理が必要であり、これが質問の要件に合致しません。
正解は B の「AWS Fargate for ECSとEFS」を使用する方法です。Fargateを利用することで、コンテナの管理はAWSが行い、EFSを使用して複数のコンテナ間でトランザクションデータを効率的に共有し、スケーラブルで低遅延のストレージソリューションを提供します。
356-AWS SAP AWS 「理論・実践・一問道場」AWS Application Discovery Agent
理論
インベントリとは、企業や組織が保有している物品、資産、リソースなどの一覧または目録を指します。具体的には、物理的な在庫や、システム、サーバー、アプリケーションなどのデジタルリソースの情報が含まれます。
この文脈では、「オンプレミスのサーバーとアプリケーションのインベントリ」というのは、企業が現在所有しているサーバー（物理サーバーおよび仮想サーバー）、そのサーバーで稼働しているアプリケーション、さらにはこれらのサーバー間の接続や依存関係を正確に把握し、リスト化することを意味します。移行計画を立てるためには、これらのリソースを正確に把握しておくことが重要です。
1. AWS Migration Hub
- AWS Migration Hub は、AWSに移行するアプリケーションの進行状況を追跡し、管理するためのサービスです。移行中のインスタンスの状況や、進捗状況を一元的にモニタリングできます。
- Strategy Recommendations 機能を使用することで、AWSに適した移行方法やリソースの提案を受けることができます。
2. AWS Application Discovery Service
- AWS Application Discovery Service は、オンプレミスのITインフラやアプリケーションの依存関係を発見するためのツールです。これを使用することで、移行に必要なサーバーやアプリケーションのインベントリを取得できます。
- Agentless Collector：サーバーにエージェントをインストールせずに、ネットワーク上の情報を収集する方法。より手軽に情報を取得できます。
- Discovery Agent：サーバーにインストールして、詳細なパフォーマンス情報や依存関係を収集します。
3. AWS Migration Evaluator
- AWS Migration Evaluator は、オンプレミスのインフラを評価し、AWSに移行する際に必要なコストやリソースの予測を行うツールです。これにより、移行後に予想される費用やリソースの需要を明確にし、右サイズ（最適化）されたリソースを計画できます。
4. AWS Application Migration Service
- AWS Application Migration Service は、サーバーやアプリケーションの移行を簡素化するサービスです。このサービスは、インスタンスの変換やデータの移行をサポートします。
5. リソースの右サイズ化（Rightsizing）
- 移行先のAWSクラウド環境で効率的にリソースを使用するためには、適切なリソースのサイズ設定が必要です。リソースの右サイズ化を行うことで、コストの最適化が図れます。AWS Migration Evaluatorや、他のツールで提供される推奨リソースサイズに基づいて、最適な設定を行うことが重要です。
6. 依存関係の管理
- 依存関係を管理することは、移行計画を作成する上で非常に重要です。アプリケーションやサーバー間の依存関係を把握することで、移行の優先順位を決めたり、必要なタイミングでサーバーやアプリケーションを移行したりすることができます。AWS Application Discovery Serviceを活用して依存関係を明確化し、スムーズな移行を実現できます。
結論
オンプレミスからAWSクラウドへの移行を成功させるためには、アプリケーションの依存関係やリソースの現在の状況を正確に把握し、移行の計画を立てることが不可欠です。AWS Migration Hub、AWS Application Discovery Service、AWS Migration Evaluatorなどのツールを活用して、移行を効率的に行い、移行後のAWS環境で最適化されたリソースを利用することが重要です。
実践
略
一問道場
問題 #356
ある企業がAWSクラウドへの移行を計画しています。この企業は、WindowsサーバーとLinuxサーバーで多数のアプリケーションをホストしています。サーバーの一部は物理サーバーで、残りは仮想サーバーです。この企業はオンプレミス環境で複数の種類のデータベースを使用していますが、オンプレミスのサーバーとアプリケーションのインベントリが正確に管理されていません。
この企業は移行時にリソースの適切なサイズを決定したいと考えています。ソリューションアーキテクトは、ネットワーク接続やアプリケーションの依存関係に関する情報を取得する必要があります。ソリューションアーキテクトは、企業の現在の環境を評価し、移行計画を立てる必要があります。
移行計画を作成するために必要な情報をソリューションアーキテクトに提供するために、どのソリューションを使用すべきですか？
A. Migration Evaluatorを使用して、AWSに環境の評価を依頼します。AWS Application Discovery Service Agentless Collectorを使って、詳細情報をMigration Evaluator Quick Insightsレポートにインポートします。
B. AWS Migration Hubを使用して、サーバーにAWS Application Discovery Agentをインストールします。Migration Hub Strategy Recommendationsアプリケーションデータコレクターを展開し、Migration Hub Strategy Recommendationsを使ってレポートを生成します。
C. AWS Migration Hubを使用して、AWS Application Discovery Service Agentless Collectorをサーバーに実行します。AWS Application Migration Serviceを使用してサーバーとデータベースをグループ化し、Migration Hub Strategy Recommendationsを使ってレポートを生成します。
D. AWS Migration Hubインポートツールを使用して、企業のオンプレミス環境の詳細情報をインポートします。Migration Hub Strategy Recommendationsを使ってレポートを生成します。
解説
この問題では、企業がオンプレミスからAWSクラウドに移行する際、移行計画を立てるために現在のインフラを正確に把握する必要があるというシナリオです。特に、サーバーの種類、アプリケーション、データベース、ネットワーク接続などのリソースを評価することが求められています。
移行計画を立てるために、サーバーやアプリケーションのインベントリを作成するための情報を取得するツールが必要です。これを実現するために、以下の選択肢があります。
各選択肢の解説：
- A. Migration Evaluator と AWS Application Discovery Service Agentless Collector を使用
- Migration Evaluator は、オンプレミスの環境を評価し、AWSへの移行に必要なコストやリソースの予測を提供するツールです。
- AWS Application Discovery Service Agentless Collector は、サーバーやアプリケーションの依存関係やネットワーク接続を発見し、レポートとして出力できます。
- この方法は、環境を評価し、AWSに移行するためのリソースを把握するのに有効です。しかし、詳細な移行計画を立てるためには、他の選択肢がより適切かもしれません。
- B. AWS Migration Hub と AWS Application Discovery Agent のインストール
- AWS Migration Hub は、AWSへの移行プロセス全体を監視し、管理するためのツールです。
- AWS Application Discovery Agent は、サーバーにインストールして、そのサーバーの依存関係やパフォーマンスを監視するエージェントです。このエージェントを使用すると、サーバーやアプリケーションの詳細な情報を収集できます。
- さらに、Migration Hub Strategy Recommendations では、収集したデータを基に、移行戦略の推奨が得られます。これにより、移行計画を立てるのに必要な情報を得ることができます。
- C. AWS Migration Hub と AWS Application Discovery Service Agentless Collector を使用
- こちらもAWS Migration Hub を使用しますが、AWS Application Discovery Service Agentless Collector をサーバーにインストールせずに、ネットワーク接続やアプリケーションの依存関係を把握できます。サーバーやデータベースをAWS Application Migration Service でグループ化することもできます。
- この方法でも情報を収集し、レポートを生成して移行計画を立てることができますが、詳細なデータ収集が必要な場合、エージェントをインストールする方が効果的です。
- D. AWS Migration Hub import tool を使用
- Migration Hub import tool は、手動でオンプレミス環境の詳細な情報をAWSにインポートできるツールです。この方法では、事前にインベントリを作成して、手動でデータをインポートする必要があります。
- この方法は、自動化されたインベントリ収集には向いていないため、他の方法よりも手間がかかります。
最適な選択肢：
- 最も適切なのは B の選択肢です。AWS Migration Hub と AWS Application Discovery Agent を使用して、サーバーやアプリケーションの依存関係を正確に収集し、移行戦略を作成できるため、移行計画の作成に最も適しています。
結論：
- B の選択肢が最も効果的な方法であり、移行計画を立てるために必要なインベントリ情報を収集するのに適しています。
357-AWS SAP AWS 「理論・実践・一問道場」AWS CloudTrail
理論
1. AWS CloudTrail
AWS CloudTrailは、AWSアカウントでのAPIコールを監査し、ログとして保存するサービスです。これにより、ユーザーの操作やシステムの変更履歴を記録して、セキュリティ監査やコンプライアンスの要件に対応できます。
- CloudTrailの主要な機能：
- API呼び出しの監査：AWSリソースへのアクセスや変更を追跡します。
- グローバルリソースの管理：すべてのリージョンで同じCloudTrailを設定できます。
- イベントの保存：イベントデータを指定したS3バケットに保存し、長期間保存できます。
2. S3バケットの設定
AWS CloudTrailのログは通常、Amazon S3に保存されます。S3バケットの管理は非常に重要で、以下のセキュリティ設定を適用できます。
- バージョン管理：S3バケットに保存されたデータの過去のバージョンを保持する機能です。データ損失のリスクを軽減し、削除や上書きされたデータも復元可能にします。
- 暗号化：データがS3に保存されるとき、サーバーサイドの暗号化でデータを保護できます。これにより、保存されているログデータを第三者がアクセスできないようにします。
- MFA削除：重要なデータを削除する際に多要素認証(MFA)を要求することで、誤ってまたは不正にデータが削除されるリスクを減少させます。
3. AWS Organizations
AWS Organizationsは、複数のAWSアカウントを一元的に管理するサービスです。これを利用することで、複数のAWSアカウントにまたがる監査や管理が効率的になります。CloudTrailの設定は、組織全体に対して一貫して適用でき、各アカウントのAPIコールも追跡できます。
- 組織単位での管理：CloudTrailを組織単位で設定することで、複数アカウントにまたがるログを一元管理できます。
4. 規制コンプライアンスと監査
多くの業界で、規制要件に基づく監査証跡の保存が求められています。特に金融業界などでは、APIコールの追跡や変更履歴を保持することが義務付けられています。AWS CloudTrailは、こうした規制要件に対応するためのツールです。
- コンプライアンス対応：規制に準拠した監査ログの保存をCloudTrailとS3で簡単に実現できます。
結論
この問題は、最小限の運用負荷でコンプライアンスを満たす方法を問うもので、CloudTrail と S3の管理 による監査ログの取り扱いが重要なポイントです。特に、ログ保存の一貫性とデータ保護の強化（暗号化、MFA削除、バージョン管理）が求められます。
実践
略
一問道場
ある金融サービス会社は、アプリケーションのコンプライアンスを提供するソフトウェア・アズ・ア・サービス（SaaS）プラットフォームを大手グローバル銀行に提供しています。このSaaSプラットフォームはAWS上で実行され、AWS Organizations内で管理されている複数のAWSアカウントを使用しています。また、SaaSプラットフォームは世界中の多くのAWSリソースを利用しています。
規制コンプライアンスのために、AWSリソースへのすべてのAPIコールを監査し、変更を追跡し、耐久性がありセキュアなデータストアに保存する必要があります。
最小の運用負荷でこの要件を満たすソリューションはどれですか？
A. 新しいAWS CloudTrailトレイルを作成します。既存のAmazon S3バケットを組織の管理アカウントで使用してログを保存します。トレイルをすべてのAWSリージョンに展開し、S3バケットでMFA削除と暗号化を有効にします。
B. 組織の各メンバーアカウントに新しいAWS CloudTrailトレイルを作成します。新しいAmazon S3バケットを作成してログを保存します。トレイルをすべてのAWSリージョンに展開し、S3バケットでMFA削除と暗号化を有効にします。
C. 組織の管理アカウントで新しいAWS CloudTrailトレイルを作成します。ログを保存するために新しいAmazon S3バケットを作成し、バージョン管理を有効にします。すべてのアカウントに対してトレイルを展開し、S3バケットでMFA削除と暗号化を有効にします。
D. 組織の管理アカウントで新しいAWS CloudTrailトレイルを作成します。ログを保存するために新しいAmazon S3バケットを作成します。Amazon Simple Notification Service（Amazon SNS）を設定して、ログファイルの配信通知を外部の管理システムに送信し、そのシステムでログを追跡します。S3バケットでMFA削除と暗号化を有効にします。
解説
この問題は、AWSリソースへのAPIコールを監査、追跡、保存する方法に関するもので、特に AWS CloudTrail と Amazon S3 を使用したログ保存についての選択肢が提示されています。要点は、最小限の運用負荷で規制コンプライアンスを満たす方法です。
それぞれの選択肢を見ていきましょう：
A. 新しいAWS CloudTrailトレイルを作成し、既存のS3バケットにログを保存する
- メリット：
- 管理アカウントの既存のS3バケットを利用することで、追加のS3バケットを作成する必要がないため、管理がシンプルになります。
- 複数のAWSリージョンに渡ってトレイルをデプロイし、S3バケットに保存されたログに対してMFA削除と暗号化を有効にすることで、データの保護が強化されます。
- デメリット：
- 複数のアカウントがある場合、既存のS3バケットにログを保存することで、アクセス管理が複雑になる可能性があります。
B. 各メンバーアカウントにCloudTrailトレイルを作成し、個別のS3バケットにログを保存する
- メリット：
- 各アカウントごとに独立したログストレージを使用することで、アカウント間でのデータ管理やアクセス制御がしやすくなります。
- デメリット：
- 複数のS3バケットを管理する必要があり、運用負荷が増大します。特に大規模な環境では、トレイルやバケットの数が増え、管理が煩雑になります。
C. 組織の管理アカウントにCloudTrailトレイルを作成し、S3バケットでバージョン管理を有効にする
- メリット：
- 組織全体で統一されたログ保存先を使用することで、監査・管理が簡素化されます。バージョン管理を有効にすることで、ログの整合性を確保できます。
- S3の暗号化とMFA削除の設定により、高いセキュリティが確保されます。
- デメリット：
- 他のアカウントで発生したログがすべて1つのS3バケットに保存されるため、アクセス制御を適切に行わなければ情報漏洩のリスクが高まります。
D. CloudTrailトレイルを作成し、SNSで外部システムに通知を送信する
- メリット：
- SNSを使って外部の管理システムに通知を送ることで、システムがログを即時に受け取ることができます。これにより、外部監視ツールでログ追跡が可能になります。
- デメリット：
- SNSによる通知の仕組み自体は便利ですが、外部システムに依存するため、システムの構築や運用が追加の負担になります。また、SNSの設定も必要です。
最も適切な選択肢：
C. 組織の管理アカウントに新しいAWS CloudTrailトレイルを作成し、S3バケットでバージョン管理を有効にする
理由：
- 最も簡単でスケーラブルな解決策です。組織全体で統一されたS3バケットを使用し、ログのバージョン管理を有効にすることで、データの整合性を保ちながら、運用負荷を最小化できます。
- MFA削除と暗号化を有効にすることで、データの保護も強化されます。
他の選択肢は管理が複雑になったり、追加の運用負担が増えたりするため、最小の運用負荷を実現するCが最適です。
358-AWS SAP AWS 「理論・実践・一問道場」クラスタ配置グループ
理論
低遅延ネットワーキングとインスタンス配置
AWSで低遅延のネットワーキングを実現するために、インスタンスの配置方法は非常に重要です。特に、分散システムやインメモリデータベースのようなパフォーマンスが求められるアプリケーションにおいて、最適な配置を選択することがパフォーマンス向上の鍵になります。
AWSのインスタンス配置方法の種類
- パーティション配置グループ（Partition Placement Group）
- 目的: 耐障害性を向上させるため、インスタンスを異なる物理的ハードウェアに分散配置します。
- 適用シナリオ: 高可用性が求められる場合や、故障による影響を最小限に抑えたい場合に使用されますが、低遅延には向いていません。
- クラスタ配置グループ（Cluster Placement Group）
- 目的: インスタンスを物理的に近くに配置し、インスタンス間のネットワーキング遅延を最小化します。
- 適用シナリオ: 低遅延が重要なワークロード（例えば、インメモリデータベースや高速データ処理）に最適です。インスタンス間で大量の通信が発生する場合に、クラスタ配置グループを使用することでパフォーマンスを最大化できます。
- スプレッド配置グループ（Spread Placement Group）
- 目的: インスタンスを異なる物理的ハードウェアに分散し、障害が発生した場合のリスクを軽減します。
- 適用シナリオ: 高可用性が求められるが、ネットワーク遅延はあまり重要ではない場合に使用されます。
インメモリデータベースと最適なインスタンス配置
インメモリデータベースでは、データの読み書きが非常に高速であるため、インスタンス間の通信速度、つまりネットワーキング遅延がパフォーマンスに大きな影響を与えます。そのため、データの処理が大量に行われるシステムでは、クラスタ配置グループが最適です。クラスタ配置グループを使用することで、インスタンス間のネットワーキング遅延を最小限に抑え、高速なデータアクセスと処理を実現できます。
メモリ最適化インスタンス
- インメモリデータベースのようなメモリ集約型のワークロードには、メモリ最適化インスタンスが最適です。これらのインスタンスは、大量のメモリを利用するワークロードに適しており、高速なデータアクセスをサポートします。
結論
インメモリデータベースのパフォーマンス向上には、クラスタ配置グループとメモリ最適化インスタンスを使用することが最適です。この構成により、低遅延の通信と高いメモリ性能を活かしたデータベースの運用が可能となります。
実践
略
一問道場
ある企業が、Amazon EC2インスタンスのフリートに分散型インメモリデータベースをデプロイしています。このフリートは、1つのプライマリノードと8つのワーカーノードで構成されています。プライマリノードは、クラスターのヘルスを監視し、ユーザーからのリクエストを受け付け、それをワーカーノードに分配し、クライアントに集約されたレスポンスを返します。ワーカーノードは、データパーティションをレプリケートするために互いに通信します。企業は、最大のパフォーマンスを達成するために最小限のネットワーキング遅延を必要としています。
どのソリューションがこの要件を満たすでしょうか？
A. パーティション配置グループでメモリ最適化されたEC2インスタンスを起動する
B. パーティション配置グループでコンピュート最適化されたEC2インスタンスを起動する
C. クラスタ配置グループでメモリ最適化されたEC2インスタンスを起動する
D. スプレッド配置グループでコンピュート最適化されたEC2インスタンスを起動する
解説
この問題では、分散型インメモリデータベースを構成するために、低いネットワーキング遅延を達成し、最大パフォーマンスを実現するソリューションを選ぶ必要があります。
選択肢の分析：
- A. パーティション配置グループでメモリ最適化されたEC2インスタンスを起動する
- パーティション配置グループは、インスタンスが異なる物理的なハードウェアで動作することを確保するために使いますが、これは主に耐障害性を高めるためのものです。ネットワーキングの遅延を最小限にするためには最適ではありません。
- B. パーティション配置グループでコンピュート最適化されたEC2インスタンスを起動する
- パーティション配置グループは、耐障害性に重点を置いた配置方式であり、パフォーマンスの向上には向いていません。コンピュータリソースの最適化は、タスクに対する負荷を軽減するために良いですが、遅延にはあまり関係ありません。
- C. クラスタ配置グループでメモリ最適化されたEC2インスタンスを起動する
- クラスタ配置グループは、インスタンス間での低遅延ネットワーキングを提供します。この配置方法では、すべてのインスタンスが物理的に近く配置され、ノード間通信の遅延を最小限に抑えられます。分散型インメモリデータベースにおいて、ノード間の高速通信が求められるため、最適な選択です。さらに、メモリ最適化されたEC2インスタンスは、メモリ集約型のワークロードに適しており、インメモリデータベースにおいて非常に有用です。
- D. スプレッド配置グループでコンピュート最適化されたEC2インスタンスを起動する
- スプレッド配置グループは、インスタンスを異なる物理的なハードウェアに分散配置するため、耐障害性を高めますが、ネットワーク遅延を最小化するためには最適ではありません。コンピュータリソースの最適化は重要ですが、遅延の最小化には適していません。
結論：
最小のネットワーク遅延と最大のパフォーマンスを実現するためには、C. クラスタ配置グループでメモリ最適化されたEC2インスタンスを起動するが最適です。この配置では、ノード間での高速通信が可能であり、インメモリデータベースのパフォーマンスを最大化できます。
359-AWS SAP AWS 「理論・実践・一問道場」AWS DataSync
理論
1. AWS DataSync
AWS DataSyncは、大量のデータを効率的にAWSに移行するためのサービスです。オンプレミスとAWS間でデータを転送する際のデータの移行効率やスケーラビリティを大きく改善します。特に、以下のような特長があります：
- 増分バックアップ：DataSyncは、データの変更分のみを転送することで、転送時間を短縮し、コストを削減できます。
- カスタムフィルタ：特定のディレクトリやファイルのみを選んでバックアップできるため、必要なデータだけを効率的に移行可能です。
- AWS S3との統合：DataSyncはAmazon S3との密接な統合が可能で、大量のデータを低コストでストレージできます。
2. AWS Snowball Edge
AWS Snowball Edgeは、オフラインで大量のデータをAWSに転送するためのデバイスで、インターネット接続が不安定な環境や非常に大量のデータを扱う場合に便利です。初期バックアップや一度に大量のデータをAWSに移行する際に有用ですが、増分バックアップには通常使用しません。オンラインでの転送が可能な場合は、DataSyncの方が適しています。
3. AWS Backup
AWS Backupは、EC2インスタンスやEFSなどのAWSリソースのバックアップを管理するためのサービスです。オンプレミスのデータや特定のファイルシステムに対しては、AWS Backupが適切でない場合があります。そのため、S3にバックアップする際はDataSyncの方が効率的です。
4. Amazon S3
Amazon S3は、データのバックアップやアーカイブに利用される最も一般的なサービスです。特徴としては：
- 低コスト：データ量が多い場合でも、S3は非常にコスト効率の良いストレージソリューションです。
- スケーラブル：データ量が増加しても問題なく対応でき、容量を気にせずにデータを格納できます。
- セキュリティ：データの暗号化やアクセス制御が強化されており、機密性が求められるデータの保護に適しています。
5. Amazon Direct Connect
AWS Direct Connectは、オンプレミスとAWSクラウド間で高速な専用線接続を提供するサービスです。大量のデータ転送を行う際に、インターネット経由の転送よりも低レイテンシと安定性を提供します。これにより、DataSyncやAWS Snowball Edgeを補完する形で、効率的にデータをクラウドに転送することができます。
まとめ
オンプレミスのデータをAWSにバックアップするには、データのサイズ、転送速度、バックアップの頻度などに基づいて最適な方法を選ぶ必要があります。特にAWS DataSyncは、増分バックアップやカスタムフィルタを活用できるため、大量のデータを効率的にバックアップするのに最も適しています。また、AWS S3との統合により、長期的なデータの保存にも適しています。
実践
略
一問道場
問題 #359
ある企業は、約100万個の.csvファイルをVMでホストして、オンプレミスで情報を管理しています。このデータは最初に10TBのサイズがあり、毎週1TBずつ増加します。企業は、このデータをAWSクラウドに自動的にバックアップする必要があります。バックアップは毎日実行されなければなりません。企業は、指定されたソースディレクトリ内にあるデータのサブセットだけをバックアップするためのカスタムフィルタを適用する必要があります。企業はAWS Direct Connect接続を設定しています。
どのソリューションが、最も運用負荷を抑えてバックアップ要件を満たすでしょうか？
A. Amazon S3 CopyObject API操作を使用して、既存のデータをAmazon S3にコピーします。CopyObject API操作を使用して、新しいデータを毎日Amazon S3に複製します。
B. AWS Backupでバックアッププランを作成し、データをAmazon S3にバックアップします。バックアッププランを毎日実行するようにスケジュールします。
C. AWS DataSyncエージェントをオンプレミスのハイパーバイザー上で実行するVMにインストールし、DataSyncタスクを構成して、毎日データをAmazon S3に複製します。
D. 初期バックアップにはAWS Snowball Edgeデバイスを使用し、増分バックアップは毎日AWS DataSyncを使用してAmazon S3に行います。
解説
この問題では、AWSクラウドにデータをバックアップするための効率的で運用負荷の少ないソリューションを求められています。
各選択肢の解説:
A. Amazon S3 CopyObject API操作を使用して、既存のデータをAmazon S3にコピーします。CopyObject API操作を使用して、新しいデータを毎日Amazon S3に複製します。
- 問題点: CopyObject APIは、単一のオブジェクトのコピーに適しているため、大量のファイル（この場合は100万個の.csvファイル）をバックアップするには非効率的です。毎日の増分バックアップにも向いていません。
- 不適切な選択肢です。
B. AWS Backupでバックアッププランを作成し、データをAmazon S3にバックアップします。バックアッププランを毎日実行するようにスケジュールします。
- 問題点: AWS Backupは、主にEFSやRDS、EC2などのAWSネイティブリソースに対して使用されるバックアップソリューションです。ファイルシステム（.csvファイル）に対してはあまり適していません。さらに、カスタムフィルタを使った細かいバックアップ制御が難しいです。
- 不適切な選択肢です。
C. AWS DataSyncエージェントをオンプレミスのハイパーバイザー上で実行するVMにインストールし、DataSyncタスクを構成して、毎日データをAmazon S3に複製します。
- 適切な選択肢:
- AWS DataSyncは、大量のデータ移行に特化したサービスで、オンプレミスのストレージからAWS S3へのデータ転送に非常に適しています。
- カスタムフィルタを設定して、特定のディレクトリのみをバックアップすることができ、増分バックアップもサポートしています。
- 運用負荷が少なく、高い効率でデータを転送・バックアップできます。
- これにより、毎日のバックアップが自動化され、オンプレミスのデータを簡単にAWSに移行できます。
- 最適な選択肢です。
D. 初期バックアップにはAWS Snowball Edgeデバイスを使用し、増分バックアップは毎日AWS DataSyncを使用してAmazon S3に行います。
- 問題点:
- 初期バックアップにAWS Snowball Edgeは適しているかもしれませんが、増分バックアップにはDataSyncを使用する方法は、手間とコストがかかる可能性があります。
- さらに、初期バックアップとしてSnowball Edgeを使用する必要がないケース（既にAWS Direct Connectが設定されている場合）では過剰な方法です。
- 最適ではない選択肢です。
結論:
最も効率的で運用負荷が少ない方法は、C. AWS DataSyncエージェントを使用して、オンプレミスからAWS S3にデータをバックアップする方法です。この方法であれば、大量のファイルのバックアップを効率的に行い、カスタムフィルタを使って特定のディレクトリのみをバックアップすることもできます。
360-AWS SAP AWS 「理論・実践・一問道場」AWS Service Catalog
理論
AWS Service CatalogとIAMポリシーの違いは、**「誰が何を提供するか」と「誰が何をできるか」**にあります。これをもう少し具体的に分けてみます。
1. AWS Service Catalog
- 提供: 企業や組織が特定のリソースやサービスを予め定義し、そのリソースをユーザーに提供するために使用します。例えば、事前に承認されたEC2インスタンスやRDSのテンプレートを「カタログ」にして、ユーザーがそれを選んでデプロイできるようにします。
- アクセス: ユーザーは「カタログから選べる範囲」内でリソースにアクセスします。それ以上のリソースの作成や変更はできません。
例:
企業が「EC2インスタンス（t3.medium）」というテンプレートをService Catalogに登録したとします。社員はそのテンプレートを選ぶことができますが、異なるインスタンスサイズを選んだり、新しいテンプレートを追加したりはできません。提供されるリソースが限定されるという点が特徴です。
2. IAMポリシー
- 提供: これは直接的にはリソースの提供ではなく、ユーザーに対する権限を決定します。どのユーザーやグループがどのリソースにアクセスできるか、またはどの操作を実行できるかを決定するものです。
- アクセス: ユーザーが特定のリソースにアクセスするためには、適切なIAMポリシーが必要です。アクセス権限が与えられれば、リソースにアクセスできます。
例:
ある開発者に対して「S3バケットへの読み書き権限」をIAMポリシーで付与することができます。このポリシーがないと、その開発者はS3バケットにアクセスすることができません。アクセスできるリソースが制限されるという点が特徴です。
主な違い
- AWS Service Catalog: リソースそのものを「提供」する場面で使います。誰がどのリソースを使えるかを制御しますが、リソースの範囲を制限するのが主な役割です。
- IAMポリシー: アクセス権限そのものを管理する場面で使います。誰がどのリソースを操作できるか、どのアクションを実行できるかを制御します。
簡単な対比
- Service Catalog → 事前に定義したリソースを提供（リソースの「選択」肢を与える）
- IAMポリシー → ユーザーがリソースに対してアクセスする権限を設定（どの操作をできるかを管理）
このように、両者は似た目的に見えますが、提供する内容とアクセス権限の制御が異なります。
1. AWS Service Catalogの概要
AWS Service Catalogは、管理者が事前定義したリソースのカタログを作成し、それをユーザーに提供できるサービスです。これにより、企業内で使用するリソースを標準化し、利用者が事前承認されたサービスだけを選択することを促進します。ユーザーは、カタログ内から必要なリソースをデプロイし、設定に従って作業を進めることができます。
主な機能:
- リソースの標準化：管理者が承認したテンプレート（AWS CloudFormationスタックなど）を提供し、ユーザーに対してリソースの一貫性を維持します。
- アクセス管理：リソースへのアクセス権限をIAM（Identity and Access Management）と連携させて制御します。
- ガバナンス強化：コンプライアンスやセキュリティ要件に従ったリソースの利用が保証されます。
2. 最小権限の原則の適用
最小権限の原則（Principle of Least Privilege）とは、ユーザーやシステムが業務を行うために必要最小限のアクセス権を付与するセキュリティの原則です。この原則は、ユーザーが不要な権限を持たないようにすることで、誤った操作やセキュリティのリスクを減らします。
AWS Service Catalogでは、以下の方法で最小権限の原則を実現できます:
- IAMロールとの統合：ユーザーやグループに特定のサービスカタログを提供するIAMポリシーを適用し、アクセスできるリソースを制限します。これにより、ユーザーが事前に承認されたリソースのみを利用できるようにします。
- サービスの管理：管理者はユーザーがアクセスできるサービスのバージョンや設定を制限し、承認されたリソースのみを利用できるように設定できます。
3. リソースのタグ付け
AWSでは、リソースにタグを付けることで、管理・追跡・コスト分析を効率化できます。タグは、リソースの管理や監視、そしてコスト配分に役立ちます。Service Catalogを利用すると、ユーザーがデプロイしたリソースにタグを付けるように設定できます。
タグ付けの利点:
- リソースの管理：特定のプロジェクトや部門、ユーザーに関連付けたタグを利用して、リソースを簡単に追跡できます。
- コストの最適化：タグを使用してコストを分割し、特定のプロジェクトや部門に関連するコストを管理できます。
- コンプライアンスと監査：タグを利用してリソースの利用状況を監査し、コンプライアンス要件に沿って管理できます。
4. 他のツールとの統合
AWS Service Catalogは、他のAWSサービスと連携してさらに強力なリソース管理を提供します。例えば、AWS CloudFormationと統合することで、スタックベースのデプロイを管理し、インフラのコード化（Infrastructure as Code）を実現できます。また、AWS Configと組み合わせることで、リソースの状態を監視し、準拠性をチェックできます。
5. AWS Service Catalogの利用シーン
- 大規模な企業でのリソース管理：企業内で多くのAWSリソースを使う場合に、リソースの標準化とアクセス制御を行うために役立ちます。
- セキュリティとコンプライアンス管理：セキュリティポリシーに準拠したリソース管理が求められる環境で、承認されたリソースのみを使わせることができます。
- コスト管理：部署やプロジェクトごとにリソースを利用し、タグ付けしてコストを追跡しやすくします。
結論
AWS Service Catalogは、最小権限の原則やリソース管理の実現に非常に有効なツールです。特に、企業規模でのリソース標準化やアクセス制御、コスト最適化に役立つため、効率的なガバナンスを実現するために広く利用されています。
実践
略
一問道場
問題 #360
ある金融サービス会社が提供する資産管理製品は、世界中の多くの顧客に利用されています。顧客は製品に対するフィードバックをアンケート形式で提供します。この会社は、これらのアンケートデータを分析するためにAmazon EMRを使った新しい分析ソリューションを構築しています。以下のユーザーが異なる作業を行うために、この分析ソリューションにアクセスする必要があります：
- 管理者：分析チームの要件に基づいてEMRクラスターを設定します。
- データエンジニア：ETLスクリプトを実行してデータを処理、変換、強化します。
- データアナリスト：データに対してSQLやHiveクエリを実行します。
ソリューションアーキテクトは、各ユーザーが必要なリソースにのみアクセスできるように最小権限の原則を適用しなければなりません。また、ユーザーが起動できるアプリケーションは承認されているものでなければなりません。さらに、ユーザーが作成したリソースにはタグ付けが必要です。
これらの要件を満たす解決策はどれですか？
A. 各ユーザー用にIAMロールを作成し、それぞれのロールに適切なアクセス権限を付与します。AWS Configルールを使用して、準拠していないリソースを検出し、管理者に通知します。
B. EMRクラスターを起動する際に、Kerberos認証を設定し、クラスター固有のセキュリティオプションを指定します。
C. AWS Service Catalogを使用して、利用可能なEMRのバージョン、クラスター設定、各ユーザーの権限を管理します。
D. AWS CloudFormationでEMRクラスターを起動し、リソースベースのポリシーをクラスターに適用します。AWS Configルールを作成して、準拠していないリソースについて管理者に通知します。
正解
正解はCの「AWS Service Catalogを使用する」です。
解説：
C. AWS Service Catalogを使用する
- 適切な選択肢です。
- AWS Service Catalogは、ユーザーがデプロイできるリソース（ここではAmazon EMRのバージョンやクラスター設定）を事前に定義して管理することができます。これにより、承認されたアプリケーションやリソースのみがユーザーに提供され、適切なアクセス権限を持ったユーザーにリソースを制限できます。
- また、AWS Service Catalogでは、リソースにタグをつける機能が組み込まれており、ユーザーが作成したリソースにタグを付けることが容易に行えます。これにより、リソースの管理とコストの追跡がしやすくなります。
- この解決策では、ユーザーごとに適切なリソースの提供と、リソースの適切なタグ付けができ、最小権限の原則も適用されます。
他の選択肢に関する理由：
A. IAMロールとAWS Configルールを使用する
- IAMロールやAWS Configルールも適切なアクセス制御や準拠性管理を提供しますが、特にアプリケーションのバージョン管理や設定を制限する機能が不十分です。この解決策は、ユーザーがアクセスするリソースを管理するための一つの方法にはなりますが、リソース自体の提供方法としては不完全です。
B. Kerberos認証を設定する
- Kerberosは主にセキュリティ強化のための認証技術で、ユーザーアクセス制御やリソースタグ付けには関連しません。したがって、この選択肢は要件を満たしません。
D. AWS CloudFormationとAWS Configを使用する
- AWS CloudFormationはインフラのデプロイには適していますが、個別のリソース管理やユーザー権限の制御には柔軟性が不足しています。これにより、リソースの管理やタグ付けには適切ではありません。
結論：
AWS Service Catalogを使用する選択肢が、リソースの管理、タグ付け、ユーザー権限の最小化という要件に最も適しており、解決策として正解です。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/177d7ae8-88e2-801f-94f3-ea55ed877aa3
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
