While either option could work. Its typically better to air on the side caution and store the logs. You can always have the logs for later use with other services, audits, observability (across your entire stack). To that end, you can use the Kinesis solution for log preservation/parsing, but it also adds more moving parts to your solution. What i would do is
Firelens/Fluent Bit -> CloudWatch -> OpenSearch (or ES)
This gives you the best of both benefits of the solutions you highlighted. Unless there is another reason for Kenisis, i.e. real time analytics for example, this simplifies the pipeline considerably.
Here are some resources to get you started
Firelens/Fluent Bit -> CloudWatch https://aws.amazon.com/blogs/containers/fluent-bit-integration-in-cloudwatch-container-insights-for-eks/
CloudWatch -> OpenSearch https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html.
Throttling a Client/Index from OpenSearch (ElasticSearch)Accepted Answer
OpenSearch [elasticsearch] elasticsearch/client.go:407 Cannot index event publisher.Eventasked 6 months ago
The firelens didn't send out logs after remote loki server is restartedasked a year ago
Cannot send WAF logs to Kinesisasked 4 months ago
Impact to AWS Elasticsearch on the licensing change of Elasticsearch(elastic.co)Accepted Answerasked 2 years ago
Log Subscription Filter To Opensearchasked 10 months ago
Fluent Bit Logs, Kinesis vs OpenSearch (ElasticSearch) Directly
Segregate logs in Opensearch based on accountsasked 8 months ago
ElasticSearch version change gets stuck in Amazon OpenSearch Serviceasked 4 months ago
Logging with CloudWatch vs. ElasticSearch/KibanaAccepted Answerasked 5 years ago