What is the MOST operationally efficient solution that meets these requirements?
Create an Amazon Kinesis Data Firehose delivery stream to ingest the alerts. Configure the Kinesis Data Firehose stream to deliver the alerts to an Amazon S3 bucket. Set up an S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.
Launch Amazon EC2 instances across two Availability Zones and place them behind an Elastic Load Balancer to ingest the alerts. Create a script on the EC2 instances that will store the alerts in an Amazon S3 bucket. Set up an S3 Lifecycle configuration to transition data to Amazon S3 Glacier after 14 days.
Create an Amazon Kinesis Data Firehose delivery stream to ingest the alerts. Configure the Kinesis Data Firehose stream to deliver the alerts to an Amazon OpenSearch Service (Amazon Elasticsearch Service) cluster. Set up the Amazon OpenSearch Service (Amazon Elasticsearch Service) cluster to take manual snapshots every day and delete data from the cluster that is older than 14 days.
Create an Amazon Simple Queue Service (Amazon SQS) standard queue to ingest the alerts, and set the message retention period to 14 days. Configure consumers to poll the SQS queue, check the age of the message, and analyze the message data as needed. If the message is 14 days old, the consumer should copy the message to an Amazon S3 bucket and delete the message from the SQS queue.
Explanations:
This option uses Amazon Kinesis Data Firehose to efficiently ingest data and store it in S3, which is highly available and scalable. The S3 Lifecycle configuration allows for automatic transition of data to Glacier after 14 days, minimizing management overhead and costs while fulfilling the data retention requirement.
While this option meets the data retention requirement, it introduces additional management overhead with EC2 instances and an Elastic Load Balancer, which increases operational complexity and costs. The solution is not as operationally efficient as option A.
Although this option uses Kinesis Data Firehose, it directs the data to an OpenSearch Service cluster, which requires more management and maintenance compared to S3. Additionally, manual snapshots and deletion processes add operational complexity, making it less efficient than option A.
This option uses SQS for ingestion, which adds complexity in managing message retention and requires consumers to actively poll and manage the messages. It does not provide a straightforward storage solution like S3 and can lead to inefficiencies in handling alerts compared to option A.