Manage Security and Costs Across the Enterprise With AWS Organizations
As an IT Pro, managing your organization's computing resources is a key role. AWS Organizations provides the tools to organize and manage user accounts and cloud resources for security and cost control at the enterprise level.
- AWS Organizations
- How to create an Organization
- Best practices for managing an Organization
About | |
---|---|
✅ AWS Level | Intermediate - 200 |
⏱ Time to complete | 15 minutes |
💰 Cost to complete | Free when using the AWS Free Tier or USD 1.01 |
🧩 Prerequisites | - AWS Account |
📢 Feedback | Any feedback, issues, or just a 👍 / 👎 ? |
⏰ Last Updated | 2023-07-26 |
- Create the organization,
- Create the organizational units,
- Create the service control policies,
- Test the policies.
- AWS Organizations offer four support plans. Support plans are tailored to how you will use AWS Organizations. If you are just starting with AWS, choose the Developer plan to learn about the service. Next step up is the Business support plan. Choose this option if you are performing formal development and running production workloads. The Enterprise support plans are for organization running mission critical business and production workloads on AWS.
- Secure the root or Management account. Avoid using the the root account for administrative tasks and workloads.
- Enable multi-factor authentication for the root account.
- Create alternate contacts for billing, operations, and security accounts to ensure notifications are properly routed. Consider using email distribution lists to reach multiple team members.
- AWS recommends creating two foundational OUs:
- An infrastructure OU for shared networking and IT services. You should create accounts for each type of infrastructure service in use.
- A security OU for security services such as logging, security tooling, and break-glass access.
- Under the infrastructure and security OU, create a non-production or SDLC (software development lifecycle) OU and a production OU
- OUs are hierarchical and can be nested but start with a relatively flat hierarchy as shown in this diagram:
- You can find a list of best practice OUs in this article.
- SCPs are invisible and applied to all roles in a child account.
- SCPs can be attached to multiple levels in an organization hierarchy which means an account can inherit multiple policies. The permissions of a child account is a combination of policies attached to the account and the policies inherited from the parent account.
- The higher up in the organization, the less granular the policy. Lower level accounts have more restrictive policies. For example, a higher-level policy allows the Amazon Relational Database Service (RDS), but a lower level account might be restricted to smaller instances.
- Examples of SCPs can be found in the AWS Organizations User Guide.
- You can find a list of best practices for SCPs in Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment.
- AWS Organizations do not have a direct way to test the effect of SCPs. However, the AWS Identity and Access Management (IAM) Access Advisor can show last accessed services for an Organization. This function is also available through the AWS CLI with the command
aws generate-organizations-access-report
and the AWS API with GenerateOrganizationsAccessReport. The Access Identity and Access Management Guide has the details on viewing last accessed information for AWS Organizations.
- The alternative way to test SCPs is to use AWS CloudTrail and you can follow steps on how to create a trail for an organization.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.