Based on the question's comments, this answer is mostly about adding authentication to that Lambda URL...
I don't think the Lambda URL will work being called from Firehose. The reason is if you're using IAM authorization (implied due to the security requirement) calling it requires the client to sign the API request. Firehose doesn't support that.
I'm not sure of the reason for Firehose, but I think you can remove that and then either call the Lambda directly from EventBridge, or put API Gateway in between EventBridge and the Lambda.
Calling the Lambda directly might be simpler, but then you lose the flexibility of having a web API. But security is easy, its handled by IAM roles.
API Gateway shouldn't be much more difficult, and I assume your Lambda already handles the payload (since that's what the Lambda function URL sends). That looks like this:
EventBridge -> API Gateway -> Lambda
The API Gateway would need either IAM or Cognito authorization:
- IAM would be easiest; the EventBridge rule can target the API Gateway directly and then the rule just needs to use the proper IAM role.
- Cognito would be more complicated, but the idea here would be to set up a user pool client that uses the
client_credential
flow. In EventBridge, you'd set up your target as a "EventBridge API destination" and use an authorization type of "OAuth Client Credentials".
You also mention the ClickHouse API, I imagine looking into that would be even simpler, depending on how much logic you have in the Lambda. It looks like they have an interface, so you'd then just need to use the "EventBridge API destination" and send to that. Your EC2 hosts would either need to be publicly accessible, or you might be able to proxy the request through API Gateway or something else.