Serverless Functions for Your Website: AWS Lambda

Contact Form Processing with AWS Lambda

Contact form on a React site with 2000+ submissions per day started failing: response came after 30 seconds, emails were lost. The old monolithic EC2 instance couldn't handle the spikes. We replaced it with AWS Lambda — response time dropped to 300 ms, cost per form submission — fractions of a cent. Serverless architecture eliminates server management: you focus on the code, and AWS scales the load. However, cold start and database operations require careful design. We'll cover typical scenarios, show code, and provide ready-made solutions. To evaluate your project, contact our certified AWS engineers with 12+ years of experience and 80+ serverless projects delivered.

Lambda vs EC2: When to Use Which

Lambda is efficient for asynchronous and episodic tasks. Here's a comparison with a classic EC2 server:

Suitable for: contact form processing, on-demand PDF/image generation, webhooks from payment systems and CRM, image resizing on upload, task schedulers (cron via EventBridge), API proxies for third-party services.

Not suitable for: long-lived connections (WebSocket requires a separate service), tasks exceeding 15 minutes, high-frequency DB operations without connection pooling. In such cases, Lambda becomes not only more expensive but also slower: at 5000 req/s, EC2 with autoscaling costs less than Provisioned Concurrency.

Why Lambda Is More Cost-Effective

From a cost perspective, Lambda wins under uneven load. On EC2, you pay for a running server 24/7, even if it processes requests once per hour. Lambda charges per invocation — savings on idle time can reach 90%. The official AWS documentation gives an example: a site with 10,000 requests per day on EC2 t3.micro costs ~$8/month, while Lambda costs $0.05 for the same workload — a 99% reduction. Additionally, you avoid configuring autoscaling, patching the OS, and monitoring. Our clients save up to 70% on infrastructure by moving to Lambda.

How Lambda Processes a Form: Code Example

A contact form on a React site sends a POST request to API Gateway, which triggers a Lambda function. The function validates data with Zod and sends an email via SES. Code:

import { APIGatewayProxyHandler } from "aws-lambda";
import { SESClient, SendEmailCommand } from "@aws-sdk/client-ses";
import { z } from "zod";

const ses = new SESClient({ region: "eu-west-1" });

const ContactSchema = z.object({
  name: z.string().min(2).max(100),
  email: z.string().email(),
  message: z.string().min(10).max(2000),
});

export const handler: APIGatewayProxyHandler = async (event) => {
  const headers = {
    "Access-Control-Allow-Origin": "https://www.example.org",
    "Content-Type": "application/json",
  };

  try {
    const body = JSON.parse(event.body || "{}");
    const data = ContactSchema.parse(body);

    await ses.send(new SendEmailCommand({
      Source: "[email protected]",
      Destination: { ToAddresses: ["[email protected]"] },
      Message: {
        Subject: { Data: `New message from ${data.name}` },
        Body: {
          Text: { Data: `From: ${data.name} <${data.email}>\n\n${data.message}` }
        }
      }
    }));

    return { statusCode: 200, headers, body: JSON.stringify({ ok: true }) };

  } catch (error) {
    if (error instanceof z.ZodError) {
      return { statusCode: 400, headers, body: JSON.stringify({ errors: error.errors }) };
    }
    console.error(error);
    return { statusCode: 500, headers, body: JSON.stringify({ error: "Internal error" }) };
  }
};

Optimizing Lambda Performance

How to Reduce Cold Start?

Cold start is the initialization latency after a long idle period. On Node.js 20 it's 200–500 ms, on Python 100–300 ms. If sub-second response time is critical, use one of these methods:

Example of initializing clients outside the handler (executed once):

const dbClient = new DynamoDBClient({ region: "eu-west-1" });
const sesClient = new SESClient({ region: "eu-west-1" });

export const handler = async (event) => {
  // handler uses already initialized clients
};

Common Developer Mistakes

• Overly large bundle: including all dependencies without tree-shaking increases cold start by 200–500 ms.
• Creating clients inside the handler: each invocation creates a new DB connection — leads to N+1 problem.
• Ignoring timeout limits: if the function runs longer than timeout (max 15 min), it fails.
• Lack of error handling: uncaught exceptions lead to retries and additional costs.

