Large enterprises typically have dedicated teams handling security, network operations, audit, software development, and so on. These teams are often grouped by cost centers, require customized access controls, and are governed by security controls and governance policies. Software development teams, on the other hand, are grouped by business domains or value streams and have several environments, such as development, staging, and production, where they host their application workloads. The boundaries provided by an AWS account in terms of billing, access, and isolation needs map well to such scenarios. OUs can provide a logical structure that these accounts can be further grouped under, for access control and policy enforcement. A sample OU structure is given in Figure 11.2:
Figure 11.2 – Sample OU hierarchy for an organization hosting regulated workloads
Grouping the AWS accounts under specific OUs simplifies the definition, and mapping of policies. Let’s discuss this in the following section.
Enforcing policies to control service usage and tag assignments
Three types of policies are supported by AWS Organizations – Service Control Policies (SCPs), Tagging Policies, and Backup Policies.
SCPs can restrict certain IAM actions to all OUs, or accounts they are mapped to. It is important to not overuse them as there are restrictions around policy size (5,120 bytes) and the total number of policies that can be directly applied to an AWS account or OU (currently 5). Think of them asglobal controls that deny all actions that you do not want your users to perform. For example, denying all other AWS regions except the ones you want to operate in is a common SCP control. Another could be denying the configurations to make an S3 bucket public or restricting certain EC2 instance types that can have cost repercussions or be misused in a certain way. AWS IAM inherently denies all actions that are not explicitly added to a policy, but SCPs are a type of global administrative mechanism that takes the highest precedence, even in scenarios where a certain IAM action has been mistakenly allowed on a user or resource.
Tagging policies, in combination with SCPs, are used to enforce the existence of certain tag keys and the corresponding values. Almost all AWS resources support tags, which are key-value pairs that are used to provide additional context to a particular resource. This is particularly useful for tracking down the owners and application teams for support, operations, or cost analysis needs. A common mistake that organizations make is investing too much time and effort in coming up with a tagging strategy that will fulfill all their future needs. It’s highly recommended to start backward – that is, identify the problem that you want to solve with tags and then arrive at a tagging policy that helps you enforce it. For example, if an organization is struggling with identifying the resource owners in the aggregated cost and usage reports, it might help to enforce the tag keys that map teams and individuals.
Backup policies are used to automatically apply backup plans to supported resources, across all your AWS accounts.