Best practices for managing AWS account meta-data at scale

As we all know, using multiple accounts on your AWS environment is one of the recommended best practices when organizing your workloads and your environment. Using multiple accounts brings multiple benefits allowing you to better leverage AWS services. However, AWS accounts are additional resources that you need to manage. In this blog post, you will learn how you can manage the meta-data on AWS accounts at scale including creating an alerting mechanism if the meta-data changes. You will also learn how you can use service control policies (SCPs) to limit access.

Solution Overview

To manage the meta-data on AWS accounts, you can leverage the Account Management APIs for accounts within an organization or standalone accounts. These APIs allow you to update the AWS account attributes. In addition, you can leverage AWS CloudTrail and Amazon EventBridge to build monitoring systems to perform automated actions to remediate changes or to send notifications. For certain actions, such as updating the alternate contacts, you may want to receive a near-real time notification to ensure that the action is legitimate. Using the Account Management APIs will allow you to avoid unnecessarily polling actions, which will prevent you from generating additional data when changes haven’t occurred.

Sending notifications to the appropriate stakeholders for security, operations, or billing, as well as to activate or deactivate opt-in Regions within your accounts in real time will allow you to ensure the resources in your accounts are up to the most current standards. Also, you need to make sure that monitor changes changes to these attributes to avoid security and operational breaches. Similar to multi-account environment, we recommend you delegate the administration of these actions outside of the management account when possible.

As with every action on AWS, it is always recommended to secure who can access these APIs. As you are using multiple accounts to manage your environment, you can leverage service control policies (SCP), to protect the Account Management API calls across all of your accounts with just one SCP.

Additionally, as you group multiple accounts within your organization, you can leverage integrated services within your organization to simplify the deployment of services across your AWS environment. AWS Services that integrate with AWS Organizations, interact with your organization in two ways, through trusted access, or through delegated administrator.

• Trusted access allows environment administrator of the management account to modify the information and meta-data specific to each member account in AWS Organizations, such as, primary or alternate contact details.
• A delegated administrator account can call AWS Account Management API operations for other member accounts in the organization.

Let’s get hands on keyboard, and build something cool to centrally manage your account attributes, using few services like Amazon EventBridge, AWS CloudTrail, and AWS Organizations!

Prerequisites:

1. Ability to access to the AWS Management Console for the management and delegated administrator AWS accounts.
2. Familiarity with AWS Organizations, Identity and Access Management (IAM), and Amazon EventBridge.

Walkthrough

Amazon EventBridge is a powerful event bus service that allows you to connect various AWS services and applications to react to events in real-time.

The API operations in the Account Management (account) namespace enables you to modify your AWS account. These events are sent to AWS CloudTrail. In the following steps, we will see how we can monitor these API calls in your member accounts using Amazon EventBridge.

These actions can be performed in the management account or a delegated administrator account. In this walk through, we will use a delegated administrator account to perform the actions.

Monitoring Account Management API calls using Amazon EventBridge

Step 1: If you need to setup a delegated administrator account for your organization, follow the step below, else please skip Step 1 and directly proceed to Step 2.

Login to the management account and use AWS CloudShell to run the following command. Please replace 123456789012 with the account ID of the delegated administrator account. Please note that this is only available from the command line as of now, and not in the AWS Management Console.

$ aws organizations register-delegated-administrator \
    --account-id 123456789012 \
    --service-principal account.amazonaws.com

Step 2: Log in to AWS Management Console as a delegated administrator or a management account. Navigate to Amazon EventBridge and click on Create rule or click on Rules from the left side menu and then click Create Rule.

Step 3: Enter an appropriate name for the rule and select the Rule with an event pattern option and click Next.

Step 4: The Account Management APIs events are logged with source as “aws.account” in EventBridge and the detail-type will have the API that was executed. The full list of APIs are present in the Account Management API Operations.

For example, let’s consider monitoring the EnableRegion event. If you request a new AWS Region, this event will trigger. You can monitor multiple API actions in one rule by adding multiple rules in an array. If you simply want to monitor all API actions, we can just specify the Source in the rule.

{
  "detail-type": ["Region Opt-In Status Change"],
  "source": ["aws.account"]
}

Step 5: Choose the Target Type as AWS service and select CloudWatch log group as the target. Specify a name for the Log group. Please note that EventBridge supports multiple target types including AWS Lambda functions and Amazon Simple Notification Service (SNS). You can choose the right target based on your use-case. For this demonstration, we are using the CloudWatch log group.

Step 6: Add any tags such as Name, Environment, Project, etc. depending on your needs and proceed to next step to create the rule.

Step 7: We are going to use the delegated administrator account to enable an AWS Region in a different AWS account within the same organization to confirm that our rule is working. We are using CloudShell to enable a Region, but you can also use other options like the AWS console to enable a Region.

Please note that the account-id will enable us to execute this API from the delegated administrator account of the organization but perform the enable-region account action on other member AWS account within the organization.

Step 8: Navigate to CloudWatch in the AWS console and select the new log stream that was created. The EnableRegion API is an asynchronous API call and there will be two events posted to EventBridge, one with status ENABLING once the request is made and another event with status ENABLED after the Region is successfully enabled.

Using SCPs to limit access to the delegated administrator account

Service control policies (SCPs) can be used to limit access to services and actions. One way to ensure that the account management actions such as updating alternate contact, enabling/disabling Region etc. can be centrally managed is to prevent member accounts from making these changes themselves. In the following section we will see how we can create an SCP to limit these actions to a specific IAM role in the delegated administrator account.

Let’s walk through creating a service control policy (SCP) to ensure only your delegated administrator account can execute the actions.

Step 1: Reviewing the Account Management APIs, we want to restrict anyone except the delegated administrator from changing the contact information or Regions. This means we want to deny PutAlternateContact, PutContactInformation, DeleteAlternateContact, DisableRegion, and EnableRegion for member accounts that aren’t delegated administrators.

Here’s an example of the SCP we want to create. We deny all of those actions except for the privileged role (DelAdminRole) in the delegated administrator account (123456789012):

{
    “Version”: “2012-10-17”,
    “Statement”: [
        {
        “Sid”: “DenyModifications”,
        “Effect”: “Deny”,
        “Action”: [
            “account:Put*”,
            “account:Delete*”,
            “account:DisableRegion”,
            “account:EnableRegion”
            ],
        “Resource”: [
        “*”
    ],
    “Condition”: {
        “ArnNotLike”: {
            “aws:PrincipalARN”: “arn:aws:iam::123456789012:role/[PRIVILEGED_ROLE]”
            }
        }
        }
    ]
}

Step 2: Navigate to AWS Organizations in the AWS console, then Policies , then click on Service control policies and select Create policy . On the following page, give it an understandable policy name and description, paste in the policy we created in Step 1 like shown in Image 3 below. Make sure you replace the PrincipalARN with the account ID and role as per the Step 1.