> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Lambda Event Source Mapping > AWS Lambda Event Source Mapping. Reads records from a queue or stream and invokes a Lambda function in batches, managing polling and progress through the event source. **On this page** * [Coverage by target cloud](#coverage-by-target-cloud) * [How the targets compare](#how-the-targets-compare) * [Infrastructure-only adaptation](#infrastructure-only-adaptation) * [On Google Cloud](#on-google-cloud) * [On Azure](#on-azure) * [Debug this service](#debug-this-service) ## Coverage by target cloud | Target | Available | | ------------------ | --------- | | Google Cloud | ✓ | | Azure | ✓ | | OCI | - | | Private Kubernetes | - | ## How the targets compare Each row compares a capability of Lambda Event Source Mapping with its adaptation on each target. A dash means this row is not stated for that target. ### Infrastructure-only adaptation | Capability | Lambda Event Source Mapping | Google Cloud | Azure | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Trigger model · how a queue or stream reaches the function | a Lambda-managed poller (the mapping) reads the source and invokes the function with batches | a push binding (a Pub/Sub push subscription or an Eventarc trigger) delivers each message to a Cloud Run service as an HTTP request; the Tensor9-built service serves the synchronous Invoke wire only, so no source is polled on the function's behalf | a trigger binding is a property of the function app's code package; the Tensor9-built package exposes a synchronous HTTP trigger only, so no source is polled on the function's behalf | | Delivery semantics · batches, filtering, ordering | at-least-once batches with a batch size and window, optional filter criteria, per-shard ordering for streams | none on this edge; a producer that invokes the function directly decides its own batching and retry | none on this edge; a producer that invokes the function directly decides its own batching and retry | | Failure handling · what happens to a failed batch | the mapping retries the batch, can report partial failures, and can send discarded records to a destination | none on this edge; the invoking producer sees the function's error contract (X-Amz-Function-Error) and retries under its own policy | none on this edge; the invoking producer sees the function's error contract (X-Amz-Function-Error) and retries under its own policy | | API coverage | full | minimal | minimal | ## On Google Cloud | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ---------------- | ------------ | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Batching and batching windows | Delivery | Out of scope | - | - | no batches are formed, because nothing polls a source | | Event filtering | Delivery | Out of scope | - | - | no filter criteria are applied | | Queue and stream sources | Event sources | Out of scope | - | - | SQS, Kinesis, DynamoDB Streams, Amazon MQ, Kafka and DocumentDB sources are not polled on the function's behalf; the producer side is re-wired to invoke the function (see the how-it-works) | | Retries, on-failure destinations and partial-batch responses | Failure handling | Out of scope | - | - | there is no redelivery, no failure destination and no ReportBatchItemFailures handling without a poller | | Operation | Area | Support | Depth | Notes | | ------------------------ | --------------------- | ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CreateEventSourceMapping | Event source mappings | Out of scope | Common | no source is polled on the function's behalf; the call is refused with a typed Lambda error (InvalidParameterValueException naming the operation), so a deployment that declares a mapping stops on that resource with a clear message and nothing is dropped silently | | DeleteEventSourceMapping | Event source mappings | Out of scope | Most usage | there is no mapping to delete | | GetEventSourceMapping | Event source mappings | Out of scope | Common | there is no mapping to describe; refused with the same typed error | | ListEventSourceMappings | Event source mappings | Out of scope | Common | there is no mapping to list; refused with the same typed error | | UpdateEventSourceMapping | Event source mappings | Out of scope | Most usage | there is no mapping to update | #### Event source mappings and push bindings On AWS an event source mapping is a Lambda resource of its own: it holds the binding from an SQS queue, a Kinesis or DynamoDB stream, an Amazon MQ broker, a Kafka topic or a DocumentDB change stream to a function, and Lambda runs pollers that read the source and invoke the function with batches, at least once, retrying a failed batch and optionally sending discarded records to a destination. Cloud Run does the same job in the opposite direction. A queue or stream reaches a service through a push binding: a Pub/Sub push subscription or an Eventarc trigger delivers each message to the service's URL as an HTTP request, Cloud Run scales the service per request, and delivery, retry and acknowledgement belong to the binding. Nothing polls on the service's behalf, and the binding expects an endpoint that understands its envelope. The service Tensor9 builds for a Lambda function serves the synchronous Invoke wire that the routing layer calls with identity tokens minted for it, and no other entry point, so a source cannot be bound to it. A declared mapping is therefore refused: CreateEventSourceMapping answers with a typed Lambda error naming the operation, a deployment that declares the mapping stops on that resource with a clear message, and nothing is dropped silently. #### Limitations * **No source is polled on the function's behalf.** SQS, Kinesis, DynamoDB Streams, Amazon MQ, Kafka and DocumentDB mappings are all refused; the function itself deploys and serves synchronous Invoke as the Lambda card for Cloud Run describes. - **Batching, filtering and failure destinations go with the mapping.** Without a poller there is no batch size or window, no filter criteria, no retry of a failed batch, no partial-batch response and no on-failure destination. A producer that invokes the function directly decides those for itself. - **The deployment names the mapping it refused.** The error names the operation and the mapping, so a trigger is never lost silently; the deployment stops until the mapping is removed from it and the producer is re-wired. #### Other considerations * **Re-wiring the asynchronous path.** Two shapes work: the producer calls Invoke directly through the routing layer, synchronously and with the Lambda error contract; or the queue moves with its consumer, so that a consumer of your own reads the queue served on the same appliance and invokes the function. - **Nothing migrates.** A mapping holds no data; messages already in the source are drained by whichever consumer reads it after cutover. - **Who operates what.** Google operates Cloud Run; Tensor9 operates the invoke path. There is no mapping to operate. ## On Azure | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ---------------- | ------------ | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Batching and batching windows | Delivery | Out of scope | - | - | no batches are formed, because nothing polls a source | | Event filtering | Delivery | Out of scope | - | - | no filter criteria are applied | | Queue and stream sources | Event sources | Out of scope | - | - | SQS, Kinesis, DynamoDB Streams, Amazon MQ, Kafka and DocumentDB sources are not polled on the function's behalf; the producer side is re-wired to invoke the function (see the how-it-works) | | Retries, on-failure destinations and partial-batch responses | Failure handling | Out of scope | - | - | there is no redelivery, no failure destination and no ReportBatchItemFailures handling without a poller | | Operation | Area | Support | Depth | Notes | | ------------------------ | --------------------- | ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CreateEventSourceMapping | Event source mappings | Out of scope | Common | no source is polled on the function's behalf; the call is refused with a typed Lambda error (InvalidParameterValueException naming the operation), so a deployment that declares a mapping stops on that resource with a clear message and nothing is dropped silently | | DeleteEventSourceMapping | Event source mappings | Out of scope | Most usage | there is no mapping to delete | | GetEventSourceMapping | Event source mappings | Out of scope | Common | there is no mapping to describe; refused with the same typed error | | ListEventSourceMappings | Event source mappings | Out of scope | Common | there is no mapping to list; refused with the same typed error | | UpdateEventSourceMapping | Event source mappings | Out of scope | Most usage | there is no mapping to update | #### Event source mappings and trigger bindings On AWS an event source mapping is a Lambda resource of its own: it holds the binding from an SQS queue, a Kinesis or DynamoDB stream, an Amazon MQ broker, a Kafka topic or a DocumentDB change stream to a function, and Lambda runs pollers that read the source and invoke the function with batches, at least once, retrying a failed batch and optionally sending discarded records to a destination. Azure Functions does the same job in a different shape. A queue or stream reaches a function through a trigger binding (Service Bus, Event Hubs, Queue Storage, the Cosmos DB change feed and others), and that binding is declared on the function in its code package; the Functions host polls the source and scales the function per trigger. There is no resource beside the function to create, so a mapping cannot be carried as one. The code package Tensor9 builds for a Lambda function exposes the synchronous HTTP trigger that the routing layer invokes and no other trigger, so a source cannot be bound to it either. A declared mapping is therefore refused: CreateEventSourceMapping answers with a typed Lambda error naming the operation, a deployment that declares the mapping stops on that resource with a clear message, and nothing is dropped silently. #### Limitations * **No source is polled on the function's behalf.** SQS, Kinesis, DynamoDB Streams, Amazon MQ, Kafka and DocumentDB mappings are all refused; the function itself deploys and serves synchronous Invoke exactly as its own card describes. - **Batching, filtering and failure destinations go with the mapping.** Without a poller there is no batch size or window, no filter criteria, no retry of a failed batch, no partial-batch response and no on-failure destination. A producer that invokes the function directly decides those for itself. - **The deployment names the mapping it refused.** The error names the operation and the mapping, so a trigger is never lost silently; the deployment stops until the mapping is removed from it and the producer is re-wired. #### Other considerations * **Re-wiring the asynchronous path.** Two shapes work: the producer calls Invoke directly through the routing layer, synchronously and with the Lambda error contract; or the queue moves with its consumer, so that a consumer of your own reads the queue served on the same appliance and invokes the function. The Lambda card for Azure Functions (Flex Consumption) names the SQS and SNS mappings that move together with the function. - **Nothing migrates.** A mapping holds no data; messages already in the source are drained by whichever consumer reads it after cutover. - **Who operates what.** Microsoft operates Azure Functions; Tensor9 operates the invoke path. There is no mapping to operate. ## Debug this service For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the [BYOC service-adapter debugging runbook](/byoc/service-adapters/debugging/overview) to capture and interpret the diagnostic evidence. [Service Catalog](/byoc/service-adapters/catalog).