1. AWS Organizations is an account management service that enables consolidating multiple AWS accounts into an organization that can be created and centrally managed.

2. Using multiple accounts can provide greater workload isolation and more layers of security. You can use consolidated billing to manage multiple accounts under a single payer. Keep in mind that cross-account access is not enabled by default.

3. AWS Organizations includes consolidated billing and account management capabilities that enable one to better meet the budgetary, security, and compliance needs of your business.

4. As an administrator of an organization, new accounts can be created in an organization and invite existing accounts to join the organization.

5. AWS Organizations enables you to

   1. Centrally manage policies across multiple AWS accounts

   2. Control access to AWS services

   3. Automate AWS account creation and management

   4. Consolidate billing across multiple AWS accounts

6. 
   

1. Centralized management of all of your AWS accounts

• Combine existing accounts into or create new ones within an organization that enables them to be managed centrally.

• Policies can be attached to accounts that affect some or all of the accounts

2. Consolidated billing for all member accounts

• Master account of the organization can be used to consolidate and pay for all member accounts.

3. Hierarchical grouping of accounts to meet budgetary, security, or compliance needs

• Accounts can be grouped into organizational units (OUs) and each OU can be attached different access policies.

• OUs can also be nested to a depth of five levels, providing flexibility in how you structure your account groups.

4. Control over AWS services and API actions that each account can access

• Access to users and roles in each member account can be restricted to which AWS services and individual API actions.

• Organization permissions overrule account permissions.

• This restriction even overrides the administrators of member accounts in the organization.

• When AWS Organizations blocks access to a service or API action for a member account, a user or role in that account can’t access any prohibited service or API action, even if an administrator of a member account explicitly grants such permissions in an IAM policy.

5. Integration and support for AWS IAM

• AWS Organizations expands that control to account level by giving control over what users and roles in an account or a group of accounts can do.

• User can access only what is allowed by both the AWS Organizations policies and IAM policies.

• Resulting permissions are the logical intersection of what is allowed by AWS Organizations at the account level, and what permissions are explicitly granted by IAM at the user or role level within that account.

6. Integration with other AWS services

• Select AWS services can be enabled to access accounts in the organization and perform actions on the resources in the accounts.

• When another service is configured and authorized to access with the organization, AWS Organizations creates an IAM service-linked role for that service in each member account.

• Service-linked role has predefined IAM permissions that allow the other AWS service to perform specific tasks in the organization and its accounts.

• All accounts in an organization automatically have a service-linked role created, which enables the AWS Organizations service to create the service-linked roles required by AWS services for which you enable trusted access.

• These additional service-linked roles come with policies that enable the specified service to perform only those required tasks.

• Data replication that is eventually consistent

• AWS Organizations is eventually consistent.

• AWS Organizations achieves high availability by replicating data across multiple servers in AWS data centers within its region.

• 
  

1. Organization

• An entity created to consolidate AWS accounts.

• An organization has one master account along with zero or more member accounts.

• An organization has the functionality that is determined by the feature set that you enable i.e. All features or Consolidated Billing only

2. Root

• Parent container for all the accounts for the organization.

• Policy applied to the root is applied to all the organizational units (OUs) and accounts in the organization.

• There can be only one root currently and AWS Organization automatically creates it when an organization is created.

3. Organization unit (OU)

• A container for accounts within a root.

• An OU also can contain other OUs, enabling hierarchy creation that resembles an upside-down tree, with a root at the top.

• A policy attached to one of the nodes in the hierarchy, flows down and affects all branches (OUs) and leaves (accounts) beneath it.

• An OU can have exactly one parent, and currently each account can be a member of exactly one OU.

4. Account

• A standard AWS account that contains AWS resources.

• Each account can be directly in the root, or placed in one of the OUs in the hierarchy.

• Policy can be attached to an account to apply controls to only that one account.

• Accounts can be organized in a hierarchical, tree-like structure with a root at the top and organizational units nested under the root.

• Master account

  • Primary account which creates the organization

  • can create new accounts in the organization, invite existing accounts, remove accounts, manage invitations, apply policies to entities within the organization.

  • Has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts.

• Member account

  • Rest of the accounts within the organization are member accounts.

  • An account can be a member of only one organization at a time.

5. Invitation

• Process of asking another account to join an organization.

• An invitation can be issued only by the organization’s master account and is extended to either the account ID or the email address that is associated with the invited account.

• Invited account becomes a member account in the organization, after it accepts the invitation.

• Invitations can be sent to existing member accounts as well, to approve the change from supporting only consolidated billing feature to supporting all features.

• Invitations work by accounts exchanging handshakes.

6. Handshake

• A multi-step process of exchanging information between two parties

• Primary use in AWS Organizations is to serve as the underlying implementation for invitations.

