Cross account metadata and management events

Question

I want to report a few kinds of small events from customer accounts to my account - things like CloudFormation stack updates and certain API calls in CloudTrail - and minimise the cost, complexity and security footprint in the customer account. I'd estimate max 100 messages/day in the long term, evenly distributed, so scalability and per-message processing cost isn't really a concern. In-order would be nice but can live without. I can idempotently re-process. I would only need one processor. Replay might be good, if my receiver breaks.

It seems clear the first step will be an EventBridge rule in my customer accounts. From there, it looks like I could:

1. Invoke my own HTTPS API. This benefits from some amount of retries, it decouples my receiver from AWS in case that was ever useful - and even if I stay on AWS, it decouples me from Lambda vs ECS vs EKS vs EC2 etc. I don't need to pre-configure anything on my end - just receive the event and check it against my users. Customer account policies need to allow invocations of APIs outside their VPC etc. Hard to change my architecture later once customers are setup.
2. [Cross-account target](https://aws.amazon.com/blogs/compute/introducing-cross-account-targets-for-amazon-eventbridge-event-buses/) it into my own EventBridge bus. This is super cheap, lets me plug my own eventual targets in and out. Customer account policies need to allow cross-account targets.
3. Cross-account target my own SQS. Can poll that from ECS, or trigger a Lambda. Hard to change my architecture later once customers are setup. Customer account policies need to allow cross-account targets.
4. Cross-account target my own SNS, which feeds an SQS. Not sure what this adds for this scenario. Hard to change my architecture later once customers are setup. Customer account policies need to allow cross-account targets.
5. Something else?

Any thoughts?

re:Post Agent · Answer

Based on your requirements and the options you've outlined, the most suitable approach for your scenario would be to use cross-account targets with Amazon EventBridge (option 2). This solution offers several advantages that align well with your needs:

1. Simplicity and Cost-Effectiveness: EventBridge is a serverless service, which means you don't have to manage any infrastructure. It's also very cost-effective, especially for your low volume of events (estimated 100 messages/day).

2. Flexibility and Future-Proofing: By sending events to your own EventBridge bus in your account, you maintain the flexibility to change your event processing architecture in the future without requiring changes in your customers' accounts. You can easily add or modify targets for your EventBridge bus as your needs evolve.

3. Minimal Security Footprint: This approach requires minimal permissions in the customer accounts. You only need to allow the EventBridge in the customer account to send events to your account's EventBridge bus.

4. Built-in Retry Mechanism: EventBridge has a built-in retry mechanism for failed event deliveries, which addresses your concern about potential processing failures.

5. Replay Capability: EventBridge supports event replay, which can be useful if your receiver breaks and you need to reprocess events.

6. Decoupling: This approach decouples the event source from the event processing, allowing you to change your processing logic or infrastructure without affecting the customer setup.

7. Scalability: While not a primary concern for your current volume, using EventBridge provides built-in scalability if your needs grow in the future.

To implement this:

1. Create an EventBridge bus in your account to receive events.
2. Set up the necessary permissions on your EventBridge bus to allow events from customer accounts.
3. In each customer account, create an EventBridge rule that matches the desired events (CloudFormation stack updates, specific CloudTrail API calls) and set the target as your EventBridge bus.
4. In your account, create rules on your EventBridge bus to process the incoming events as needed (e.g., triggering a Lambda function, sending to SQS, etc.).

This approach provides a good balance of simplicity, flexibility, and security for your use case, while also allowing for easy modifications and scaling in the future if needed.  
**Sources**  
[Introducing cross-account targets for Amazon EventBridge Event Buses | AWS Compute Blog](https://aws.amazon.com/blogs/compute/introducing-cross-account-targets-for-amazon-eventbridge-event-buses/)  
[Shall we use default eventbus or Custom eventbus for cross account aws event transfer | AWS re:Post](https://repost.aws/questions/QUlCr3sYYPTqS_y_fDSUIywQ/shall-we-use-default-eventbus-or-custom-eventbus-for-cross-account-aws-event-transfer)  
[Sending events to an AWS service in another account in EventBridge - Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-cross-account.html)  
[Create a cross-account Amazon EventBridge connection in an organization - AWS Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-cross-account-amazon-eventbridge-connection-organization.html)

Cross account metadata and management events

Add your answer

Relevant content