India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
AWS Lambda, Step Functions & EventBridge Serverless Services
AWS Lambda is AWS's serverless compute service that runs code in response to events and bills per millisecond, and it pairs with API Gateway, EventBridge, SQS, SNS and Step Functions to build event-driven applications without servers. NTSPL designs these pipelines for Indian insurers, agri-food firms and public bodies, handling retries, idempotency and orchestration so workloads scale with events.
AWS services in scope
The Problem AWS Lambda and Amazon API Gateway Solve
Serverless projects rarely fail on Lambda itself; they fail on the glue. A claims upload triggers a function that calls three downstream services synchronously, one times out, the event is retried and the customer receives two SMS messages and two claim numbers. A sensor alert queue has no dead-letter queue, so a malformed payload blocks the batch for hours. A 40-step approval is written as Lambda functions calling each other, so nobody can see where an application is stuck. The real engineering problem is reliable integration: retries, idempotency, back-pressure, ordering and visible state.
NTSPL designs the event contract before the code. We decide which interactions are synchronous through API Gateway, which are queued in SQS for back-pressure, which are fanned out through SNS or routed by content in EventBridge, and which are long-running workflows in Step Functions. Every consumer is idempotent using a request key in DynamoDB, every queue has a dead-letter queue and redrive procedure, and concurrency is capped so a spike never overwhelms a downstream database or a partner API.
When to Build on AWS Lambda and Event-Driven Integration (and When Not To)
Signals that point to serverless & integration on AWS
- You run servers that sit idle more than 70% of the time waiting for uploads, webhooks or scheduled jobs.
- Batch jobs on cron servers fail silently and nobody knows until a business user complains.
- Partner or citizen traffic spikes 10x or more around deadlines, campaigns or weather events.
- Business processes such as claims, grievances or approvals are tracked in spreadsheets because the system cannot show case status.
- Point-to-point integrations between systems break whenever one system is slow or down.
- IoT devices or apps generate millions of small events a day that need filtering and alerting.
When a different approach is better
- Long-running, steady compute such as a video transcode farm or a continuously busy API at high utilization is usually cheaper on Amazon ECS on Fargate or EC2 with Savings Plans.
- Workloads needing persistent low-latency connections to a relational database from thousands of concurrent functions need RDS Proxy at minimum, or should run as containers on ECS to control connection pools.
- High-throughput streaming analytics with replay over days fits Amazon Kinesis Data Streams or Amazon MSK better than SQS and Lambda alone.
Serverless Building Blocks: Lambda Functions, API Gateway, EventBridge, SQS, SNS and Step Functions
| Service | Role in the architecture | Choose it when |
|---|---|---|
| AWS Lambda | Runs functions in response to events from more than 200 AWS services and SaaS sources, with memory from 128 MB to 10,240 MB, up to 15 minutes per invocation and billing per millisecond. | Work is triggered by an event, finishes within minutes and arrives irregularly or in bursts. |
| Amazon API Gateway | Publishes REST, HTTP and WebSocket APIs in front of Lambda and other backends, with authorization, throttling, request validation, usage plans and caching. | Clients such as mobile apps, citizen portals or partners call your backend over HTTPS and you need throttling and authentication at the edge. |
| Amazon EventBridge | Routes events between AWS services, SaaS applications and your own services by content-based rules, with schema registry, archive and replay, Pipes and Scheduler. | Several independent consumers need different subsets of business events, or you need scheduled jobs without servers. |
| Amazon SQS | Buffers messages between producers and consumers in standard queues with at-least-once delivery or FIFO queues with ordering and deduplication, with dead-letter queues for failures. | A downstream system must be protected from spikes, or work must survive consumer failures and be retried. |
| Amazon SNS | Publishes messages to many subscribers at once, including SQS queues, Lambda functions, HTTPS endpoints, email and SMS, with message filtering per subscription. | One event must reach several systems or people immediately, such as an alert to operations, a queue and a mobile notification. |
| AWS Step Functions | Orchestrates multi-step workflows as state machines with retries, timeouts, parallel branches, human-approval callbacks and direct integrations with over 200 AWS services. | A business process has more than three or four steps, waits for people or external systems, or must show where each case is at any moment. |
Event-driven serverless backend with queued ingestion and Step Functions orchestration
Event-driven serverless backend with queued ingestion and Step Functions orchestration
Clients call API Gateway, which authenticates the request and hands it to a Lambda function that validates input, writes an idempotency record and publishes an event to EventBridge or a message to SQS. Consumers process work at controlled concurrency, Step Functions orchestrates multi-step cases with retries and human approvals, and SNS notifies people and systems, with failures landing in dead-letter queues for redrive.
Select any component
Event-driven serverless backend with queued ingestion and Step Functions orchestration: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Serverless Engineering Decisions: Sync vs Async, Idempotency, Concurrency and Workflow Type
Synchronous vs asynchronous boundaries
API Gateway integrations time out at 29 seconds by default, and users should not wait for OCR or partner calls anyway. We keep the synchronous path to validation, idempotency check and acknowledgement, returning a reference number in under a second, then move work to SQS or EventBridge. Clients poll a status endpoint or receive a WebSocket or SMS update. Only lookups that complete in a few hundred milliseconds stay fully synchronous.
Choosing SQS, SNS or EventBridge
SQS is for work one consumer must complete, with back-pressure and retries. SNS is for immediate fan-out to many subscribers, particularly people and webhooks. EventBridge is for business events many teams consume selectively, with content filtering, schema registry and replay. A common pattern is EventBridge rules targeting SQS queues per consumer, so routing is central but each consumer keeps its own buffer and DLQ. FIFO queues are used only where ordering per entity truly matters.
Idempotency and retries
Every AWS event source can deliver a message more than once, so every handler must be idempotent. We use Powertools for AWS Lambda idempotency with a DynamoDB table keyed on a business identifier such as claim upload ID or sensor reading ID, and TTL of 24-72 hours. Retries use exponential backoff with jitter; poison messages go to the DLQ after 3-5 attempts, with a CloudWatch alarm and a redrive runbook.
Concurrency and downstream protection
Lambda's default account concurrency quota per Region is shared by all functions, and a burst can starve critical ones or overwhelm a database. We set reserved concurrency for critical functions, maximum concurrency on SQS event sources for consumers that write to RDS or call rate-limited partner APIs, and RDS Proxy for relational access. Provisioned concurrency or SnapStart is applied only where cold starts breach a measured latency target.
Step Functions Standard vs Express
Standard workflows run up to one year, are billed per state transition and keep full execution history, which suits claims, grievances and approvals that wait on people. Express workflows run up to five minutes, are billed by duration and requests and suit high-volume event processing such as per-sensor enrichment. We use direct service integrations instead of Lambda glue where possible, cutting both code and cost.
How NTSPL Delivers an Event-Driven Serverless Backend on AWS
Event storming and contract design
Map the business process into commands, events and states with business owners, and agree JSON schemas and identifiers used for idempotency.
Integration topology
Decide per interaction between API Gateway, SQS, SNS, EventBridge and Step Functions, and define DLQs, retries and concurrency caps before code is written.
Function and workflow build with Powertools
Write handlers with Powertools for logging, tracing and idempotency, and model long processes as Step Functions using direct service integrations.
Load and failure testing
Replay peak event rates, inject downstream failures and malformed payloads, and confirm DLQ capture, alarms and redrive.
Staged go-live
Release behind API Gateway stages or Lambda aliases with weighted traffic shifting through AWS CodeDeploy, rolling back automatically on alarms.
Cost and cold-start tuning
Tune function memory with AWS Lambda Power Tuning, move compatible functions to arm64 and apply SnapStart or provisioned concurrency only where latency targets require.
What you receive
Securing Serverless Applications: Execution Roles, API Authorizers, Event Policies and Secrets
In serverless systems the perimeter is every API, event rule and queue policy. Threats are over-privileged execution roles, unauthenticated or unthrottled APIs, event injection through permissive resource policies and secrets in environment variables. NTSPL gives each function its own least-privilege role, authenticates every API route, validates payloads at API Gateway, restricts who can publish to buses and queues, encrypts queues and topics with KMS and fetches secrets at runtime.
- One IAM execution role per function, scoped to the specific queues, tables and buckets it touches
- API Gateway request validation, throttling and AWS WAF to block malformed and abusive calls
- Resource policies on EventBridge buses, SQS queues and SNS topics limiting producers to named principals
- SSE-KMS encryption on SQS queues and SNS topics carrying personal or claims data
- Secrets Manager or Parameter Store retrieval with caching, instead of plaintext environment variables
Lambda and Integration Pricing Levers: GB-Seconds, Requests, State Transitions and Graviton
Lambda bills per request and per GB-second of duration at the configured memory, with arm64 priced lower than x86; provisioned concurrency adds a charge while enabled. API Gateway bills per million requests, with HTTP APIs cheaper than REST APIs. SQS and SNS bill per request, EventBridge per event published, and Step Functions Standard per state transition. Costs scale with events, so the design target is fewer, larger and cheaper invocations.
- Arm64 (Graviton) Lambda functions for lower price per GB-second
- Memory tuning with Lambda Power Tuning to find the cheapest memory size for each function
- SQS batch sizes and batching windows to reduce invocations
- HTTP APIs instead of REST APIs where usage plans and request transformation are not needed
- Step Functions direct service integrations and Express workflows to cut Lambda calls and state transitions
Amazon EventBridge vs SNS vs SQS: which should we use for messaging on AWS?
Use three criteria. Consumption model: SQS is a queue, where each message is processed by one consumer, with back-pressure and retries, so use it to protect slow systems. SNS is publish-subscribe for immediate fan-out to many subscribers, including people via SMS and email. EventBridge is an event router, filtering business events by content to many targets, with schema registry, archive and replay. Throughput and latency: SNS and SQS handle very high throughput with low latency; EventBridge adds rich routing at somewhat higher latency. Coupling: EventBridge best decouples teams because producers do not know consumers. Most production designs combine them: EventBridge for routing, SQS per consumer for buffering, SNS for notifications.
Key facts about serverless & integration on AWS
Serverless & Integration on AWS in Practice
3 serverless & integration scenarios from General insurance (motor claims), Agri and food cold chain (dairy, frozen foods and fresh produce), Public sector (state-level citizen grievance redressal): the starting position, the services chosen, the architecture, the rollout and the measured outcome.
General insurer cuts motor-claim intake from 2 days to 25 minutes with serverless
Cold-chain operator cuts temperature-excursion response from hours to 4 minutes
State grievance portal handles 8x deadline-day traffic and tracks every case end-to-end
Online exam platform holds 2.2 lakh concurrent candidates with predictive scaling
Regional-language OTT service halves video start time and cuts origin egress by 82%
Hotel booking engine ends overbooking with DynamoDB conditional writes on room inventory
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Serverless & Integration on AWS: Frequently Asked Questions
How is AWS Lambda priced?
Lambda charges per request and per GB-second of compute, calculated from the memory you configure and the execution time rounded to the millisecond. Arm64 functions cost less per GB-second than x86. There is a monthly free tier for requests and compute. Provisioned concurrency, if enabled, adds an hourly charge whether or not it is used.
Are Lambda cold starts a problem for user-facing APIs?
For most APIs, no. Cold starts typically add a few hundred milliseconds for Node.js or Python and can be longer for Java and .NET without optimization. They affect a small share of requests. Where a strict latency target applies, Lambda SnapStart for supported runtimes or provisioned concurrency remove most cold-start delay. We measure before paying for either.
How do we move cron jobs and batch scripts from on-premises servers to serverless?
Jobs under 15 minutes usually move to Lambda triggered by EventBridge Scheduler, with retries and DLQs. Longer jobs are split into steps in Step Functions or run as ECS tasks on Fargate launched by the scheduler. We first inventory cron entries, their inputs, outputs and failure handling, which are often undocumented.
Can a public sector body or insurer in India host serverless workloads in-country?
Yes. Lambda, API Gateway, EventBridge, SQS, SNS and Step Functions are available in Asia Pacific (Mumbai), and most are in Asia Pacific (Hyderabad), so data can be processed within India. This supports DPDP Act 2023 obligations and IRDAI expectations for insurers. Government bodies should also check MeitY empanelment requirements for their cloud service provider and integrator.
What happens if a Lambda function keeps failing on a message?
With SQS as the source, the message returns to the queue after the visibility timeout and is retried until it reaches the configured maximum receive count, then moves to a dead-letter queue. NTSPL alarms on DLQ depth, records the error with the correlation ID and provides a redrive procedure so messages are reprocessed once the bug or downstream issue is fixed.
When should we use Step Functions instead of chaining Lambda functions?
Use Step Functions whenever a process has more than a few steps, needs retries with different rules per step, waits for people or external systems, or must show where each case is. Chaining functions hides state in logs and doubles cost because functions wait on each other. Step Functions also integrates directly with many AWS services without any Lambda code.