比較表
特徴 | ガードレール (AWS Control Tower) | SCP (AWS Organizations) |
---|---|---|
目的 | AWS 環境でのリソース使用や設定のガバナンスを強化する。 | AWSアカウントやOUごとのアクセス制御を管理する。 |
適用対象 | AWS Control Tower 管理下のアカウントやOU。 | AWS Organizations 管理下のアカウントやOU。 |
種類 | 予防制御(Preventive)および検出制御(Detective)。 | 許可または拒否によるサービスアクセスの制御。 |
リソース管理 | 特定のサービスやリソースの使用制限 | サービスの利用権限を制御し、アクセスできるサービスを決定。 |
管理者への通知 | 検出ガードレールで通知される(例: 設定違反のアラート)。 | 設定によって適用されるが通知は含まない。 |
適用の方法 | AWS Control Towerで自動的にアカウントに適用。 | AWS Organizationsでアカウント単位またはOU単位で手動設定。 |
設定方法 | SCPのようにJSON形式で直接記述がない。コンソールで選択的に設定する形。 | JSON形式で設定できる。 |
ガードレールのユースケース
リソースの使用制限
特定の EC2インスタンスタイプ(例:バースト可能なインスタンスのみを許可)や、RDSインスタンスタイプ、特定のサービス(例:S3やLambdaなど)の利用を制限することができます。
リソースの無駄遣いや予期しない高コストの発生を防ぐことができます。
サービス利用制限
開発環境において、特定のサービス(例:CloudFrontやRedshiftなど)の使用を禁止することができます。
開発環境で不要なサービスが使用されるのを防ぎ、コスト管理やセキュリティ管理が容易になります。
リソースタグ付けの強制
リソースに特定のタグ(例:Environment: Development)が必ず付けられるよう強制できます。
リソース管理が統一され、運用やコスト分析の際にリソースを簡単にトラッキングすることができます。
インスタンスの起動や変更の制限
特定のリージョンでのみリソースを作成可能にします。
特定の設定(例えば、データベースの暗号化)が必須であることを強制することができます。
開発者がリソースを作成する際に、ガードレールによって設定ミスやポリシー違反が事前に防がれます。
セキュリティポリシーの強制
セキュリティグループやネットワークACL(アクセスコントロールリスト)の設定を強制することができます。
外部インターネットからアクセス可能なインスタンスを制限したりすることができます。
検出と通知(検出ガードレール)
検出ガードレールを使うことで、設定違反やリソースの不適切な利用を検出し、アラートや通知を受け取ることができます。
リソースが想定通りに使われていない場合に早期に対応することができます。
SCPsのユースケース
アクセス制御
アカウントがAWSサービスを利用できるかどうか、どのアクションが許可されるかを制御します。
組織の開発アカウントには特定のAWSサービスの利用を制限する、または本番環境のアカウントに対してはIAM権限の変更を制限するなど、サービスの使用を制限します。
サービスごとに設定され、特定のサービスやアクションにアクセスできるかどうかを決定します。
「許可」または「拒否」で設定
組織の親アカウント(ルート)で設定されたSCPポリシーは、下位のアカウントに自動的に適用され、ポリシーに従ったサービス利用を強制します。
ガードレールとSCPを組み合わせて使う
SCPでアクセスを制限し、Control Towerのガードレールでリソースの使い方を制限するという二重の防御が可能です。
SCP は主にアクセス制御に使用されるため、組織全体で特定のサービスやリソースにアクセスできないように制限します。
例:開発アカウントに対してSCPで本番環境に使うべきサービスへのアクセスを制限します。
ガードレール は、AWS Control Towerのポリシーとしてリソースの作成や使用に対する制限を加えるため、アカウント内でどのようにリソースが使用されるかを管理します。
例:開発アカウントで特定のインスタンスタイプしか使用できないように制限するなど、リソース管理に強い制限を加えることができます。
参考サイト