328-AWS SAP AWS 「理論・実践・一問道場」予防的ガードレール

type

status

date

slug

summary

理論

1. AWS Control Tower

AWS Control Towerは、AWS環境で複数のアカウントを効率的に管理するためのサービスです。特にガードレールを使って、組織内の各アカウントの設定やポリシーを統一し、セキュリティとコンプライアンスを確保できます。Control Towerは、リソースの設定ミスを減らすために使われます。

ガードレールには予防的ガードレールと探知的ガードレールがあり、前者はリソースの作成や変更を制限し、後者は不適切な設定を検出する役割があります。

2. AWS OrganizationsとSCP（サービスコントロールポリシー）

AWS Organizationsは、複数のAWSアカウントを管理するためのサービスで、組織単位でポリシーや設定を一元的に管理できます。SCPは、組織全体または特定のOU（組織単位）に対して適用できるポリシーで、許可または制限を行うためのものです。しかし、SCPはあくまでアクセス権限の制御を行うものであり、リソースの作成や変更そのものを制限するわけではありません。これに対して、Control Towerのガードレールはリソース作成の制限を行います。

3. AWS Config

AWS Configは、リソースの設定監視および変更履歴を追跡するサービスです。AWS Configルールを使用して、リソースが適切に設定されているかどうかを監視し、ポリシー違反を検出できます。AWS Configは主に設定や状態の監視に役立つため、リソースのデプロイ制限には向いていません。

4. 予防的ガードレール

AWS Control Towerの予防的ガードレールは、AWSリソースが特定のポリシーに従ってデプロイされることを確実にするために使います。これを使用すると、開発者が特定のインスタンスタイプ（例えば、バースト可能なインスタンス）以外のリソースを作成することを防ぐことができます。

まとめ

この問題では、開発OUに対して特定のインスタンスタイプとサービスの制限をかけるために、AWS Control Towerの予防的ガードレールを使用することが推奨されます。これにより、開発者がバースト可能なインスタンスだけをデプロイし、関連しないサービスを使用できないように制御できます。

実践

略

一問道場

質問 #328

ある会社が、AWS Control Towerを使用してマルチアカウント構造をオーケストレーションしています。同社はAWS Organizations、AWS Config、AWS Trusted Advisorを使用しています。同社には、開発者がAWSで実験するために使用する特定のOU（組織単位）があります。会社には何百人もの開発者がおり、各開発者には個別の開発アカウントがあります。同社はこれらの開発アカウントでコストを最適化したいと考えています。Amazon EC2インスタンスとAmazon RDSインスタンスはバースト可能でなければなりません。さらに、関連しないサービスの使用を禁止したいと考えています。

この要件を満たすために、ソリューションアーキテクトはどのような推奨をすべきですか？

A. AWS OrganizationsでカスタムSCPを作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このSCPを開発OUに適用します。

B. AWS Control Towerでカスタムの探知コントロール（ガードレール）を作成し、そのコントロール（ガードレール）を設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このコントロール（ガードレール）を開発OUに適用します。

C. AWS Control Towerでカスタムの予防コントロール（ガードレール）を作成し、そのコントロール（ガードレール）を設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。このコントロール（ガードレール）を開発OUに適用します。

D. AWS ConfigルールをAWS Control Towerアカウントで作成し、そのAWS Configルールを設定してバースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。AWS ConfigルールをCloudFormation StackSetsを使用して開発OUに展開します。

解説

この問題は、開発アカウントにおいてAWSリソースの使用を制限し、特にバースト可能なインスタンスのみを使用し、関連しないサービスの使用を禁止する方法に関するものです。最も適切な解決策を選ぶために、各選択肢を詳しく見ていきましょう。

選択肢の解説

A. AWS OrganizationsでカスタムSCPを作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。SCPを開発OUに適用します。

*サービスコントロールポリシー(SCP)**は、AWS Organizationsで設定され、IAMユーザーとロールのアクセス許可を制御します。SCPを使用すると、AWSリソースの使用を制限することができますが、実際のリソースの作成や管理に関する制限を厳密に行うためには、ガードレールを使用するのが一般的です。

SCPは「許可する」ポリシーを定義するのが難しく、特定のサービスやインスタンスに制限を加えることはできません。このため、リソース制限に関しては、SCPではなくガードレールを使う方が適切です。

B. AWS Control Towerでカスタムの探知コントロール（ガードレール）を作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。これを開発OUに適用します。

*探知コントロール（ガードレール）**は、リソースの使用状況を監視し、ポリシー違反を検出するために使用されます。リソースの作成や削除を直接制限するものではないため、リソースの使用を制限する目的には不十分です。

C. AWS Control Towerでカスタムの予防コントロール（ガードレール）を作成し、バースト可能なインスタンスのデプロイのみを許可し、関連しないサービスの使用を禁止します。これを開発OUに適用します。

*予防コントロール（ガードレール）**は、リソースの作成や変更を防ぐために使用されるもので、バースト可能なインスタンスのみを許可するという要件に最も適しています。予防コントロールはリソースの制限やガイドラインに従わせるため、特定のインスタンスタイプやサービスの使用を制限することができます。

開発OUに適用することで、開発者の使用するインスタンスを制限し、他のサービスを使わせないようにできます。これが最も効果的な方法です。

AWS Configは、AWSリソースの設定の監視と管理を行います。リソースの状態や変更を追跡するために使用されますが、リソースのデプロイを直接制限することはできません。AWS Configは、既存のリソースに対して監視や評価を行うツールであり、ポリシー違反を検出することができますが、リソースの作成を制御するためには予防コントロールが必要です。

結論

最適な解決策は、Cです。予防的ガードレールを使用することで、開発OU内でバースト可能なインスタンスのデプロイのみを許可し、その他のサービスを使用できないように制限できます。これにより、要件を満たし、効率的な管理が可能になります。