# Organizational Units

Organizational units form a tree-like hierarchy. The hierarchy's root must always be named as Root. The maximum depth of nested organizational units is 5.

Organizational units are configured in organizationalUnits object where keys are organizational unit paths and values are configuration for the corresponding organizational units.

# Example: Configure an empty root organizational unit

organizationalUnits:
  Root: {}

# Example: Configure some organizational units under the root

organizationalUnits:
  Root/Sandbox: {}
  Root/Environments/Dev: {}
  Root/Environments/Test: {}
  Root/Environments/Prod: {}
  "Root/Customer Accounts": {}

As seen in this example, you don't need to explicitly define parent organizational units if it's empty and has children. The path needs to be quoted if some organizational unit name in it has spaces.

# Service Control Policies

NOTE

Service control policies are supported only when all features is enabled in the organization.

If service control policies are enabled in the organization, then each organizational unit must have a service control policy attached to it. Service control policies attached to an organizational unit are inherited by its children, so the attachment does not have to be direct.

To attach a service control policy to a organizational unit, add its name into serviceControlPolicies list of the organizational unit.

# Example: Attach service control policies to organizational units

serviceControlPolicies:
  MySCP:
    description: Custom policy
  AnotherSCPPolicy:
    description: Another policy

organizationalUnits:
  Root:
    serviceControlPolicies:
      - MySCP
  Root/Environments:
    serviceControlPolicies:
      - AnotherSCPPolicy
  Root/Environments/Dev: {}
  Root/Sandbox: {}

In this example, the MySCP is attached directly to the Root, and is inherited by all of its children. AnotherSCPPolicy is attached directly to Root/Environments and inherited by Root/Environments/Dev, but not by Root/Sandbox as they do not share the same parent.

# See also

# Tag Policies

NOTE

Tag policies are supported only when all features is enabled in the organization.

Tag policies attached to an organizational unit are inherited by its children.

To attach a tag policy to a organizational unit, add its name into tagPolicies list of the organizational unit.

# Example: Attach tag policies to organizational units

tagPolicies:
  MyTagPolicy:
    description: Simple tag policy
  EnvironmentSpecificTagPolicy:
    description: Tag policy for an environment

organizationalUnits:
  Root:
    tagPolicies:
      - MyTagPolicy
  Root/Environments:
    tagPolicies:
      - EnvironmentSpecificTagPolicy
  Root/Environments/Dev: {}
  Root/Sandbox: {}

In this example, the MyTagPolicy is attached directly to the Root, and is inherited by all of its children. EnvironmentSpecificTagPolicy is attached directly to Root/Environments and inherited by Root/Environments/Dev, but not by Root/Sandbox as they do not share the same parent.

# See also

# Accounts

Each organizational unit can have zero or more accounts, and each account can belong to exactly one organizational unit.

To add an account to an organizational unit, add the account into accounts list of the organizational unit.

# Example: Add accounts to organizational units

organizationalUnits:
  Root:
  Root/Environments:
    accounts:
      - "123456789012"
  Root/Environments/Dev:
    accounts:
      - "111111111111"
      - "888888888888"
  Root/Sandbox:
    accounts:
      - id: "222222222222"

In this example, account 222222222222 uses object configuration where the account id is given in id property. Other accounts are given as plain account ids. The object configuration allows more configuration options.

# See also

# Config Sets

Each organizational unit can have zero or more config sets. Config sets added to an organizational unit are inherited by its children and the accounts that belong to the organizational unit.

When the organization is launched, the accounts selected to be deployed get their config sets executed.

To add a config set to an organizational unit, add the config set name into configSets list of the organizational unit.

# Example: Add config sets to organizational units

configSets:
  basic:
    description: Some basic config set
    commandPaths:
      - /basic/stuff
  networking:
    description: Networking config
    commandPaths:
      - /network/vpc.yml
      - /network/transit-gateway.yml

organizationalUnits:
  Root:
    configSets:
      - basic
  Root/Environments:
    configSets:
      - networking
    accounts:
      - "123456789012"
  Root/Environments/Dev:
    accounts:
      - "111111111111"
  Root/Sandbox:
    accounts:
      - "222222222222"

In this example, accounts 123456789012 and 111111111111 would have config sets basic and networking, and account 222222222222 would have only basic config set.

# See also

# Status

Organizational unit status is used to control whether the accounts that belong to the organizational unit are deployed when the organization is launched. It is inherited by the organizational unit's children.

Allowed values:

  • active - Accounts are deployed (default)
  • disabled - Accounts are not deployed

# Example: Set status to organizational unit

organizationalUnits:
  Root: {}
  Root/Environments:
    status: disabled
  Root/Environments/Dev: {}
  Root/Sandbox: {}

In this example, the Root/Environments organizational unit has status disabled, and so does all its children.

# Deploying Organizational Units

Takomo uses organizational unit paths to identify them. When the organization is launched, Takomo compares organizational units found from the local configuration to the ones found from the organization.

  • The organizational unit is removed from the organization if it is found from the organization but not from the local configuration
  • The organizational unit is added to the organization if it is found from the local configuration but not from the organization
Last Updated: 5/4/2020, 3:54:44 PM