A developer maintains a serverless application that uses AWS Lambda to process financial transaction files...

The hourly scheduled batch model is causing timeouts because the function must process an ever-growing backlog in a single invocation, which can exceed AWS Lambda’s maximum 15-minute runtime. A best-practice serverless refactor is to switch from “periodic polling” to an event-driven approach where work is split into smaller, independent units that can scale horizontally.

Configuring Amazon S3 Event Notifications to invoke Lambda on each object upload turns each file into its own discrete event. Instead of one long-running invocation that scans and processes many files, Lambda executes quickly per upload and automatically scales with incoming volume (subject to concurrency and downstream limits). This directly reduces processing time per run and eliminates the backlog buildup that leads to timeouts.

The remaining requirement is preventing duplicate processing. S3 event delivery is designed to be highly reliable, and applications should be built with idempotency in mind. Recording processed identifiers (such as a transaction ID, object key + version ID, or an application-level unique ID) in Amazon DynamoDB allows the function to check whether an item has already been processed before performing writes or downstream actions. Using DynamoDB with a conditional write (for example, “insert only if not exists”) is a common pattern to ensure exactly-once effect even when events are delivered more than once.

The other options do not meet the requirements as well: running more frequently (C) or continuously polling (D) still wastes time scanning and can still create duplicate work; moving to a single EC2 instance (B) reduces elasticity and increases operational overhead, and it doesn’t inherently solve deduplication or scaling.

Therefore, A provides scalable, event-driven processing and a straightforward deduplication mechanism.