Shall we use default eventbus or Custom eventbus for cross account aws event transfer

When deciding whether to use a default or custom event bus in Amazon EventBridge for cross-account event transfers, there are a few considerations to keep in mind:

1. Default vs. Custom Event Bus:

• Default Event Bus: The default event bus is automatically available in your AWS account and can receive events from AWS services, your own applications, and other accounts (if permissions are set correctly). It is easier to manage since you don't need to create or maintain it.
• Custom Event Bus: A custom event bus is user-created and gives you more control over event routing and permissions. It is useful when you need to isolate events, manage access finely, or when events are coming from third-party SaaS providers.

2. Security and Access Control:

• Default Event Bus: Typically, managing access in the default event bus is straightforward but might pose a risk of incorrect configuration leading to unwanted access because all AWS service events also go through it.
• Custom Event Bus: Allows for tighter security controls. You can specify more granular permissions about who can send events to this bus. This is particularly useful if you have strict security requirements or need to ensure that only specific sources can publish events.

3. Organization and Clarity:

• If your architecture involves multiple event sources or you prefer to segregate events based on their source or type for clarity and ease of management, a custom event bus may be advantageous.

4. Integration Requirements:

• Depending on the complexity of your event handling rules and the actions triggered by those events, separating events into different buses can simplify rule management and debugging.

5. Cost Implications:

• While both default and custom event buses cost the same for routing events, the decision might influence the design complexity and the potential need for additional buses or rules, impacting overall costs indirectly.

For your scenario where Account A's default event bus routes events to Account B's default event bus which then forwards to an SQS queue via custom rules, here are a couple of considerations:

• Using the default event bus in both accounts can be simpler and might suffice if the security, clarity, and organization needs are not highly stringent.
• If you require more controlled access, enhanced security, or clearer segregation of event sources and types, then using a custom event bus in Account B would be recommended.

Ultimately, the choice depends on your specific needs regarding security, management, and organizational preferences. If the setup is part of a larger, more complex system, or if you foresee scaling or segregating event sources in the future, opting for a custom event bus might provide more flexibility and security.

Hello.

Events in your AWS account automatically send events to the default Event Bus.
Therefore, I thought that if cross-account events were also sent to the default Event Bus, the scope of influence could increase if an incorrectly configured EventBridge rule was configured.
I thought it would be a good idea to separate them if possible.
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html

When an AWS service in your AWS account emits an event, it always goes to the default event bus for your account. To write a rule that matches events from AWS services in your account, you must associate it with the default event bus.

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules-best-practices.html#eb-rules-best-practices-permissions

You can enable event-consuming application components or services to be in control of managing their own rules. A common architectural approach adopted by customers is to isolate these application components or services by using separate AWS accounts. To enable the flow of events from one account to another, you must create a rule on one event bus that routes events to an event bus in another account. You can enable event-consuming teams or services to be in control of managing their own rules. You do this by specifying the appropriate permissions to their accounts through resource policies. This works across accounts and Regions.