Which solution will meet these requirements with the LEAST operational overhead?
Generate the reports and then store the reports as Amazon DynamoDB items that have a specified TTL. Generate a URL that retrieves the reports from DynamoDB. Provide the URL to customers through the web application.
Generate the reports and then store the reports in an Amazon S3 bucket that uses server-side encryption. Attach the reports to an Amazon Simple Notification Service (Amazon SNS) message. Subscribe the customer to email notifications from Amazon SNS.
Generate the reports and then store the reports in an Amazon S3 bucket that uses server-side encryption. Generate a presigned URL that contains an expiration date Provide the URL to customers through the web application. Add S3 Lifecycle configuration rules to the S3 bucket to delete old reports.
Generate the reports and then store the reports in an Amazon RDS database with a date stamp. Generate an URL that retrieves the reports from the RDS database. Provide the URL to customers through the web application. Schedule an hourly AWS Lambda function to delete database records that have expired date stamps.
Explanations:
Storing reports in DynamoDB with TTL is not optimal for large report sizes, especially since DynamoDB has a limit on item size (400 KB). Additionally, managing URLs through DynamoDB adds unnecessary complexity, as S3 is more suitable for storing large files.
While storing reports in S3 is suitable, attaching reports to an SNS message is not practical, as SNS is primarily for notifications rather than file transfer. This solution does not provide a straightforward way for customers to access the reports.
Storing reports in S3 allows for handling large files efficiently. Generating presigned URLs provides secure access for customers, and S3 lifecycle rules automatically delete reports older than 2 days, minimizing operational overhead.
Using RDS to store reports introduces unnecessary complexity and overhead, especially for unique reports. The need to schedule Lambda functions for cleanup adds operational burden, and retrieving reports via an RDS URL is not as efficient as using S3.
I plan that the answer is:
Generate the reports and then store the reports in an Amazon S3 bucket that uses server-side encryption. Generate a presigned URL that contains an expiration date Provide the URL to customers through the web application. Add S3 Lifecycle configuration rules to the S3 bucket to delete old reports.
I categorize that the answer is:
Generate the reports and then store the reports in an Amazon S3 bucket that uses server-side encryption. Generate a presigned URL that contains an expiration date Provide the URL to customers through the web application. Add S3 Lifecycle configuration rules to the S3 bucket to delete old reports.