AWS Organizations, moving an organization member account to another organization: Part 3

In part one, we identified different features of AWS Organizations requiring guidance and consideration when you move an account from one organization in Organizations to another. We focused on Organizations Polices, AWS Resource Access Manager (AWS RAM) shares, and AWS global condition context keys. In part two of the series, we identified behavior and actions when you want to move an account registered as an Organizations delegated administrator for one or more compatible AWS services.

In this post, part three of a three-part series, we identify behaviors, provide guidance and actions when you move an account, where one or more AWS services is enabled for trusted access in the current and target organization.

As with part one, we continue to build on the information provided in the Organizations User Guide for removing a member account from your organization and inviting an AWS account to join your organization. Moving an account between organizations requires you to remove the account from an organization, making the account standalone, and then accepting an invite to join another organization. Before you remove an account from your organization, we recommend that you determine if you have one or more AWS services enabled for trusted access in the organization.

This post uses AWS Command Line Interface (AWS CLI) examples. To make use of these, you must first install and configure the AWS CLI. For more information, see Installing the AWS CLI.

AWS Organizations trusted access

When you enable trusted access for a compatible AWS service, that trusted service can perform operations as described in the service’s documentation across all of the AWS accounts in your organization. When you remove the account, the trusted service can no longer perform operations on the account. Before you remove an account from an organization and into another organization you’ll want to understand what happens to the account relating to the trusted service and any actions to consider.

We have included a list of AWS services that currently support trusted access. You can find an AWS service listed by either AWS service name or service principal name. The service principal name can be found when you use the AWS CLI list-aws-service-access-for-organization command to discover one or more trusted services for an organization.

The following AWS CLI example retrieves a list of the AWS services that are trusted and enabled to integrate with your organization.

PROMPT> aws organizations list-aws-service-access-for-organization

When you have retrieved a list of AWS services that have trusted access for the current and target organization, you can plan any actions required when you move one or more accounts between organizations. When moving your account into another organization, check if you must configure your account to work with an AWS service with trusted access enabled. For most cases you don’t need to configure the account or the AWS service. We have included any guidance within the list of AWS services that currently support Organizations trusted access.

AWS services that support AWS Organizations trusted access

The following list of AWS services work with AWS Organizations and currently support trusted access. This section includes guidance, behavior and actions for each service to consider before and after you remove an account from an organization, and into the target organization.

AWS Account Management: account.amazonaws.com

If you have enabled trusted access with AWS Account Management, you can manage the account metadata for all of the accounts in the organization. When you remove an account from the organization you can no longer manage the account metadata using the organization management or a delegated administrator account for Account Management.

When the account joins the target organization, the account information and metadata can be managed by the target organization management or an existing delegated administrator account.

AWS Artifact: aws-artifact-account-sync.amazonaws.com

If you have enabled trusted access with AWS Artifact, you can accept an agreement with AWS on behalf of all accounts in your organization. When you remove an account from the organization you can no longer automatically accept agreements on behalf of the account from the organization management account. The removed account will no longer have access to, or be covered by AWS Artifact organization agreements accepted on behalf of the organization. You can view a list of organization agreements in the organization management account, AWS Artifact console under the Agreements menu, Organization Agreements.

Before removing the account from the organization, determine (with the assistance of your legal, privacy, or compliance teams where appropriate) whether it is necessary for you to have new agreement(s) in place in the standalone account or target organization. If you need agreements across multiple accounts in the target organization, ensure you have enabled trusted access with AWS Artifact and accepted the required agreement.

AWS Audit Manager: auditmanager.amazonaws.com

If you have enabled trusted access with AWS Audit Manager, you can gather evidence from a broader source by including multiple AWS accounts from your organization within the scope of your assessments. When you remove an account from the organization you can no longer gather evidence from the account as part of an assessment scope. Audit Manager receives a notification about the removal and automatically removes that account from the scope of any existing assessments.

When the account joins the target organization, the account is not automatically added to an existing Audit Manager assessment scope. Review the scope of existing assessments and edit the list to the include the account where required.

AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com

If you have enabled trusted access for AWS CloudFormation StackSets, the management or a delegated administrator account has permissions to create and manage stack sets for the organization. When you remove an account from the organization, CloudFormation StackSets can no longer deploy stack instances to the account using the service-linked role that has the relevant permission in the account. If you have a stack in the account as part of a StackSet and you want to retain the stack in the account, ensure the StackSet account removal behavior when an account is removed from a target organization or organizational unit (OU) is configured as ‘Retain stacks’. You can use the AWS CLI describe-stack-set command to determine the removal behavior, checking the output of the command for the StackSet, AutoDeployment structure for the RetainStacksOnAccountRemoval value. If set to true, stack resources are retained when an account is removed from a target organization or OU, If set to false, stack resources are deleted.

