B - EMR cluster is for Big Data, has nothing to do with this C - invokes the function "on a schedule", but you want to capture events D - Could work, but would be overcomplex and would "affect the speed of EC2 instance launches" (which it should not)

This solution meets the requirements because it is serverless and does not affect the speed of EC2 instance launches. Amazon CloudWatch metric streams can continuously stream CloudWatch metrics to destinations such as Amazon S3. Amazon Kinesis Data Firehose can capture, transform, and deliver streaming data into data lakes, data stores, and analytics services. It can directly put the data into Amazon S3, which can then be used for near-real-time updates in a dashboard.

B. introduces unnecessary complexity and overhead for collecting and sending the EC2 Auto Scaling status data to S3. It is not the most efficient serverless solution for this specific requirement. C. would introduce delays in data updates, as it is not triggered in real-time. Additionally, it adds unnecessary overhead and complexity compared to using a direct data stream. D. introduces additional dependencies and management overhead. It may also impact the speed of EC2 instance launches, which is a requirement that needs to be avoided. Overall, option A provides a streamlined and serverless solution by leveraging CloudWatch metric streams and Kinesis Data Firehose to efficiently capture and store the EC2 Auto Scaling status data in S3 without affecting the speed of EC2 instance launches.

Answer A: Near real time --> Amazon Kinesis Data Firehose

Serverless solution and near real time

Changing my answer to *A* as the dashboard will provide near-real updates. Unless the lambda is configured to run every minute which is not common with schedules - it is not considered near real-time.

A because of near real time scenario

You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. Supported destinations include AWS destinations such as Amazon Simple Storage Service and several third-party service provider destinations. Main usage scenarios for CloudWatch metric streams: Data lake— Create a metric stream and direct it to an Amazon Kinesis Data Firehose delivery stream that delivers your CloudWatch metrics to a data lake such as Amazon S3. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html#:~:text=CloudWatch%20metric%20streams

You can use metric streams to continually stream CloudWatch metrics to a destination of your choice, with near-real-time delivery and low latency. One of the use cases is Data Lake: create a metric stream and direct it to an Amazon Kinesis Data Firehose delivery stream that delivers your CloudWatch metrics to a data lake such as Amazon S3. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Metric-Streams.html

Both A and C are applicable - no doubt there. C is more straightforward and to the point of the question imho.

A seemsright choice but serverless keyword confuses,and cloud watch metric steam is server less too.

C. Create an Amazon EventBridge rule to invoke an AWS Lambda function on a schedule. Configure the Lambda function to send the EC2 Auto Scaling status data directly to Amazon S3.

near real time -eliminates c

Answer is A

A seems to be the right answer. Don't think C could be correct as it says "near real-time" and C is on schedule

Option C, using an Amazon EventBridge rule to invoke an AWS Lambda function on a schedule to send the EC2 Auto Scaling status data directly to Amazon S3, may not be the best choice because it may not provide real-time updates to the dashboard. A schedule-based approach with an EventBridge rule and Lambda function may not be able to deliver the data in near real-time, as the EC2 Auto Scaling status data is generated dynamically and may not always align with the schedule set by the EventBridge rule. Additionally, using a schedule-based approach with EventBridge and Lambda also has the potential to create latency, as there may be a delay between the time the data is generated and the time it is sent to S3. In this scenario, using Amazon CloudWatch and Kinesis Data Firehose as described in Option A, provides a more reliable and near real-time solution.

C invokes the Lambda function "on a schedule". It would collect the scaling status during its runs. But you don't want the hourly status, you want to report "scaling events".

"On a schedule" but you want to capture events, not a regular status report.

But A is serverless.

A: I was thinking D is the answer but the solution should not impact ec2 launches will make the difference and i fast read the question. A is a right choice.

While EventBridge can capture events, scheduling Lambda functions to poll data is less efficient and may introduce latency, which would not meet the near-real-time requirement.

Right.

Kinesis is for data streams not events. So, C