What are the different ways to invoke an AWS Lambda function, and where do you configure its invocation settings?

Lambda functions are invoked in three ways: synchronously (the caller waits for the result), asynchronously (Lambda queues the event and the caller moves on), or through an event source mapping, where Lambda polls a stream or queue and invokes the function with batches. Each has its own settings, and where you configure them depends on the type.

1. Synchronous

• The caller waits for the response and handles errors itself.
• Callers: API Gateway, Application Load Balancer, Lambda function URLs (a built-in HTTPS endpoint), the SDK or CLI with invoke, Cognito triggers.
• Settings: the caller's own timeouts and retries, and the function's timeout, memory and concurrency.

2. Asynchronous

• Lambda puts the event in an internal queue and returns at once. Callers include S3 event notifications, SNS, EventBridge (including EventBridge Scheduler for cron-style schedules) and the CLI with --invocation-type Event.
• On a function error, Lambda retries twice by default, and keeps unprocessed events for up to 6 hours.
• Settings live on the function under Configuration → Asynchronous invocation: maximum retry attempts (0 to 2), maximum event age, and a destination for failures (or successes): an SQS queue, SNS topic, EventBridge bus, another function or S3 bucket. A dead-letter queue is the older alternative.

3. Event source mappings (polling)

• Lambda reads from SQS, Kinesis, DynamoDB Streams, Amazon MSK or self-managed Kafka, and Amazon MQ, and invokes the function with batches.
• Settings live on the mapping (Configuration → Triggers, or create-event-source-mapping): batch size, batching window, starting position, filters, maximum retries, bisect batch on error, parallelization factor for streams, on-failure destination, and partial batch responses.
• Errors behave differently: in a stream, a failing batch blocks its shard until it succeeds or expires; in SQS, failed messages return to the queue and go to its dead-letter queue after the queue's receive limit.

Settings that apply to every invocation

• Timeout (up to 15 minutes), memory (which also sets CPU), environment variables.
• Reserved concurrency to cap or guarantee capacity, and provisioned concurrency to avoid cold starts.
• The function's resource-based policy says which services or accounts may invoke it; event source mappings instead use the function's execution role to read the source.

A good answer explains why the type matters: it decides who retries, how failures are captured, and whether order is kept.