If you are planning to continue to include the stack in a StackSet in the target organization, you can import a stack into a StackSet. In the target organization create a new StackSet using the same template used for the source organization StackSet. When creating the StackSet ensure to include the OU where the source account will placed. Whilst you are working on one or more accounts to be imported into the StackSet, configure the StackSet automatic deployment to disabled, this will prevent the stack being automatically deployed to the account when it joins the target organization, you will do this manually as the stack already exists in the account. When the account joins the target organization you can import the stack into the StackSet you created. You may notice in the account, after the import, the stack will include a change set with a status of ‘FAILED’. This is an expected status for this import, accompanied by the reason ‘The submitted information didn’t contain changes. Submit different information to create a change set.’ In this case, joining the StackSet, there was no stack deployed as the stack already existed and subsequent changes not required.

AWS CloudTrail: cloudtrail.amazonaws.com

If you have enabled trusted access for AWS CloudTrail, you can create an organization trail that logs all events for all AWS accounts in that organization. When you remove an account from the organization, any organization trails stop functioning for the account because CloudTrail can’t access the organization. You can setup an account trail before leaving the organization to continue to log events for the account. Consider removing the account trail, after joining the target organization, if the account is included in an organization trail. When the account joins the target organization, the account is automatically included in an existing CloudTrail organization trail.

AWS Compute Optimizer: compute-optimizer.amazonaws.com

If you have enabled trusted access for AWS Compute Optimizer, you can access and manage Compute Optimizer recommendations for the organization. When you remove an account from the organization, Compute Optimizer from the management or a delegated administrator account can no longer access or manage recommendations for the account. The opt-in status for the account is retained including any preferences set when part of the organization. When the account joins the target organization, Compute Optimizer from the management or delegated administrator account can access and manage recommendations for the account.

AWS Config: config.amazonaws.com

If you have enabled trusted access for AWS Config, a Config aggregator can collect Config configuration and compliance data from accounts in the organization. When you remove an account from the organization, if the account is part of an organization aggregator, the aggregator can no longer collect Config configuration and compliance data from the account. Data will remain in the aggregator account for up to 24 hours before being deleted. Deployed organization config rules or conformance packs to the account will be removed. AWS Config allows you to create an individual account aggregator and authorize the account to collect Config configuration and compliance data from one or more accounts. Removing an authorized aggregator account from an organization does not alter an authorization from another account to collect AWS Config compliance and configuration data.

When the account joins the target organization, Config needs to be enabled in the account to be included in an existing Config organization aggregator. You must make sure that the Config configuration recorder is enabled for the account to work with existing deployed Config organizational rules and conformance packs. Deployment of existing organizational rules and conformance packs will only be retried for 7 hours after an account is added to the target organization if a recorder is not available.

AWS Control Tower: controltower.amazonaws.com

If an account is enrolled in AWS Control Tower, before you remove the account from the organization, follow the steps to unmanage a member account from the Account Factory or remove an account from Account Factory for Terraform (AFT).

Whilst the account is standalone, no longer part of an organization, update the trusted relationship for the AWS IAM role AWSControlTowerExecution. You will need to change the principal in the role trust policy to be the target organization management AWS account ID. When the account joins the target organization, and you are enrolling an account under AWS Control Tower, follow the process to enroll an existing AWS account into AWS Control Tower.

Amazon Detective: detective.amazonaws.com

If you have enabled trusted access with Amazon Detective, an organization behavior graph can provide visibility into the activity for all of your organization accounts. If the account you remove from the organization is a member of a Detective organization behavior graph, the account is removed as a member of the graph. This includes if the account was invited to the organization behavior graph before joining the organization or became a member of the graph after joining the organization. In some cases where an account was added to a graph by invitation, the account continues to be a member of the graph, you can choose to disable the account membership of the graph. To check members of a Detective organization behavior graph, you can list the members using the AWS CLI list-members command, using the AWS CLI list-graphs command to discover the Amazon Resource Name (ARN) of the organization graph. Both commands require you to use either organization management account or Detective delegated administrator account credentials.

When the account is removed as a member of a graph, Detective stops ingesting data, however existing data sourced from the account remains in the graph. Membership to a different organization’s behavior graph by invitation is not effected when joining or leaving an organization. For example, if an account is a member of a target organization behavior graph and leaves the source organization, the account is no longer a member of the source organization graph and remains a member of the target organization graph. When you remove an account from the organization, if Detective is enabled in the account, Detective remains enabled, and all of the account behavior graph content and configuration is retained. To retain organization visibility of an account during the move between organizations, before you remove an account from the organization, consider adding the account as a member, by invitation to the target organization behavior graph. When the account becomes a member of a behavior graph, for the initial extraction, data usually becomes available in a graph within 24 hours.

When the account joins the target organization, if Detective is configured to auto-enable new organization accounts as member accounts of the organization behavior graph, the account will be an enabled member of the graph ‘By organization’. If the account was a member of the graph by invitation, the account membership is retained and membership type changed from ‘By invitation’ to ‘By organization’. If the account is not configured as a member of the organization graph you can optionally invite the account to the graph, if part of the same organization the account will automatically accept the invitation.

Amazon DevOps Guru: devops-guru.amazonaws.com

If you have enabled trusted access for Amazon DevOps Guru, you can manage insights across your entire organization. When an account leaves an organization and DevOps Guru is enabled in the account, the organization management account or configured DevOps Guru delegated administrator can no longer view, sort, and filter insights from the account to develop a holistic view of the health of all monitored applications within the account.

