Coverage by target cloud
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
On Google Cloud
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
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.