How to Connect Lambda to a Database?

Standard TCP connection to PostgreSQL/MySQL in Lambda creates a new connection per invocation — at 1000 RPS, the database chokes. Solutions:

For a high number of concurrent invocations, RDS Proxy can become a bottleneck — in such cases, migrate to DynamoDB or shard the database.

Deployment and Monitoring

Development and Deployment Process

1. Design: define triggers, IAM roles, timeouts, and memory.
2. Development: write the function in TypeScript with validation and error handling.
3. Local testing: run with SAM CLI or Docker with API Gateway emulation.
4. Build: use esbuild for bundling (tree-shaking, minification).
5. Deploy: via AWS SAM (template.yaml) — first sam deploy --guided, then sam deploy.
6. Monitoring: set up CloudWatch dashboards, alerts for errors and execution time.

We use AWS Serverless Application Model (SAM) documentation for infrastructure as code. Example template.yaml:

AWSTemplateFormatVersion: "2010-10-09"
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Runtime: nodejs20.x
    Timeout: 10
    MemorySize: 256
    Environment:
      Variables:
        NODE_ENV: production

Resources:
  ContactFormFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: dist/handlers/contact-form.handler
      Events:
        Api:
          Type: HttpApi
          Properties:
            Path: /contact
            Method: POST
      Policies:
        - SESCrudPolicy:
            IdentityName: example.org

Commands:

npm run build
sam build
sam deploy --guided
sam deploy

Logging and Tracing

AWS Lambda Powertools is the official library for structured logging, tracing via X-Ray, and metrics via CloudWatch EMF.

import { Logger } from "@aws-lambda-powertools/logger";
import { Tracer } from "@aws-lambda-powertools/tracer";

const logger = new Logger({ serviceName: "contact-form" });
const tracer = new Tracer({ serviceName: "contact-form" });

export const handler = tracer.captureLambdaHandler(async (event) => {
  logger.addContext(context);
  logger.info("Processing contact form", { email: event.body?.email });
  // ...
});

Our Services

What's Included in Our Work

• Architectural design: choose triggers, balance cold start
• Develop functions in TypeScript with validation and error handling
• Set up CI/CD via GitHub Actions: build, tests, deploy
• API documentation and infrastructure description
• Monitoring: CloudWatch dashboards, alerts for errors and execution time
• Team training: code review, maintenance guide

Timeline

A single Lambda function with SAM deployment — 1–2 days. A set of 5–7 functions with CI/CD and monitoring — 5–7 days. Our engineers have 12+ years of AWS experience and have delivered 80+ serverless projects. Exact timelines depend on integrations. Get a consultation on the solution architecture — we'll prepare a detailed turnkey proposal.

Why Serverless Development? The Real Economics and Technical Trade-offs

Serverless does not mean "without servers". Servers exist—you just don't manage them. It's more accurate to think of it as "without server management": no OS patching, no nginx configuration, no disk space monitoring. The function receives an event, processes it, and returns a response. The provider decides where to run it. Мы занимаемся serverless-архитектурой более 5 лет и реализовали 30+ проектов на AWS Lambda, Vercel Functions и Cloudflare Workers. Гарантируем, что ваша система масштабируется без переплат — при условии правильного выбора платформы и оптимизации холодного старта.

Cold start — Lambda's main pain point on Node.js. In VPC, cold start reached 10 seconds before recent improvements. For production functions with latency requirements: Provisioned Concurrency (keeps instances warm), SnapStart for Java, minimize bundle via tree-shaking. Our typical optimization reduces cold start from 3.2s to 400ms.

Practical case: an image processing function (resize, WebP conversion, upload to S3). Bundle with sharp was 40MB due to native binaries. Solution: Lambda Layer with sharp, main function 800KB. Cold start dropped from 3.2s to 400ms. Lambda Layers — shared dependencies between functions. Up to 5 layers per function, each up to 250MB. Standard practice: layer with heavy dependencies (sharp, puppeteer, ffmpeg), layer with common business logic. Infrastructure for Lambda via AWS CDK or Terraform. SAM — for beginners, CDK — for serious projects with type safety.