When the account joins the target organization, and DevOps Guru is enabled in the account, the management account or configured DevOps Guru delegated administrator will automatically include the account to monitor.

AWS Directory Service: ds.amazonaws.com

If you have enabled trusted access for AWS Directory Service, you can seamlessly share an AWS Managed Microsoft Active Directory (AD) directory across multiple accounts. You can share a single directory with other trusted AWS accounts within the same organization or share the directory with other AWS accounts that are outside the organization. When you remove an account from the organization which is a consumer of a directory, shared with either the AWS Organizations or Handshake sharing methods, the directory continues to be shared with the account.

When the account joins the target organization, where you have one or more AWS Managed Microsoft AD directories, a directory is not automatically shared with an account. You can share a directory with an account using either the AWS Directory Services console or the AWS CLI share-directory command.

AWS Firewall Manager: fms.amazonaws.com

If you have enabled trusted access for AWS Firewall Manager, you can use the Firewall Manager administrator account to manage all Firewall Manager security policies for your organization in AWS Organizations. When an account leaves an organization, Firewall Manager can no longer perform supported operations within the account. If the account is within a Firewall Manager policy scope, the account will no longer be associated with the policy, and compliance status will no longer be visible to the Firewall Manager administrator account.

Before you remove an account from the organization, we recommend you ensure a Firewall Manager policy scope is configured to retain resources or protections in the account. When the account leaves the organization it will leave the policy scope, and no longer be managed, you can configure the policy option that Firewall Manager doesn’t automatically remove protections or delete Firewall Manager-managed resources. The option is defined as ‘Resource cleanup’ and should be configured as ”Do not automatically delete policy resources when they aren’t in use by the policy“. This option can be found in the Firewall Manager console configuration for supporting policy types including DNS Firewall, Network Firewall, Security group (common) and WAF. The policy types WAF Classic, and Shield Advanced do not provide the option to adjust the policy scope for when a resource goes out of scope. By default any associated WAF web access control lists (web ACLs) that contain any resources are retained, web ACLs that do not contain resources are deleted.

If you have Shield Advanced policy enabled for an account, when the account leaves the organization, the account is no longer in scope of any configured Firewall Manager policies for Shield Advanced. If you subscribed to Shield Advanced in the account, scoped resources continue to be protected. After leaving the organization, the account is no longer under a single consolidated billing of the organization, and it will continue to incur a prorated Shield Advanced subscription fee. You will continue to pay the subscription fee in the source organization, and pay a new or existing subscription fee when account joins the target organization. If you plan to delete the source organization you can raise an AWS support case to consolidate the Shield Advanced subscriptions under the target organization.

If a Network Firewall or DNS Firewall policy is configured, Firewall Manager uses AWS Resource Access Manager (AWS RAM) to share Network Firewall and DNS Firewall policy configured rules groups with accounts across the organization. When the account leaves the organization, a policy configured rule group is no longer shared with the account. If you have configured the Network Firewall or DNS Firewall policy scope resource cleanup option as “Do not automatically delete policy resources when they aren’t in use by the policy” a policy rule group identity and configuration remains associated with the respective resource, either the AWS Network Firewall or Amazon Virtual Private Cloud (VPC). You can no longer view the rule group in the account, as the permission to view the rule group is removed when the AWS RAM share is disassociated with the account.

Before you move an account to the target organization, ensure you have created or updated the equivalent Firewall Manager policy for each policy type you identified in the source organization that is applicable for the account you are moving. In the target organization, you can configure WAF and WAF Classic policy types with a policy action to replace existing associated web ACLs that are currently associated with in-scope resources of the policy. You can use this option to replace web ACLs applied by a source organization policy, by configuring the policy action option ‘Replace web ACLs that are currently associated with in-scope resources with the web ACLs created by this policy’. If you chose to replace existing associated web ACLs, Firewall Manager disassociates other web ACLs that aren’t managed by another active Firewall Manager policy from in-scope resources. If you are configuring a DNS Firewall policy type, set the priority for a rule group to be different to the source organization policy. If you have a matching rule group priority, the target organization policy can not be applied to an Amazon VPC in the account, due to conflicting rule priorities.

In the account you are moving, you will also need to check you have AWS service quota capacity to allow for both source and target organizations policy created resources and protections. Plan to temporarily increase the adjustable quota in the account per AWS Region to allow for at least double the current number of policy applicable resources or protections configured in the account by the source organization. You will need to consider the current usage in the account of the AWS services including Network Firewall (adjustable quotas), Amazon VPC (subnet quotas), Security Groups (VPC security groups per AWS Region and Security groups per network interface quotas), WAF (web ACLs and rule groups quotas), WAF Classic (web ACLs and rule groups quotas), Shield Advanced (adjustable quotas) and Route 53 Resolver DNS Firewall (adustable quotas). Quota increase will allow the coexistence of existing resources and protections created by the source organization policy and the newly created resources and protections by target organization policy.

