Limiting Aimably Access to a Subset of AWS Accounts in an Organization

Follow all other standard integration steps to complete this method. Aimably will not grant itself access to those member accounts during setup.

Pros: Minimal variation from standard integration workflow. Low effort when member account IDs are known and can be copied from a CSV list.

Cons: Not appropriate for a scenario where excluded accounts are numerous and their ID numbers are not easily accessible.

Option 2: Member Account-Level Integration

To use this method, the Aimably integration wizard should be run directly on each of the member accounts that are included in Aimably's access scope instead of at the organization level. Prior to performing each integration, log in directly as an administrator to each of the member accounts in scope, then initiate the Aimably integration using the Add Using Wizard button on the Connect to Cloud page.

Pros: Gives the user explicit control over where access has been granted. Excellent for scenarios where Aimably access is intended only for a small proportion of the overall organization.

Cons: Requires extra effort which grows with the quantity of member accounts in scope.

Option 3: AWS-Side Access Blocking

Under this method, Aimably's access is explicitly denied within the customer's AWS organization prior to Aimably establishing the integration. 

To implement this, first identify the IAM role that is used to establish trusted access between your management account and member accounts. Most often, this role is named OrganizationAccountAccessRole. Then, for each member account not in scope for the Aimably integration, visit IAM > Roles > [NAME OF TRUSTED ACCESS ROLE] and use the JSON editor to update the trust policy using the script provided below replacing MGMT_ACCOUNT_ID with the Account ID number of your management account.

{

  "Sid": "DenyAimablyAssumeRole",

  "Effect": "Deny",

  "Principal": { "AWS": "*" },

  "Action": "sts:AssumeRole",

  "Condition": {

    "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::MGMT_ACCOUNT_ID:role/Aimably*" }

  }

}

Pros: Can be scripted to run fairly quickly using the CLI. Gives the user confidence that they have implemented the access block directly rather than relying on Aimably's CloudFormation script.

Cons: If the Aimably role name is manually edited by any user which results in altering the prefix, the effect of this action is erased.