Question

Difficulty: MediumServerless and Automated Scaling Architectures for Cost Efficiency

A smart utility provider receives water consumption telemetry reports from 500,000500,000 smart meters. These meters upload data in unpredictable bursts three times a day. The processing pipeline requires strict message ordering for each smart meter to compute usage trends accurately. Each batch processing job performs complex analytics that runs continuously for 2020 to 2525 minutes per batch. The final results are stored in an Amazon DynamoDB table. The provider wants to design a highly cost-effective, serverless backend architecture that minimizes operational overhead.

Which combination of actions will meet these requirements most cost-effectively? (Select TWO.)

  1. A
    Use Amazon SQS standard queues to ingest the telemetry data.
  2. Use Amazon SQS FIFO queues to ingest the telemetry data.Answer
  3. C
    Deploy the analytics application on AWS Lambda functions.
  4. Deploy the analytics application as containerized tasks using Amazon ECS on AWS Fargate.Answer
  5. E
    Configure the target Amazon DynamoDB table with provisioned capacity mode.

Answer

The correct architecture uses Amazon SQS FIFO queues to ingest the telemetry data and deploys the analytics application as containerized tasks using Amazon ECS on AWS Fargate.
To satisfy the requirements cost-effectively, the solution must handle spiky workloads, preserve message ordering, and support execution runtimes longer than 1515 minutes without manual server management. Amazon SQS FIFO queues ensure strict ordering per smart meter. Amazon ECS on AWS Fargate is serverless, scales to zero when no messages are in the queue, and supports long-running tasks without the execution timeout limit of AWS Lambda.

Step-by-Step Solution

1
Analyze the ingestion and message ordering requirements.
Determine that Amazon SQS FIFO queues are necessary to ensure strict ordering of messages per smart meter, preventing standard SQS queue out-of-order delivery.
Correct trend calculations require telemetry data to be processed in the exact order it was generated.
2
Evaluate the compute execution duration limits.
Select Amazon ECS on AWS Fargate for the batch processing jobs, rejecting AWS Lambda.
AWS Lambda functions will time out due to the 1515-minute limit, whereas AWS Fargate tasks can run for the required 2020 to 2525 minutes and scale dynamically to zero when idle.
3
Assess the database access pattern and capacity needs.
Identify that the DynamoDB table should use on-demand capacity mode rather than provisioned mode.
On-demand capacity mode eliminates the cost of provisioning for peak spiky bursts and charges only for the actual read/write requests made.

Key Concept

Serverless and Automated Scaling Architectures for Cost Efficiency
Estimated Time:2m 0s
Rate this question