Контактная форма на React-сайте при 2000+ заявок в день начала падать: ответ приходил через 30 секунд, письма терялись. Старый монолит на EC2 не справлялся с пиками. Заменили его на AWS Lambda — время ответа упало до 300 мс, стоимость обработки одной формы — доли цента. Серверлес-архитектура избавляет от управления серверами: вы фокусируетесь на коде, а AWS масштабирует нагрузку. Но холодный старт и работа с базами данных требуют аккуратного проектирования. Мы разберём типовые сценарии, покажем код и дадим готовые решения. Для оценки вашего проекта свяжитесь с нашими инженерами.
Когда Lambda подходит для сайта
Lambda эффективна для асинхронных и эпизодических задач. Вот сравнение с классическим сервером на EC2:
| Критерий | AWS Lambda | AWS EC2 |
|---|---|---|
| Управление сервером | Не требуется | Полное управление |
| Масштабирование | Автоматическое | Ручное / автоскейлинг |
| Холодный старт | 100–500 мс | Нет |
| Цена | За выполнение | За время работы |
| Лимит времени | 15 минут | Безлимит |
Подходит: обработка форм обратной связи, генерация 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 мс. Если для вас критично субсекундное время ответа, используйте один из методов:
| Метод | Описание | Дополнительные затраты |
|---|---|---|
| Provisioned Concurrency | N прогретых экземпляров | $0.015 за экземпляр/час |
| esbuild + tree-shaking | Уменьшение размера бандла | Нет |
| SnapStart (Java) | Снимок состояния после инициализации | Нет |
| Пинг-запросы | EventBridge раз в 5 минут | Мизерно |
Пример подготовки клиентов вне 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 | Пул соединений перед RDS | +$0.015 за vCPU/час |
| DynamoDB | Нативный serverless, без соединений | По запросам |
| PlanetScale / Neon | Serverless-БД с HTTP API | По использованию |
Для большого числа одновременных вызовов RDS Proxy может стать узким местом — в таких случаях переходят на DynamoDB или шардирование.
Процесс разработки и деплоя
- Проектирование: определение триггеров, ролей IAM, таймаутов и памяти.
- Разработка: написание функции на TypeScript с валидацией и обработкой ошибок.
- Локальное тестирование: запуск через SAM CLI или Docker с эмуляцией API Gateway.
- Сборка: использование esbuild для бандла (tree-shaking, минификация).
- Деплой: через AWS SAM (template.yaml) — первый раз
sam deploy --guided, затемsam deploy. - Мониторинг: настройка дашбордов 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, выполнили десятки проектов разной сложности. Точные сроки зависят от интеграций. Получите консультацию по архитектуре решения — подготовим детальное предложение под ключ.