When the account joins the target organization, the Firewall Manager policies you have configured in the target organization scoped for the account will be applied to the account. Where you have set a source organization policy resource cleanup option as “Do not automatically delete policy resources when they aren’t in use by the policy” you will have remaining resources and protections from the source organization policy. There is no reuse of resources previously created by the polices in the source organization, for policies applied in the target organization. If you rejoin the account back into the source organization, and the Firewall Manager Delegated Administrator, and a Firewall Manager policy was not altered since the account left the source organization, the policy will re-use the any existing resources created when the account was previously in the organization.

Where a target organization policy duplicates the policy resource configuration provided by the source organization, you can choose to remove the source organization policy created resource or associated protection. To discover remaining resources or protection created by a source organization policy, you need to check in each AWS Region scoped by the policy, and applicable to the policy type. Firewall Manager policy created resources use a specific naming convention for each policy type, this always includes the prefix ‘FMManaged’ and depending on the policy type, include either the policy name or policy ID, or both. You can use the AWS CLI list-policies command in the source organization Firewall Manager Administrator account to list the policies and identify policy metatdata including the Policy Name (“PolicyName”) and Policy ID (“PolicyId“).

Before removing a source organization Firewall Manager policy created resource or protection, ensure the equivalent target organization policy is scoped and applied to the account. Check the policy matches the security configuration of the source organization and the Firewall Manager policy compliancy status for the account indicates ‘Compliant’, meaning that the policy has successfully been applied to all of in-scope resources for the account. You can use the AWS CLI list-compliance-status command to get a summary of which member accounts are protected by the specified policy and their compliance status. You may have to wait up to 5 hours before an account is fully unmanaged from the source organization Firewall Manager administrator and fully managed by the Firewall Manager administrator in the target organization.

To help you identity a policy created resource or protection association, we have listed for each supported policy type, the naming convention used for a resource created by the policy and the AWS CLI command to retrieve a list of the applicable resources or associations in the account.

‘AWS Network Firewall’ policy type

A network firewall is created by the policy using the naming convention FMManagedNetworkFirewall <policy name><policy-id><vpc-id>. Replace <policy-name>, <policy-id> with the policy name and policy id of an ‘AWS Network Firewall’ type policy in the source organization. You can use the AWS CLI list-firewalls command to retrieve the metadata for one or more network firewalls in the account.

A firewall policy is created by the policy using the naming convention FMManagedNetworkFirewallPolicy<policy-name><policy-id><vpc-id> Replace <policy-name>, <policy-id> with the policy name and policy id of an ‘AWS Network Firewall’ type policy in the source organization. You can use the AWS CLI list-firewall-policies command to retrieve the metadata for a firewall policy defined. When an ‘AWS Network Firewall’ policy type is applied, if configured, it will create Amazon VPC subnets to contain the VPC endpoints used by the Network Firewall. A subnet is named using the convention “AWSFirewallManagerManagedResource”. You can use the AWS CLI describe-firewall command to return data objects including one or more subnets associated with the network firewall.

‘WAF’ policy type

A WAF Web ACL is created by a policy using the naming convention FMManagedWebACLV2-<policy name>. Replace <policy name> with the policy name of a ‘WAF’ type policy in the source organization. You can use the AWS CLI list-web-acls command to retrieve one or more WAF web ACLs in the account.

‘WAF Classic’ policy type

A WAF Classic Web ACL is created by a policy using the naming convention FMManagedWebACL<policy-id>. Replace <policy id> with the policy ID of a ‘WAF Classic’ type policy in the source organization. You can use the AWS CLI list-web-acls command to retrieve one or more WAF Classic web ACLs in the account.

‘Security group – common’ policy type

A security group is created by a policy using the naming convention FMManagedSecurityGroup<policy-id><security-group-id><vpc-id>. Replace <policy id> with the policy ID of a ‘Security group – common’ type policy in the source organization. You can use the AWS CLI describe-security-groups command to retrieve one or more security groups in the account. You will need to disassociate the security group from one or more resources before you can remove the security group.

‘Shield Advanced’ policy type

A Shield Advanced protection is created by policy using the naming convention FMManagedShieldProtection<policy-id>. Replace <policy id> with the policy ID of a ‘Shield Advanced’ type policy in the source organization. You can use the AWS CLI list-protections command to retrieve one or more protections in the account.

‘DNS Firewall’ policy type

A DNS Firewall rule group associated with the policy is shared using AWS RAM, which is removed when the account is removed from the organization. You can list the DNS Firewall rule group associations with one or more Amazon VPCs using the AWS CLI list-firewall-rule-group-associations command. You can identify a source organization DNS Firewall rule group, matching a firewall rule group association “CreatorRequestId” with the policy ID of the DNS Firewall policy in the source organization. You can then use the AWS CLI disassociate-firewall-rule-group command to disassociate the source organization rule group using the firewall group association ID you have discovered.

Amazon GuardDuty: guardduty.amazonaws.com

If you have enabled trusted access for Amazon GuardDuty, you can help simplify management of GuardDuty by using AWS Organizations to manage GuardDuty across all of the accounts in your organization. When an account associated with a GuardDuty administrator leaves the organization, it is automatically disassociated from the administrator in each AWS Region associated. The GuardDuty administrator account can no longer manage the account, however the status of GuardDuty in the account remains as previously set by the administrator. GuardDuty findings and usage data for the account are no longer included in the GuardDuty administrator account.

