As AWS ingrains itself in business strategies and IT infrastructure, deployments at every organization take on different shapes and sizes. Often, organic AWS deployments from IT development teams collide with the complexities of running a large IT shop with hundreds or thousands of users and multiple business units. Cloud control and complexity become major problems.
When individuals and workgroups create accounts and AWS resources for specific projects or applications, it's almost impossible to maintain the control IT and business processes require. AWS Organizations is a service designed to address the needs of large organizations that migrate production workloads and internal development projects to AWS. The Organizations management platform targets multiple AWS accounts and enables hierarchical group- and role-based policies for an entire enterprise user population.
Back to basics
Before diving into the features of AWS Organizations, it's important to review the basics of AWS cloud services. Accounts are the primary billing entity for Amazon services; they act to securely isolate different AWS environments, applications and users. Before an IT professional can use AWS, he must create an account, as it accumulates service charges. Because account-based billing has been problematic for large organizations, AWS introduced consolidated billing as an umbrella to accumulate charges for multiple subaccounts.
Introduced at AWS re:Invent 2016 and released for general availability in February 2017, AWS Organizations is designed to address the complex mix of hierarchical and overlapping business units, projects and workgroups within large companies. IT pros can simplify and automate AWS account creation for large-scale AWS users. Enterprises also can group logically connected accounts to streamline user management and consistently enforce security policies based on organizational units.
While AWS Organizations likely is overkill for small businesses and startups, the service could prove invaluable for large firms that use AWS as part of their core IT infrastructures.
Concepts and features
AWS Organizations introduces several administrative features for account management. The service groups all AWS accounts under central management into an elemental organization. Each organization includes:
- individual AWS accounts that consume services and are controllable with AWS Identity and Access Management (IAM) policies covering users and their roles;
- a master account that manages and accumulates charges for all other accounts; and
- organizational units (OU) that logically group accounts with similar policies.
- OUs are a management construct that can include accounts and other OUs in a hierarchical structure. But the OU hierarchy isn't strict, as an account can belong to multiple OUs. A tree view feature lets administrators browse accounts and OUs to see the hierarchical structure and apply policies.
Admins can only use the master account to create other user accounts within an organization. They can create accounts manually, using the AWS Management Console, or programmatically, using the Organizations API. Assign each user account to an IAM role, which defines permissions to access and use AWS resources. The master also can invite existing accounts to an organization, which triggers a process similar to a Facebook friend request and requires an affirmative response from the account owner.
Automate account creation using the AWS Command Line Interface and the following syntax:
Admins control accounts and resource use in an organization via two types of policy descriptions:
- Organizational control policies (OCP) are templates that consistently apply access and security policies to either the entire organization, an OU or individual accounts. OCPs are hierarchical, which means that parent OU policies automatically apply to all suborganizations and accounts.
- Service control policies (SCP) regulate access to AWS APIs using firewall-like white and black lists. SCPs and IAM role permissions combine to provide and manage access.
Best practices to get the most out of AWS Organizations
AWS Organizations gives enterprise admins the ability to control resource use at a granular level with policies that apply to users, roles, services, APIs or OUs. Aside from the inherent benefits of centralized financial control over IT expenses, AWS Organizations reduces overall AWS charges because all accounts within an organization are treated as one for billing purposes. This means they share certain resources, such as a Reserved Instance (RI), to save money. Consolidated billing makes it easier to qualify for higher volume discounts.
For example, AWS automatically discounts Elastic Compute Cloud RI use that reaches over $500,000 by 5% on both hourly and upfront fees. The discount jumps to 10% for over $4 million in reserved capacity use.
But admins must plan ahead to effectively use AWS Organizations. In a re:Invent 2016 session that covered the service, Amazon Principal Technical Program Manager Anders Samuelsson offered some best practices:
- Monitor activity via the master account, but don't use it to manage resources. Only use master accounts with AWS CloudTrail. Accumulate resource use into the master account via CloudTrail to get a look at overall AWS activity and spending.
- Use the standard security practice of least privilege when assigning access rights, and use OUs to define controls to accounts and user roles. OUs make it easier to match an organizational structure to the required level of AWS access.
- Although SCPs support allow and deny rules, don't mix white and black lists in the same policy; this creates the equivalent of spaghetti code.
- Perform tests on a single account before assigning it to an OU, and don't deploy controls without testing. Avoid assigning overly broad controls to the base of an organization on the master account.
Use Organizations APIs and CloudFormation templates with OCPs and SCPs to automate account creation and policy enforcement. Automation ensures IAM role and policy consistency, and it can preconfigure options, like the use of certain virtual private clouds and usage logging.
Use IAM to gain control over multiaccount deployments
Divide app dev stages into separate accounts to reduce frustration
How to use, balance multiple cloud management platforms