Question

Difficulty: MediumServerless and Automated Scaling Architectures for Cost Efficiency

A law firm is designing a serverless system to automate the metadata extraction of scanned case files. Case documents are uploaded to Amazon S3 at unpredictable times throughout the day, followed by long periods of inactivity. The processing pipeline must process the documents in the exact chronological order of their upload to maintain case sequence integrity. The extraction logic is packaged as a containerized application and takes between 2020 and 3535 minutes per document batch. The extracted metadata is stored in a database that is queried sporadically by internal applications. Which system architecture meets these requirements in the most cost-effective manner?

  1. Configure Amazon S3 event notifications to publish messages to an Amazon SQS FIFO queue. Deploy the containerized application on Amazon ECS using the AWS Fargate launch type, scaling the number of tasks dynamically based on queue depth. Store the metadata in an Amazon DynamoDB table configured with On-Demand capacity mode.Answer
  2. B
    Configure Amazon S3 event notifications to trigger an AWS Lambda function that runs the containerized application. Store the metadata in an Amazon DynamoDB table configured with On-Demand capacity mode.
  3. C
    Configure Amazon S3 event notifications to publish messages to an Amazon SQS Standard queue. Deploy the containerized application on Amazon ECS using the AWS Fargate launch type, scaling the number of tasks dynamically based on queue depth. Store the metadata in an Amazon DynamoDB table configured with On-Demand capacity mode.
  4. D
    Configure Amazon S3 event notifications to publish messages to an Amazon SQS FIFO queue. Deploy the containerized application on Amazon ECS using the AWS Fargate launch type, scaling the number of tasks dynamically based on queue depth. Store the metadata in an Amazon DynamoDB table configured with Provisioned capacity mode with Auto Scaling.

Answer

Configure Amazon S3 event notifications to publish messages to an Amazon SQS FIFO queue, deploy the containerized application on Amazon ECS using the AWS Fargate launch type scaling dynamically based on queue depth, and store the metadata in an Amazon DynamoDB table configured with On-Demand capacity mode.
The correct solution uses an Amazon SQS FIFO queue to guarantee the chronological sequence of case document updates. It runs the containerized logic on Amazon ECS with the AWS Fargate launch type, which supports runtimes exceeding 1515 minutes and scales dynamically down to zero when the queue is empty to avoid idle compute charges. Finally, it uses Amazon DynamoDB with On-Demand capacity mode to store the metadata, avoiding any minimum hourly costs during long periods of database inactivity.

Step-by-Step Solution

1
Select the appropriate messaging queue to ensure message ordering.
Choose Amazon SQS FIFO queue.
The scenario requires processing documents in the exact chronological order of their upload. SQS Standard does not guarantee ordering, whereas SQS FIFO guarantees first-in, first-out order.
2
Select the appropriate serverless compute service based on the processing duration.
Choose Amazon ECS on AWS Fargate.
The processing takes 2020 to 3535 minutes. AWS Lambda has a hard execution limit of 1515 minutes and cannot be used. AWS Fargate allows containerized tasks to run for hours without server management, and scaling them based on SQS queue depth ensures tasks scale down to zero when idle, minimizing compute cost.
3
Select the database capacity mode based on the access pattern.
Choose Amazon DynamoDB with On-Demand capacity mode.
The metadata is queried sporadically with unpredictable activity. DynamoDB On-Demand capacity mode charges per request and has no minimum hourly cost for idle capacity, making it more cost-effective than Provisioned capacity mode.

Key Concept

Serverless queue-based container orchestration and database capacity optimization for unpredictable, long-running batch workloads.
Rate this question