I tend to forget how full of usefull checks the Trusted Advisor tool is. I guess the reasons I forget is because I work with multiple accounts on a daily base and I don’t want to shift my attention to a tool like the Trusted Advisor each time I login for an other purpose. Basically this means, and I think this counts for a lot of us, when my attention is needed it needs to be forced by some kind of alarm, notification or email.

Some examples of the usefull checks of the Trusted Advisor I like to get notified about:

• Exposed Access Keys: Are there any AWS access keys which are exposed to the public in a repository
• Service limits: Which service is using more than 80% of the limit

When you only have to manage one account this task is simple. Each Trusted Advisor run will create Eventbridge events and using Eventbridge Rules you will be able to send those events to a SNS topic or Lambda function. Now when you want to do the same for multiple account in your AWS organization you might think there is a simple way to aggregate all those events into one account. Unfortunaly this functionality does not (yet) exists. At first sight the Organizational view for The Trusted Advisor tool seems to solve this situation, but this feature will only allow you to create reports over the accounts in your organizations.

Luckily Eventbridge can forward events from the default eventbus to an eventbus in a different account. Using Eventbridge I will be able to forward the Trusted Advisor Events of interest from multiple account to one central account where I will process the events and configure the actions to take. Of course we do not want to create the Eventbridge rules in the accounts one-by-one, for that part we will use Cloudformation Stacksets.

Cloudformation Stackset

The Stackset will create two resources: the Eventbridge rule and the role.

IAM Role

To be able to send events to a different account we need permissions to put events (events:putEvents) on the default eventbus in the root account.

EventbridgeTACrossAccountRole:
Type: "AWS::IAM::Role"
Properties:
    AssumeRolePolicyDocument:
    Statement:
    - Effect: Allow
        Principal:
        Service: 
            - "events.amazonaws.com"
        Action:
        - sts:AssumeRole
    Policies:
    - PolicyName: "EventBridgePutEvents"
        PolicyDocument:
        Version: "2012-10-17"
        Statement:
            -
            Effect: "Allow"
            Action:
                - "events:PutEvents"
            Resource:
                - "arn:aws:events:eu-west-1:123456789123:event-bus/default"

Event rule

In the rule we first configure the event pattern which will trigger the rule. The second part to configure is the target to invoke. In our case the target is the default eventbus in the root account in our organization.

EventbridgeTARule:
Type: AWS::Events::Rule
Properties:
    Name: ExposedKeyEventRule
    EventPattern:
    source: 
        - "aws.trustedadvisor"
    detail-type: 
        - "Trusted Advisor Check Item Refresh Notification"
    detail: 
        status: 
        - "ERROR"
        check-name:
        - "Exposed Access Keys"
    State: "ENABLED"
    Targets:
    - Arn: arn:aws:events:eu-west-1:123456789123:event-bus/default
        Id: DefaultBusRootAccount
        RoleArn: !GetAtt EventbridgeTACrossAccountRole.Arn

The Id attribute for the Target is mandatory, although it can be a random string. The attribute RoleArn is a reference to the IAM Role.

Deploying the Stackset

After creating the Stackset we want to deploy it to all our accounts in the us-east-1 region. The Trusted Advisor is not an regional services and events will only be available in us-east-1.

Configure root account

As always cross account actions require permissions from both accounts involved. In the root account which will receive all the events from the other accounts we need to set the resource-based policy on the default eventbus rule to accept all events from accounts in the organization.
This conversation was marked as resolved by dazzle1979
Show conversation

This is done using a Condition in the policy. We allow every principal to put events on the default eventbus as long as the aws:PrincipalOrgID is equal to our OrganizationId.

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "allow_all_accounts_from_organization_to_put_events",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "events:PutEvents",
        "Resource": "arn:aws:events:us-east-1:123456789123:event-bus/default",
        "Condition": {
            "StringEquals": {
                "aws:PrincipalOrgID": "<OrganizationId>"
            }
        }
    }]
}

And create a new Eventbridge rule which will be triggered by the forwarded Trusted Advisor events.

{
  "source": ["aws.trustedadvisor"],
  "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
  "detail": {
    "status": ["ERROR"],
    "check-name": ["Exposed Access Keys"]
  }
}

The only thing remaining is configuring a Lambda function as the target for the Eventbridge rule. In my case I’m using the Lambda function to compose an email which I will send using SNS.

Conclusion

Where many AWS services already have smart solutions for aggregating data for multiple accounts in you organization this is not the case for the Trusted Advisor tool. Luckily there are some other powerfull tools in the AWS ecosystem to solve limitations like this.