Entry
- Amazon API Gateway for APIs
- Amazon CloudFront for web assets
- EventBridge rules and schedules
- S3 event notifications
Serverless Development
AWS serverless application development
Serverless saves you from running servers, but its limits decide your design: timeouts, payload sizes and concurrency. Agnotic Technologies builds applications on AWS serverless services, chooses containers where they fit better, and ships both with infrastructure as code and tracing.
Lambda and Step FunctionsEvent-driven designInfrastructure as codeTracing built in
Trusted by global innovators
Serverless on AWS
What is AWS serverless development?
AWS serverless development is building applications from managed AWS services such as Lambda, API Gateway, Step Functions, EventBridge, SQS and DynamoDB, so you run no servers and pay for what you use. Agnotic Technologies designs serverless applications around the service limits that decide each workload, and ships them with infrastructure as code and tracing.
Serverless is a choice per workload, not per company. Most of the systems we build mix serverless functions with a few container services where a job runs long or traffic stays high all day.
This page covers AWS. On Microsoft Azure the comparable building blocks are Azure Functions and Logic Apps, and on Google Cloud they are Cloud Run functions and Workflows.
Decision table
Which workloads fit serverless, and which fit containers?
We fill this in with your team for each workload before choosing the compute.
| Workload | Serverless or containers | The AWS limit that decides it | Pattern we use |
|---|---|---|---|
| Request and response API with uneven traffic | Serverless | 6 MB synchronous payload limit; large files cannot pass through the function | API Gateway to Lambda, with uploads and downloads through presigned S3 URLs |
| Scheduled job that finishes within minutes | Serverless | 900 second Lambda timeout | EventBridge Scheduler invoking Lambda, with a dead letter queue for failures |
| Event processing from queues and streams | Serverless | Concurrent executions shared per Region | SQS or EventBridge to Lambda with reserved concurrency and batch failure reporting |
| Multi-step process with waits or approvals | Serverless | Standard workflows run up to one year | Step Functions Standard workflow calling Lambda and AWS services directly |
| Batch job that runs longer than 15 minutes | Containers | Lambda timeout | Amazon ECS on AWS Fargate or AWS Batch, started from Step Functions |
| Steady high traffic all day | Often containers | Per-request billing at constant load | Containers behind a load balancer, compared with Lambda on your own usage figures |
| Rarely called endpoint that must answer fast | Serverless | Cold start on new execution environments | Provisioned concurrency on that function only |
When the answer is unclear, we model both options from your traffic and run a short load test before committing.
How it fits together
How does a serverless application on AWS fit together?
The building blocks we combine, from the request coming in to the team watching it run.
Compute
- Lambda functions, one task each
- Fargate tasks for long or heavy jobs
Orchestration
- Step Functions Standard for business processes
- Step Functions Express for short, high-volume flows
Messaging
- SQS queues with dead letter queues
- EventBridge event buses
- SNS for fan-out
Data
- DynamoDB tables designed from access patterns
- Aurora or RDS where data is relational
- S3 for files and exports
Operations
- CloudWatch logs, metrics and alarms
- AWS X-Ray or OpenTelemetry traces
- One IAM role per function
Failure points
Where do serverless applications fail in production?
Problems we design around on every serverless build, and the fix we put in place.
Challenge
Retries process the same event twice, such as charging a card twice.
Agnotic approach
Handlers are idempotent, using an idempotency key stored in DynamoDB before the side effect runs.
Challenge
One busy function uses up the Region's concurrency and others are throttled.
Agnotic approach
Reserved concurrency for critical functions, and queues in front of anything that can wait.
Challenge
Chains of synchronous calls hit timeouts under load.
Agnotic approach
Long or multi-step work moves to queues or Step Functions, so no function waits on another.
Challenge
Users notice slow first requests on rarely used paths.
Agnotic approach
Smaller deployment packages, lazy loading of SDK clients, and provisioned concurrency where latency matters.
Challenge
The bill jumps because of a recursive trigger or chatty logging.
Agnotic approach
Budgets and anomaly alerts, log retention settings and guards against functions triggering themselves.
Challenge
Failed events disappear without anyone noticing.
Agnotic approach
Every asynchronous path has a dead letter queue with an alarm and a replay procedure.
DevOps for serverless
How do we deploy and run serverless applications?
The pipeline and operating practices we set up with every serverless build.
- Infrastructure as code with AWS SAM, AWS CDK or Terraform, one stack per service, reviewed like application code
- Separate AWS accounts for development, staging and production, with the same templates deployed to each
- A pipeline that runs unit tests, deploys to a staging stack and runs integration tests against real AWS services
- Lambda versions and aliases, with traffic shifted to a new version gradually and rolled back on alarm
- Structured logs with a correlation ID that follows a request through every function and queue
- Alarms on errors, throttles, dead letter queue depth and cost, routed to the team that owns the service
What do we build on AWS serverless services?
Typical serverless work, from a new product backend to moving old jobs off servers.
APIs and product backends
REST and GraphQL APIs on API Gateway or AWS AppSync, with Lambda handlers and authorization at the edge.
Event-driven processing
Order, document and webhook processing on SQS and EventBridge, with retries and replay built in.
Workflow orchestration
Step Functions workflows for onboarding, approvals and long business processes, visible step by step.
Scheduled and batch jobs
Nightly jobs moved from cron servers to EventBridge Scheduler, with Fargate for the long ones.
Data and AI pipelines
Ingestion and transformation steps that call model endpoints and store results for your product.
Gradual moves from servers
Endpoints moved one at a time from an existing application to serverless, behind the same API.
Who it is for
Which teams choose serverless on AWS?
Teams whose workloads fit the model, and who want to spend less time running infrastructure.
AWS serverless services for startups
Products with uneven early traffic, where paying per use keeps running costs close to real usage.
Product teams adding event processing
Webhooks, imports and notifications moved out of the main application into queues and functions.
Teams retiring cron servers
Scheduled jobs that run on one server nobody wants to patch.
Integration backends
Glue between SaaS tools, partners and your own systems, triggered by events.
Apps that handle PHI
Serverless builds that use AWS HIPAA eligible services under a business associate addendum, with Agnotic signing a BAA with you.
Frameworks
Frameworks we design serverless applications against
The AWS guidance and open standards behind the patterns on this page.
AWS Well-ArchitectedAWS SAMAWS CDKTerraformOpenTelemetry
Facts and sources
Facts behind serverless design on AWS
Service limits and AWS documentation that shape a serverless design, each linked to its source.
A standard AWS Lambda function can run for up to 900 seconds (15 minutes) per invocation, and synchronous invocations accept up to 6 MB each for the request and the response.
Source: AWS Lambda quotas (AWS documentation)AWS Lambda's default quota for concurrent executions is 1,000 per AWS Region, shared by all functions in the account in that Region unless concurrency is reserved.
Source: AWS Lambda quotas (AWS documentation)AWS Step Functions Standard workflows can run for up to one year with exactly-once execution, while Express workflows run for up to five minutes with at-least-once execution.
Source: Choosing workflow type in Step Functions (AWS documentation)Lambda provisioned concurrency keeps a set number of execution environments pre-initialized, which removes cold start latency for those environments.
Source: Configuring provisioned concurrency (AWS documentation)AWS Lambda, Amazon API Gateway, AWS Step Functions, Amazon EventBridge, Amazon SQS and Amazon DynamoDB are on AWS's list of HIPAA eligible services, which applies to accounts covered by a business associate addendum with AWS.
Source: HIPAA Eligible Services Reference (AWS)
Scope and cost
What drives the cost of AWS serverless development?
Build cost is quoted per project. These factors decide it, and the AWS running cost is a separate estimate.
Number of services and workflows
How many APIs, event flows and Step Functions workflows the first release needs.
Integrations
Third-party APIs, webhooks and internal systems the application exchanges events with.
Data model
Whether DynamoDB access patterns are known, or relational data needs Aurora or RDS.
Existing systems
A new build, or endpoints and jobs moved gradually from a running application.
Compliance scope
Whether PHI or payment data is involved, which narrows services and adds logging and review.
Running cost model
Your AWS bill depends on requests, duration, memory and data transfer; we estimate it from your own traffic figures.
Engagement
How does a serverless engagement work?
From the workload review to a system running in production.
1.
Scoping and workload review
We go through each workload with the decision table, agree serverless or containers, and fix the scope of the first release.
Scope2.
Fixed-scope first release
We build the first services with IaC, the pipeline, tracing and alarms in place from the first deploy.
Build3.
Scale and support
We add workflows and services, tune cost and concurrency from real traffic, and support the system after launch.
ScaleFrequently Asked Questions
When a job runs longer than Lambda's 15 minute limit, when traffic is high and steady all day, or when you need software that expects a long-running process. We compare both on your workload before deciding.
It depends on requests, function duration and memory, data transfer and the other services you use. We do not quote AWS bills from averages; we model them from your traffic and set budgets and alerts from day one.
Most functions never need special treatment. For latency-sensitive paths we keep packages small, initialize clients outside the handler and use provisioned concurrency on those functions only, so you do not pay for it everywhere.
Yes, if you use services on AWS's HIPAA eligible list under a business associate addendum with AWS. We sign a BAA with you before touching PHI and design logging, encryption and access to match.
The one your team will maintain. AWS SAM suits function-heavy services, AWS CDK suits teams who want to write infrastructure in TypeScript or Python, and Terraform suits teams that manage more than AWS.
Usually in parts. We move scheduled jobs and event processing first, then individual endpoints behind the same API, so the running application keeps serving users throughout.
Engineers may use AI assistants for boilerplate such as IaC templates, but every change goes through code review, a staging deploy and integration tests against real AWS services before it reaches production.