Question

Difficulty: HardServerless and Automated Scaling Architectures for Cost Efficiency

A media startup is designing a processing pipeline to transcode high-resolution video uploads. Users upload videos of varying sizes to an Amazon S3 bucket. The transcoding process is compute-intensive, taking between 15 to 30 minutes per video, and the daily upload volume is highly unpredictable with long periods of zero activity. The processing order of the videos is not important. The startup wants a cost-effective, serverless architecture that scales dynamically to meet demand and incurs no compute costs when there are no video uploads. Which two solutions should the solutions architect recommend to meet these requirements in the most cost-effective manner? (Select TWO.)

  1. Use Amazon Elastic Container Service (Amazon ECS) with the AWS Fargate launch type to run the transcoding tasks.Answer
  2. Use Amazon Simple Queue Service (Amazon SQS) standard queues to hold the transcoding jobs, and scale the container tasks based on queue depth.Answer
  3. C
    Create an AWS Lambda function triggered directly by Amazon S3 event notifications to perform the video transcoding.
  4. D
    Configure an Amazon SQS FIFO queue to manage the transcoding jobs to ensure that videos are processed in the exact order they are uploaded.
  5. E
    Store transcoding job states in Amazon DynamoDB configured with provisioned capacity mode to orchestrate the tasks.

Answer

The correct solutions are to use Amazon ECS with the AWS Fargate launch type to run the transcoding tasks, and to use Amazon SQS standard queues to hold the transcoding jobs while scaling the container tasks based on the queue depth.
The correct approach combines Amazon SQS standard queues for decoupling and Amazon ECS on AWS Fargate for serverless container execution. Amazon SQS standard queues are cost-effective and scale automatically to absorb spikes in uploads, while allowing the container tasks to scale down to zero when the queue is empty. AWS Fargate is ideal here because the transcoding process takes 15 to 30 minutes, which exceeds the 15-minute maximum runtime limit of AWS Lambda. Fargate runs containers serverlessly, charging only for the resources consumed during the active transcoding duration and incurring zero cost when idle.

Step-by-Step Solution

1
Analyze the processing duration and compute requirements.
Identify that the transcoding tasks take 15 to 30 minutes, which exceeds the 15-minute execution limit of AWS Lambda.
Determining the execution duration prevents choosing serverless compute options that will timeout and fail.
2
Determine the most cost-effective serverless compute service that can run tasks longer than 15 minutes.
Select Amazon ECS with the AWS Fargate launch type.
AWS Fargate runs containers serverlessly, allows tasks to run up to 24 hours, and scales to zero when no tasks are running, ensuring no idle compute costs.
3
Select the queue type and integration to store jobs and trigger scaling.
Select an Amazon SQS standard queue to buffer jobs and use queue depth to scale ECS Fargate tasks.
SQS standard queues are cheaper than FIFO queues, scale virtually infinitely, and are appropriate since strict message ordering is not required.

Key Concept

Designing cost-optimized serverless architectures for long-running, unpredictable workloads by combining SQS standard queues and ECS Fargate scaling.
Rate this question