.png)
AWS Lambda Integration Guide
Connect AWS Lambda with enterprise systems through its HTTPS APIs, Function URLs, API Gateway integrations, event sources, queues, and AWS-authenticated workflows.
AWS Lambda integration options at a glance
AWS Lambda supports HTTPS service APIs for managing and invoking functions, including synchronous, asynchronous, and dry-run invocation. Functions can also be reached through Function URLs or Amazon API Gateway. Event source mappings connect Lambda with Amazon SQS, Kinesis, DynamoDB Streams, Kafka, and Amazon MQ, while AWS services such as S3, EventBridge, SNS, and CloudWatch can provide event-driven invocation. Lambda uses IAM authorization and AWS Signature Version 4 for direct API calls. Martini can orchestrate these calls, expose APIs for Lambda, transform JSON payloads, and coordinate retries, queues, files, and downstream enterprise systems.
| Integration point | Supported by AWS Lambda? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | The AWS Lambda service API uses HTTPS and JSON for invoking functions and managing functions, versions, aliases, permissions, event source mappings, and configuration. Function URLs and API Gateway can also provide HTTP invocation paths. | Martini can consume the Lambda API or a Lambda-backed API endpoint, map JSON payloads, orchestrate calls, and expose a REST API for Lambda callers. |
| Webhooks and outbound callbacks | Limited | Function URLs and API Gateway accept inbound HTTPS requests, while asynchronous destinations can send selected success or failure records to EventBridge, SNS, SQS, or another Lambda function. Lambda does not provide a universal webhook subscription model. | Martini can expose a secured REST or webhook-style API for Lambda and can consume HTTP endpoints where an AWS service provides the required delivery path. |
| Events and event source mappings | Yes | Lambda can be invoked by S3, EventBridge, SNS, CloudWatch, API Gateway, Cognito, SQS, Kinesis, DynamoDB Streams, Kafka, and Amazon MQ, subject to source-specific configuration and delivery semantics. | Martini workflows can orchestrate event-driven processing, normalize source-specific envelopes, apply business rules, and route results to enterprise systems. |
| Bulk, asynchronous, and batch processing | Limited | Lambda supports asynchronous invocation and batch processing through event source mappings, but it is not a general bulk CRUD API. | Martini can submit asynchronous work, coordinate batches, preserve correlation identifiers, and implement bounded retries and failure routing. |
| File and object processing | Limited | Lambda can process Amazon S3 object events and use AWS SDK operations to read or write objects. Lambda itself is not a file-transfer or attachment-storage service. | Martini can orchestrate object references, transform file-related payloads, and coordinate S3-backed processing with downstream applications. |
| Database and stream access | Limited | Lambda can connect to databases and consume change streams such as DynamoDB Streams, but it does not provide a general database or analytics query API. | Martini can coordinate Lambda with database or stream endpoints, map change events, and persist normalized results using workflows and database capabilities. |
| Authentication | Yes | Direct AWS Lambda API requests use IAM authorization and AWS Signature Version 4. Temporary STS credentials, execution roles, resource-based policies, and Function URL authentication are also available. | Martini can store credentials in secure configuration, call authenticated endpoints, and use custom JVM-compatible logic where direct SigV4 signing is required. |
| SDKs and command-line tools | Yes | AWS SDKs and the AWS CLI support Lambda invocation and resource administration across multiple programming languages and deployment environments. | Martini can use HTTPS APIs directly and extend workflows with custom JVM-compatible logic when SDK-like behavior or signing flexibility is needed. |
How AWS Lambda exposes data and business events
AWS Lambda REST APIs
AWS Lambda provides an HTTPS service API with JSON requests and responses for invoking functions and administering functions, versions, aliases, permissions, event source mappings, and configuration. Direct service API requests use AWS Signature Version 4 and IAM authorization.
Martini implementation pattern
Martini consumes the Lambda API from a workflow or reusable API implementation. The workflow prepares the AWS request, applies the required authentication approach, handles pagination or asynchronous responses, maps the result, and records AWS and Martini correlation data.
Implementation sequence
Function URLs and API Gateway
Function URLs and Amazon API Gateway provide HTTPS invocation paths for Lambda functions. API Gateway can add routing, authorization, throttling, and transformation controls, while Function URLs provide direct function access with AWS_IAM or unauthenticated modes.
Martini implementation pattern
Martini can call a Lambda-backed HTTP endpoint when the goal is function execution rather than resource administration. It can also expose a Martini REST API that Lambda or API Gateway calls, allowing Martini to validate input and orchestrate downstream systems.
Implementation sequence
Event Source Mappings
Lambda event source mappings poll or consume selected sources such as Amazon SQS, Kinesis, DynamoDB Streams, Kafka, and Amazon MQ. Batch size, retry, checkpoint, ordering, and failure behavior depend on the source.
Martini implementation pattern
Martini coordinates the surrounding event workflow rather than assuming a universal Lambda event model. It normalizes source-specific envelopes, applies idempotency and business rules, and writes results to enterprise targets or queues.
Implementation sequence
AWS Service Events
AWS services including Amazon S3, EventBridge, SNS, CloudWatch, API Gateway, and Amazon Cognito can invoke Lambda through service-specific integrations. Event availability and delivery semantics vary by source.
Martini implementation pattern
Martini can consume a Lambda callback or an endpoint exposed through API Gateway, or coordinate an AWS event flow through an available AWS service endpoint. The workflow isolates AWS event formats from downstream canonical data models.
Implementation sequence
Asynchronous Invocation and Destinations
Asynchronous Lambda invocation queues events for processing and can retry according to configuration. Event invoke configurations can route successful or failed invocation records to EventBridge, SNS, SQS, or another Lambda function.
Martini implementation pattern
Martini submits or receives asynchronous work and treats acknowledgement separately from business completion. It tracks correlation identifiers, consumes completion or failure information where available, and applies bounded retries without assuming exactly-once delivery.
Implementation sequence
Common AWS Lambda integration patterns
Pattern 1: Invoke a Lambda-backed API
When to use this pattern
Use this pattern when an enterprise application needs Lambda business logic behind a stable HTTP contract. Martini can validate the request, enrich it with enterprise data, call API Gateway or a Function URL, and return a normalized response while separating endpoint errors from function errors.
Integration direction
Example Mapping
| AWS Lambda Field | Canonical Field | Target Field |
|---|---|---|
| requestId | correlationId | requestId |
| customerReference | customerId | customerId |
| operation | businessOperation | action |
| payload | businessData | event |
Martini implementation pattern
A Martini API or workflow receives the request, validates required fields, maps the payload to the Lambda-backed contract, calls API Gateway or a Function URL, and transforms the response. The workflow applies timeout and retry rules, logs the AWS request identifier, and returns a controlled error model.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Orchestrate asynchronous Lambda processing
When to use this pattern
Use this pattern for long-running or decoupled work where the caller should receive an acknowledgement before Lambda completes. Martini can submit work, track correlation data, and process a completion or failure destination without treating the initial acknowledgement as business success.
Integration direction
Example Mapping
| AWS Lambda Field | Canonical Field | Target Field |
|---|---|---|
| InvocationType | executionMode | processingMode |
| requestId | correlationId | correlationId |
| functionError | processingStatus | status |
| payload | workItem | requestBody |
Martini implementation pattern
The workflow creates an idempotency key, invokes Lambda asynchronously or submits work through an AWS queue, stores the correlation state, and handles destination records or downstream callbacks. Bounded retries, duplicate checks, and explicit failure routing prevent repeated business effects.
Martini capabilities used
- workflows
- API consumption
- queues
- data mapping
- business rules
- error handling
Pattern 3: Process S3 objects through Lambda
When to use this pattern
Use this pattern when files are uploaded to Amazon S3 and Lambda performs transformation or validation. Large content remains in object storage while Martini coordinates metadata, downstream delivery, and processing outcomes.
Integration direction
Example Mapping
| AWS Lambda Field | Canonical Field | Target Field |
|---|---|---|
| bucket | objectStore | sourceBucket |
| key | objectPath | sourceObject |
| size | contentSize | fileSize |
| eventTime | receivedAt | ingestionTimestamp |
Martini implementation pattern
Martini receives an object reference or Lambda result, validates the bucket and key metadata, retrieves or passes the object by reference, maps extracted data to the target model, and writes the result. It records object identity and processing status so retries do not duplicate downstream files or records.
Martini capabilities used
- workflows
- API consumption
- file handling
- data mapping
- business rules
- error handling
Pattern 4: Synchronize Lambda events with enterprise applications
When to use this pattern
Use this pattern when AWS-native events must update systems such as Salesforce or ServiceNow. Because Lambda event delivery is source-specific, Martini first normalizes the event envelope and then applies routing, enrichment, and target-specific mapping.
Integration direction
Example Mapping
| AWS Lambda Field | Canonical Field | Target Field |
|---|---|---|
| functionName | sourceComponent | integrationSource |
| requestId | correlationId | externalReference |
| detail | businessPayload | requestBody |
| version | sourceVersion | sourceRevision |
Martini implementation pattern
Lambda calls a Martini API or sends a result through an AWS-supported endpoint. Martini validates the source, deduplicates using the request or business identifier, enriches the payload where required, and routes it to Salesforce, ServiceNow, or another target. Failed writes are retried or placed into an operational failure path.
Martini capabilities used
- APIs
- workflows
- data mapping
- business rules
- API security
- error handling
Applications commonly integrated with AWS Lambda
AWS Lambda is frequently used with AWS-native services and can also participate in enterprise integrations through APIs, events, queues, and intermediary services. Martini can coordinate these relationships without requiring a dedicated AWS Lambda connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Amazon API Gateway | Expose Lambda functions through managed HTTP APIs with routing, authorization, throttling, and a stable contract for enterprise callers. | Martini → Amazon API Gateway → AWS Lambda | Martini receives or exposes the enterprise API request, validates and maps the payload, calls the API Gateway endpoint, and normalizes the Lambda response. Workflow error handling distinguishes gateway, Lambda, and business errors. |
| Amazon S3 | Process uploaded objects, transform files, and pass large payloads by object reference instead of embedding them in Lambda requests. | Amazon S3 → AWS Lambda → Martini | A Martini workflow receives an object event or object reference, retrieves or writes the S3 object through an available AWS endpoint, maps the file or event payload, and routes processing failures for retry. |
| Amazon SQS | Decouple workloads, absorb bursts, and support asynchronous Lambda processing with queue-based retries and failure handling. | Amazon SQS → AWS Lambda → Martini | Martini publishes or consumes queue work through AWS-supported endpoints, adds correlation and idempotency identifiers, and coordinates Lambda processing with downstream writes and explicit retry or dead-letter handling. |
| Amazon DynamoDB | Run business logic from table changes through DynamoDB Streams or invoke Lambda-backed processing that reads and writes DynamoDB data. | Amazon DynamoDB → AWS Lambda → Martini | Martini receives a normalized event or calls an API-backed function, maps DynamoDB attributes to a canonical model, applies business rules, and persists downstream results while accounting for stream replay and duplicate delivery. |
| Amazon EventBridge | Route scheduled or business events to Lambda and coordinate event-driven processing with other enterprise workflows. | Amazon EventBridge → AWS Lambda → Martini | Martini can expose an API for Lambda results or consume an EventBridge-integrated endpoint where available, then validate event envelopes, map detail payloads, and route events to target applications. |
| Amazon SNS | Fan out notifications and event messages to Lambda and other consumers. | Amazon SNS → AWS Lambda → Martini | Martini processes normalized notification payloads from an AWS-supported endpoint, records message and correlation identifiers, applies filtering rules, and handles duplicate or failed downstream delivery. |
| Salesforce | Use serverless processing to transform Salesforce API or event data before updating enterprise applications or completing asynchronous work. | Salesforce → AWS Lambda → Martini | A Lambda function or API Gateway endpoint handles AWS-side processing while Martini consumes the resulting API contract, maps Salesforce-oriented fields to a canonical model, and orchestrates downstream updates. |
| ServiceNow | Support serverless processing for incidents, requests, or catalog workflows while Martini coordinates enterprise workflow and system-of-record updates. | ServiceNow → AWS Lambda → Martini | Martini receives a callback or invokes an API Gateway or Function URL endpoint, validates the event, applies routing rules, and synchronizes the resulting status or business data with ServiceNow. |
How to build a AWS Lambda integration in Martini
Objective
Establish the AWS and Martini endpoints required for invocation, callbacks, or event coordination, selecting the simplest endpoint that matches the integration objective.
Instructions in Martini
- Choose the Lambda service API, Function URL, API Gateway endpoint, or adjacent AWS service endpoint.
- Configure IAM, SigV4, temporary credentials, resource policies, or endpoint authentication as applicable.
- Store credentials, signing material, and endpoint configuration in secure environment settings.
Objective
Select a synchronous, asynchronous, scheduled, event-driven, or API-led trigger based on the required latency and delivery semantics.
Instructions in Martini
- Use an API or webhook-style trigger for request-driven processing.
- Use queue, stream, S3, EventBridge, or destination-based processing for asynchronous work.
- Use a scheduler for controlled polling or operational synchronization where no event path is available.
Objective
Obtain the Lambda request, response, event envelope, object reference, or asynchronous status record while preserving source metadata.
Instructions in Martini
- Capture function name, version or alias, AWS request identifier, event source, and correlation identifier.
- Follow pagination tokens when retrieving Lambda resources.
- Treat acknowledgements separately from eventual business completion.
Objective
Coordinate Lambda with validation, enrichment, downstream API calls, queues, files, databases, and operational state.
Instructions in Martini
- Create a Martini workflow that branches for synchronous success, asynchronous acknowledgement, function failure, and transport failure.
- Use bounded parallelism and queue-based decoupling when Lambda or downstream capacity is constrained.
- Keep source-specific AWS event formats separate from canonical enterprise models.
Objective
Convert AWS Lambda request, response, or event data into the canonical and target-specific structures required by the enterprise process.
Instructions in Martini
- Map JSON event envelopes and Lambda responses to canonical fields.
- Pass large file content by S3 object reference where practical.
- Normalize timestamps, identifiers, status values, and error structures before writing to targets.
Objective
Enforce validation, authorization context, idempotency, routing, and business decisions before producing downstream effects.
Instructions in Martini
- Validate required fields and expected event sources.
- Use request or business identifiers to prevent duplicate processing.
- Distinguish Lambda service errors, function errors, validation failures, and downstream business errors.
Common AWS Lambda data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Functions | Deployable units of code that process events or direct requests. | Amazon API Gateway, Amazon S3, Amazon SQS, EventBridge, Salesforce, ServiceNow | Martini invokes functions through the Lambda API, Function URLs, or API Gateway, maps request and response payloads, and records function and correlation metadata. |
| Versions | Immutable published function revisions used for stable deployments and controlled invocation. | Deployment workflows, API Gateway integrations, operational platforms | Martini can retrieve, publish, or reference versions through the Lambda API when SigV4 and IAM permissions are configured. |
| Aliases | Named pointers to function versions for environments or deployment stages. | API Gateway, release workflows, environment management systems | Martini can orchestrate alias lookup or update operations and use aliases to avoid coupling integrations to $LATEST. |
| Event Source Mappings | Configuration resources that connect Lambda to SQS, Kinesis, DynamoDB Streams, Kafka, and Amazon MQ. | Amazon SQS, Amazon Kinesis, Amazon DynamoDB Streams, Kafka, Amazon MQ | Martini can manage or observe mappings through the Lambda API and coordinate source-specific batching, checkpointing, retries, and downstream processing. |
| Event Invoke Configurations | Settings for asynchronous invocation retries and success or failure destinations. | Amazon EventBridge, Amazon SNS, Amazon SQS, AWS Lambda | Martini can account for asynchronous outcomes, consume destination records through available endpoints, and route failures using correlation and idempotency controls. |
| Function URLs | HTTPS endpoints that invoke Lambda functions directly. | Enterprise applications, Martini APIs, external web clients | Martini can call secured Function URLs or expose a REST endpoint that a Lambda function calls, with validation, mapping, and error handling in the workflow. |
Authentication and security considerations
AWS authentication
Direct AWS Lambda service API requests use IAM authorization and AWS Signature Version 4 rather than OAuth as the primary service-to-service method. Temporary credentials through AWS STS and least-privilege IAM roles are preferred over long-lived access keys.
Invocation permissions
Separate caller permissions, Lambda execution roles, and resource-based policies control who can invoke functions and what functions can access. Cross-account invocation requires compatible permissions on both sides.
HTTP endpoints
Function URLs support AWS_IAM or unauthenticated access. API Gateway can add its own authentication and authorization controls. Martini should protect exposed APIs with configured authentication, authorization, secrets, and environment-specific policies.
Operational considerations for AWS Lambda integrations
Throughput and retries
Account concurrency, reserved or provisioned concurrency, downstream capacity, API throttling, and source-specific retry behavior affect throughput. Use bounded concurrency, exponential backoff, retry limits, and explicit failure handling.
Payloads and batching
Invocation limits, timeouts, batch sizes, and response limits vary by invocation type and event source. Store large files in Amazon S3 and pass object references instead of embedding large content in invocation payloads.
Idempotency and ordering
Queue redelivery, stream replay, asynchronous retries, and event processing can produce duplicates. Use durable identifiers and idempotent writes, and do not assume global ordering across AWS event sources.
Versions and observability
Use published versions and aliases for stable deployment targets rather than coupling integrations to $LATEST. Capture AWS request IDs, Lambda request IDs, function versions, source metadata, and Martini workflow correlation IDs for troubleshooting.
Pagination and schema changes
Lambda management APIs can return continuation tokens for functions, versions, aliases, layers, and mappings. Follow all pages and validate source-specific event schemas while tolerating appropriate additive changes.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate beyond invocation
Martini coordinates Lambda with APIs, queues, files, databases, and enterprise applications instead of limiting the integration to a single function call.
Centralize transformation and rules
Workflows provide a maintainable place to validate AWS event envelopes, map JSON payloads, enrich data, apply business rules, and normalize function and transport errors.
Support operational reliability
Martini can implement correlation, idempotency, bounded retries, failure routing, logging, and environment-specific configuration around Lambda's source-dependent delivery semantics.
Reduce point-to-point coupling
An API façade or reusable workflow can shield consuming applications from Lambda aliases, versions, payload formats, and implementation changes while preserving controlled access to AWS services.
Frequently asked questions
AWS Lambda can be integrated through its HTTPS service API, synchronous or asynchronous invocation, Function URLs, Amazon API Gateway, event source mappings, and service-specific events from systems such as S3, EventBridge, SNS, SQS, and DynamoDB Streams. Enterprise workflows can call Lambda, receive Lambda callbacks, or coordinate Lambda with queues, files, databases, and downstream applications.
Yes. Martini can consume the AWS Lambda HTTPS API, call a Lambda Function URL or API Gateway endpoint, expose a REST API for Lambda to call, and coordinate related AWS services such as S3 and SQS. Direct Lambda API calls require AWS-compatible SigV4 authentication and appropriate IAM permissions.
No. A dedicated AWS Lambda connector is not required. Martini can use Lambda's native HTTPS APIs, Function URLs, API Gateway endpoints, event-related endpoints, queues, files, and AWS authentication mechanisms, with custom JVM-compatible logic available when direct SigV4 signing requires additional flexibility.
Lonti does not charge an additional per-connector or per-vendor fee to integrate AWS Lambda. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from AWS, infrastructure providers, or other third-party systems based on subscriptions, execution, storage, traffic, and deployment choices.
Use the Lambda service API for direct invocation or resource administration when IAM and SigV4 signing are appropriate. Use API Gateway or a Function URL for a stable HTTPS invocation contract. Use event source mappings, S3, EventBridge, SNS, or SQS when the process is event-driven or asynchronous.
No. Lambda does not provide a universal webhook subscription model. Function URLs and API Gateway support inbound HTTPS invocation, while AWS services provide source-specific events and asynchronous destinations provide selected success or failure records. Delivery, ordering, and retry behavior depend on the source.
Synchronization should preserve correlation identifiers, function versions or aliases, source checkpoints, and business identifiers. Because retries, queue redelivery, stream replay, and asynchronous processing can produce duplicates, Martini workflows should use idempotency keys, durable processing state, bounded retries, and explicit failure routing.
Yes. Martini can expose a REST API that validates and transforms enterprise requests, invokes a Lambda-backed endpoint or the Lambda service API, and returns a controlled response. This can provide a stable contract, centralized authorization and error handling, and an abstraction from function versions or implementation changes.
Related Martini documentation
Transformation
Connect AWS Lambda with your enterprise systems
Use Martini to orchestrate AWS Lambda APIs, HTTPS endpoints, events, queues, files, and downstream enterprise workflows in a maintainable integration architecture.