When the account joins the target organization, for each AWS Region you have enabled GuardDuty for the organization and configured the Auto-enable feature for GuardDuty, the account will automatically be associated as a GuardDuty administrator member account. GuardDuty will be enabled in the account, and if configured the selected source preferences, including options for S3 Protection and Kubernetes Audit Logs Monitoring. If an account isn’t associated, then you can manually add as a member account using the GuardDuty console or AWS CLI create-members command using the administrator account and each AWS Region required.

Using permissions of the account added, you can use the AWS CLI get-administrator-account command to check the details for the GuardDuty administrator account for the account, using the AWS CLI list-detectors command to discover the GuardDuty detector ID. If the account is not associated with an administrator for the AWS Region the command output will not show the administrator Account ID or the Relationship status as “Enabled”.

AWS Health: health.amazonaws.com

If you have enabled trusted access for AWS Health, you can aggregate AWS Health events across all accounts in the organization. If you have configured a Health organizational view, when your account leaves the organization, new events from the account are no longer logged to the organizational view. Existing events remain in the organizational view allowing you to query them up to the 90-day limit. When an account joins the target organization, the account is included in an enabled Health organizational view.

AWS IAM Access Analyzer: access-analyzer.amazonaws.com

If you have enabled trusted access for AWS Identity and Access Management Access Analyzer (IAM Access Analyzer), you can analyze resource-based policies across your organization to identify any policies that grant access to a principal outside of your zone of trust. If an account is part of a IAM Access Analyzer organization zone of trust analyzer, when leaving the organization the account will no longer generate findings in the organization zone of trust. During the transition between organizations you can create an analyzer using the standalone account as the zone of trust. When an account joins the target organization, if there are already analyzers created with the organization as the zone of trust, the account will be included in the set of resources that are analyzed.

AWS IAM Identity Center (successor to AWS Single Sign-On): sso.amazonaws.com

If you have enabled trusted access for AWS IAM Identity Center (successor to AWS Single Sign-On), you can pick multiple AWS accounts whose users need single sign-on (SSO) access AWS accounts and cloud applications. When an account leaves the organization, IAM Identity Center will no longer, enumerate the account, or be able to deploy common sets of permissions, and manage access from the management or a delegated administrator account. IAM Identity Center automatically cleans up the account of any metadata and resources, including the IAM Identity Center service-linked role. The account no longer works with IAM Identity Center and you can no longer access the account using the AWS Access Portal for any configured identity source.

When an account joins the target organization, you will need to configure required permissions or assignments to users and groups in IAM Identity Center for the account.

Amazon Inspector: inspector2.amazonaws.com

If you have enabled trusted access for Amazon Inspector, you can manage multi accounts across the organization and perform tasks on behalf of the organization. These tasks include enabling or disabling scans for member accounts, viewing aggregated finding data from the entire organization, and the creation and management of suppression rules. When an account associated with an Inspector administrator leaves the organization, it is automatically disassociated from the administrator in each AWS Region associated. The Inspector administrator account can no longer manage the account, however the status of Inspector in the account including scan configuration remains as previously set by the administrator. Inspector findings for the account are no longer included in the Inspector administrator account.

When an account joins the target organization, for each AWS Region you have enabled Inspector for the organization and configured auto-enable for scans, the account will automatically be associated as a Inspector administrator member account. Inspector will be enabled in the account, and if configured, the selected scan preferences, including options for EC2 scanning and ECR container scanning enabled. If an account isn’t associated, then you can manually add as a member account using the Inspector console or AWS CLI associate-member command using the administrator account and each AWS Region required. Using permissions of the account added, you can use AWS CLI get-delegated-admin-account command to check the details for the Inspector administrator account for the account. If the account is not associated with an administrator for the AWS Region the command output will not show the administrator Account ID or the Relationship status as “Enabled”.

AWS License Manager: license-manager.amazonaws.com : license-manager.member-account.amazonaws.com

If you have enabled trusted access for AWS License Manager you can enable cross-account resource discovery in order to manage license usage and resource discovery across all in the organization.

When an account leaves the organization, License Manager can no longer perform resource discovery to manage license usage on the account. If you have a License Manager self-managed license shared with the account, the AWS Resource Access Manager (AWS RAM) share setup by License Manager automatically disassociates the account from the share. The self-managed license is no longer shared with the account. If required, you can modify the AWS RAM share setup by License Manager and add the removed account to continue sharing the self-managed license with the account, you need to accept the License Manager share invitation in the removed account.

When an account joins the target organization, for each AWS Region you have enabled License Manager cross-account resource discovery in order to manage license usage across all accounts of the organization, the account will automatically be included in the scope of the resource discovery. If you have shared a self-managed license in the organization and you want to share with an account, you may need to modify the AWS RAM share setup by License Manager to include the account. The account, as a member of the organization will automatically accept an invitation to join the License Manager AWS RAM share. In part one of this post series we cover AWS RAM resource shares and considerations when moving between organizations for both owner and consumer accounts. We cover the distribution of License Manager granted license entitlement with an organization using License Manager under the AWS Marketplace section of this post.

