type
status
date
slug
summary
tags
category
icon
password
 

理論


AWS Organizations と AWS Control Tower による効率的なインフラ管理

1. AWS Organizationsの概要

AWS Organizations は、複数のAWSアカウントを一元的に管理するためのサービスです。組織単位(OU: Organizational Units)を使用して、アカウントを論理的にグループ化できます。これにより、企業はアカウントを部門別やプロジェクト別に整理し、それぞれに対して異なる管理ポリシーを適用できます。
  • アカウントの管理: AWS Organizationsを使用すると、複数のAWSアカウントを一括で作成、削除、管理することができます。
  • サービスコントロールポリシー(SCP): これにより、特定のAWSサービスへのアクセス制限や制御を実施できます。例えば、特定のアカウントでAmazon EC2の起動を禁止することができます。

2. AWS Control Towerの役割

AWS Control Tower は、AWS Organizationsを基盤にした管理機能を提供するサービスです。主に以下の目的で使用されます。
  • ガバナンスの確立: Control Towerは「積極的なコントロール(Guardrails)」というセキュリティ・コンプライアンスポリシーを提供します。これにより、組織内のアカウントに一貫した管理ポリシーを適用できます。
  • 自動化: Control Towerは新しいアカウントを迅速にセットアップするためのテンプレートとプロセスを提供し、管理者は新しいアカウントを一貫したベストプラクティスに従って簡単に作成できます。
  • セキュリティとコンプライアンスの強化: Control Towerは、AWS Config、CloudTrail、GuardDutyなどを統合して、組織全体でセキュリティとコンプライアンスを強化する機能を提供します。

3. Guardrailsと積極的なコントロール

Control Towerでは、**積極的なコントロール(Guardrails)を利用して、企業全体でベストプラクティスを強制することができます。これらのコントロールは、セキュリティやコスト管理、インフラの運用に関するものです。Guardrailsは「検出型」「強制型」**の2種類に分かれます。
  • 検出型Guardrails: 特定のリソースに関する設定が正しいかどうかを監視し、違反が発生した場合に通知を送ります。
  • 強制型Guardrails: 規定の設定を強制し、違反が発生した場合にリソース作成を防ぎます。
例えば、インスタンスのパブリックIPアドレスの管理に関するポリシーは、強制型Guardrailsとして設定できます。この設定により、OU内のすべてのアカウントでインスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。

4. 事前防止と事後対応の違い

事前防止型アプローチは、問題が発生する前に制限やポリシーを設定し、問題を未然に防ぐ方法です。たとえば、AWS Control Towerのガードレールを使用して、インスタンスにパブリックIPアドレスを割り当てないように制限する方法がこれに該当します。事前防止型のアプローチは、組織全体で一貫性を保ちながら、手間をかけずにセキュリティとコンプライアンスを維持できます。
一方、事後対応型アプローチは、問題が発生した後にそれを検出し、修正する方法です。例えば、AWS ConfigとLambdaを使用して、インスタンスにパブリックIPアドレスが割り当てられている場合に自動的に修正する方法がこれに該当します。事後対応型アプローチは、柔軟性がありますが、問題発生後の対応が必要になるため、予防策としてはやや不十分です。

5. パブリックIPアドレスの管理

Amazon EC2インスタンスがパブリックIPアドレスを取得しないようにするためには、いくつかの方法があります。
  • AWS Control Towerの積極的なコントロール: Control Towerのガードレールを利用して、インスタンスの設定を制御できます。特に、AssociatePublicIpAddressプロパティを設定し、インスタンスにパブリックIPアドレスが自動的に割り当てられないようにすることが可能です。
  • SCP(Service Control Policies): SCPを使用して、アカウント全体にパブリックIPアドレスを設定できないようにすることもできますが、これはServiceの利用に対するアクセス制御の範疇であり、リソースの設定に直接関連する制御とは異なります。
  • AWS ConfigとLambda: AWS Configでインスタンス設定を監視し、インスタンスがパブリックIPアドレスを持っている場合にLambda関数で修正する方法もあります。この方法は後から修正するため、プロアクティブな解決策としては適していません。

まとめ

AWS OrganizationsとAWS Control Towerは、企業全体のAWSアカウント管理とガバナンスを効率的に行うための強力なツールです。特に、パブリックIPアドレスの設定を管理する際には、AWS Control Towerの積極的なコントロールを活用することで、セキュリティとコンプライアンスの維持が容易になります。事前防止型アプローチを採用することで、リソース設定の一貫性を保ちながら、運用の効率化を実現することができます。

