type
status
date
slug
summary
tags
category
icon
password
261-AWS SAP AWS 「理論・実践・一問道場」AWS IAM Identity Center
理論
この問題に関連する本質的な知識は、複数のAWSアカウントを効率的に管理し、統一的な認証を実現する方法です。以下が重要なポイントです。
- AWS Organizations:
- AWS Organizationsは、複数のAWSアカウントを一元的に管理するサービスです。これを使用することで、複数のアカウントの請求や権限を中央で管理できます。
- アカウントを「オーガニゼーション」に招待し、管理者アカウントを設定することで、アカウント間のリソース共有や請求管理を簡素化できます。
- アイデンティティフェデレーション:
- アイデンティティフェデレーションにより、Azure Active Directory（Azure AD）などの外部認証基盤をAWSに統合し、ユーザー認証を簡素化します。
- *AWS IAM Identity Center (AWS SSO)**を使用することで、Azure ADのユーザーとグループをAWSに同期させ、管理者は個別にユーザーを作成する必要がなくなります。
- 一時的な資格情報:
- 長期間使用するアクセスキーの代わりに、一時的な資格情報（AWS STS）を使用することで、セキュリティが向上します。
- 一時的なアクセス権限を使うことで、リスクを最小限に抑え、アクセス管理を動的に行えるようになります。
これらを組み合わせることで、企業全体のAWS環境に対して、効率的で安全な管理が可能になります。
実践
略
一問道場
質問 #261
トピック 1
ある企業は多数の独立したAWSアカウントを持ち、中央の請求または管理を使用していません。それぞれのAWSアカウントは、会社の異なる部門のサービスをホストしています。企業にはMicrosoft Azure Active Directoryが展開されています。
ソリューションアーキテクトは、企業のAWSアカウントの請求と管理を集中化する必要があります。企業は、手動のユーザー管理の代わりにアイデンティティフェデレーションを使用したいと考えており、長期間のアクセスキーの代わりに一時的な資格情報を使用したいと考えています。
これらの要件を満たすための手順の組み合わせはどれですか？（3つ選んでください。）
A. 新しいAWSアカウントを作成して管理アカウントとして使用し、AWS Organizationsで組織を展開します。各既存のAWSアカウントに組織に参加するように招待し、各アカウントがその招待を受け入れるようにします。
B. 各AWSアカウントのメールアドレスをaws+@example.comに設定し、アカウント管理のメールメッセージと請求書が同じ場所に送信されるようにします。
C. 管理アカウントにAWS IAM Identity Center（AWS Single Sign-On）を展開し、IAM Identity CenterをAzure Active Directoryに接続します。ユーザーとグループの自動同期のためにIAM Identity Centerを設定します。
D. 管理アカウントにAWS Managed Microsoft ADディレクトリを展開し、AWS Resource Access Manager（AWS RAM）を使用して組織内のすべての他のアカウントとディレクトリを共有します。
E. AWS IAM Identity Center（AWS Single Sign-On）の権限セットを作成し、適切なIAM Identity CenterグループとAWSアカウントに権限セットを割り当てます。
F. 各AWSアカウントでAWS Identity and Access Management（IAM）を設定し、AWS Managed Microsoft ADを認証および認可に使用します。
解説
この問題では、企業のAWSアカウントの請求と管理を集中化し、アイデンティティフェデレーションを使用して、長期間のアクセスキーの代わりに一時的な資格情報を使用することが求められています。以下の手順でそれを実現できます。
- A: 新しい管理アカウントを作成し、AWS Organizationsを使って各アカウントを統合します。これにより、中央で管理できるようになります。
- C: AWS IAM Identity Center (AWS SSO) を管理アカウントに展開し、Azure Active Directoryと連携させることで、ユーザーとグループを自動的に同期し、ユーザー管理を簡素化します。
- E: IAM Identity Center の権限セットを作成して、それぞれのグループやアカウントに必要な権限を付与することで、アクセス管理を効率化します。
これらの手順により、AWSアカウントの管理が一元化され、アイデンティティフェデレーションを使用して安全な認証が行えるようになります。
262-AWS SAP AWS 「理論・実践・一問道場」リソースの効率化コンテナ技術
理論
アプリをコンテナ単位でデプロイするとは？
- コンテナとは
各アプリケーションを独立したコンテナ（Dockerなど）にパッケージ化します。このコンテナにはアプリケーションのコード、ライブラリ、依存関係が含まれます。
- Amazon ECSの役割
Amazon ECS (Elastic Container Service) は、これらのコンテナを管理し、必要な数だけデプロイしたり、スケーリングを行ったりするサービスです。
- ECSタスク単位でアプリをデプロイ
- 1つのアプリケーション = 1つのECSタスク
- 各タスクはメモリやCPUの使用量に応じてスケール可能。
各アプリケーションを「ECSタスク」という単位でデプロイします。
この方法のメリット
- リソースの効率化
アプリの利用状況に応じてスケールするため、無駄なリソース消費を抑えられます。
- 独立性
各アプリケーションが独立して動作するため、障害が他のアプリに影響を及ぼしません。
- 柔軟性
アプリごとに異なる依存関係を持つ場合でも、コンテナ単位で管理可能。
まとめ
選択肢Bの「アプリをコンテナ単位でデプロイ」は、20個のアプリケーションを効率的に管理し、コストを最小限に抑えるための最適な方法です。Amazon ECSを利用することで、必要に応じたスケーリングやリソースの最適化が容易になります。
実践
略
一問道場
質問 #262
トピック 1
ある企業が、AWSに移行して、頻繁には使用されないがビジネスにとって重要な20のアプリケーションに関連するコストを管理したいと考えています。これらのアプリケーションは、JavaとNode.jsが混在しており、異なるインスタンスクラスターに分散しています。企業はコストを最小限に抑えながら、単一の展開方法を使用して標準化を図りたいと考えています。
ほとんどのアプリケーションは月末処理の一部であり、並行ユーザーは少ないものの、時々他のタイミングでも実行されます。アプリケーションの平均メモリ使用量は1GB未満ですが、ピーク時には2.5GBを使用するものもあります。
最も重要なアプリケーションは、複数のデータソースにアクセスし、数時間にわたって実行されるJavaで書かれた請求書レポートです。
最もコスト効果の高い解決策はどれでしょうか？
A. 各アプリケーションごとにAWS Lambda関数を個別にデプロイし、AWS CloudTrailログとAmazon CloudWatchアラームを使用して重要なジョブの完了を確認します。
B. メモリ使用率が75%に設定されたAmazon EC2でAmazon ECSコンテナをデプロイし、ECSタスクスケーリングを使用して各アプリケーションを移行します。サービスとホストをAmazon CloudWatchで監視します。
C. 各アプリケーションにAWS Elastic Beanstalkをデプロイし、Auto Scalingを使用してリクエストに必要なリソースを確保します。各Elastic Beanstalkの展開をCloudWatchアラームで監視します。
D. 新しいAmazon EC2インスタンスクラスターをデプロイし、すべてのアプリケーションを共存させ、EC2 Auto Scalingとアプリケーションロードバランサーを使用して、インスタンスメモリ使用率に基づいてクラスターサイズをスケールします。Auto ScalingグループのGroupMaxSizeパラメーターに相当する3年のReserved Instance予約を購入します。
解説
この問題のポイントは、コスト効率とアプリケーションの特性（低頻度の利用、変動するメモリ使用量）を考慮して、最適なAWSのソリューションを選ぶことです。
選択肢の評価
- A. AWS Lambda
- サーバーレスでコストは低いが、長時間実行やメモリが多く必要なアプリケーションには適さない。
- Javaで書かれた請求書レポートがあるため、非適切。
- B. Amazon ECS on EC2
- ECSコンテナを使用し、Auto Scalingで動的にリソースを割り当てられる。
- メモリ使用量に基づくスケーリングが可能で、コスト効率が高い。
- 最適な選択肢。
- C. AWS Elastic Beanstalk
- 各アプリケーションに個別にElastic Beanstalkを使うと、運用が複雑になり、コストが高くなる可能性がある。
- D. EC2インスタンスクラスター
- 全アプリケーションをインスタンスで共存させる方法。
- 固定リソースの購入（Reserved Instances）によりコストを抑えられるが、使用頻度が低いためリソースが無駄になりやすい。
解答
B. Amazon ECS on EC2
ECSのコンテナ化による柔軟性とリソース最適化が、コスト効率を最も高める方法です。
263-AWS SAP AWS 「理論・実践・一問道場」EMRクラスター
理論
EMRクラスターとコスト最適化の基本知識
Amazon EMR（Elastic MapReduce）は、大規模データ処理を簡単かつ効率的に実行できるAWSのサービスです。この問題を解くためには、以下の基本知識が重要です。
1. EMRの基本構成
- プライマリノード
クラスター管理を担当。ジョブのスケジューリングやノードの状態管理を行う。
→ 必ずオンデマンドインスタンスを使用するのが推奨（安定性が必要なため）。
- コアノード
データの保存と処理を担当。HDFS（Hadoop Distributed File System）のデータを保持する。
→ 通常、安定性が必要なのでオンデマンドインスタンスが適している。
- タスクノード
一時的なデータ処理を行うノード。HDFSのデータを保持せず、単に処理を実行する。
→ スポットインスタンスを使用してコストを削減できる。
2. インスタンスの種類とコスト削減
- オンデマンドインスタンス
必要な時に利用可能。柔軟性が高いが、コストは高め。
→ プライマリノードやコアノードに適している。
- スポットインスタンス
AWSの余剰キャパシティを利用する低コストなインスタンス。一時的に停止する可能性がある。
→ タスクノードに適しており、大幅なコスト削減が可能。
- コンピュートセービングプラン
長期間使用するインスタンスのコストを削減する予約型のプラン。
→ オンデマンドインスタンスのコストを抑えるために有効。
3. COST最適化のためのEMR設計のポイント
- プライマリノードとコアノードは安定性重視
これらのノードはクラスター全体の動作に影響するため、オンデマンドインスタンスを使用する。
- タスクノードはスポットインスタンスを活用
処理が完了すれば終了しても問題ないため、スポットインスタンスでコストを抑える。
- クラスターの終了タイミングを明確化
処理が完了したらクラスター全体、または一部のノード（タスクノードのみ）を終了してリソースの無駄を防ぐ。
- コンピュートセービングプランの適用
プライマリノードやコアノードなど、長期間利用するインスタンスのコストを抑える。
5. まとめ
EMRクラスターの設計では、ノードごとに役割と安定性の要件を理解し、オンデマンドインスタンスとスポットインスタンスを適切に使い分けることが重要です。また、長期間利用するリソースには予約プランを適用することで、さらにコストを最適化できます。
実践
略
一問道場
質問 #263
トピック 1
ソリューションアーキテクトは、EMRファイルシステム（EMRFS）を使用するAmazon EMRクラスターの設計をレビューする必要があります。このクラスターは、ビジネス上重要なタスクを実行します。すべてのタスクノード、プライマリーノード、コアノードは常にAmazon EC2のオンデマンドインスタンスで稼働しています。EMRのタスクは毎朝1:00 AMに開始し、6時間かけて実行を完了します。ただし、このデータはその日の遅い時間まで参照されないため、処理時間の長さは優先事項ではありません。
ソリューションアーキテクトはアーキテクチャをレビューし、コンピュートコストを最小限に抑えるための解決策を提案する必要があります。
どのソリューションをソリューションアーキテクトが推奨すべきですか？
A.
タスクノード、プライマリーノード、コアノードをすべてインスタンスフリートのスポットインスタンスで起動する。処理が完了したら、クラスターを含むすべてのインスタンスを終了する。
B.
プライマリーノードとコアノードをオンデマンドインスタンスで起動する。タスクノードをインスタンスフリートのスポットインスタンスで起動する。処理が完了したら、クラスターを含むすべてのインスタンスを終了する。オンデマンドインスタンスの使用をカバーするためにコンピュートセービングプランを購入する。
C.
すべてのノードをオンデマンドインスタンスで起動し続ける。処理が完了したら、クラスターを含むすべてのインスタンスを終了する。オンデマンドインスタンスの使用をカバーするためにコンピュートセービングプランを購入する。
D.
プライマリーノードとコアノードをオンデマンドインスタンスで起動する。タスクノードをインスタンスフリートのスポットインスタンスで起動する。処理が完了したら、タスクノードのインスタンスのみを終了する。オンデマンドインスタンスの使用をカバーするためにコンピュートセービングプランを購入する。
解説
この質問では、Amazon EMRクラスターでのコンピュートコストを最小限に抑えるための適切なアプローチを選択する必要があります。以下は各選択肢の評価と正解の解説です。
選択肢の評価
A.
「タスクノード、プライマリーノード、コアノードをすべてスポットインスタンスで起動する」
- 利点: スポットインスタンスはコストが大幅に安い。
- 欠点: スポットインスタンスは中断される可能性があり、プライマリーノードやコアノードがスポットインスタンスに設定されると、クラスター全体が中断されるリスクがある。ビジネス上重要なタスクには適さない。
- 結論: 不適切。
B.
「プライマリーノードとコアノードをオンデマンドインスタンスで起動し、タスクノードをスポットインスタンスで起動する」
- 利点: プライマリーノードとコアノードは常に安定性を確保し、タスクノードにスポットインスタンスを使用することでコスト削減が可能。処理が完了後、全ノードを終了するため無駄がない。
- 追加のメリット: コンピュートセービングプランを購入することでオンデマンドインスタンスのコスト削減も図れる。
- 結論: 適切。
C.
「すべてのノードをオンデマンドインスタンスで起動し続ける」
- 利点: 安定性が確保される。
- 欠点: コスト削減ができないため、要件（コスト最小化）に反する。
- 結論: 不適切。
D.
「プライマリーノードとコアノードをオンデマンドインスタンスで起動し、タスクノードをスポットインスタンスで起動する」
- 利点: プライマリーノードとコアノードの安定性を確保しつつ、タスクノードでコスト削減が可能。
- 欠点: 処理後にタスクノードのみを終了し、クラスター全体を停止しない。このため、プライマリーノードとコアノードが動き続け、無駄なコストが発生する可能性がある。
- 結論: 不適切。
正解: B
理由:
- プライマリーノードとコアノードをオンデマンドインスタンスで稼働させることで、ビジネス上重要なタスクの安定性を確保。
- タスクノードをスポットインスタンスにすることで、全体のコストを最小化。
- 処理後にすべてのノードを終了するため、不要なランニングコストを発生させない。
- コンピュートセービングプランによりオンデマンドインスタンスのコストをさらに削減可能。
この構成は、コスト効率と安定性のバランスを取った最適なアーキテクチャ設計です。
264-AWS SAP AWS 「理論・実践・一問道場」NATゲートウェイで固定IP
理論
NATゲートウェイとオンプレミス通信の設計ポイント
AWS環境からオンプレミス環境への通信を設計する際に考慮すべき重要なポイントを以下にまとめます。
1. NATゲートウェイの役割
- プライベートサブネットの通信をインターネットやオンプレミスへ中継 NATゲートウェイは、プライベートサブネット内のリソースが外部（インターネットやオンプレミスシステム）と通信する際に使用されます。NATゲートウェイを通じて通信する場合、Elastic IPを割り当てることで固定IPが保証されます。
2. Elastic IPの活用
- オンプレミス側のファイアウォール要件 多くの場合、オンプレミスシステムは特定の送信元IPアドレス（Elastic IP）からの通信のみを許可します。このため、NATゲートウェイや他の中継リソースにElastic IPを割り当てる必要があります。
3. 高可用性の考慮
- 単一障害点の排除
- NATゲートウェイはデフォルトで1つのAZ内で動作します。そのため、1つのNATゲートウェイに依存すると、障害時に通信が停止するリスクがあります。
- 冗長性を持たせるためには、複数のAZにNATゲートウェイを配置し、障害時に自動で切り替える仕組みを設計する必要があります。
4. 自動復旧の重要性
- CloudWatchとLambdaによる監視と復旧
- NATゲートウェイや他のリソースのヘルスチェックをAmazon CloudWatchで監視します。
- 障害が検知された場合、AWS Lambdaをトリガーして新しいNATゲートウェイを作成し、Elastic IPを再割り当てすることで通信を復旧させることが可能です。
5. コスト効率の向上
- 最小限のNATゲートウェイ利用 複数AZで冗長性を持たせる場合、コストが増加するため、単一のNATゲートウェイを採用しつつ自動復旧を設計することでコストを抑える選択肢も有効です。
まとめ
AWSでのオンプレミス通信を設計する際のポイントは以下です：
- NATゲートウェイを使用してプライベートサブネットから通信を中継
- Elastic IPを活用して固定IPを保証
- CloudWatchとLambdaを利用した自動復旧を設計
- 冗長性とコスト効率のバランスを最適化
これらを考慮した設計が、信頼性の高いオンプレミス通信を実現します。
実践
略
一問道場
質問 #264
トピック 1
ある企業がレガシーアプリケーションをAWSクラウドに移行しました。このアプリケーションは、3つのAmazon EC2インスタンス上で稼働しており、それらは3つのアベイラビリティゾーンに分散されています。各アベイラビリティゾーンに1つのEC2インスタンスが存在します。これらのEC2インスタンスは、VPCの3つのプライベートサブネットで動作しており、3つのパブリックサブネットに関連付けられたApplication Load Balancer (ALB)のターゲットとして設定されています。
このアプリケーションは、オンプレミスのシステムと通信する必要があります。オンプレミスのシステムにアクセスできるのは、企業のIPアドレス範囲内のIPアドレスからのトラフィックに限定されています。企業のセキュリティチームは、内部のIPアドレス範囲からクラウドに1つのIPアドレスのみを持ち込んでいます。このIPアドレスは、企業のファイアウォールの許可リストに追加されています。また、このIPアドレス用にElastic IPアドレスを作成しています。
ソリューションアーキテクトは、アプリケーションがオンプレミスのシステムと通信できるソリューションを作成する必要があります。このソリューションは、障害が発生した場合に自動で復旧する能力も備えている必要があります。
どのソリューションがこれらの要件を満たしますか？
A.
各パブリックサブネットに1つずつ、合計3つのNATゲートウェイをデプロイします。Elastic IPアドレスをNATゲートウェイに割り当てます。NATゲートウェイのヘルスチェックを有効にします。NATゲートウェイがヘルスチェックに失敗した場合、新しいNATゲートウェイを再作成し、Elastic IPアドレスを新しいNATゲートウェイに割り当てます。
B.
ALBをNetwork Load Balancer (NLB)に置き換えます。Elastic IPアドレスをNLBに割り当てます。NLBのヘルスチェックを有効にします。ヘルスチェックが失敗した場合、別のサブネットにNLBを再デプロイします。
C.
1つのNATゲートウェイをパブリックサブネットにデプロイします。Elastic IPアドレスをNATゲートウェイに割り当てます。Amazon CloudWatchを使用してカスタムメトリクスでNATゲートウェイを監視します。NATゲートウェイが正常でない場合、AWS Lambda関数を呼び出して別のサブネットに新しいNATゲートウェイを作成し、Elastic IPアドレスを新しいNATゲートウェイに割り当てます。
D.
Elastic IPアドレスをALBに割り当てます。Elastic IPアドレスを値とするAmazon Route 53のシンプルレコードを作成します。Route 53のヘルスチェックを作成します。ヘルスチェックが失敗した場合、別のサブネットでALBを再作成します。
解説
この問題は、AWS上のアプリケーションからオンプレミスシステムへの通信を設計するために、適切なソリューションを選択する内容です。以下に解説します。
問題の要件
- オンプレミスとの通信が必要
- 通信は、会社の内部IPアドレス範囲内からのみに制限されており、特定のElastic IPアドレスを使用する必要があります。
- 高可用性が求められる
- 通信が中断しないように、障害時の自動復旧機能が必要です。
- 現在の構成
- プライベートサブネット内のEC2インスタンスがオンプレミスシステムと通信。
- Elastic IPアドレスを使用して通信を許可。
選択肢の検討
A. 3つのNATゲートウェイをデプロイし、Elastic IPを割り当てる
- メリット: 各アベイラビリティゾーン（AZ）にNATゲートウェイを配置することで、高可用性を確保できます。
- デメリット: NATゲートウェイは各AZで独立して動作するため、Elastic IPを共有する仕組みがありません。この設計では、障害が発生した際にElastic IPの再割り当てが適切に行われないため、要件を満たしません。
B. ALBをNLBに置き換え、Elastic IPを割り当てる
- メリット: NLBはElastic IPを直接割り当てることが可能です。オンプレミスシステムとのIP固定要件を満たします。
- デメリット: NLBはヘルスチェック機能を持つものの、AZ間での自動復旧やElastic IPの再利用に関しては、明確な冗長性がありません。また、ロードバランサーの目的が異なるため、不適切です。
C. 単一のNATゲートウェイとLambdaによる自動復旧
- メリット:
- Elastic IPを単一のNATゲートウェイに割り当てるため、オンプレミス通信要件を満たします。
- CloudWatchでヘルスチェックを監視し、障害時にLambdaを使用して新しいNATゲートウェイを作成し、Elastic IPを再割り当てすることで、自動復旧を実現します。
- コスト効率が高い。
- デメリット: 単一のNATゲートウェイに依存するため、完全な高可用性ではありません。ただし、コストを優先する場合は合理的な選択肢です。
D. ALBにElastic IPを割り当て、Route 53を使用
- メリット: Route 53のヘルスチェックで、障害時にALBのリソースを再作成できます。
- デメリット: ALB自体はElastic IPを直接割り当てることができないため、この選択肢は技術的に実現不可能です。
正解: C. 単一のNATゲートウェイとLambdaによる自動復旧
この選択肢は以下の理由で要件を満たします：
- Elastic IPを割り当ててオンプレミス通信を確保。
- CloudWatchとLambdaを使用して障害時の自動復旧を実現。
- コストを最小限に抑える。
設計の補足
- 高可用性をさらに向上させるには、複数のNATゲートウェイを異なるAZにデプロイし、Route 53やLambdaでトラフィックの切り替えを管理する方法も検討できます。
- ビジネス要件とコストを慎重にバランスさせることが重要です。
265-AWS SAP AWS 「理論・実践・一問道場」組織の移動
理論
AWS Organizations によるアカウント移行の本質的な知識
AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスで、組織内のアカウントをグループ化して管理することができます。複数のアカウントを効率的に管理するためには、アカウントの移行や再構成が必要になることがあります。以下では、AWS Organizationsを使用してアカウントを移行する際に必要な知識を解説します。
1. AWS Organizationsの基本概念
- 管理アカウントとメンバーアカウント AWS Organizations内には、管理アカウント（組織を作成するために必要なアカウント）と、メンバーアカウント（組織に参加するアカウント）があります。
- 組織の構成 組織内のアカウントは、OU（Organizational Units） にグループ化され、管理者はポリシーやアクセス権限を一元管理できます。
2. アカウントの移行方法
アカウントを異なる組織やOUに移動する際の手順は以下の通りです：
- アカウントの削除と招待
- RemoveAccountFromOrganization操作は、アカウントを現在のAWS Organizationsから削除するために使用します。この操作を実行した後、アカウントは完全に独立した状態になります。移行先の組織に再招待する必要があります。
- InviteAccountToOrganization操作は、新しい組織にアカウントを招待する際に使用します。これにより、アカウントは新しい組織に追加され、再度管理下に入ります。
- アカウント移行の順序
- まず、アカウントを元の組織から削除し、次に新しい組織に招待するという順番で行います。
- 一度削除されたアカウントは新しい組織に招待することで再度追加され、移行が完了します。
3. 自動化と管理のベストプラクティス
- APIの活用
- AWS OrganizationsのAPIを使用することで、アカウント移行のプロセスを自動化できます。API操作には、MoveAccount、RemoveAccountFromOrganization、InviteAccountToOrganizationなどがあります。
- 一括移行の管理
- 1,000以上のアカウントを移行する場合、一括操作を実行できるようにAPIを利用したスクリプトやツールを作成することが重要です。これにより手動での操作ミスを減らし、効率的に移行作業を進めることができます。
- 移行の確認
- アカウント移行後、移行先の組織内でアカウントの設定が正しく適用されていることを確認するため、ポリシーや権限設定を再確認することが推奨されます。
まとめ
AWS Organizationsを使用したアカウント移行には、アカウントの削除と招待を組み合わせて実行する必要があります。移行プロセスを効率的に行うためには、APIを活用して自動化することが重要です。また、大規模な移行を行う際は、移行後の設定確認をしっかり行い、移行作業の品質を保つことが求められます。
実践
略
一問道場
質問 #265
トピック 1
ある企業は、AWS Organizationsを使用して1,000以上のAWSアカウントを管理しています。企業は新しい開発者組織を作成しました。この新しい開発者組織に移動すべき開発者のメンバーアカウントが540件あります。すべてのアカウントには、各アカウントが独立したアカウントとして運用できるように必要な情報が設定されています。
開発者アカウントを新しい開発者組織に移動するために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（3つ選んでください。）
A.
旧組織の管理アカウントからOrganizations APIのMoveAccount操作を呼び出して、開発者アカウントを新しい開発者組織に移行する。
B.
管理アカウントから、Organizations APIのRemoveAccountFromOrganization操作を使用して、各開発者アカウントを旧組織から削除する。
C.
各開発者アカウントから、Organizations APIのRemoveAccountFromOrganization操作を使用して、アカウントを旧組織から削除する。
D.
新しい開発者組織の管理アカウントにサインインし、開発者アカウントの移行先として機能するプレースホルダーメンバーアカウントを作成する。
E.
新しい開発者組織の管理アカウントからOrganizations APIのInviteAccountToOrganization操作を呼び出して、開発者アカウントに招待を送信する。
F.
各開発者が自分のアカウントにサインインし、新しい開発者組織に参加することを確認する。
解説
- B: 管理アカウントから、Organizations APIのRemoveAccountFromOrganization操作を使用して、各開発者アカウントを旧組織から削除する。
RemoveAccountFromOrganization操作は、管理アカウントから呼び出して、開発者アカウントを旧組織から削除するために使用します。この操作はメンバーアカウントではなく、管理アカウントからのみ実行可能です。開発者アカウントは自分自身で組織から削除することはできません。
- E: 新しい開発者組織の管理アカウントからOrganizations APIのInviteAccountToOrganization操作を呼び出して、開発者アカウントに招待を送信する。
新しい組織に開発者アカウントを追加するためには、InviteAccountToOrganization操作を使用して招待を送信します。この操作を使って、新しい組織の管理アカウントから開発者アカウントに招待を送信し、アカウントが新しい組織に参加します。
- F: 各開発者が自分のアカウントにサインインし、新しい開発者組織に参加することを確認する。
LeaveOrganization操作を使用することで、各開発者アカウントは旧組織から自分で退出し、新しい組織に参加します。これにより、開発者は自分自身で組織に参加することを確認することが可能です。
まとめ
- B: 管理アカウントが開発者アカウントを旧組織から削除。
- E: 新しい開発者組織に開発者アカウントを招待。
- F: 各開発者が自分で新しい組織に参加を確認。
これで、正しい手順を踏まえた移行が実現できます。
266-AWS SAP AWS 「理論・実践・一問道場」Lambda@Edge origin-response
理論
この問題に関連する本質的な知識は、以下のポイントに集約されます：
1. Lambda@Edge と CloudFront の統合
- Lambda@Edge は、Amazon CloudFront のイベントに基づいて関数を実行できるサービスで、ユーザーにコンテンツを配信する直前や直後にコードを実行できます。これにより、低レイテンシで迅速な処理が可能です。
- origin-response イベント は、CloudFront がオリジンからコンテンツ（例：S3バケットの画像）を受け取った後に発生します。このタイミングで関数を実行することで、コンテンツが最終的にユーザーに配信される前に検証を行えます。
2. レイテンシとリアルタイム処理
- 画像やコンテンツがユーザーに配信される直前に検証や処理を行うことは、最小限のレイテンシ でリアルタイムに問題を検出し、修正できるため重要です。特に、インタラクティブなウェブアプリケーションでは、遅延や障害がユーザー体験に大きな影響を与える可能性があるため、処理のタイミングを最適化することが重要です。
3. S3 イベント通知と Lambda
- S3 イベント通知 は、S3 にオブジェクトがアップロードされるとトリガーされ、別の AWS サービス（例えば Lambda）を呼び出すことができます。ただし、この方法では、画像がS3にアップロードされた後の処理が行われるため、CloudFrontによる画像配信のタイミングと同期が難しく、リアルタイムの検出 には向いていない場合があります。
4. コンテンツ配信ネットワーク（CDN）と最適化
- CDN（CloudFront）は、コンテンツ配信を最適化するために使用され、コンテンツをエンドユーザーに近い場所で配信することで、パフォーマンスを向上させます。CloudFrontのエッジロケーションでコードを実行できるLambda@Edgeは、コンテンツ配信と処理を効率的に統合するための強力なツールです。
まとめ
- Lambda@Edge と CloudFront を組み合わせることで、コンテンツ配信の直前にリアルタイムで検証処理を行うことが可能です。これにより、最小のレイテンシで破損した画像を検出し、ユーザーに影響を与えないようにすることができます。origin-response イベントはそのための理想的なタイミングを提供します。
実践
略
一問道場
質問 #266
トピック 1
ある企業のインタラクティブなウェブアプリケーションは、Amazon CloudFrontディストリビューションを使用してAmazon S3バケットから画像を提供しています。時折、サードパーティツールが破損した画像をS3バケットに取り込むことがあります。この画像の破損は、後にアプリケーションで悪いユーザー体験を引き起こします。企業は破損した画像を検出するためのPythonロジックを正常に実装し、テストしました。
ソリューションアーキテクトは、取り込まれた後、画像を提供する前に検出ロジックを統合する方法を推奨する必要があります。最小のレイテンシでこの要件を満たすソリューションはどれですか？
A. Lambda@Edge関数を使用し、viewer-responseイベントによって呼び出す。
B. Lambda@Edge関数を使用し、origin-responseイベントによって呼び出す。
C. S3イベント通知を使用し、AWS Lambda関数を呼び出す。
D. S3イベント通知を使用し、AWS Step Functionsステートマシンを呼び出す。
解説
正解は B. Lambda@Edge関数を使用し、origin-responseイベントによって呼び出す です。
理由：
- Lambda@Edge 関数を
origin-responseイベントで呼び出すことで、CloudFrontがオリジン（S3）から画像を受け取った後、ユーザーに配信する前に破損した画像を検出できます。
- このアプローチは、最小のレイテンシ で破損した画像を迅速に検出し、ユーザーに配信される前に問題を解決できるため、効率的で即時の画像検出が可能です。
origin-responseイベントは、CloudFrontがオリジンからレスポンスを受け取った後、配信前に処理されるため、リアルタイムでの画像検出 に最適です。
他の選択肢の評価：
- C. S3イベント通知を使用し、AWS Lambda関数を呼び出す は、画像がS3にアップロードされた後に処理が行われますが、画像の配信前に破損を検出するタイミングが遅れる可能性があり、最小のレイテンシには不向きです。
したがって、B が最適な解決策です。
267-AWS SAP AWS 「理論・実践・一問道場」CodeDeployエージェント
理論
AWS CodeDeployとは？
AWS CodeDeployは、アプリケーションのデプロイメントを自動化するためのAWSのサービスです。このサービスは、EC2インスタンス、Lambda関数、オンプレミスサーバーなど、さまざまなターゲットに対して、アプリケーションコードを自動的にデプロイ（配布）することができます。CodeDeployは、アプリケーションのデプロイを手動で行うことなく、一貫して効率的に実施できるため、運用の負担を減らし、デプロイの品質を向上させることができます。
主な特徴は以下の通りです：
- 自動化：アプリケーションのデプロイを自動化し、手動操作を減らします。
- ターゲットの管理：EC2インスタンス、Lambda関数、オンプレミスサーバーなど、さまざまな環境に対応。
- ロールバック：デプロイメントに失敗した場合、自動でロールバックを実行し、前のバージョンに戻すことができます。
- 監視とレポート：デプロイメントの進捗を監視し、失敗した場合のアラートを出すことができます。
CodeDeployのデプロイメントグループとは、アプリケーションをデプロイする対象のインスタンスやリソースをまとめたグループです。このグループ内のEC2インスタンスやLambda関数に対して、新しいアプリケーションコードを自動で配信します。デプロイメントグループを使うことで、複数のリソースに一貫したデプロイメントを簡単に実行できます。
この問題に関連した本質的知識
この問題は、AWS EC2 Auto ScalingとAWS CodeDeployを組み合わせて、アプリケーションのデプロイメントを自動化し、運用負荷を最小限に抑える方法に関するものです。ポイントとなる知識を以下に整理します：
1. EC2 Auto ScalingとCodeDeployの統合
- EC2 Auto Scalingグループは、トラフィックの増減に応じて自動的にインスタンスを追加または削除します。これにより、インスタンスの数が動的に調整され、アプリケーションは高い可用性とスケーラビリティを持つことができます。
- CodeDeployは、アプリケーションのコードをEC2インスタンスにデプロイするツールです。しかし、Auto Scalingでインスタンスが自動的に追加されると、そのインスタンスにCodeDeployを手動で関連付ける必要があります。これを自動化する方法を考えるのがこの問題のポイントです。
2. AMI（Amazon Machine Image）の利用
- AMIは、EC2インスタンスのイメージであり、アプリケーションや設定を含む環境をコピーするために使用されます。Auto Scalingグループでは、新しいインスタンスを起動する際にAMIを使用して、インスタンスが事前に設定された状態で立ち上がるようにすることができます。
- AMIの更新によって、新しいコードや変更を反映させることができます。これにより、新しく起動されたインスタンスが最新のコードを自動的に受け取ることができ、CodeDeployの手動設定が不要になります。
3. 自動化のアプローチ
- Auto Scalingグループにインスタンスが追加された際に、CodeDeployエージェントを自動的に関連付ける方法としては、Lambda関数を使用するアプローチや、事前に設定したAMIを使用して自動的にインスタンスをデプロイする方法が考えられます。
- AMIを利用した自動化（選択肢D）は、CodeDeployエージェントがインストールされたAMIを作成し、そのAMIをAuto Scalingグループの起動テンプレートに設定することで、インスタンスが自動的に最新のコードをデプロイすることができ、運用負荷が大きく軽減されます。
4. 運用負荷の最小化
- この問題の目的は、運用負荷を最小限に抑え、デプロイメントを自動化することです。AMIを使った方法では、インスタンスが自動的に新しいコードをデプロイするため、手動でインスタンスを関連付けたり、デプロイ前に操作を行う必要がなくなります。
- LambdaやEventBridgeを使って自動化する方法もありますが、AMIの活用が最もシンプルで効果的な方法です。
まとめ
- AWS CodeDeployは、EC2インスタンスに自動でアプリケーションコードをデプロイするためのサービスで、スケーリングイベントが発生したときにもコードの更新が自動で行われるように設定できます。
- AMIを活用することで、新しく起動されたインスタンスが最新のコードを常に持つことができ、運用負荷を大きく軽減できます。
- 運用負荷の最小化が重要なため、選択肢DのようにAMIを使って自動化するアプローチが最適です。
実践
略
一問道場
質問 #267
トピック 1
ある企業では、アプリケーションがAmazon EC2インスタンスで実行され、Amazon EC2 Auto Scalingグループに属しています。企業はAWS CodePipelineを使用してアプリケーションをデプロイしています。Auto Scalingグループで実行されるインスタンスは、スケーリングイベントのために常に変動しています。企業が新しいアプリケーションコードバージョンをデプロイする際、企業は新しいターゲットEC2インスタンスにAWS CodeDeployエージェントをインストールし、インスタンスをCodeDeployのデプロイメントグループに関連付けます。アプリケーションは次の24時間以内に本番環境に公開予定です。
ソリューションアーキテクトは、運用負荷を最小限に抑えたアプリケーションのデプロイメントプロセスを自動化するために、何を推奨するべきですか？
A. Amazon EventBridgeを設定して、Auto Scalingグループに新しいEC2インスタンスが起動された際にAWS Lambda関数を呼び出します。Lambda関数でEC2インスタンスをCodeDeployのデプロイメントグループに関連付けるコードを記述します。
B. 新しいコードのデプロイ前にAmazon EC2 Auto Scaling操作を一時停止するスクリプトを記述します。デプロイが完了したら、新しいAMIを作成し、そのAMIを新しい起動時にAuto Scalingグループの起動テンプレートに設定します。Amazon EC2 Auto Scaling操作を再開します。
C. 新しいコードを含むAMIを作成する新しいAWS CodeBuildプロジェクトを作成します。CodeBuildがAuto Scalingグループの起動テンプレートを新しいAMIで更新するように設定し、Amazon EC2 Auto Scalingインスタンス更新操作を実行します。
D. CodeDeployエージェントがインストールされた新しいAMIを作成します。Auto Scalingグループの起動テンプレートを新しいAMIを使用するように設定し、EC2インスタンスではなくAuto ScalingグループにCodeDeployのデプロイメントグループを関連付けます。
解説
この問題のポイントは、アプリケーションのデプロイを自動化し、運用負荷を最小限に抑えることです。それぞれの選択肢を簡単にわかりやすく説明します。
A. Amazon EventBridge + Lambda 関数
- 方法：Auto Scalingグループに新しいEC2インスタンスが起動するたびに、EventBridgeでトリガーし、Lambda関数でインスタンスをCodeDeployのデプロイメントグループに関連付けます。
- メリット：自動化されるが、Lambdaの設定や管理が少し手間がかかります。
- デメリット：新しいインスタンスごとにLambdaを設定する必要があり、少し複雑になります。
B. EC2 Auto Scalingを一時停止して新しいAMIを作成
- 方法：新しいコードをデプロイする前にAuto Scalingを一時停止し、デプロイ後に新しいAMIを作成してAuto Scalingグループを更新します。
- メリット：確実に新しいコードを反映できます。
- デメリット：一時的にAuto Scalingを停止するため、ダウンタイムが発生し、手動操作が多くなります。運用負荷が高いです。
C. AWS CodeBuild + インスタンス更新
- 方法：CodeBuildを使って新しいAMIを作成し、それをAuto Scalingグループの起動テンプレートに設定します。
- メリット：AMI作成が自動化され、更新操作も含まれます。
- デメリット：設定が複雑で、運用負荷が少し高くなります。
D. 新しいAMIを作成してAuto Scalingの起動テンプレートに設定
- 方法：CodeDeployエージェントがインストールされた新しいAMIを作成し、Auto Scalingグループの起動テンプレートにそのAMIを設定します。これで新しいインスタンスは自動的にCodeDeployを使ってコードをデプロイします。
- メリット：一度設定すれば、新しいインスタンスが自動的にデプロイされるので、運用負荷が最小限です。スケーリングの度に手動操作が必要ありません。
- デメリット：特に大きなデメリットはなく、最も効率的な方法です。
結論
最も簡単で運用負荷が少ない方法は、Dの方法です。新しいAMIにCodeDeployエージェントをインストールし、それをAuto Scalingグループに設定することで、スケーリングされるインスタンスが自動的に新しいコードを受け取ることができます。これにより、手動で操作する必要がなくなり、運用が非常に簡単になります。
268-AWS SAP AWS 「理論・実践・一問道場」Auto Scalingグループに既存のEC2インスタンス
理論
AWSの公式ドキュメントでは、Auto Scalingグループに既存のEC2インスタンスを直接接続することに関する明確な推奨事項は記載されていません。ただし、一般的なベストプラクティスとして、Auto Scalingグループは新規インスタンスの起動と管理を目的としており、既存のインスタンスを直接管理下に置くことは推奨されていないと考えられます。
一方で、AWSの公式ドキュメントでは、Auto Scalingグループに既存のインスタンスをアタッチする際の考慮事項が説明されています。具体的には、アタッチされたインスタンスはスケーリングイベント中に終了される可能性があることや、インスタンスをアタッチする際のキャパシティ設定に関する注意点が挙げられています。
また、AWSの公式ドキュメントでは、Auto Scalingグループのインスタンスを更新する際の仕組みが説明されています。このプロセスでは、新しい起動テンプレートを作成し、既存のインスタンスを新しいインスタンスに置き換える方法が示されています。
これらの情報から、既存のインスタンスをAuto Scalingグループに直接接続することは、スケーリングや管理の観点から注意が必要であることがわかります。そのため、既存のインスタンスをAuto Scalingグループに接続する際は、これらの考慮事項を十分に理解し、適切な設定を行うことが重要です。
実践
略
一問道場
問題 #268
トピック 1
ある企業は、4つのAmazon EC2インスタンスで実行されているウェブサイトを運営しており、これらはApplication Load Balancer (ALB) の背後に配置されています。ALBがEC2インスタンスが利用できなくなったことを検出すると、Amazon CloudWatchアラームがALARM状態に入ります。その後、企業の運用チームのメンバーが手動で新しいEC2インスタンスをALBに追加します。
ソリューションアーキテクトは、EC2インスタンスの置き換えを自動的に処理する高可用性のソリューションを設計する必要があります。企業は新しいソリューションへの切り替え中のダウンタイムを最小限に抑える必要があります。
どの手順セットがこれらの要件を満たすべきでしょうか？
A. 既存のALBを削除し、ウェブアプリケーショントラフィックを処理するように構成されたAuto Scalingグループを作成する。新しいローンチテンプレートをAuto Scalingグループに接続する。新しいALBを作成する。新しいALBにAuto Scalingグループを接続する。既存のEC2インスタンスをAuto Scalingグループに接続する。
B. ウェブアプリケーショントラフィックを処理するように構成されたAuto Scalingグループを作成する。新しいローンチテンプレートをAuto Scalingグループに接続する。Auto Scalingグループを既存のALBに接続する。既存のEC2インスタンスをAuto Scalingグループに接続する。
C. 既存のALBとEC2インスタンスを削除し、ウェブアプリケーショントラフィックを処理するように構成されたAuto Scalingグループを作成する。新しいローンチテンプレートをAuto Scalingグループに接続する。新しいALBを作成する。新しいALBにAuto Scalingグループを接続する。Auto Scalingグループが最小数のEC2インスタンスを起動するのを待つ。
D. ウェブアプリケーショントラフィックを処理するように構成されたAuto Scalingグループを作成する。新しいローンチテンプレートをAuto Scalingグループに接続する。Auto Scalingグループを既存のALBに接続する。既存のALBが既存のEC2インスタンスをAuto Scalingグループに登録するのを待つ。
解説
Auto Scalingグループは、通常、新しいインスタンスを起動して管理するものであり、既存のインスタンスを直接接続することは一般的には推奨されません。既存のインスタンスは、Auto Scalingグループの管理下に置くことができませんし、既存のインスタンスに対してスケーリングや置き換えが自動的に行われないため、理想的ではありません。
この観点から、Bの選択肢は不適切です。最も適切な解決策は、新しいEC2インスタンスをAuto Scalingグループで管理し、既存のインスタンスは削除または無視する方法です。
したがって、Cがより適切な選択肢となります。Cでは、Auto Scalingグループを作成し、新しいローンチテンプレートを設定し、新しいEC2インスタンスを起動させ、最小限のインスタンス数を保つことで、EC2インスタンスの置き換えが自動的に行われます。
正解は、Cとなります。
269-AWS SAP AWS 「理論・実践・一問道場」AWS Service Catalog
理論
AWSコスト最適化とガバナンスのポイント
1. NATゲートウェイとS3ゲートウェイエンドポイント
- NATゲートウェイは、インターネットへの通信を中継するために使用しますが、データ転送量に応じた料金が発生します。
- S3ゲートウェイエンドポイントを利用することで、同一リージョン内でのS3アクセスをプライベートネットワーク経由にし、NATゲートウェイコストを削減可能。
2. AWS Service Catalogの役割
- 標準化されたテンプレートを提供し、承認済みリソースのみを簡単に作成可能。
- 管理者が構成を事前に制御できるため、開発者が誤った設定を行うリスクを回避。
3. コスト最適化の基本戦略
- データ転送の最適化: 必要な通信をローカル化し、転送コストを削減。
- 承認済みリソースの利用: 過剰なリソースや未承認の構成を防ぎ、予算を管理。
- 監視とアラート: AWS BudgetsやCloudWatchを活用し、異常な利用状況を検知。
4. ガバナンスと柔軟性の両立
- 開発者の生産性を維持しつつ、リソースの使用を標準化・自動化。
- AWS Service CatalogやAWS Configでルールを強制しつつ、必要な自由度を提供。
この知識を基に、コスト最適化とガバナンスを両立するソリューションを設計できます。
実践
略
一問道場
問題 #269
トピック 1
ある企業は、AWS Organizations内の開発者アカウント間でAWSのデータ転送コストと計算コストを最適化したいと考えています。開発者はVPCを構成し、単一のAWSリージョン内でAmazon EC2インスタンスを起動できます。EC2インスタンスは、毎日約1 TBのデータをAmazon S3から取得します。この開発者の活動により、EC2インスタンスとS3バケット間のデータ転送料金とNATゲートウェイの処理料金が過剰になり、計算コストも高くなっています。企業は、開発者がAWSアカウント内で展開するEC2インスタンスとVPCインフラストラクチャに対して承認されたアーキテクチャパターンを積極的に強制したいと考えていますが、この強制が開発者の作業速度に悪影響を与えることは避けたいと考えています。どのソリューションがこれらの要件を最もコスト効率よく満たすでしょうか？
A. 開発者が未承認のEC2インスタンスタイプを起動できないようにするためにSCP（サービスコントロールポリシー）を作成します。開発者には、承認されたVPC構成をデプロイするためのAWS CloudFormationテンプレートを提供します。開発者がCloudFormationでのみVPCリソースを起動できるように、IAMの権限をスコープ設定します。
B. AWS Budgetsで毎日の予測予算を作成し、EC2の計算コストとS3のデータ転送料金を開発者アカウント全体で監視します。予測コストが実際の予算コストの75％に達した場合、開発者チームにアラートを送信します。実際の予算コストが100％に達した場合、予算アクションを作成して開発者のEC2インスタンスとVPCインフラを終了させます。
C. 開発者アカウントがS3ゲートウェイエンドポイントと承認されたEC2インスタンスを使用する承認されたVPC構成を作成できるようにするために、AWS Service Catalogのポートフォリオを作成します。このポートフォリオを開発者アカウントと共有します。承認されたIAMロールを使用するようにAWS Service Catalogの起動制約を構成します。開発者のIAM権限を設定して、AWS Service Catalogへのアクセスのみを許可します。
D. 開発者のAWSアカウントでEC2およびVPCリソースのコンプライアンスを監視するためにAWS Configルールを作成して展開します。開発者が未承認のEC2インスタンスを起動した場合や、開発者がS3ゲートウェイエンドポイントなしでVPCを作成した場合、修復アクションを実行して未承認のリソースを終了させます。
270-AWS SAP AWS 「理論・実践・一問道場」AWS Control Tower
理論
AWSでのリージョン制限に関する知識
AWS環境で特定のリージョン外の操作を制御することは、セキュリティとコスト管理において重要です。以下は、このテーマに関連する主要なポイントです。
1. AWS OrganizationsとSCP（サービスコントロールポリシー）
- 概要: SCPはAWS Organizations内のすべてのアカウントで許可される操作を制御するポリシーです。
- 特徴:
- IAMポリシーとは異なり、すべてのユーザー、ロール、サービスに適用。
- 指定されたリージョン外でのリソース作成や操作を簡単に拒否可能。
- 適用例:
- 承認されたリージョン外でのリソースデプロイを防止。
- 例えば、
"aws:RequestedRegion"条件キーを使用して特定リージョンの操作を制限。
2. AWS Control Tower
- 概要: AWS環境のガバナンスとアカウント管理を簡素化するサービス。
- 利点:
- 複数のアカウントを一元管理。
- OU（組織単位）ごとにポリシー適用が可能。
- SCPの作成と管理をサポート。
- 適用例:
- 新規アカウント作成時に自動的にリージョン制限を適用。
3. IAMポリシーの制約
- 制限: IAMポリシーは個々のアカウント、ユーザー、またはロールにのみ適用され、組織全体の一貫したガバナンスには不向き。
4. AWS Security Hubの役割
- 概要: セキュリティ基準の監視とアラートを提供。
- 制約: アクセス制御や操作の強制には適していない。
重要なポイント:
- SCPを活用すると、特定リージョン外での操作を包括的に制御可能。
- AWS Control Towerは、スケーラブルなアカウント管理とポリシー適用を実現。
- IAMポリシーやSecurity Hubは、特定用途には役立つがリージョン制限には不十分。
ランディングゾーンとは？
ランディングゾーンとは、AWSで新しいアカウントやシステムを安全かつ効率的に運用するための「整った環境」のことです。
たとえるなら、 「新しい家を建てるために、最初に整備された土地」 です。
たとえ話: 家を建てるときのランディングゾーン
- 土地の整備
家を建てる前に、水道や電気の配線、地盤の整備をしますよね。
→ AWSでは、ネットワーク設定（VPCやサブネット）やセキュリティルール（IAMポリシーやSCP） がこれに当たります。
- インフラの準備
さらに、家の設計に合わせて基礎を作ります。例えば、どこにキッチンを置くか、玄関を作るかなどを決めます。
→ AWSでは、ログ管理、セキュリティ監視、共有アカウントの設定 などがこの部分です。
- テンプレートの用意
同じ設計の家を複数建てたい場合、あらかじめテンプレートを用意しておくと楽になります。
→ AWSでは、CloudFormationやService Catalog を使って新しいアカウントを簡単にセットアップできます。
- 安心して家を建て始める
土地が整備され、基礎ができていれば、安全でスムーズに家を建て始められます。
→ AWSでは、ランディングゾーンが整っていれば、新しいアカウントをすぐに運用開始できます。
AWSのランディングゾーンの主な要素
- AWS Control Tower: ランディングゾーンを簡単に作成・管理するサービス。
- VPCとネットワーク設定: 各アカウントの通信環境を整備。
- セキュリティポリシー: ガードレールとしてSCPを適用。
- ログと監視: CloudTrailやAWS Configを使った監視基盤。
要点
AWSランディングゾーンは、AWS環境で「最初に作る基盤」であり、
安全・効率的に運用するための出発点 を提供するものです。
実践
略
一問道場
質問 #270
トピック 1
ある企業が事業を拡大しています。この企業は、複数のAWSリージョンで数百の異なるAWSアカウントにリソースを分ける計画を立てています。ソリューションアーキテクトは、指定されたリージョン外での操作を拒否するソリューションを推奨する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. 各アカウントにIAMロールを作成する。アカウント用に承認されたリージョンのみを含む条件付き許可のIAMポリシーを作成する。
B. AWS Organizationsで組織を作成する。各アカウント用にIAMユーザーを作成する。アカウントがインフラをデプロイできないリージョンへのアクセスをブロックするポリシーを各ユーザーにアタッチする。
C. AWS Control Towerランディングゾーンを起動する。OU（組織単位）を作成し、承認されたリージョン外でのサービス実行を拒否するSCP（サービスコントロールポリシー）をアタッチする。
D. 各アカウントでAWS Security Hubを有効にする。アカウントがインフラをデプロイできるリージョンを指定するコントロールを作成する。
解説
正解: C. AWS Control TowerとSCPの活用
理由:
- AWS OrganizationsとSCPの活用
- サービスコントロールポリシー (SCP) により、指定リージョン外での操作を確実に拒否できる。
- SCPはすべてのIAMユーザーとロールに適用されるため、漏れがない。
- AWS Control Towerのメリット
- 組織の管理を簡素化し、数百のアカウントを効率的にセットアップ。
- リージョン制限やガバナンスを一元管理可能。
他の選択肢の問題点:
- A: IAMポリシーはSCPほど包括的ではなく、IAMユーザーやロールに適用される制約が限定的。
- B: IAMユーザー管理は煩雑で、ガバナンスの適用範囲が狭い。
- D: AWS Security Hubは監視ツールであり、アクセス制御には不向き。
Cのソリューションは、スケーラブルかつ強力なリージョン制限を実現する最適な選択肢です。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/174d7ae8-88e2-80f6-88a5-e5c75d714fb0
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
