Manage and govern multiple AWS environments centrally with AWS Organizations
Cloud-managed services are inevitable to increase business productivity and maintain a competitive edge in the market. This USD 86.1 billion market is rapidly gaining acceptance worldwide by large enterprises and SMEs due to various benefits, including the rise in digitization and emerging trend of workplace transformation, reduced costs, efficient collaborations, and reduced time to market for new products.
The usage of cloud services and resources is only going to explode due to devices proliferating with the IoT technology and hence is more important to have an organized way of managing cloud usage. With the enterprises accelerated into digital transformation at scale, one of the big 4 consultancies predicts that by 2030, IoT could enable $5.5 trillion to $12.6 trillion in value globally, including the value captured by consumers and customers of IoT products and services.
The increased usage demands appropriate management, keeping in mind the various budgetary, security, and compliance needs specific to the organization. Anything more than 50 accounts with a cloud provider consumes significant time, resources, and thus costs for the organization. In this blog, let’s explore how we can use “AWS Organizations” to efficiently manage and govern an enterprise’s cloud service requirements.
Why AWS Organizations
When we create a single account with a public cloud service provider, we only need to provide an email id to uniquely identify our account and billing details. This works fine as long as we are working on a single account. But when we want to combine multiple accounts based on different strategies like a business unit, application, environment, etc., we need to have a way to organize those accounts with respect to the budgetary, security, and compliance needs. Another concern is AWS account creation, which is manual and time-consuming.
To overcome the above problems, AWS has a service called AWS Organizations, which centrally manages multiple accounts and applies policies to those accounts for compliance. It also provides consolidated billing of those multiple cross accounts, which yields more usage discounts (volume discount for EC2, S3…etc.) in your bill.
Organizations API is available to automate AWS account creation via Master Account. Before AWS Organizations, AWS account creation was done manually, which was time-consuming. With AWS Organizations, it can be done programmatically.
An administrator of an organization can create accounts in your organization and invite existing accounts to join the organization. The finance administrator can easily investigate the monthly expenditure report of multiple accounts from a central Master account. The security team can apply compliance through Service Control Policies (SCPs) in a more effective way from a single place (Master account).
AWS Organizations is a free AWS service, i.e., there is no charge while using it.
Integration with AWS Single Sign-On (SSO). With the help of SSO, you can use any auth service like OKTA/Azure AD to access your AWS Accounts.
AWS Organizations architecture
Figure 1: AWS Organizations Architecture
Organizational Units (OUs)
An organizational unit (OU) is a logical grouping of accounts in your AWS Organization. Organizational Units enable you to organize your accounts into a hierarchy and make it easier for you to apply management controls.
Your OUs should be based on function or a common set of controls rather than mirroring your company’s reporting structure.
Please find the organizational unit (OU) example below:
Figure 2: An Organizational Unit (OU) example
Service Control Policies (SCPs)
AWS Organizations support Service Control Policies (SCPs) that can be used to control the maximum available permissions for all accounts in the organization. SCPs can be used to guarantee that all the accounts follow the organization’s access control policies. SCPs can be defined at the organization, organizational unit, and account level. However, SCPs do not grant permissions to users — they just define the maximum available permissions. This means that user permissions still need to be defined separately using IAM policies. An action is allowed only if policies, both identity-based and resource-based, and SCP allow the action. In addition, the action must be permitted by every parent above the account, or otherwise, it is blocked.
SCPs support whitelisting and blacklisting. Whitelisting means that only defined actions are allowed, and everything else is forbidden. Blacklisting means that everything is allowed except the defined actions.
- SCP is applied at the OU or account level but doesn’t apply to the Master Account
- SCP is applied to all the users and roles of the account, including root user
- The SCP does not affect service-linked roles
- Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs
- SCP must have an explicit ‘Allow’ (does not allow anything by default)
Use cases:
- Restrict access to certain services (for example: can’t use EMR)
- Enforce PCI compliance by explicitly disabling services
SCP hierarchy
Figure 3: SCP hierarchy
Multi-account strategies
- Create accounts per department, per cost center, per dev/test/prod, based on regulatory restrictions (using SCP), for better resource isolation (ex: VPC), to have separate per-account service limits, isolated account for logging
- Multi-Account vs One Account Multi VPC
- Use tagging standards for billing purposes
- Enable AWS CloudTrail on all accounts, send logs to a central S3 account
- Send CloudWatch Logs to the central logging account
- Establish Cross-Account Roles for Admin purposes
Manage and govern multiple AWS environments centrally with AWS Organizations
AWS Organizations equivalent to Azure and GCP
In Azure, we can organize subscriptions into containers called “management groups” and apply our governance conditions to the management groups.
In Google Cloud Platform (GCP), the Organization resource represents an “organization” (for example, a company) and is the root node in the Google Cloud resource hierarchy. The Organization resource is the hierarchical ancestor of project resources and folders.
Figure 4: AWS Organizations Equivalent in Azure & GCP
AWS Organizations best practices
While creating any organization in AWS, it's essential to know how to utilize it in its best way. Kindly find some best practices while utilizing AWS Organizations as below:
- AWS Organizations have only one Master Account, which is also known as Payer Account. This account needs to be most secure. Kindly do not add resources to the Master Account (except those are extremely crucial).
- Use AWS Cloudtrail to monitor and log activities in the Master Account.
- Manage Organization using the principle of “Least Privilege”.
- Use Organization Units (OUs) to assign controls.
- Test Service Control Policies (SCPs) first on a single AWS account before rolling out.
- For easy scaling, assign Service Control Policies (SCPs) at the Organization Unit (OU) level instead of the account level.
- Avoid assigning Service Control Policies (SCPs) at the root level, unless necessary.
- Use either Whitelisting or Blacklisting Service Control Policies (SCPs) in the Organization, but not both.
- Create new AWS Accounts for the right reasons within the Organization.
For further information, feel free to contact us on iotworks@hcl.com
