
Tech • AI • Robotics • Game
An event-driven AWS pipeline can transcribe uploaded audio automatically by combining S3, Lambda, SQS, EC2, and Whisper into an asynchronous workflow that scales calmly under bursts.
The system is built so uploads and transcription run independently. A user drops an audio file into cloud storage and leaves; the upload does not wait for processing, and the worker handling transcription does not need to know who uploaded the file or when. That decoupling lets the service handle one file or dozens with the same user action.
The setup uses one S3 bucket, one standard SQS queue, one Lambda function, and one EC2 worker. It is intentionally small to highlight the core pattern of event, queue, worker, while leaving out harder production layers such as autoscaling worker fleets, stricter IAM scoping, and dead-letter handling for repeated failures.
Security starts with two IAM roles instead of permanent access keys. The EC2 role allows the worker to read and write S3 objects and receive and delete SQS messages, while the Lambda role allows the dispatcher to write logs and send messages to the queue. That keeps long-lived secrets off disk and limits each component to the services it needs.
Audio lands in an input prefix and completed transcripts are written to an output prefix inside the same S3 bucket. This works because S3 folders are just name prefixes rather than true directories. Using one bucket with two prefixes simplifies routing while keeping inbound and outbound files separate.
A standard SQS queue sits between upload events and the transcription worker. If 40 files arrive at once, they line up as messages instead of overwhelming the compute layer. The worker processes them one by one, so upstream uploads continue smoothly even when transcription takes time.
The key queue setting is a 300-second visibility timeout, raised from the default 30 seconds. When the worker pulls a job, the message becomes invisible while processing runs. That matters because transcribing a long recording on a small machine can take minutes; without the longer timeout, the same message could reappear and be processed twice.
The Lambda dispatcher is triggered only when objects are created in the input prefix. It reads the bucket name and object key from the S3 event and sends those details to SQS. Restricting the trigger to the input area prevents the worker’s transcript output from being mistaken for a new audio upload and re-queued forever.
The worker runs on a small Amazon Linux EC2 instance using Docker and no SSH key pair, with console access used when a shell is needed. Because Whisper and its container exceed the limits of a tiny machine, the disk is increased to 30 GB and a 2 GB swap file is added. That makes a low-cost instance usable for machine learning inference, trading speed for lower idle cost.
A prebuilt Whisper worker container is configured with the queue address, AWS Region, bucket, and input and output prefixes. It polls the queue continuously, downloads audio, transcribes it, uploads the resulting text file to the output prefix, and deletes the queue message after success. If the worker crashes before deletion, the message becomes visible again after five minutes and can be retried.
In a typical run, an uploaded recording triggers an S3 event, wakes the Lambda dispatcher, and produces one queue message. The EC2 worker receives that message, processes the audio, and writes a transcript a minute or two later. The result is a text file that appears automatically without manual transcription steps.
The design shows how a modest AWS stack can turn audio uploads into automatic transcripts with reliable, low-cost asynchronous processing. Its main value lies in the pattern itself: isolate the event, buffer the work, and let a worker process jobs at its own pace.
Explain this