Amazon Macie: macie.amazonaws.com

If you have enabled trusted access for Amazon Macie, you can centrally manage and enable Macie for accounts in your organization. When an account associated with a Macie administrator leaves the organization, it is automatically disassociated from the administrator in each AWS Region associated. The Macie administrator account can no longer manage the account, or access certain Macie settings, data, and resources. The status of Macie in the account remains as previously set by the administrator. Macie summary and findings for the account are no longer included in the Macie administrator account.

When an account joins the target organization, for each AWS Region you have enabled Macie for the organization and configured auto-enable, Macie will be enabled in the account and will automatically be associated as a Macie administrator member account. If an account isn’t associated, then you can manually add as a member account using the Macie console or AWS CLI create-member command using the administrator account and each AWS Region required.

Using permissions of the account added, you can use the AWS CLI get-administrator-account command to check the details for the Macie administrator account for the account. If the account is not associated with an administrator for the AWS Region the command output will not show the administrator Account ID or the Relationship status as “Enabled”.

AWS Marketplace : license-management.marketplace.amazonaws.com

If you have enabled trusted access for AWS Marketplace, you can distribute a granted license for a Marketplace product subscription across organization member accounts. Marketplace granted licenses are shared with an organization using AWS License Manager to distribute rights of use, known as entitlements.

When an account leaves the organization, if the account is a recipient of a License Manager shared Marketplace product granted license entitlement, the entitlement is no longer available to the account. The related Marketplace subscription can no longer be used to launch the product in the account. If the grant has been distributed to the account, as part of the organization or organizational unit (OU), the license grant status for the account shows ‘deleted’ (deleted by the grantor). If the grant was distributed using the individual account ID, the license grant status shows ‘disabled’ (has not been activated for use). Launched products using the subscription remain in the account, including launched AWS resources for Amazon Machine Image (AMI), container, machine learning, and data products.

When an account joins the target organization, a License Manager shared entitlement, configuring rights of using a Marketplace product to the organization or OU will be distributed to the account. As part of the organization, the grant is automatically accepted and activated for use by the account.

If you are moving a Marketplace product subscriber account to the target organization, and using a License Manager grant to distribute an entitlement to an individual organization account. When the subscriber account is removed from the organization, a License Manager grant for a license is no longer distributed to the recipient account. The grant status, showing the ability to use the license for the recipient account, shows ‘disabled’ (has not been activated for use). If you move a grant recipient account to the same target organization as the subscriber, in the recipient account firstly check the status of the grant from the subscriber account using License Manager. If the grant status shows ‘disabled’ you can choose to activate the license. If the grant status shows ‘deleted’ you can choose to create a new grant in the Marketplace subscriber account for the grant recipient account.

If the account you are moving to the target organization, is a License Manager delegated administrator account, you will need to remove the account as the delegated administrator for License Manager before the account can leave the organization. When you deregistered the account as the delegated administrator, cross-account resource discovery and license management is removed. If the account is Marketplace subscriber account and using a License Manager grant to distribute an entitlement to the organization, OU or an individual account, a recipient account grant status shows ‘disabled’ (has not been activated for use). When the account joins the target organization, if no delegated administrator for License Manager is configured, you can choose to register the account as a delegated administrator. If you register the account, you can create a grant to distribute a Marketplace license entitlement across the organization, or to an OU or individual account. If you do not register the account, you can create one or more grants for the required individual accounts in the organization.

AWS Network Manager: networkmanager.amazonaws.com

If you have enabled trusted access for AWS Network Manager, you can create a single global network for any of your AWS accounts, and then register one or more AWS Transit Gateways from more or more accounts. When an account leaves the organization, Network Manager can no longer centrally manage, monitor, and visualize network resources in the account. A transit gateway registered from the account with a Network Manager global network will be deregistered. Transit gateway attachments (such as VPCs, VPN connections, and AWS Direct Connect gateways) are no longer included in the global network.

When an account joins the target organization, to include one or more account transit gateways in a Network Manager global network, you will need to register each transit gateway.

AWS Security Hub: securityhub.amazonaws.com

If you have enabled trusted access for AWS Security Hub, you can automatically enable Security Hub for all of your organization accounts, and increase the coverage for Security Hub checks and findings. When an account associated with a Security Hub administrator leaves the organization, it is automatically disassociated from the administrator in each AWS Region associated. The Security Hub administrator account can no longer manage the account, however the status of Security Hub in the account including enabled standards or controls remain as previously set by the administrator. Security Hub findings and data for the account are no longer included in the Security Hub administrator account.

When an account joins the target organization, for each AWS Region you have enabled Security Hub for the organization and configured auto-enable, the account will automatically be associated as a Security Hub administrator member account. Security Hub will be enabled in the account, and if configured, the selected standards and controls enabled. If an account isn’t associated, then you can manually add as a member account using the Security Hub console in the administrator account for each AWS Region required.

