EventBridge Resource-based Policy | Overview.

Amazon EventBridge Resource-based Policies - Overview

Scope:

• Intro,
• Key Uses and Resources,
• Policy Management,
• The Concept of Resource-Based Policy (deep dive),
• Supported Resources (that Resource-based policies can be attached to),
• Key Capabilities,
• Structure of a Resource-based Policy (Sample for an event bus),
• Key Parts of a Resource-based Policy,
• Common Actions Controlled by Resource Policies,
• Cross-Account Event Bus Access – Flow (how resource-based policies enable cross-account publishing),
• Sample Use Cases,
• Security Best Practices,
• Sample Visual Lifecycle of Resource-based Policy.

Intro:

• Amazon EventBridge uses resource-based policies to manage permissions directly on resources like event buses and schemas, rather than on IAM identities. 
• These policies define which principals (accounts, users, or services) can perform specific actions on the resource. 

Key Uses and Resources

• Event Buses: Resource-based policies for event buses are used to grant permissions for cross-account or cross-service event publishing. 
• By default, a custom event bus does not have a policy, and one must be attached to allow access from other accounts.
• Target Invocations: When EventBridge triggers certain targets—such as AWS Lambda functions, Amazon SNS topics, Amazon SQS queues, or CloudWatch Logs—it relies on the resource-based policy of the target itself to grant EventBridge permission to invoke it.
• Schemas: The EventBridge schema registry also supports resource-based policies to control who can view or manage event schemas.
• Dead-Letter Queues (DLQ): If twtech uses an Amazon SQS queue in another account as a DLQ, it must attach a resource-based policy to that queue to allow EventBridge to send failed events to it. 

Policy Management

• Configuration: twtech can manage these policies via the Amazon EventBridge Console, AWS CLI, or APIs.
• Action Syntax: Permissions are defined using the events: prefix followed by the API operation (e.g., events:PutRule or events:PutEvents).
• Automation: When using the AWS Management Console to set up rules, EventBridge often automatically creates the necessary resource-based policies for targets like CloudWatch Logs.
•  However, if twtech uses the API, it must manually create them.

1. The Concept of Resource-Based Policy (deep dive)

A resource-based policy in Amazon EventBridge is an IAM policy attached directly to an EventBridge resource (like an event bus, archive, or replay).

• Unlike identity-based IAM policies (attached to users, groups, or roles), resource-based policies define who can access the resource itself and what actions they can perform.
• This is crucial for cross-account event sharing, SaaS integrations, and secure event bus management.

2. Supported Resources (that Resource-based policies can be attached to).

• Event buses (primary use case)
• Archives (stored event collections)
• Replays (reprocessing events from archives)

3. Key Capabilities

• Cross-account access → Allow accounts (or orgs) to publish/subscribe to twtech event bus.
• Service integrations → Permit AWS services (like SaaS partners) to put events into your bus.
• Granular permissions → Control actions like events:PutEvents, events:DescribeEventBus, etc.
• Organization-wide sharing → Policies can reference AWS Organizations (Org IDs, OU IDs).
• Principals → Policies grant access to AWS accounts, IAM roles/users, or AWS services.

4. Structure of a Resource-based Policy (Sample for an event bus):

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "twtechAllowAccountBtoPutEvents",

      "Effect": "Allow",

      "Principal": {

        "AWS": "arn:aws:iam::twtechPrincipalAccountId:root"

      },

      "Action": "events:PutEvents",

      "Resource": "arn:aws:events:us-east-2:accountID:event-bus/partner-bus"

    }

  ]

}

Key Parts of a Resource-based Policy :

• Principal → who gets access (account, user, role, or service).
• Action → what they can do (events:PutEvents, events:DescribeEventBus, etc.).
• Resource → which EventBridge resource is being protected.
• Condition (optional) → restrict access (IP, Org ID, time, etc.).

5. Common Actions Controlled by Resource Policies

• events:PutEvents → Allow producers to send events.
• events:DescribeEventBus → Allow consumers to query bus details.
• events:PutRule / events:PutTargets → Allow creation of rules/targets.
• events:Replay / events:DescribeReplay → For replay functionality.
• events:CreateArchive / events:DescribeArchive → For event archiving.

6. Cross-Account Event Bus Access – Flow (how resource-based policies enable cross-account publishing):

[ twtechAccount-A ] (Producer)  --->  [ twtechAccount-B ] (Event Bus Owner)

             PutEvents                               Event Bus / Resource Policy

NB:

• twtechAccount-B owns the Event Bus.
• twtechAccount-B attaches a resource policy allowing Account A to call events:PutEvents.
• twtechAccount-A publishes events to twtechAccount-B’s event bus.
• Consumers in twtechAccount-B (Lambdas, Step Functions, etc.) process those events.

7. Sample Use Cases

1. SaaS Event Ingestion
• SaaS provider publishes customer-specific events into customer’s event bus.
• Resource-based policy grants the SaaS provider’s AWS account permission.
2. Cross-Account Event Routing
• Centralized event bus in a "Shared Services Account".
• Application accounts push events into it for governance/logging.
3. Organization-wide event access
• Use AWS Organizations conditions:

"Condition": {

  "StringEquals": {

    "aws:PrincipalOrgID": "o-abc123"

  }

}

8. Security Best Practices

• Least privilege → Grant only events:PutEvents to producers.
• Conditions with Org IDs → Enforce access control within twtech AWS Org.
• Audit with CloudTrail → Track cross-account PutEvents API calls.
• Test with dry-run → Use events:TestEventPattern to validate policies.
• Rotate access → Review and prune unused principals in resource policies.

9. Sample Visual Lifecycle of Resource-based Policy