Разработка Serverless Functions для сайта (AWS Lambda)

Контактная форма на React-сайте при 2000+ заявок в день начала падать: ответ приходил через 30 секунд, письма терялись. Старый монолит на EC2 не справлялся с пиками. Заменили его на AWS Lambda — время ответа упало до 300 мс, стоимость обработки одной формы — доли цента. Серверлес-архитектура избавляет от управления серверами: вы фокусируетесь на коде, а AWS масштабирует нагрузку. Но холодный старт и работа с базами данных требуют аккуратного проектирования. Мы разберём типовые сценарии, покажем код и дадим готовые решения. Для оценки вашего проекта свяжитесь с нашими инженерами.

Когда Lambda подходит для сайта

Lambda эффективна для асинхронных и эпизодических задач. Вот сравнение с классическим сервером на EC2:

Подходит: обработка форм обратной связи, генерация PDF/изображений по запросу, вебхуки от платёжных систем и CRM, ресайз изображений при загрузке, планировщики задач (cron через EventBridge), API-прокси для сторонних сервисов.

Не подходит: долгоживущие соединения (WebSocket нужен отдельный сервис), задачи дольше 15 минут, высокочастотные операции с БД без connection pooling. В таких случаях Lambda не только дороже, но и медленнее: при 5000 запросов/с EC2 с автоскейлингом обойдётся дешевле, чем Provisioned Concurrency.

Почему AWS Lambda выгоднее традиционного сервера?

С точки зрения затрат Lambda выигрывает при неравномерной нагрузке. На EC2 вы платите за запущенный сервер 24/7, даже если он обрабатывает запросы раз в час. Lambda оплачивается по вызовам — экономия на простое достигает 90%. AWS Lambda Developer Guide приводит пример: сайт с 10 000 запросов в день на EC2 t3.micro обойдётся ≈ $8/мес, а Lambda — $0.05 за выполнение. При этом не нужно настраивать автоскейлинг, патчить ОС и следить за мониторингом. Наши клиенты экономят до 70% на инфраструктуре, переходя на Lambda.

Как Lambda обрабатывает форму? Пример кода

Контактная форма на React-сайте отправляет POST-запрос на API Gateway, который триггерит Lambda. Функция валидирует данные с помощью Zod и отправляет email через SES. Код:

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://your-site.com",
    "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: `Новое сообщение от ${data.name}`,
        },
        Body: {
          Text: {
            Data: `От: ${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" }),
    };
  }
};

Как снизить холодный старт?

Холодный старт — задержка на инициализацию после длительного простоя. На Node.js 20 он составляет 200–500 мс, на Python — 100–300 мс. Если для вас критично субсекундное время ответа, используйте один из методов:

Пример подготовки клиентов вне handler (выполняется один раз):

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

export const handler = async (event) => {
  // handler использует уже инициализированные клиенты
};

Какие типичные ошибки допускают разработчики?

• Чрезмерный размер бандла: включение всех зависимостей без tree-shaking увеличивает холодный старт на 200–500 мс.
• Создание клиентов внутри handler: каждый вызов создаёт новое соединение с базой — приводит к N+1 проблеме.
• Игнорирование лимита времени: если функция выполняется дольше таймаута (макс. 15 мин), она завершается с ошибкой.
• Отсутствие обработки ошибок: не перехваченные исключения приводят к повторным вызовам и затратам.

Как подключить Lambda к базе данных?

Стандартное TCP-соединение к PostgreSQL/MySQL в Lambda создаёт новое соединение на каждый вызов — при 1000 RPS база захлёбывается. Решения:

Для большого числа одновременных вызовов RDS Proxy может стать узким местом — в таких случаях переходят на DynamoDB или шардирование.

Процесс разработки и деплоя

1. Проектирование: определение триггеров, ролей IAM, таймаутов и памяти.
2. Разработка: написание функции на TypeScript с валидацией и обработкой ошибок.
3. Локальное тестирование: запуск через SAM CLI или Docker с эмуляцией API Gateway.
4. Сборка: использование esbuild для бандла (tree-shaking, минификация).
5. Деплой: через AWS SAM (template.yaml) — первый раз sam deploy --guided, затем sam deploy.
6. Мониторинг: настройка дашбордов CloudWatch, алертов по ошибкам и времени выполнения.

Мы используем AWS SAM для инфраструктуры как код. Пример 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: your-site.com

Команды:

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

Логирование и трейсинг

AWS Lambda Powertools — официальная библиотека для структурированного логирования, трейсинга через X-Ray и метрик через 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 });
  // ...
});

Что входит в работу

• Архитектурное проектирование: выбор триггеров, балансировка холодного старта
• Разработка функций на TypeScript с валидацией и обработкой ошибок
• Настройка CI/CD через GitHub Actions: сборка, тесты, деплой
• Документация API и описание инфраструктуры
• Мониторинг: дашборды CloudWatch, алерты на ошибки и время выполнения
• Обучение команды: code-review, руководство по дальнейшей поддержке

Сроки

Одна Lambda-функция с деплоем через SAM — 1–2 дня. Набор из 5–7 функций с CI/CD и мониторингом — 5–7 дней. Наши инженеры имеют многолетний опыт с Lambda, выполнили десятки проектов разной сложности. Точные сроки зависят от интеграций. Получите консультацию по архитектуре решения — подготовим детальное предложение под ключ.