type
status
date
slug
summary
tags
category
icon
password
书籍
101-サービスロール
理論
AWSで複数のアカウント間でデータを共有する際、セキュリティとアクセス管理が重要です。特に、S3バケットへのアクセスとその暗号化には、IAMポリシー、S3バケットポリシー、KMSキー管理が関わります。
- IAMロールとポリシー: AWSでは、異なるアカウント間でリソースにアクセスするためにIAMロールとポリシーを使用します。これにより、どのユーザーやサービスが特定のリソースにアクセスできるかを細かく制御できます。
- S3バケットポリシー: S3バケットポリシーは、バケットに対するアクセス許可を管理するためのもので、アクセス元アカウントやIAMロールを指定することができます。これにより、外部アカウントからの安全なアクセスが可能になります。
- KMSキー管理: S3バケットがKMS（Key Management Service）で暗号化されている場合、暗号化キーのアクセス権限も管理する必要があります。これにより、他のアカウントが暗号化されたデータを復号する際のアクセスを制御します。
これらの管理は、最小限の運用負荷でセキュアなアクセスを確保するために、適切に設定される必要があります。
一問道場
質問 #101
トピック 1
ある会社は、AWSのマルチアカウント環境でアプリケーションを実行しています。営業チームとマーケティングチームはAWS Organizationsで別々のAWSアカウントを使用しています。
営業チームはペタバイト規模のデータをAmazon S3バケットに保存しています。マーケティングチームは、データの可視化のためにAmazon QuickSightを使用しています。マーケティングチームは、営業チームがS3バケットに保存したデータにアクセスする必要があります。会社は、S3バケットをAWS Key Management Service (AWS KMS)キーで暗号化しています。マーケティングチームはすでにQuickSight用のIAMサービスロールを作成し、マーケティングAWSアカウントでQuickSightアクセスを提供しています。会社は、AWSアカウント間でS3バケットのデータに安全にアクセスできるソリューションを必要としています。
どのソリューションが、最も運用上のオーバーヘッドを最小限に抑えながらこれらの要件を満たすでしょうか？
A. マーケティングアカウントに新しいS3バケットを作成します。営業アカウントでS3レプリケーションルールを作成して、営業アカウントのオブジェクトをマーケティングアカウントの新しいS3バケットにコピーします。QuickSightの権限をマーケティングアカウントで更新して、新しいS3バケットへのアクセスを許可します。
B. SCP（サービスコントロールポリシー）を作成して、S3バケットへのマーケティングアカウントのアクセスを許可します。AWSリソースアクセスマネージャー（AWS RAM）を使用して、営業アカウントからマーケティングアカウントにKMSキーを共有します。QuickSightの権限をマーケティングアカウントで更新して、S3バケットへのアクセスを許可します。
C. マーケティングアカウントのS3バケットポリシーを更新して、QuickSightロールにアクセスを許可します。S3バケットで使用されている暗号化キーのためにKMS権限を作成します。QuickSightロールに復号化アクセスを許可します。QuickSightの権限をマーケティングアカウントで更新して、S3バケットへのアクセスを許可します。
D. 営業アカウントにIAMロールを作成し、S3バケットへのアクセスを許可します。マーケティングアカウントから、営業アカウントのIAMロールを引き受けてS3バケットにアクセスします。QuickSightロールを更新して、営業アカウントの新しいIAMロールとの信頼関係を作成します。
解説
この質問は、AWSアカウント間でデータを安全にアクセスする方法を尋ねており、具体的には、営業チームが保持しているS3バケットのデータにマーケティングチームがアクセスできる方法を問うものです。AWS KMS（Key Management Service）を使用してデータが暗号化されており、マーケティングチームはQuickSightを使ってデータを可視化するためにアクセスが必要です。
解説を順に見ていきます。
A. 新しいS3バケットを作成し、レプリケーションを使用する
- 新しいS3バケットを作成し、営業アカウントのデータをレプリケーションルールでマーケティングアカウントにコピーするという方法です。これにより、データは2つのバケットに複製され、マーケティングチームがアクセスできるようになります。
- 問題点: データのレプリケーションには運用コストがかかり、また、常に最新のデータを同期する必要があるため、オーバーヘッドが増えます。また、暗号化されたデータのキー共有に関する設定も別途必要になります。
- 結論: この方法は運用負荷が高いため、最小限のオーバーヘッドを求める要件に合いません。
B. SCPを使用してアクセスを許可し、AWS RAMでKMSキーを共有する
- *SCP（サービスコントロールポリシー）**を使って、営業アカウントのS3バケットへのアクセスをマーケティングアカウントに許可します。そして、**AWSリソースアクセスマネージャー（AWS RAM）**を使用して、営業アカウントのKMSキーをマーケティングアカウントに共有します。
- 問題点: SCPはAWS Organizations全体のポリシーを制御するため、他のアカウントにアクセスを許可することが目的であれば、細かな権限設定が必要となります。KMSキーを共有する部分も設定が煩雑で、管理が少し複雑になる可能性があります。
- 結論: この方法は理論的に可能ですが、設定が複雑になりやすく、最小限のオーバーヘッドを要求する要件には最適ではありません。
C. S3バケットポリシーとKMS権限を更新する
- S3バケットポリシーを更新して、QuickSightロールにアクセス権を付与します。また、KMS権限を作成し、QuickSightロールに復号化の権限を付与します。
- メリット: この方法は、必要なアクセス権をバケットポリシーとKMSキーの設定で直接管理するため、比較的簡単に実装できます。QuickSightは既にマーケティングアカウントで設定されているため、追加の設定が少なく済みます。
- 結論: この方法は、S3バケットへのアクセスとKMSキーの設定を適切に行うことで、最小限のオーバーヘッドで安全にアクセスを提供できます。最も効率的でシンプルな解決策です。
D. IAMロールを使用してアクセスする
- 営業アカウントにIAMロールを作成し、そのロールをマーケティングアカウントで引き受けてS3バケットにアクセスします。QuickSightロールには、営業アカウントのIAMロールとの信頼関係を設定します。
- 問題点: この方法では、IAMロールの作成と引き受けの手順が必要で、追加の設定が発生します。特に、IAMロールの信頼関係やQuickSightの設定に手間がかかる可能性があります。
- 結論: この方法は機能的には問題ありませんが、設定が比較的複雑で運用のオーバーヘッドが増えるため、最小限のオーバーヘッドを求める要件には不向きです。
結論
最も運用負荷が少なく、要件を満たすのはCの方法です。この方法では、S3バケットポリシーとKMSの設定を適切に行うことで、マーケティングチームのQuickSightロールに安全にアクセスを許可することができます。
102-データベース移行
理論
AWSで異種データベース移行を行う際、重要な要素として以下のツールと手法があります。
- AWS Schema Conversion Tool (SCT)
SCTは、異なるデータベース間でスキーマを変換するツールです。例えば、Microsoft SQL ServerからMySQLへのスキーマ移行に使用されます。SCTはテーブル構造やインデックス、ビューなどを新しいデータベースに適応させるために必要な変更を自動的に行います。
- AWS Database Migration Service (DMS)
DMSは、実際のデータ移行を担当します。DMSを使用すると、ソースデータベースからターゲットデータベースへデータをリアルタイムで移行することができます。データ移行中にダウンタイムを最小限に抑えながら、データの整合性を保つことができます。
- 異種データベース移行の考慮事項
異種データベース移行（例：SQL ServerからMySQLへの移行）では、データ型の互換性、インデックスの最適化、ストアドプロシージャやトリガーの変換などが課題となります。これらはSCTを使用して処理できますが、手動での調整が必要な場合もあります。
- 移行ツールの選択
データ転送のためには、AWS DMSが最適です。これはデータのリアルタイム移行に特化しており、異種データベース間でのデータ移行をスムーズに行えます。また、大規模なデータ移行が必要な場合、SnowballやDataSyncなどを補完的に利用することもありますが、スキーマ変換にはDMSとSCTの組み合わせが主に推奨されます。
これらのツールを適切に組み合わせることで、異なるデータベース間の移行を効率的かつ安全に実行することができます。
一問道場
質問 #102
トピック 1
ある企業は、ビジネスに重要なアプリケーションをオンプレミスのデータセンターからAWSに移行する予定です。この企業は、オンプレミスにMicrosoft SQL Server Always Onクラスタをインストールしています。企業は、AWSのマネージドデータベースサービスに移行したいと考えています。ソリューションアーキテクトは、AWSでの異種データベース移行を設計する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. SQL ServerデータベースをAmazon RDS for MySQLに移行するために、バックアップとリストアユーティリティを使用する。
B. AWS Snowball Edge Storage Optimizedデバイスを使用してデータをAmazon S3に転送し、Amazon RDS for MySQLを設定する。SQL Serverの機能（例えばBULK INSERT）との統合を使用する。
C. AWS Schema Conversion Toolを使用してデータベースのスキーマをAmazon RDS for MySQLに変換し、その後AWS Database Migration Service（AWS DMS）を使用してオンプレミスのデータベースからAmazon RDSにデータを移行する。
D. AWS DataSyncを使用してオンプレミスのストレージとAmazon S3間でデータをネットワーク越しに移行し、Amazon RDS for MySQLを設定する。S3との統合を使用してSQL Serverの機能（例えばBULK INSERT）を使用する。
解説
この問題は、オンプレミスのSQL ServerデータベースをAWSのマネージドデータベースサービスに移行する方法に関するものです。異種データベース移行を行うために、AWSのツールとサービスを使用する方法を選ぶ必要があります。
各選択肢の解説
A. バックアップとリストアでの移行
- SQL ServerからMySQLへの移行は、バックアップとリストアではなく、データベース間の互換性を考慮したツールが必要です。MySQLに移行するのは適切ではありません。
- 不適切な選択肢。
B. Snowball Edgeを使用した移行
- Snowball Edgeは大量のデータを物理的に転送するためのデバイスで、データの転送に便利ですが、SQL ServerからMySQLへの移行には直接的な方法が不足しています。
- 不適切な選択肢。
C. AWS Schema Conversion Tool（SCT）とDMSを使用する
- SCTを使ってSQL ServerのスキーマをMySQLに変換し、DMSを使ってデータを移行する方法が一般的な異種データベース移行のベストプラクティスです。この方法は、異なるデータベース間でのスキーマとデータの移行に最適です。
- 最適な選択肢。
D. DataSyncを使用してS3にデータ転送
- DataSyncはデータを高速で転送するツールですが、SQL ServerからMySQLへの移行において、S3を中継するアプローチは効率的ではなく、DMSを使用する方が適切です。
- 不適切な選択肢。
結論
最適な方法は C の「AWS Schema Conversion ToolとDMSを使用してデータベーススキーマとデータを移行する方法」です。
103-STS:AssumeRole
一問道場
質問 #103
トピック 1
ある出版会社のデザインチームは、eコマースWebアプリケーションで使用されるアイコンやその他の静的アセットを更新します。同社は、静的アセットを同社の本番アカウントでホストされているAmazon S3バケットから配信しています。また、開発アカウントも使用しており、デザインチームのメンバーはそのアカウントにアクセスできます。
デザインチームが開発アカウントで静的アセットをテストした後、デザインチームはそれらのアセットを本番アカウントのS3バケットにロードする必要があります。ソリューションアーキテクトは、Webアプリケーションの他の部分に不要な変更のリスクをさらすことなく、デザインチームに本番アカウントへのアクセスを提供する必要があります。
どの手順の組み合わせがこれらの要件を満たしますか？（3つ選んでください）
A. 本番アカウントで、新しいIAMポリシーを作成して、S3バケットへの読み取りおよび書き込みアクセスを許可します。
B. 開発アカウントで、新しいIAMポリシーを作成して、S3バケットへの読み取りおよび書き込みアクセスを許可します。
C. 本番アカウントでロールを作成し、新しいポリシーをそのロールにアタッチします。開発アカウントを信頼されたエンティティとして定義します。
D. 開発アカウントでロールを作成し、新しいポリシーをそのロールにアタッチします。本番アカウントを信頼されたエンティティとして定義します。
E. 開発アカウントで、デザインチームのすべてのIAMユーザーを含むグループを作成し、そのグループに、STS:AssumeRoleアクションを本番アカウントのロールに対して許可する別のIAMポリシーをアタッチします。
F. 開発アカウントで、デザインチームのすべてのIAMユーザーを含むグループを作成し、そのグループに、開発アカウント内のロールに対してSTS:AssumeRoleアクションを許可する別のIAMポリシーをアタッチします。
解説
このシナリオでは、デザインチームが本番アカウントのS3バケットにアクセスするために適切な手順を選ぶ必要があります。最小限の変更でアクセスを提供する方法を選びます。
正解となる手順:
- A. 本番アカウントで、新しいIAMポリシーを作成して、S3バケットへの読み取りおよび書き込みアクセスを許可: 本番アカウントにアクセス権を付与するために、適切なポリシーを作成します。
- C. 本番アカウントでロールを作成し、新しいポリシーをそのロールにアタッチします。開発アカウントを信頼されたエンティティとして定義: 本番アカウントでロールを作成し、開発アカウントからそのロールを引き受けることを許可する設定を行います。
- E. 開発アカウントで、デザインチームのすべてのIAMユーザーを含むグループを作成し、そのグループに、STS:AssumeRoleアクションを本番アカウントのロールに対して許可する別のIAMポリシーをアタッチ: 開発アカウントのIAMユーザーが本番アカウントのロールを引き受けるための権限を付与します。
解説:
- A と C により、本番アカウントにおけるS3バケットへの適切なアクセス権とロール設定が行われます。
- E により、開発アカウントのデザインチームが本番アカウントのロールを引き受ける権限を持つことができます。
これらの手順により、デザインチームは本番アカウントのS3バケットにアクセスでき、不要な変更を避けることができます。
104-Elastic Beanstalk環境タイプ
理論
AWS Elastic Beanstalkにおけるスケーリングと負荷分散の仕組みについてです。具体的には、アプリケーションのパフォーマンスが低下する要因を理解し、それに対処するための最適な方法として、オートスケーリングと負荷分散を使用する方法を学ぶことが重要です。以下に、関連する主要な概念を紹介します。
1. AWS Elastic Beanstalkの基本
AWS Elastic Beanstalkは、アプリケーションのデプロイ、管理、スケーリングを簡素化するフルマネージドサービスです。開発者はコードをアップロードするだけで、Elastic Beanstalkが環境をセットアップし、必要なリソース（EC2インスタンス、ロードバランサー、データベースなど）を管理します。
2. スケーリングの概念
Elastic Beanstalkは、オートスケーリング機能を提供しており、アプリケーションのトラフィックや負荷の変動に応じて、インスタンスの数を自動的に増減させることができます。これにより、負荷が増加した場合でもアプリケーションのパフォーマンスを維持することが可能です。
- スケールアウト: インスタンス数を増加させて、アプリケーションの処理能力を拡張します。
- スケールイン: 不要なインスタンスを削除してコストを削減します。
3. CPU使用率とスケーリングの設定
アプリケーションが高いCPU使用率（例えば、85％を超える）を維持している場合、サーバーのパフォーマンスが低下し、レスポンスが遅くなる可能性があります。この問題を解決するためには、オートスケーリングルールを設定して、CPU使用率が一定の閾値（例えば、85％）を超えた場合に新しいインスタンスを追加するようにします。
- スケールアウトルール: CPU使用率やメモリ使用量などのメトリクスに基づいて、インスタンス数を増やすトリガーを設定します。例えば、CPU使用率が85％を超えて5分間続いた場合にスケールアウトを実行するなど。
4. 負荷分散の設定
Elastic Beanstalkはロードバランサーを組み込んでおり、トラフィックを複数のインスタンスに分散させることで、個々のインスタンスにかかる負荷を均等にします。これにより、アプリケーションのパフォーマンスを安定させ、可用性を向上させます。
- ロードバランシング環境: 負荷分散を使用することで、複数のEC2インスタンスが均等にトラフィックを処理し、特定のインスタンスに過負荷がかかるのを防ぎます。
5. Elastic Beanstalk環境タイプの選択
Elastic Beanstalkでは、環境タイプを選択する際に単一インスタンス環境とロードバランス環境があります。単一インスタンス環境はコスト効率が高いですが、スケーラビリティが制限されるため、高トラフィックなアプリケーションではパフォーマンスに問題が生じやすいです。一方、ロードバランス環境を使用することで、アプリケーションが自動的にスケールアウトし、トラフィックの増加に対応できます。
6. Elastic Beanstalkの運用負荷の最小化
Elastic Beanstalkの利点の一つは、運用負荷を最小化できる点です。環境のスケーリングや負荷分散の設定は、Elastic Beanstalkのダッシュボードやコンソールで簡単に行うことができ、複雑なインフラ管理をAWSが代行してくれます。
一問道場
質問 #104
トピック 1
ある企業がAWS Elastic BeanstalkとJavaを使用してパイロットアプリケーションを開発しました。開発中のコスト削減のため、企業の開発チームはアプリケーションを単一インスタンス環境にデプロイしました。最近のテストでは、アプリケーションが予想以上にCPUを多く消費していることが分かりました。CPU使用率は定期的に85％を超えており、これがパフォーマンスのボトルネックを引き起こしています。
ソリューションアーキテクトは、企業がアプリケーションを本番環境に投入する前に、パフォーマンスの問題を軽減する必要があります。
最小の運用負荷でこれらの要件を満たす解決策はどれですか？
A. 新しいElastic Beanstalkアプリケーションを作成し、ロードバランス環境タイプを選択します。すべてのアベイラビリティゾーンを選択します。CPU使用率が85％を超えて5分間続く場合に実行されるスケールアウトルールを追加します。
B. 新しいElastic Beanstalk環境を作成し、トラフィックスプリット展開ポリシーを適用します。CPU使用率が85％を超えて5分間続く場合、受信トラフィックの一定割合を新しい環境に送信するよう指定します。
C. 既存の環境のキャパシティ設定を変更し、ロードバランス環境タイプを使用します。すべてのアベイラビリティゾーンを選択します。平均CPU使用率が85％を超えて5分間続く場合に実行されるスケールアウトルールを追加します。
D. リビルド環境アクションを選択し、ロードバランスオプションを選択します。アベイラビリティゾーンを選択します。CPU使用率の合計が85％を超えて5分間続く場合に実行されるスケールアウトルールを追加します。
解説
この問題では、AWS Elastic Beanstalkでアプリケーションのパフォーマンスを改善する方法が問われています。具体的には、CPU使用率が高く、アプリケーションのパフォーマンスが低下しているため、スケーリングと負荷分散を利用して、インスタンス数を自動的に増やす必要があります。
最適な解決策は、ロードバランス環境を使って複数のインスタンスに負荷を分散させ、スケーリングルールを設定して、CPU使用率が85％を超えた場合に新しいインスタンスを追加することです。この方法は、運用負荷が少なく、シンプルかつ効果的です。
選択肢Cが最も適切で、既存の環境の設定を変更することで、必要なスケーリングと負荷分散を実現できます。
105-自己管理型のMySQL
理論
AWSのパフォーマンス最適化
AWSでのデータベースやアプリケーションのパフォーマンスを最適化するためには、負荷分散、スケーリング、ストレージのパフォーマンス向上の3つの側面を考慮することが重要です。
- スケーリングと負荷分散
負荷が増加する状況に対処するためには、Auto Scalingや**Elastic Load Balancing (ELB)**を使用してインスタンス数を動的に調整し、トラフィックを適切に分散させます。これにより、リクエストの処理能力を高め、システム全体のパフォーマンスを向上させることができます。
- データベースのパフォーマンス向上
データベースのパフォーマンスがボトルネックになることがあります。特に、I/O操作が多いMySQLのようなデータベースでは、ストレージの種類がパフォーマンスに大きな影響を与えます。Amazon RDS（Relational Database Service）は、マネージドサービスで、データベースの運用を簡素化し、負荷に応じてリードレプリカを追加することができます。これにより、読み取り負荷を分散させ、月末などのピーク時の負荷にも対応できます。
- ストレージの最適化
データベースのパフォーマンスはストレージの性能にも依存します。AWSのEBSボリュームには、**GP2（汎用）とPIOPS（プロビジョンドIOPS）**などのオプションがあります。I/O負荷が高いアプリケーションには、PIOPSボリュームを使用することで、より高速なデータアクセスが可能となり、パフォーマンスの向上が期待できます。
一問道場
問題 #105
トピック 1
ある金融会社は、現在世代のLinux EC2インスタンス上でビジネスクリティカルなアプリケーションを運用しています。このアプリケーションには、I/O操作が多い自己管理型のMySQLデータベースが含まれています。アプリケーションは月の間の中程度のトラフィックに問題なく対応していますが、月末の報告時にトラフィックが増加するため、月末の最後の3日間はパフォーマンスが低下します。会社はElastic Load BalancersとAuto Scalingをインフラに使用していますが、それでもパフォーマンスに影響があります。
次のうち、データベースが月末の負荷を最小限のパフォーマンス影響で処理できるようにするためには、どのアクションを取るべきでしょうか？
A. Elastic Load Balancersを事前にウォームアップし、インスタンスタイプを大きくし、すべてのAmazon EBSボリュームをGP2ボリュームに変更する。
B. データベースクラスターをAmazon RDSに一度だけ移行し、月末の負荷を処理するためにいくつかのリードレプリカを作成する。
C. Amazon CloudWatchとAWS Lambdaを使用して、CloudWatchメトリクスに基づいてクラスター内のAmazon EBSボリュームのタイプ、サイズ、またはIOPSを変更する。
D. すべての既存のAmazon EBSボリュームを新しいPIOPSボリュームに置き換え、最大のストレージサイズとI/O秒ごとに最大のパフォーマンスを提供するように、月末前にスナップショットを取り、その後に元に戻す。
解説
この問題では、月末の負荷増加に対応するためのデータベースパフォーマンス改善策を選ぶ必要があります。具体的には、I/O操作が多いMySQLデータベースがパフォーマンス低下を起こす原因を特定し、それに対処するための最適なソリューションを選ぶことが求められています。
各選択肢の分析
- A. Elastic Load Balancersを事前にウォームアップし、インスタンスタイプを大きくし、すべてのAmazon EBSボリュームをGP2ボリュームに変更する。
- ウォームアップはロードバランサーに対するトラフィックの負荷を減らす効果があるかもしれませんが、データベースのI/O性能の問題には直接関係がありません。また、インスタンスタイプを大きくしても、データベース自体のストレージのパフォーマンスには限界があるため、効果的な解決策とは言えません。
- B. データベースクラスターをAmazon RDSに一度だけ移行し、月末の負荷を処理するためにいくつかのリードレプリカを作成する。
- Amazon RDSはマネージドサービスであり、自動バックアップ、スケーラビリティ、パッチ管理などを提供します。さらに、リードレプリカを使用することで、読み取り専用の負荷を分散させ、データベースのパフォーマンス向上が期待できます。このアプローチは、月末の報告に伴う高負荷を効果的に処理できる可能性があります。
- C. Amazon CloudWatchとAWS Lambdaを使用して、CloudWatchメトリクスに基づいてクラスター内のAmazon EBSボリュームのタイプ、サイズ、またはIOPSを変更する。
- Amazon CloudWatchとAWS Lambdaを使って、動的にEBSボリュームを変更する方法は、非常に柔軟ですが、月末の負荷に即座に対応するには管理が複雑で、パフォーマンスに即効性がない場合があります。さらに、EBSボリュームのサイズやタイプを変更するには時間がかかるため、月末のピーク時には間に合わない可能性があります。
- D. すべての既存のAmazon EBSボリュームを新しいPIOPSボリュームに置き換え、最大のストレージサイズとI/O秒ごとに最大のパフォーマンスを提供するように、月末前にスナップショットを取り、その後に元に戻す。
- PIOPSボリュームは高性能なストレージオプションであり、I/O負荷が高いアプリケーションに適しています。しかし、月末前にスナップショットを取って置き換える方法は、運用に手間がかかり、スナップショットを取る際のダウンタイムや、月末後に戻す手間が発生します。この方法は実装が煩雑で、効果的とは言えません。
最適な解決策
B. データベースクラスターをAmazon RDSに一度だけ移行し、月末の負荷を処理するためにいくつかのリードレプリカを作成するが最適です。
RDSに移行することで、データベースの管理が簡素化され、リードレプリカを活用して読み取り負荷を分散することができるため、月末の高負荷時にもデータベースのパフォーマンスが維持されます。また、RDSはスケーラブルで、負荷が高い場合に自動的にリソースを追加することができるため、最小の管理オーバーヘッドでパフォーマンス向上を実現できます。
106-AWS App2Container
理論
AWS App2Container は、オンプレミスのアプリケーションをAWSに移行するためのツールです。このツールを使うことで、既存のアプリケーションをコンテナ化し、AWSのクラウド環境に簡単にデプロイできるようにします。
具体的には、AWS App2Containerは以下のことをサポートします：
- アプリケーションの検出と解析
オンプレミスのアプリケーションをスキャンし、その構成や依存関係を分析します。これにより、アプリケーションをどのようにコンテナ化するかの計画を立てることができます。
- コンテナ化の自動化
アプリケーションのソースコードやバイナリを元に、コンテナ化するための設定を自動的に生成します。例えば、アプリケーションが依存するライブラリやリソースをコンテナ内で正しく動作させるための構成ファイルを作成します。
- AWS上へのデプロイ
作成したコンテナイメージを、Amazon Elastic Container Registry (ECR)に保存し、Amazon Elastic Container Service (ECS)やAmazon Elastic Kubernetes Service (EKS)などのサービスを使用して、AWSクラウドにデプロイします。
- 既存のアプリケーションの継続的な運用
コンテナ化されたアプリケーションは、スケーラビリティや高可用性を持たせやすく、AWSのマネージドサービスとの統合が可能になります。これにより、アプリケーションの運用管理が容易になります。
簡単に言うと、AWS App2Container は、オンプレミス環境にある既存のアプリケーションを迅速にコンテナ化し、AWSのマネージド環境に移行するためのツールです。これにより、インフラ管理の手間を削減し、クラウドネイティブなアーキテクチャへの移行を簡素化します。
一問道場
質問 #106
トピック 1
ある企業が、データセンターにあるVMに依存する複雑なJavaアプリケーションを運用しています。アプリケーションは安定していますが、企業は技術スタックの近代化を望んでおり、アプリケーションをAWSに移行してサーバーの管理負担を最小化したいと考えています。
最小限のコード変更でこの要件を満たすソリューションはどれですか？
A. AWS App2Containerを使用してアプリケーションをAmazon Elastic Container Service (Amazon ECS)にAWS Fargateで移行します。コンテナイメージはAmazon Elastic Container Registry (Amazon ECR)に保存します。ECSタスク実行ロールにECRイメージリポジトリへのアクセス権限を付与します。Amazon ECSを構成して、アプリケーションに対してApplication Load Balancer (ALB)を使用します。ALBを使用してアプリケーションとやり取りします。
B. アプリケーションコードをコンテナに移行し、AWS Lambdaで実行します。Amazon API Gateway REST APIをLambda統合で構築します。API Gatewayを使用してアプリケーションとやり取りします。
C. AWS App2Containerを使用してアプリケーションをAmazon Elastic Kubernetes Service (Amazon EKS)に移行します。EKS管理ノードグループでコンテナイメージをAmazon Elastic Container Registry (Amazon ECR)に保存します。EKSノードにECRイメージリポジトリへのアクセス権限を付与します。Amazon API Gatewayを使用してアプリケーションとやり取りします。
D. アプリケーションコードをコンテナに移行し、AWS Lambdaで実行します。Lambdaを構成してApplication Load Balancer (ALB)を使用します。ALBを使用してアプリケーションとやり取りします。
解説
AWS App2Container は、オンプレミスのアプリケーションをAWSに移行するためのツールです。このツールを使うことで、既存のアプリケーションをコンテナ化し、AWSのクラウド環境に簡単にデプロイできるようにします。
具体的には、AWS App2Containerは以下のことをサポートします：
- アプリケーションの検出と解析
オンプレミスのアプリケーションをスキャンし、その構成や依存関係を分析します。これにより、アプリケーションをどのようにコンテナ化するかの計画を立てることができます。
- コンテナ化の自動化
アプリケーションのソースコードやバイナリを元に、コンテナ化するための設定を自動的に生成します。例えば、アプリケーションが依存するライブラリやリソースをコンテナ内で正しく動作させるための構成ファイルを作成します。
- AWS上へのデプロイ
作成したコンテナイメージを、Amazon Elastic Container Registry (ECR)に保存し、Amazon Elastic Container Service (ECS)やAmazon Elastic Kubernetes Service (EKS)などのサービスを使用して、AWSクラウドにデプロイします。
- 既存のアプリケーションの継続的な運用
コンテナ化されたアプリケーションは、スケーラビリティや高可用性を持たせやすく、AWSのマネージドサービスとの統合が可能になります。これにより、アプリケーションの運用管理が容易になります。
簡単に言うと、AWS App2Container は、オンプレミス環境にある既存のアプリケーションを迅速にコンテナ化し、AWSのマネージド環境に移行するためのツールです。これにより、インフラ管理の手間を削減し、クラウドネイティブなアーキテクチャへの移行を簡素化します。
107-Route 53 ェイルオーバー
理論
AWS Lambda と API Gateway を使って、アプリケーションのリージョン間フェイルオーバーを実現する方法。フェイルオーバーとは、あるリージョンでサービスが停止した場合に、別のリージョンにトラフィックを切り替えてサービスを継続させる仕組みです。
主なポイント:
- Route 53 のフェイルオーバールーティングポリシーを使って、トラフィックを複数のリージョンに分散し、1つのリージョンがダウンした際に他のリージョンに切り替える。
- AWS Lambda と API Gateway を複数のリージョンにデプロイし、Route 53 で自動的にトラフィックを切り替えることで、アプリケーションの可用性を高める。
この方法で、障害発生時でもサービスを継続できます。
一問道場
質問 #107
トピック 1
ある会社は、非同期のHTTPアプリケーションをAWS Lambda関数としてホストしています。パブリックなAmazon API GatewayエンドポイントがそのLambda関数を呼び出します。Lambda関数とAPI Gatewayエンドポイントはus-east-1リージョンに配置されています。ソリューションアーキテクトは、別のAWSリージョンへのフェイルオーバーをサポートするようにアプリケーションを再設計する必要があります。
次のうち、要件を満たす解決策はどれですか？
A. us-west-2リージョンにAPI Gatewayエンドポイントを作成し、トラフィックをus-east-1のLambda関数にルーティングします。Amazon Route 53を使用してフェイルオーバールーティングポリシーを設定し、2つのAPI Gatewayエンドポイントへのトラフィックをルーティングします。
B. Amazon Simple Queue Service（Amazon SQS）キューを作成します。API Gatewayを設定して、Lambda関数ではなくSQSキューにトラフィックを送信します。Lambda関数がキューからメッセージをプルして処理するように設定します。
C. Lambda関数をus-west-2リージョンにデプロイします。us-west-2にAPI Gatewayエンドポイントを作成し、トラフィックをそのLambda関数に送信します。AWS Global AcceleratorとApplication Load Balancerを設定して、2つのAPI Gatewayエンドポイント間でトラフィックを管理します。
D. Lambda関数とAPI Gatewayエンドポイントをus-west-2リージョンにデプロイします。Amazon Route 53を使用してフェイルオーバールーティングポリシーを設定し、2つのAPI Gatewayエンドポイントへのトラフィックをルーティングします。
解説
正解は D です。
解説:
- A: この解決策では、us-west-2リージョンにAPI Gatewayを作成し、トラフィックをus-east-1のLambda関数にルーティングする方法です。しかし、Lambda関数がus-east-1にしか存在しないため、フェイルオーバーを実現できません。これでは、別のリージョンにLambda関数が配置されていない限り、フェイルオーバーが機能しません。
- B: SQSを使ってLambda関数にメッセージをプルさせる方法ですが、これはフェイルオーバーの目的には適していません。SQSはメッセージの管理には便利ですが、リージョン間のフェイルオーバーを管理する方法としては不十分です。
- C: Lambda関数を別リージョン（us-west-2）にデプロイし、Global AcceleratorやALBを使ってトラフィックを管理する方法ですが、これは過剰な設定です。Global AcceleratorやALBは、リージョン間でトラフィックを管理するために使用されることが多いですが、Route 53を使って単純にフェイルオーバーを設定する方が簡便で効率的です。
- D: Lambda関数とAPI Gatewayをus-west-2にデプロイし、Route 53のフェイルオーバールーティングポリシーを使用してトラフィックをルーティングする方法です。これにより、us-east-1のリージョンがダウンした場合に、us-west-2にトラフィックを切り替えることができます。この方法が最もシンプルで効果的にフェイルオーバーを実現できます。
正解は D です。
108-統合請求
理論
AWSの組織構成、RI（リザーブドインスタンス）割引、請求管理、そしてAWS Organizationsの利用方法
1. AWS Organizationsとアカウント管理
AWS Organizationsは、複数のAWSアカウントを中央集権的に管理するためのサービスです。企業は、複数のアカウントを組織単位（OU）に分け、各部署や環境ごとにアカウントを分けることができます。これにより、アカウント間で一貫性のあるガバナンスや請求管理を行うことができます。
2. リザーブドインスタンス（RI）とは
リザーブドインスタンス（RI）は、AWSのEC2インスタンスに対する長期的な利用契約を結ぶことで、料金を割引価格で提供するサービスです。RIを購入することで、企業は特定のインスタンスタイプやリージョンにおいて、大きな割引を受けることができます。
RIの特性として、複数アカウントでの共有が可能です。つまり、同じ組織内の複数のアカウントで、RI割引を共用することができます。これを「RIの共有」と呼びます。この機能により、複数のAWSアカウントでRIを効率的に活用でき、コスト削減が期待できます。
3. RI共有の管理
RIの共有は、AWS Organizationsの請求設定で制御できます。組織の親アカウント（管理アカウント）から、RI割引をどのアカウントと共有するかを設定します。例えば、HR部門がRIを購入した場合、他の部門（営業や財務部門）もそのRI割引を利用することができます。しかし、特定のアカウントや部門とRI割引を共有したくない場合は、RI共有設定をオフにする必要があります。
4. AWSの請求管理
AWSの請求管理コンソールでは、以下のことができます：
- 統合請求（Consolidated Billing）：組織内の複数アカウントの請求を統合して管理できます。
- RIの購入と共有：RI購入後、その割引を他のアカウントと共有する設定を行います。これにより、複数アカウント間でリソースの割引を効率的に利用できます。
- コスト管理とレポート：コストエクスプローラーや予算管理を使用して、リソースの使用量とコストを監視・管理できます。
5. サービスコントロールポリシー（SCP）
SCPは、AWS Organizationsの各アカウントでアクセスできるサービスやアクションを制限するためのポリシーです。例えば、特定のアカウントに対してAWSサービスへのアクセスを制限する場合に使用しますが、RIの共有設定を制御するためには使用できません。RIの共有管理は、AWS請求管理コンソールで行います。
まとめ
AWS Organizations内でのアカウント管理、RIの割引をどのアカウントに共有するかを管理する方法にあります。HR部門が購入したRI割引を他の部門と共有しないようにするためには、AWS Billing and Cost Managementコンソールを通じて、管理アカウントからRI共有をオフにすることが最も適切な方法です。
一問道場
質問 #108
トピック 1
小売会社は、AWS Organizations内でAWSアカウントを組織化しています。同社は統合請求を設定し、各部署を以下のように組織単位（OU）にマッピングしています：財務、営業、人事（HR）、マーケティング、運用。各OUには複数のAWSアカウントがあり、各部署内のそれぞれの環境に対応しています。これらの環境は開発、テスト、プレプロダクション、本番です。
HR部門は、3ヶ月後に新しいシステムを公開する予定です。準備のために、HR部門は本番AWSアカウントでいくつかのリザーブドインスタンス（RI）を購入しました。HR部門は、このアカウントに新しいアプリケーションをインストールする予定です。HR部門は、他の部署がRIの割引を共有できないようにしたいと考えています。
どの解決策がこの要件を満たしますか？
A. AWS Billing and Cost ManagementコンソールでHR部門の本番アカウントのRI共有をオフにする。
B. HR部門の本番AWSアカウントを組織から削除し、統合請求構成にのみアカウントを追加する。
C. AWS Billing and Cost Managementコンソールで組織の管理アカウントを使用してHR部門の本番AWSアカウントのRI共有をオフにする。
D. 組織内でRIへのアクセスを制限するSCPを作成し、他の部署のOUに適用する。
解説
この問題の解説は、リザーブドインスタンス（RI）共有の管理に関するものです。リザーブドインスタンスは、特定のAWSサービス（EC2など）の長期間利用するリソースを割引価格で購入する方法ですが、複数のAWSアカウントでその割引を共有することができます。
要件:
- HR部門が購入したリザーブドインスタンスの割引を他の部署（営業、財務など）が利用できないようにすること。
解決策の選択肢:
A. AWS Billing and Cost ManagementコンソールでHR部門の本番アカウントのRI共有をオフにする
- これは一部正しいですが、HR部門のアカウント単独でRI共有をオフにするためには、管理アカウント（組織の親アカウント）から行う必要があり、HR部門自身のアカウントから個別に設定することはできません。
B. HR部門の本番AWSアカウントを組織から削除し、統合請求構成にのみアカウントを追加する
- これは不適切です。アカウントを組織から削除することで、RI割引の共有が制限されるわけではありません。組織外にアカウントを移動させると、むしろ管理が煩雑になる可能性があります。
C. AWS Billing and Cost Managementコンソールで組織の管理アカウントを使用してHR部門の本番AWSアカウントのRI共有をオフにする
- 正解です。 これは、管理アカウント（親アカウント）からRIの共有設定を変更する方法です。この方法により、HR部門のアカウントだけでRI割引を利用し、他の部署と共有しないように設定できます。
D. 組織内でRIへのアクセスを制限するSCPを作成し、他の部署のOUに適用する
- これは不適切です。**SCP（サービスコントロールポリシー）**はアクセスを制限するためのものですが、RIの割引共有の設定には関与しません。RIの共有設定はAWSの請求設定に依存するため、SCPで制限することはできません。
結論:
最も適切な方法は、C. AWS Billing and Cost Managementコンソールで組織の管理アカウントを使用してHR部門の本番AWSアカウントのRI共有をオフにする です。これにより、HR部門のRI割引を他の部署と共有しないようにできます。
109-Auto ScalingグループのTerminateプロセス
理論
1. Auto Scalingの仕組み
Auto Scalingは、AWSのサービスで、特定の条件（例：CPU使用率、メモリ、リクエスト数など）に基づいて、Amazon EC2インスタンスの数を自動的に調整するために使用されます。これにより、アプリケーションの需要に応じて、インスタンスの数を増減させ、パフォーマンスを最適化しつつ、コストを削減することができます。
Auto Scalingの設定には、スケーリングポリシー、ヘルスチェック、インスタンスの終了条件などが含まれます。
2. ヘルスチェック
ヘルスチェックは、Auto Scalingによってインスタンスが正常かどうかを監視するためのメカニズムです。ヘルスチェックは、アプリケーションの動作状態やインスタンスのネットワーク状態を確認します。
- EC2のヘルスチェック：インスタンス自体の状態（例：EC2インスタンスが起動しているかどうか）を監視します。
- Elastic Load Balancer（ELB）のヘルスチェック：インスタンスに送信されるトラフィックが正常に処理されるかどうかを監視します。
インスタンスが不健康と判断された場合、Auto Scalingはそのインスタンスを終了して、新しいインスタンスを起動します。このプロセスは、終了保護が有効でも、ヘルスチェックが原因で自動的に終了する場合があります。
3. 終了保護（Termination Protection）
終了保護は、EC2インスタンスが手動で終了されるのを防ぐための設定です。終了保護が有効になっているインスタンスは、管理者が手動でインスタンスを終了することができなくなります。これは誤ってインスタンスを終了してしまうのを防ぐために使われます。
ただし、Auto Scalingやヘルスチェックによる終了は終了保護の影響を受けません。つまり、インスタンスが不健康と判断されると、Auto Scalingはそのインスタンスを終了するため、終了保護は効かないという点を理解しておくことが重要です。
4. Auto Scalingグループのプロセス管理
Auto Scalingは、スケーリングアクションの実行においてさまざまなプロセスを管理しています。特に、次のプロセスに注意を払う必要があります。
- HealthCheck（ヘルスチェック）：Auto Scalingグループ内でインスタンスの健康状態をチェックし、不健康なインスタンスを終了して置き換えます。これにはEC2インスタンスとELBのヘルスチェックが関与します。
- Terminate（終了）プロセス：インスタンスが不健康だと判断された場合、Auto Scalingはインスタンスを終了し、新しいインスタンスを起動します。終了保護が有効でも、このプロセスは影響を受けません。
5. トラブルシューティングの重要性
EC2インスタンスが「不健康」とマークされた場合、その理由を突き止めることが重要です。例えば、アプリケーションのエラーやリソースの過負荷、ネットワークの問題などが原因となる場合があります。
このような状況を解決するためには、次の手順を取ることが推奨されます。
- CloudWatch Logs：アプリケーションログやシステムログを確認して、問題の根本的な原因を特定します。
- Session Manager：AWS Systems Manager Session Managerを利用して、インスタンスにログインし、手動でのトラブルシューティングを行います。
結論
この問題に関連する本質的な知識は、Auto Scalingのスケーリングポリシー、ヘルスチェック、終了保護の仕組み、およびインスタンスの管理方法にあります。Auto Scalingがインスタンスを終了する際には、終了保護は有効でも影響を受けないため、ヘルスチェックやスケーリングポリシーに基づいて行われるアクションを理解しておくことが重要です。
一問道場
質問 #109
トピック
大手企業が人気のウェブアプリケーションを運営しています。このアプリケーションは、プライベートサブネット内の複数のAmazon EC2 Linuxインスタンスで実行されており、Auto Scalingグループに設定されています。アプリケーションロードバランサーは、Auto Scalingグループ内のインスタンスをターゲットにしています。AWS Systems Manager Session Managerが構成され、AWS Systems Manager AgentがすべてのEC2インスタンスで実行されています。
最近、企業はアプリケーションの新しいバージョンをリリースしました。その結果、いくつかのEC2インスタンスが不健康としてマークされ、終了されています。そのため、アプリケーションは能力が低下しています。ソリューションアーキテクトは、アプリケーションから収集されたAmazon CloudWatchログを分析して原因を特定しようとしましたが、ログは決定的なものではありません。
ソリューションアーキテクトは、問題をトラブルシュートするためにEC2インスタンスにアクセスするにはどうすべきですか？
選択肢:
A. Auto ScalingグループのHealthCheckスケーリングプロセスを一時停止します。Session Managerを使用して、不健康としてマークされたインスタンスにログインします。
B. EC2インスタンス終了保護を有効にします。Session Managerを使用して、不健康としてマークされたインスタンスにログインします。
C. Auto Scalingグループの終了ポリシーをOldestInstanceに設定します。Session Managerを使用して、不健康としてマークされたインスタンスにログインします。
D. Auto ScalingグループのTerminateプロセスを一時停止します。Session Managerを使用して、不健康としてマークされたインスタンスにログインします。
解説
この問題では、EC2インスタンスが不健康と判断されて終了される前にトラブルシューティングを行う必要があります。
- A: HealthCheckスケーリングの一時停止はインスタンス終了を防げません。トラフック減少もインスタンス終了
- B: 終了保護は有効でも、インスタンスが終了されるのを防げない場合があります。
- C: 終了ポリシーを変更してもトラブルシューティングには関係ありません。
- D: Terminateプロセスを一時停止すると、インスタンスが終了されず、Session Managerでアクセスして問題を調査できます。
正解はDです。
110-Parameter Store
理論
AWS Systems Manager Parameter Store
概要
AWS Systems Manager Parameter Store は、機密情報や設定情報を安全に管理するためのサービスです。パラメータストアは、アプリケーションの設定、データベースの認証情報、API キーなどの情報を保存し、AWS リソースやアプリケーションで安全に利用できるようにします。
主な機能
- 設定管理：
- アプリケーションの設定や環境変数を管理します。これにより、アプリケーションの変更を簡単に反映させ、設定ミスを減らすことができます。
- セキュアな情報管理：
- パスワードや認証情報など、機密情報を 暗号化 して保存できます。AWS KMS (Key Management Service) を使用して、暗号化されたパラメータを安全に管理します。
- パラメータのバージョン管理：
- パラメータの履歴を管理できるため、過去の設定に戻すことも可能です。
- アクセス制御：
- IAM ポリシー を使用して、誰がどのパラメータにアクセスできるかを細かく制御できます。これにより、機密情報のセキュリティが強化されます。
AWS WAF 管理における利用
- Parameter Store は、AWS Firewall Manager で管理する複数の AWS アカウントや組織単位（OU）に対して、動的にパラメータ（例えば、アカウント番号や OU のリスト）を管理するために使用できます。これにより、複数のアカウントにまたがる WAF ルールを一元的に管理し、変更を迅速に反映させることができます。
AWS Firewall Manager
概要
AWS Firewall Manager は、複数の AWS アカウントにまたがるセキュリティルールを一元的に管理するサービスです。特に、AWS WAF（Web Application Firewall）や AWS Shield（DDoS 保護）などのセキュリティサービスを一括で管理し、組織全体で一貫したセキュリティポリシーを適用することができます。
主な機能
- 統合管理：
- AWS WAF のルールセットを複数の AWS アカウントで一括で管理・適用できます。これにより、個別のアカウントでルールを設定する手間を省き、ポリシーの一貫性を保つことができます。
- 自動適用：
- Firewall Manager を使用すると、AWS Organizations 内のすべてのアカウントや組織単位（OU）に対して、AWS WAF ルールを自動的に適用できます。新しいアカウントが追加された場合でも、セキュリティルールを一貫して適用することができます。
- ポリシー管理：
- 複数のセキュリティポリシーを作成し、それらを AWS WAF や Shield Advanced に適用できます。Firewall Manager では、ポリシーに従ってセキュリティルールを管理し、コンプライアンス違反が発生した場合には通知を受け取ることができます。
- コンプライアンスの監視と自動修復：
- 非準拠リソース に対して自動的に修復アクションを実行できます。例えば、WAF ルールが適用されていないリソースに対して、ポリシーを強制的に適用することができます。
AWS WAF と Firewall Manager の統合
- Firewall Manager を使うと、AWS WAF のルール管理が効率化され、組織内で一貫性のあるセキュリティを保ちながら、ルールの適用や変更が自動化されます。
- Parameter Store と組み合わせることで、ルール適用対象となるアカウントや OU を動的に管理することができます。この仕組みにより、新しいアカウントや OU を追加した際にも、手動で WAF ルールを適用する必要がなくなります。
実際の運用例
- AWS Firewall Manager で複数のアカウントに対する統一的な WAF ルールを管理します。
- AWS Systems Manager Parameter Store にアカウント情報（アカウントIDやOU名）を保存します。
- 新しいアカウントが追加されると、Parameter Store の情報が更新されます。
- Amazon EventBridge がこの更新を検知し、AWS Lambda を呼び出します。
- Lambda 関数が新しいアカウントに対して、同じ WAF ルールを自動的に適用します。
この流れで、新しいアカウントが追加されるたびに WAF ルールが自動的に適用され、管理の手間が減ります。
一問道場
質問 #110
トピック 1
ある企業が、複数のAWSアカウントにわたってAWS WAFルールを管理するためにAWS WAFソリューションを展開したいと考えています。アカウントはAWS Organizations内で異なるOU（組織単位）で管理されています。
管理者は、必要に応じて管理されているAWS WAFルールセットにアカウントやOUを追加または削除できる必要があります。また、管理者はすべてのアカウントにおいて非準拠のAWS WAFルールを自動的に更新および修正できる必要があります。
最小の運用負荷でこれらの要件を満たすソリューションはどれですか？
A. AWS Firewall Managerを使用して、組織内のアカウント間でAWS WAFルールを管理します。AWS Systems Manager Parameter Storeパラメータを使用して、アカウント番号とOUを管理します。必要に応じてパラメータを更新してアカウントやOUを追加または削除します。パラメータの変更を識別するためにAmazon EventBridgeルールを使用し、AWS Lambda関数を呼び出してFirewall Managerの管理アカウントでセキュリティポリシーを更新します。
B. 組織内の選択したOUのすべてのリソースにAWS WAFルールを関連付けることを要求するAWS Configルールを展開します。AWS Lambdaを使用して非準拠のリソースを修正する自動修正アクションを展開します。AWS CloudFormationスタックセットを使用して、AWS Configルールが適用された同じOUにAWS WAFルールを展開します。
C. 組織の管理アカウントでAWS WAFルールを作成します。AWS Lambdaの環境変数を使用してアカウント番号とOUを管理します。必要に応じて環境変数を更新してアカウントやOUを追加または削除します。メンバーアカウントにクロスアカウントIAMロールを作成します。Lambda関数でAWS Security Token Service（AWS STS）を使用してロールを引き受け、メンバーアカウント内でAWS WAFルールを作成および更新します。
D. AWS Control Towerを使用して、組織内のアカウント間でAWS WAFルールを管理します。AWS Key Management Service（AWS KMS）を使用してアカウント番号とOUを管理します。必要に応じてAWS KMSを更新してアカウントやOUを追加または削除します。メンバーアカウントにIAMユーザーを作成します。管理アカウントでAWS Control Towerがアクセスキーとシークレットアクセスキーを使用して、メンバーアカウントのAWS WAFルールを作成および更新できるようにします。
解説
この質問の解説は、AWSの各サービスをどのように活用して、要件を満たすかに関するものです。要件としては、複数のAWSアカウントにわたってAWS WAFルールを管理し、アカウントやOUの追加・削除、非準拠なWAFルールの自動更新・修正を行う必要があります。最小の運用負荷を目指すため、管理の簡便さと自動化が重視されます。
各選択肢の解説
A. AWS Firewall Manager + Parameter Store + EventBridge + Lambda
- 概要: AWS Firewall Managerを使用して、組織内の複数のアカウントにAWS WAFルールを一元管理します。アカウントやOUの情報はAWS Systems Manager Parameter Storeに格納し、EventBridgeを使ってその変化を検知してLambda関数をトリガーし、Firewall ManagerでWAFルールを更新します。
- メリット:
- Firewall Managerは、AWS Organizations内の複数アカウントのWAFルールを簡単に管理できます。
- Parameter Storeにアカウント情報やOUを管理することで、シンプルかつ動的に管理が可能です。
- EventBridgeにより、パラメータの変更（アカウントやOUの追加・削除）が検知され、Lambdaを使って自動でWAFルールの適用を行えます。
- 自動化により、手動での更新作業が不要になり、運用負荷が低減します。
- 最小の運用負荷を実現するため、非常に効率的なソリューションです。
B. AWS Config + Lambda + CloudFormation
- 概要: AWS Configルールを使って、特定のOU内のリソースがAWS WAFルールを関連付けるように強制します。非準拠のリソースが検出された場合、自動的に修正するためのAWS Lambda関数を使い、AWS CloudFormationでWAFルールをOUに展開します。
- メリット:
- AWS Configは、リソースが規定のルールに従っているかを監視できます。
- 非準拠のリソースを自動修正できるため、セキュリティが保たれます。
- デメリット:
- ConfigルールとLambdaを使って修正を行う方法は、少し複雑で運用負荷が増える可能性があります。
- CloudFormationでの展開は、手動での調整が必要になる場合があり、柔軟性に欠けるかもしれません。
C. 管理アカウントでWAFルール作成 + Lambda + クロスアカウントロール
- 概要: 管理アカウントでAWS WAFルールを作成し、Lambda関数でアカウント情報やOUを管理する環境変数を使って、メンバーアカウントでクロスアカウントロールを利用してWAFルールを適用・更新します。
- メリット:
- Lambdaを使って柔軟にアカウント管理やWAFルールの適用が可能です。
- デメリット:
- クロスアカウントロールの設定が煩雑になり、運用が複雑になる可能性があります。
- Lambda関数の環境変数の管理が手動で行う必要があり、柔軟性が損なわれる可能性があります。
D. AWS Control Tower + AWS KMS + IAMユーザー
- 概要: AWS Control Towerを使って複数のアカウントのWAFルールを管理します。AWS KMSを使ってアカウント情報やOUを管理し、IAMユーザーを使ってメンバーアカウントのWAFルールを更新します。
- メリット:
- AWS Control Towerは、組織内でのガバナンスや自動化に優れた管理機能を提供します。
- KMSを使った暗号化やアクセス管理が可能ですが、IAMユーザーを作成する手間がかかります。
- デメリット:
- Control Towerを使用するのは、既にControl Towerを利用している場合には有効ですが、初期のセットアップが複雑になることがあります。
- IAMユーザーを個別に作成しアクセスキーを管理する方法は、セキュリティ管理において手間がかかり、運用負荷が高くなる可能性があります。
結論
選択肢Aが最適なソリューションです。理由としては、AWS Firewall Managerによる一元的なWAFルールの管理、AWS Systems Manager Parameter Storeによるアカウント情報の動的管理、EventBridgeを活用した自動化の流れが最も効率的で、運用負荷を最小化できるからです。他の選択肢は、手動での設定や管理が必要であったり、運用が複雑になったりするため、最小限の運用負荷を目指す要件には適していません。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16dd7ae8-88e2-80fb-babe-ec83e8563d98
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
