Organization :- An entity that consolidates our AWS Accounts. An Organization has one master account along with zero or more member accounts.Organization is hierarchical in structure. Root is at the top and other Organization unit or Accounts forms the child elements.Feature set determines the functionality of Organization. Enabling/Disabling feature set controls the functionality or Organization. Here is the list of features and benefits of AWS Organization.
Root:- Root is the parent container for all accounts. One organization has one root. Root’s child elements can be individual account or an organization unit. Policies applied to root gets applied to all Organization Units and Accounts under it. Root is created when we create an Organization.
Organization Unit:- A container for accounts within a root. It can be parent of other Organization Units or other Accounts. It is structured as typical Tree data structure. Root as the root node Organization Units or Member Accounts as child and sub child. Any policy applied to any level in the tree effects every child elements.
Account:- Account is a standard AWS account that contains your AWS resource. There are two kind of accounts Master Account and Member Accounts. One account can be member of only one organization at a time. We can attach policy to AWS account to control only that account. Master account creates and Organization.Using Master Account we can perform following actions:
- Create accounts in the organization.
- Invite other existing accounts to the organization.
- Remove accounts from organization.
- Manage invitations asking other accounts to join.
- Apply policies to entities within the organization.
- It’s payer account and is responsible for making payments for charges accrued by the member account.
Organization structure looks like typical Tree data structure.
Invitation:- The process of asking other account to join our organization. It can be issued only by Master Account and is sent by using Account id or by email address associated with the invited account. It works by exchanging handshakes.
Handshake:- Handshake is underlying implementation for invitations. Handshake messages are passed between and initiator and is responded by recipient. This is done in a way to ensure both parties knows the current status of the handshake. Valid handshake statuses are as below:
- REQUESTED: This handshake was sent to multiple recipients (applicable to only some handshake types) and not all recipients have responded yet. The request stays in this state until all recipients respond.
- OPEN: This handshake was sent to multiple recipients (applicable to only some policy types) and all recipients have responded, allowing the originator to complete the handshake action.
- CANCELED: This handshake is no longer active because it was canceled by the originating account.
- ACCEPTED: This handshake is complete because it has been accepted by the recipient.
- DECLINED: This handshake is no longer active because it was declined by the recipient account.
- EXPIRED: This handshake is no longer active because the originator did not receive a response of any kind from the recipient before the expiration time (15 days).
More details on Handshake API can be found here.
Feature sets:- Feature sets are divided in two categories:
- All features – The default set that is available to AWS Organizations. It includes all functionality of consolidated billing, plus advanced features that gives you more control over accounts in organization.
- Consolidated billing– This feature set provides shared billing functionality. It does not include use of Service Control Policy (SCP).
Service Control Policy (SCP):- A policy that specifies the services and actions that users or roles can use in the account. 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. For example if SCP limits permissions for entities in member accounts, even if user has IAM role with full Administrator permission any access that is not explicitly allowed or that is explicitly denied is blocked. SCPs are available when we enable all feature in our organization. SCP always works downward i.e policy applied to any OU is applicable to all its child elements (both OU and individual account) not its parent. We can attach SCP to following:
- A root , which affects all accounts in the organization.
- An OU which affects all accounts in the OU and all accounts in subtree of that OU.
- An individual Account. Master account is not impacted by SCP. That is why we should not have any resource in Master account as we cannot control is using SCP.
SCP is evaluated in below order from top to bottom:
- Explicit deny , denies permission.
- If not explicitly denied, explicit Allow, allows permissions.
- If not explicitly allowed, default is denied.
Information on SCP whitelisting and blacklisting is available here.