Using permissions of the account added, you can use the AWS CLI get-administrator-account command  to check the details for the Security Hub administrator account for the account. If the account is not associated with an administrator for the AWS Region the command output will not show the administrator Account ID or the Member Status as “Enabled”.

Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com

If you have enabled trusted access for Amazon S3 Storage Lens, you can collect and analyze the storage, usage and activity metrics across all of the AWS accounts in your organization. When an account leaves the organization, any dashboards created with a scope of the organization will no longer be updated from the account data, however historic data is available in the dashboard per Amazon S3 Storage Lens rentention period. The account default dashboard continues to be updated from the account data.

When an account joins the target organization, the account is automatically included S3 Storage Lens dashboards, where a dashboard scope includes all accounts in the organization.

AWS Service Catalog: servicecatalog.amazonaws.com

If you have enabled trusted access for AWS Service Catalog, you can simplify the sharing of portfolios and copying of products across an organization. When an account leaves the organization and is consumer of a Service Catalog shared portfolio, any provisioned products are retained. A Service Catalog portfolio including any associated products shared using an organization entity including organization root, organizational unit (OU), or organization account, will be automatically unshared from the account. If you need to continue managing a Service Catalog product provisioned in an account from the source organization, after you remove the account from the organization, you can create a portfolio share for the individual account. In the shared with account you will need to import the portfolio and update the permissions for the product for required principles of the account. In part two of this post series we covered how to migrate Service Catalog shared products to another organization.

Service Catalog AppRegistry uses AWS Resource Access Manager (AWS RAM) to share applications and attribute groups. When an account leaves an organization, a Service Catalog AppRegistry resource shared using an organization entity including organization root, organizational unit, or organization account will be unshared from the account. Any associated resource collections or attribute groups from the account added to a shared application are removed. In part one of this post series we cover AWS RAM resource shares and considerations when moving between organizations for both owner and consumer accounts.

When an account joins the target organization, a Service Catalog portfolio, AppRegistry application or attribute group resource shared using an organization entity including organization root, organizational unit, or organization account will be automatically shared with the account.

Service Quotas: servicequotas.amazonaws.com

If you have enabled trusted access for Service Quotas, you can create a quota request template to automatically request quota increases when an account is created. When an account leaves the organization, any quota requests applied to the account from a quota request template are not affected. A quota request template is only applied to new accounts created in the organization.

When an account joins the target organization, existing account quotas are not affected.

AWS Systems Manager: ssm.amazonaws.com : opsdatasync.ssm.amazonaws.com

If you have enabled trusted access for AWS Systems Manager, you can use Systems Manager Explorer, Change Manager and OpsCenter capabilities across all AWS accounts in the organization.

If you have created a Systems Manager Explorer resource data sync to collect data from multiple accounts. When an account leaves the organization, the account is no longer included in the resource data sync, and operations data no longer part of synchronized Systems Manager Explorer operations dashboard. When an account joins the target organization, the account is included in an existing resource data sync for Systems Manager Explorer configured for the organization.

If you have setup, Systems Manager Change Manager, you can manage changes across multiple AWS accounts and across AWS Regions. When an account leaves the organization you can no longer use the change management framework for the account, including requesting, approving, implementing, and reporting on operational changes to your application configuration and infrastructure. Existing change requests set to run as soon as approved or at a scheduled time are no longer targeted to the account. When the account joins the target organization, Change Manager change requests will run as scheduled or approved where the account ID is specified or part of an organizational unit (OU) specified in the change request.

If you have setup, System Manager OpsCenter, to work with OpsItems across the organization member accounts. When an account leaves the organization, OpsCenter can no longer create, view and update OpsItems or view detailed information about AWS resources specified in OpsItems, or start Systems Manager Automation runbooks in the account.

If you configured permissions to work with OpsItems across accounts and followed the System Manager guide for configuring access and permission for working with OpsItems across accounts from the AWS Systems Manager User Guide. The configured permissions to work with OpsItems across accounts is setup using AWS CloudFormation stacksets to create an OpsItemGroup resource policy and an IAM execution role that give users permissions to work with OpsItems across accounts. The StackSet is created in the organization management account, and creates the OpsItemCrossAccountExecutionRole with the policy OpsItemCrossAccountResourcePolicy in each organization member account scoped.

• Before you remove an account from the organization, using the AWS CloudFormation console with the organization management account, check the StackSet automatic deployment configuration, and if required configure the “Account removal behavior” to “Delete Stacks”, when an account is removed from the organization the stack instance in the account will be deleted. This will remove the OpsItemCrossAccountExecutionRole role and OpsItemGroup resource policy which is configured to work with the organization management account, and a configured Systems Manager delegated administrator account.
• When the account joins the target organization, if you have also followed the System Manager guide, the StackSet will automatically deploy if scoped for account ID, and the OpsItemGroup resource policy and an IAM execution role configured to work with the target organization management account, and a configured Systems Manager delegated administrator account.

If you configured permissions to work with OpsItems across accounts without using the System Manager guide configuring access and permission for working with OpsItems across accounts. You will need to update the permissions to work with OpsItems across accounts, including the AWS IAM role created and the Systems Manager resource policy for the OpsItemGroup resource.

