Serverless Scheduled Tasks на AWS: EventBridge, Lambda, мониторинг

Традиционный cron на EC2 — головная боль: нужно патчить ОС, следить за диском, настраивать SSH. А если сервер упадёт, задача не выполнится, а вы узнаете об этом от клиента. Классический cron требует выделенной виртуальной машины, даже если задача запускается раз в час. Вы платите за простаивающий сервер 24/7. Serverless-подход позволяет запускать Lambda только по необходимости, с автоматическим retry и мониторингом. Мы заменяем эту схему serverless-планировщиком на AWS: EventBridge Scheduler запускает Lambda по расписанию, а вы платите только за запуски. Никаких серверов, никаких crontab.

Проблемы, которые решаем

Нет сервера = нет обслуживания. EC2 требует ручного патча ОС, мониторинга диска и SSH-доступа. В serverless вы платите только за запуски. Дублирование выполнения — частая проблема: если задача запустилась дважды из-за retry или flexible time window, результат должен быть одинаковым. Пропущенные задачи без уведомлений — ещё одна боль: если Lambda не запустилась, вы узнаете только от клиента.

Почему EventBridge Scheduler — лучший выбор?

Сравним EventBridge Scheduler (современный) с устаревшим CloudWatch Events:

EventBridge Scheduler гибче в 3 раза по настройке. Мигрируем с CloudWatch Events без простоя. Serverless cron обходится в 5 раз дешевле, чем EC2-инстанс для редких задач: вы не платите за простой.

Как мы это делаем: реальный кейс

Из нашей практики: для клиента — интернет-магазина с 1 млн товаров — настроили ежедневную синхронизацию остатков из ERP. Раньше задачу крутили на устаревшем сервере, который раз в месяц падал. Перешли на такой Terraform-конфиг:

resource "aws_scheduler_schedule" "sync_erp" { name = "sync-inventory-from-erp" flexible_time_window { mode = "FLEXIBLE" maximum_window_in_minutes = 15 } schedule_expression = "cron(0 6 * * ? *)" # Каждый день в 6:00 UTC schedule_expression_timezone = "Europe/Moscow" target { arn = aws_lambda_function.sync_inventory.arn role_arn = aws_iam_role.scheduler_role.arn input = jsonencode({ source = "erp", full_sync = false }) retry_policy { maximum_event_age_in_seconds = 3600 maximum_retry_attempts = 3 } dead_letter_config { arn = aws_sqs_queue.scheduler_dlq.arn } } } 

Результат: синхронизация работает стабильно больше года, расходы на инфраструктуру снижены на 80%.

Пошаговая настройка: EventBridge Scheduler + Lambda

1. Создаёте Lambda-функцию с бизнес-логикой.
2. Определяете IAM-роль для Scheduler с разрешением lambda:InvokeFunction.
3. В Terraform описываете aws_scheduler_schedule с cron-выражением и retry policy.
4. Настраиваете DLQ (SQS) для упавших запусков.
5. Тестируете ручной запуск через AWS Console.

Как обеспечить идемпотентность serverless задачи?

Даже с retry задачу может запустить дважды: flexible window или ручное повторение. Решение — DynamoDB с TTL:

import boto3 import hashlib from datetime import datetime dynamodb = boto3.resource('dynamodb') task_locks = dynamodb.Table('task_locks') def run_with_idempotency(task_fn, task_id: str, time_window_minutes: int = 60): window_key = f"{task_id}:{datetime.utcnow().strftime('%Y%m%d%H')}" try: task_locks.put_item( Item={ 'task_key': window_key, 'ttl': int(time.time()) + time_window_minutes * 60 }, ConditionExpression='attribute_not_exists(task_key)' ) except task_locks.meta.client.exceptions.ConditionalCheckFailedException: print(f"Task {task_id} already ran in this window, skipping") return None return task_fn() 

Это гарантирует, что задача выполнится не чаще раза в час. Ключ блокировки — task_id + час. Если задача уже выполнялась, условная запись не проходит.

Мониторинг heartbeat: не пропустите сбой

Lambda без постоянного процесса — вы не увидите, что она «упала». Заведите healthcheck-сервис (например, Healthchecks.io). Успешная задача отправляет ping; если ping не пришёл — алерт.

def send_healthcheck_ping(check_id: str): requests.get(f"https://hc-ping.com/{check_id}", timeout=5) def handler(event, context): result = perform_task() send_healthcheck_ping(os.environ['HEALTHCHECK_ID']) return result 

Так мы ловим 100% пропусков. Дополнительно можно настроить CloudWatch Alarm: если количество ошибок >0 за период — уведомление в Slack.

Типичные задачи для serverless cron

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

• Проектирование архитектуры: выбираем триггер, расписание, настраиваем retry и DLQ
• Разработка Lambda-обработчиков с идемпотентностью
• Настройка мониторинга (Healthchecks.io, CloudWatch Alarms)
• Документация: схема, cron-выражения, инструкция по ручному запуску
• Передача доступов и обучение ваших инженеров
• Поддержка в течение 30 дней после запуска

Сроки реализации

• Базовая задача (EventBridge + Lambda): 1–2 дня
• Идемпотентность + retry policy: 1 день
• Мониторинг + алерты: 0.5–1 день
• Комплексное решение (5+ задач, тестирование): 5–7 дней

Стоимость рассчитывается индивидуально — зависит от числа задач и сложности. Оценим ваш проект бесплатно. Свяжитесь с нами для консультации по настройке serverless-планировщика.

Для не-production окружений ресурс можно отключить state = "DISABLED" или использовать count = 0 в Terraform. Так вы избежите случайных запусков на staging.

Мы работаем с serverless-архитектурой более 5 лет и выполнили 50+ проектов на AWS Lambda. Предоставляем гарантию на все работы. Подробнее о сервисе EventBridge Scheduler — в официальной документации AWS. Получите консультацию — мы поможем настроить serverless-планировщик под ваши задачи.