Hello, and welcome to this lecture, where I shall be explaining what AWS Organizations are and how you can use them within your own environment.

AWS Organizations provides a means of centrally managing and categorizing multiple AWS accounts that you own. This helps maintain your AWS environment from a security, compliance, and account management perspective.

To understand how AWS Organizations works, we first need to understand the hierarchy of components of the service, that allows for the simplistic management functionality. AWS Organizations uses the following components, organizations, root, organizational units, service control policies, and accounts. Let me now explain what each of these provide.

An organization is the basis of what forms the hierarchical structure of multiple AWS accounts. You could almost think of the complete organization as a family tree, which gives you a graphical view of your entire AWS account structure. At the very top of this organization, there will be a root container.

This object is simply a container that resides at the top of your organization and all of your AWS accounts and organizational units will sit underneath this root. Within any organization, there will only always be a single root object.

Organizational units. Organizational units provide a means of categorizing your AWS accounts. Again, like the root, these are simply containers allowing you to group together specific AWS accounts. An organizational unit can connect directly below the root or even below another organizational unit, which can be nested up to five times. This allow you to create a hierarchal structure like I mentioned previously.

Service Control Policies. Service Control Policies allow you to control what services and features are accessible from within an AWS account. These Service Control Policies can either be associated to the root, an organizational unit, or an individual account. When a Service Control Policy is applied to any of these objects, the controls associated are fed down to all objects below the object that the policy is applied to. These are different from IAM permissions, which control permissions on a user or service level within an AWS account. Restrictions made at a Service Control Policy override permissions within an AWS account.

For example, let's say a user within an AWS account had full access to S3, RDS and EC2. If the Service Control Policy associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2, despite having full access to S3. The Service Control Policy would not allow the service to be used within the AWS account.

Accounts. These are standard AWS accounts that can be added to the organization. When setting up AWS Organizations, one AWS account will act as the master and all other AWS accounts will act as member accounts. More on this will be discussed in the next section.

To set up an organization is a very simple process. You start with a master AWS account. This is just a standard AWS account that you have chosen to create the AWS organization. It's best practice to use this AWS account simply as a master account and not to use it to provision resources such as EC2 instances. This allows you to restrict access to the master account at a greater level. The fewer users who need to access it the better, due to its ability to manage and control other AWS accounts.

When you have selected your AWS account to be used as a master account, you can create an AWS organization. From here, you have two choices for an organization type, enable all features, or enable only consolidated billing. To allow you to create Service Control Policies as mentioned previously, you'll need to select enable all features. The second option simply allows you to control payment and manage costs centrally, from that master account across all associated AWS accounts within the organization allowing you to receive a single bill.

When the organization is created the master account can then create any organizational units and Service Control Policies for AWS account management as required. The master account can then invite other member AWS accounts to join the organization. The account owner of these invited AWS accounts will then receive an email requesting their AWS account to join the organization. When the accounts have joined the organization, the master account can then move these accounts into the corresponding organizational units that have been created and associate any Service Control Policies that may be required.

Now we have an understanding of what AWS Organizations are exactly, what benefits can this bring to our AWS environment? Account management. The primary benefit that this service brings is its ability to centrally manage multiple accounts from a single AWS account known as the master account. With its ability to join your existing accounts to an organization as well as create new accounts directly from the service, it allows you to start using the service within your existing AWS environments and accounts right away.

Greater control of your AWS environment. Through the use of Service Control Policies attached to the root, organizational units, or individual accounts, it gives the administrator of the master account control over which service and features, even down to the specific API calls, that any IAM user within these accounts, can use regardless of those users IAM permissions. C

onsolidated billing. The master account of your AWS organization can be used to consolidate the billing and costs from all member AWS accounts. This allows for a greater overall cost management across your individual AWS accounts.

Categorization and grouping of accounts. Using the organizational units, you are able to segregate and group specific AWS accounts using different Service Control Policies associated to each organizational unit. For example, you may have a number of AWS accounts who must not have the ability to access any analytical services. In this case, you could place these accounts into a single organizational unit and assign a Service Control Policy that denies this functionality.

That now brings me to the end of this lecture covering an introduction to AWS Organizations.