Which solution will meet these requirements MOST cost-effectively?
Migrate storage of the contest entries to Amazon DynamoDB. Create a DynamoDB Accelerator (DAX) cluster. Rewrite the code to run as Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type. At the end of the contest, delete the DynamoDB table.
Migrate the storage of the contest entries to Amazon Redshift. Rewrite the code as AWS Lambda functions. At the end of the contest, delete the Redshift cluster.
Add an Amazon ElastiCache for Redis cluster in front of the RDS DB instances to cache the contest entries. Rewrite the code to run as Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type. Set the ElastiCache TTL attribute on each entry to expire each entry at the end of the contest.
Migrate the storage of the contest entries to Amazon DynamoDB. Rewrite the code as AWS Lambda functions. Set the DynamoDB TTL attribute on each entry to expire each entry at the end of the contest.
Explanations:
While migrating to DynamoDB and using ECS with Fargate can improve scalability and cost-effectiveness, the use of DAX is unnecessary since the contest data is not retained after completion. Additionally, deleting the table after each contest could incur extra costs and is not an optimal use of DynamoDB’s features.
Migrating to Amazon Redshift is not suitable for this scenario as it is designed for data warehousing and not for ephemeral contest data. Moreover, rewriting the code as AWS Lambda functions without a suitable storage solution for contest entries makes this option impractical. Deleting the Redshift cluster after contests would also add unnecessary complexity and cost.
Adding ElastiCache for Redis can improve performance, but it does not solve the primary issue of reducing costs. Using ECS containers on Fargate is a good approach, but caching data that will be deleted at the end of the contest can lead to inefficient resource utilization and unnecessary complexity.
This option effectively utilizes Amazon DynamoDB for storing contest entries, which is cost-effective for transient data. By rewriting the code as AWS Lambda functions, the company can take advantage of serverless computing, reducing costs during idle times. Setting the TTL attribute in DynamoDB ensures that entries are automatically deleted after the contest, aligning perfectly with the requirement of not retaining data post-contest.
I scheme that the answer is:
Migrate the storage of the contest entries to Amazon DynamoDB. Rewrite the code as AWS Lambda functions. Set the DynamoDB TTL attribute on each entry to expire each entry at the end of the contest.