• Handshake messages are passed between and responded to by the handshake initiator (master account) and the recipient (member account) in such a way that it ensures that both parties always know what the current status is.

1. Consolidated billing

1. provides shared billing functionality

2. All features

• includes all the functionality of consolidated billing,

• includes advanced features that gives more control over accounts in the organization.

• allows master account to have full control over what member accounts can do

• master account can apply SCPs to restrict the services and actions that users (including the root user) and roles in an account can access, and it can prevent member accounts from leaving the organization.

1. Service control policy specifies the services and actions that users and roles can use in the accounts that the SCP affects.

2. Offers central control over the maximum available permissions for all accounts in your organization, ensuring member accounts stay within the organization’s access control guidelines .

3. SCPs are similar to IAM permission policies, except that they don't grant any permissions. Instead, SCPs specify the maximum permissions for an organization, organizational unit (OU), or account.

4. Available only in an organization that has all features enabled.

5. The complete feature set that is available to AWS Organizations. It includes all the functionality of consolidated billing and advanced features that give you more control over your organization's accounts.

6. The master account can apply SCPs to restrict the services and actions that users (including the root user) and roles in an account can access. It can prevent member accounts from leaving the organization.

7. SCPs are similar to IAM permission policies except that they don’t grant any permissions.

8. SCPs are filters that allow only the specified services and actions to be used in affected accounts.

9. SCPs override IAM permission policy. So even if a user is granted full administrator permissions with an IAM permission policy, any access that is not explicitly allowed or that is explicitly denied by the SCPs affecting that account is blocked. For e.g., if you assign an SCP that allows only database service access to your “database” account, then any user, group, or role in that account is denied access to any other service’s operations.

10. With an SCP attached to member accounts, identity-based and resource-based policies grant permissions to entities only if those policies and the SCP allow the action .

11. SCP can be attached to

    1. A root, which affects all accounts in the organization

    2. An OU, which affects all accounts in that OU and all accounts in any OUs in that OU subtree

    3. An individual account

12. Master account of the organization is not affected by any SCPs that are attached either to it or to any root or OU the master account might be in.

13. Effects on Permissions

• SCP never grants permissions

• limits permissions for entities in member accounts, including each AWS account root user

• does not limit actions performed by the master account.

• does not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can’t be restricted by SCPs.

• affect only principals that are managed by accounts that are part of the organization. They don’t affect users or roles from accounts outside the organization

• Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access at all, even if the applicable SCPs allow all services and all actions.

14. Strategies for Using SCPs

1. By default, an SCP named FullAWSAccess is attached to every root, OU, and account, which allows all actions and all services.

2. Testing Effects of SCPs

• don’t attach SCPs to the root of the organization without thoroughly testing the impact that the policy has on accounts.

• Create an OU that the accounts can be moved into one at a time, or at least in small numbers, to ensure that users are not inadvertently locked out of key services.

Policy Example:

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Deny",

"Action": "cloudtrail:StopLogging",

"Resource": "*"

}

]

}

1. Whitelisting and blacklisting are complementary techniques used to apply SCPs to filter the permissions available to accounts.

2. Whitelisting

   1. 1. Explicitly specify the access that is allowed.

      2. All other access is implicitly blocked.

      3. By default, all permissions are whitelisted.

      4. AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts, which ensures building of the organizations.

      5. Whitelist permissions can be assigned, by removing the default FullAWSAccess SCP.

      6. For restricting permissions, replace the FullAWSAccess policy with one that allows only the more limited, desired set of permissions.

      7. Users and roles in the affected accounts can then exercise only that level of access, even if their IAM policies allow all actions.

      8. If you replace the default policy on the root, all accounts in the organization are affected by the restrictions.

      9. You can’t add them back at a lower level in the hierarchy because an SCP never grants permissions; it only filters them.

3. Blacklisting

   1. 1. Default behavior of AWS Organizations.

      2. Explicitly specify the access that is not allowed.

      3. Explicit deny of a service action overrides any allow of that action.

      4. All other permissions are allowed unless explicitly blocked.

      5. By default, AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts. This allows any account to access any service or operation with no AWS Organizations–imposed restrictions.

      6. With blacklisting, additional policies are attached that explicitly deny access to the unwanted services and actions

      7. Using deny statements in SCPs require less maintenance, because they don’t need to updated when AWS adds new services.

      8. Deny statements usually use less space, thus making it easier to stay within SCP size limits.

      9. 
         

1. You can remove a member account only after enabling IAM user access to billing in the member account.

2. You can remove an account from your organization only if the account has the information required to operate as a standalone account.

3. Minimum IAM policy requirements for Leaving Organizations as a Member Account: organizations:DescribeOrganization (console only), and organizations:LeaveOrganization – Note that the organization administrator can apply a policy to your account that removes this permission, preventing you from removing your account from the organization.

4. 
   

1. Creating One Organization

2. Creating One Policy