• Whilst the account is standalone and no longer part of the organization, update the trusted relationship for the IAM role, and configure the trusted entities Principal and Condition elements to the target organization management account ID, and if configured, delegated administrator account ID. You will also need to update the Systems Manager resource policy for the OpsItemGroup resource, which enables AWS accounts to view and interact with OpsCenter operational work items (OpsItems). Change the Principal element in the resource-based JSON policy to specify the account ID for the target organization account ID, and if configured the Systems Manager delegated administrator account ID. You can use the AWS CLI get-resource-policies command to view the resource policy for the OpsItemGroup resource and the AWS CLI put-resource-policy command to create or update the resource policy. For the both commands specify OpsItemGroup resource policy Amazon Resource Name (ARN) as arn:aws:ssm:<region>:<account-ID>:opsitemgroup/default, where <region> is the AWS region for OpsItemGroup resource you apply the policy, and <account-ID> is the AWS account ID you are updating the resource policy. You will need to update the resource policy in each AWS region you use Systems Manager OpsCenter supporting the OpsItemGroup resource policy.
• When the account joins the target organization, if you configured permissions to work with OpsItems across accounts the management or Systems Manager delegated administrator account can use the configure IAM role and resource policy to work with OpsItems in the account.

AWS Trusted Advisor: reporting.trustedadvisor.amazonaws.com

If you have enabled trusted access for AWS Trusted Advisor, you can receive results of Trusted Advisor checks for all of the accounts in the organization and download reports to view the summaries of your checks and any affected resources. If you have enabled an organizational view, when you remove an account from the organization, Trusted Advisor can no longer view or report checks for the account. When the account joins the target organization, the account is included in an enabled Trusted Advisor organizational view.

AWS Well-Architected Tool: wellarchitected.amazonaws.com

If you have enabled trusted access for the AWS Well-Architected Tool, you can simplify the process of sharing AWS Well-Architected Tool resources with other members of the organization. You can share workloads or custom lens with the organization or an organizational unit (OU). If you have created a Well-Architected Tool organization or OU share for a workload or custom lens, when an account leaves the organization, the workload or custom lens is no longer shared with the account. If you need to continue sharing the workload or custom lens with the account, you can create a share using the target AWS account ID or account IAM user. If an account sharing a workload or custom lens leaves the organization, the workload or custom lens is no longer shared with the organization or configured OU. If you need to continue to share with organization member accounts, you can create a share using the target AWS account ID or account IAM user. Workload or custom lens shares created for individual AWS accounts and IAM users, are not removed when the sharing account leaves the organization.

When an account joins the target organization, it will be included in existing workload or custom lens share created for organization or an applicable OU.

Amazon VPC IP Address Manager (IPAM) : ipam.amazonaws.com

If you have enabled trusted access for Amazon VPC IP Address Manager (IPAM), you can monitor IP address usage throughout the organization and share IP address pools across member accounts. If you created an IPAM with the option to allow data replication from organization member accounts, when an account leaves the organization, IPAM can no longer monitor IP usage in the account. An account resource is no longer included in the IPAM scope, however a CIDR allocation from the IPAM pool remains allocated to the account resource, and utilized by the IPAM pool. Before you remove the account from the organization, if required you can remove the CIDR allocation from the IPAM pool using the IPAM console or the AWS CLI release-ipam-pool-allocation command. You cannot remove the CIDR allocation from a pool once an account is no longer in the organization. Removing a CIDR allocation from a IPAM pool does not remove the CIDR allocated to the account resource. During the transition between organizations you can create an IPAM in the standalone account to continue to monitor IP usage.

When an account joins the target organization, the account is automatically included for IP monitoring usage by an IPAM created to allow data replication from organization member accounts. Before you move an account into the organization, check the IPAM CIDR management for an IPAM pool is configured to ‘Automatically import discovered resource’. We recommend to allow automatic import to import discovered resources for an account you add to the organization. A non overlapping CIDR for a resource will be allocated from the IPAM pool, the CIDR for the resource in the account is not changed. If an account resource CIDR has not been provisioned or allocated from the IPAM pool, the IPAM compliance status for the CIDR will be unmanaged. See part two of this post series, where we discuss the delegated administrator account for IPAM, and how this can effect the IPAM pool allocated CIDR for an account resource.

Conclusion

In this post, we’ve walked you through the AWS services that support trusted access for AWS Organizations. You’ve learned how to identify if one or more compatible AWS services have been configured as a trusted service in an organization. You’ve learned considerations and actions for AWS services with trusted access enabled, when you remove an account from an organization and add to another organization.

This post series steps you through the different features of Organizations, providing guidance and consideration for when you’re using Organizations and moving an AWS account from one organization to another.

In part one of the series, we walked you through the different features of Organizations, providing guidance and consideration for when you’re using Organizations to move an AWS account from one organization to another. In part two of the series, we helped you determine any AWS Organizations delegated administrators, and identified behavior and actions when you want to move an account registered as a delegated administrator for one or more compatible AWS services.

About the authors: