Skip to main content

Command Palette

Search for a command to run...

Travelling between AWS accounts using Eventbridge event bus and IAM Assume role

Updated
3 min read
Travelling between AWS accounts using Eventbridge event bus and IAM Assume role

Have you ever wondered how you can send an event from your aws account to another account, or enter someone else account to do something? Like in real-life you take a bus to travel, from one place to another, you can use aws eventbridge - eventbus, or IAM - assume role for this.

AWS Eventbridge

Serverless service used to trigger other aws services like lambda like a cron to schedule a event, or when a real-time event occurs.

  • Serverless?

    Just use it, without worrying about the computing capacity used behind.

It contains event bus and rules. Bus is used to capture and send events to targets, a target can be in same / another account or region. Rules work like cron to schedule an event. You can trigger a lambda at a particular time using this rule.

Event Bus

Works like a router which receives events, and forwards it to its targets (one or more). To capture a specific event, create a rule with the custom pattern, and add a target to trigger whenever event occurs. You can also add filters / conditions inside the event rule.

Source account - In the default event bus, create a rule which will have the event to capture.

So now who’s the target?

  • Select EventBridge event bus option → Event bus in a different account or Region. Target will be the custom event bus arn you created in the destination account.

Destination account - Create a custom event bus, this event bus arn will be above mentioned target. Create a rule, which will have the event to capture (same as you did in source).

With this new aws eventbridge feature, you can also use same event bus, to do the same activity, which aims to reduce the latency.

IAM Assume Role

You can assume an IAM role in another account to do your activities, based on the permissions given to you in destination account role. AWS STS (Security Token service) gives you temporary credentials for each session.

Let’s say you and your brother have different aws accounts, and you want, ssm access of his servers in his account, instead of giving you permanent user and credentials, he creates a temporary role, with a session duration and required permissons for you.

Now please don’t complain if you don’t get ssm of a specific server, may be he forgot to add that instance id in your assume role ssm policy! 😜

Permissions

Source account (Your account) - Needs to have a sts assume role permission. In Resource, add destination account’s role arn, if you are bit lazy to get the arn, add “*” on it and you can assume any role in any account (only if destination account whitelists your role, mentioned below).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id:role/Test*"
  }
}

Destination account (Your brother’s account) - A trust relationship which whitelists your source account role, if root is mentioned then all roles from the source account will be allowed. Based on the permissions given on this role (destination), source can perform its activities.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789***:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

In this way, you can travel to another aws account, please remember the principal of least privilege whenever you are doing this. Thank you.