Edge Runtime is fundamentally different: the function runs on a V8 isolate in the nearest Vercel CDN point (120+ regions). No cold start as such — the isolate starts in ~0ms. But strict limitations: no Node.js API (fs, crypto via Web API), no database access via TCP (only via HTTP API), bundle size up to 4MB. Edge Runtime is ideal for: middleware (auth check, redirect, A/B test), response transformations, geolocation logic, Edge Config. Not suitable for: accessing PostgreSQL, heavy computations, file system operations.

Cloudflare Workers run on V8 isolates in 300+ points of presence. Latency for the user is literally the nearest data center. Cold start < 1ms. Workers Durable Objects solve the state problem at the edge: each Durable Object is a single coordination point, running in one region. Ideal for: game rooms, real-time documents, rate limiting without races. Workers KV — eventually consistent storage. Writes propagate to all regions in ~60 seconds. Not suitable for financial transactions, suitable for configs, feature flags, cache. D1 — SQLite on the edge. Works great on a single read replica, write latency depends on distance to primary region. Not ideal for global write-heavy applications.

Ecosystem: Hono.js — a minimalist router that works on Workers, Deno, Bun, Node.js. Good choice if you need unified code for edge and server.

Vendor lock-in — a real problem. Lambda-specific code (handler signature, Lambda context) is hard to port. Hono.js, Remix, or adapters like @hono/node-server help keep logic portable. Мы проектируем абстракции, позволяющие сменить провайдера с минимальными изменениями.

How We Optimize Cold Start in AWS Lambda?

Cold start is Lambda's worst enemy. Here’s a step‑by‑step optimisation checklist we apply:

1. Minimise bundle size — tree‑shake dependencies, use Lambda Layers for native binaries (sharp, puppeteer). Target < 1MB.
2. Enable Provisioned Concurrency for latency‑critical functions — costs extra but cuts cold start to near zero.
3. Use SnapStart for Java (Lambda) — reduces init time by 90%+.
4. Avoid VPC unless necessary — if you need VPC, use AWS PrivateLink or Elastic Network Interface optimisation.
5. Warm‑up strategies — scheduler pinging function every 5 minutes (but only for low‑volume functions, otherwise Provisioned Concurrency cheaper).

Result: our clients typically see cold start drop from 2–4s to under 500ms. For a fintech API handling 50k requests/day, that means 3 fewer seconds of latency per request during peak scale.

When Does Serverless Not Fit? Cost Comparison

Serverless saves money when traffic is unpredictable or sparse — up to 70% reduction compared to dedicated servers. But it becomes expensive under constant high load. Example: a function processing 1 million requests/day at 300ms each costs about $100–200/month on Lambda. Equivalent EC2 instance might cost $50/month. For such steady workloads, Fargate or EC2 is cheaper.

Long computations (>15 min on Lambda, >30s on Vercel) require Fargate or a regular server. WebSocket server with state — no persistent process. Tasks with frequent disk access — ephemeral storage, /tmp on Lambda 512MB–10GB.

What’s Included in Serverless Development Service?

Мы предлагаем serverless-разработку под ключ. В каждый проект входит:

• Архитектурная документация (схема event‑driven потоков, выбор платформы, justification).
• Реализация функций с unit‑ и integration‑тестами.
• CI/CD pipeline (GitHub Actions / GitLab CI) с preview‑деплоями.
• Infrastructure as Code (Terraform / AWS CDK / Pulumi).
• Мониторинг и observability (OpenTelemetry, structured logging, distributed tracing).
• 30‑дневная пост‑релизная поддержка и оптимизация производительности.

Typical Mistakes in Serverless Development and How We Avoid Them

• Ignoring cold start — we measure and budget for it from day one.
• Over‑engineering state — many teams try to use Workers Durable Objects for simple caching; KV is often enough.
• No distributed tracing — without trace IDs across SQS › Lambda › DynamoDB streams, debugging is blind. We integrate AWS X‑Ray or OpenTelemetry automatically.
• Underestimating cost at scale — we simulate load patterns and compare serverless vs. container costs before committing.

Закажите serverless архитектуру под ключ — свяжитесь с нами для бесплатной оценки вашего проекта. Сроки: от 2 недель для MVP, до 10 недель для миграции монолита. Стоимость рассчитывается индивидуально, ориентировочно от $2,000 до $15,000 в зависимости от сложности.