このような知識を活用することで、AWS環境を効果的に管理し、セキュリティやコスト管理の面でも最適化を図ることができます。

実践

一問道場

質問 #410
ある会社は、AWS Organizations内でAWS Control Towerを使用してAWSアカウントを管理しています。会社には、アカウントを含むOU(組織単位)があります。この会社は、OU内のアカウントで新規または既存のAmazon EC2インスタンスがパブリックIPアドレスを取得できないようにする必要があります。
どのソリューションがこれらの要件を満たしますか?
A. 各アカウントのインスタンスにAWS Systems Managerを使用するように設定します。Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。
B. AWS Control Towerの積極的なコントロールを実装して、OU内のアカウントでインスタンスにパブリックIPアドレスが設定されているかどうかを確認します。AssociatePublicIpAddressプロパティをFalseに設定し、この積極的なコントロールをOUに適用します。
C. パブリックIPアドレスを持つインスタンスの起動を防止するSCP(Service Control Policy)を作成します。さらに、SCPを設定して既存のインスタンスにパブリックIPアドレスを割り当てることを防ぎます。このSCPをOUに適用します。
D. インスタンスにパブリックIPアドレスが設定されているかどうかを検出するAWS Configカスタムルールを作成します。AWS Lambda関数を使用してパブリックIPアドレスをインスタンスから切り離す修復アクションを設定します。

解説

このシナリオでは、AWSアカウント内のAmazon EC2インスタンスがパブリックIPアドレスを取得できないようにする必要があります。それに対して、最適なソリューションを選択することが求められています。
各選択肢について解説します。

A. 各アカウントのインスタンスにAWS Systems Managerを使用するように設定します。Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスが割り当てられるのを防ぎます。

  • 不適切な選択肢: Systems ManagerのAutomationランブックを使用して、インスタンスにパブリックIPアドレスを割り当てないようにする方法は、管理が手動で複雑になる可能性が高く、AWS OrganizationsやControl Towerを活用して一貫したポリシーを適用する方が効率的です。この方法は、実装と運用がやや煩雑でスケールしにくいため、適切ではありません。

B. AWS Control Towerの積極的なコントロールを実装して、OU内のアカウントでインスタンスにパブリックIPアドレスが設定されているかどうかを確認します。AssociatePublicIpAddressプロパティをFalseに設定し、この積極的なコントロールをOUに適用します。

  • 適切な選択肢: AWS Control Towerの積極的なコントロール(Guardrails)を使用して、OU内のアカウントに一貫して制約を適用する方法です。この方法では、AssociatePublicIpAddressプロパティをFalseに設定することで、インスタンスにパブリックIPアドレスが割り当てられないように制御できます。このアプローチは、AWS Organizations内のすべてのアカウントに対して一貫したポリシーを適用でき、管理が簡単です。

C. パブリックIPアドレスを持つインスタンスの起動を防止するSCP(Service Control Policy)を作成します。さらに、SCPを設定して既存のインスタンスにパブリックIPアドレスを割り当てることを防ぎます。このSCPをOUに適用します。

  • 不適切な選択肢: SCP(Service Control Policy)は、アカウントやユーザーに対して許可または拒否する操作を制御するポリシーですが、パブリックIPアドレスの割り当てに対する直接的な制御は提供しません。SCPはAWSサービスの利用制限には役立ちますが、特定のリソースに対してパブリックIPアドレスを設定させないことを直接的に制御する機能はありません。そのため、この方法は不適切です。

D. インスタンスにパブリックIPアドレスが設定されているかどうかを検出するAWS Configカスタムルールを作成します。AWS Lambda関数を使用してパブリックIPアドレスをインスタンスから切り離す修復アクションを設定します。

  • 不適切な選択肢: AWS ConfigとLambdaを使用してインスタンスの修復アクションを設定する方法は、問題を発見して修正するための手段にはなりますが、事前にインスタンスにパブリックIPアドレスが設定されないようにするための予防的な手段としては最適ではありません。修復アクションは後からの対応となるため、予防策としては不十分です。

結論

最も適切な解決策は B です。AWS Control Towerの積極的なコントロールを使用して、OU内のアカウントにパブリックIPアドレスを設定させないようにすることが、最も効率的で管理が容易な方法です。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
411-AWS SAP AWS 「理論・実践・一問道場」Amazon Cognito409-AWS SAP AWS 「理論・実践・一問道場」AWS Secrets Manager
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签