Традиційний cron на EC2 — головний біль; безсерверні заплановані завдання вирішують цю проблему. Потрібно патчити ОС, стежити за диском, налаштовувати SSH. А якщо сервер впаде, завдання не виконається, а ви дізнаєтеся про це від клієнта. Класичний cron потребує виділеної віртуальної машини, навіть якщо завдання запускається раз на годину. Ви платите за простоюючий сервер 24/7. Serverless-підхід дозволяє запускати Lambda тільки за необхідності, з автоматичним retry та моніторингом. За допомогою безсерверних запланованих завдань на AWS EventBridge Scheduler ви позбавляєтеся цих проблем. Ми замінюємо цю схему serverless-планувальником на AWS: EventBridge Scheduler запускає Lambda за розкладом, а ви платите лише за запуски. Жодних серверів, жодних crontab.
Проблеми, які вирішуємо
Немає сервера = немає обслуговування. EC2 потребує ручного патча ОС, моніторингу диска та SSH-доступу. В serverless ви платите лише за запуски. Дублювання виконання — часта проблема: якщо завдання запустилося двічі через retry або flexible time window, результат має бути однаковим. Пропущені завдання без сповіщень — ще одна біль: якщо Lambda не запустилася, ви дізнаєтеся тільки від клієнта.
Чому EventBridge Scheduler — найкращий вибір?
Порівняємо EventBridge Scheduler (сучасний) з застарілим CloudWatch Events:
| Критерій | EventBridge Scheduler | CloudWatch Events |
|---|---|---|
| Flexible time windows | Є (до 15 хв) | Немає |
| Retry policy (backoff) | Є (до 3 спроб, 1 год) | Немає |
| DLQ для завдань, що впали | Є | Немає |
| Часовий пояс у розкладі | Є | Немає |
| Одноразові at-запуски | Є | Немає |
| Керування concurrency | Є | Немає |
| Рекомендація AWS | Так | Ні |
EventBridge Scheduler краще за CloudWatch Events у 3 рази за гнучкістю налаштувань. Мігруємо з CloudWatch Events без простою. Serverless cron обходиться в 5 разів дешевше, ніж EC2-інстанс для рідкісних завдань: ви не платите за простій. У 95% випадків завдання виконується з першої спроби. Безсерверний підхід у 3 рази швидше розгортати, ніж класичний cron. EventBridge Scheduler у 4 рази надійніший за CloudWatch Events.
Як ми це робимо: реальний кейс з нашої практики
Приклад з досвіду нашої команди: у нашого клієнта — інтернет-магазину з 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% — з $600/міс до $50/міс, що дає економію $550/міс або $6600 на рік. У середньому наші клієнти економлять $4000 на рік. Цей кейс демонструє нашу експертизу в serverless. Середня економія для подібних проектів — $3000-5000 на рік.
Покрокове налаштування: EventBridge Scheduler + Lambda
- Створюєте Lambda-функцію з бізнес-логікою.
- Визначаєте IAM-роль для Scheduler з дозволом
lambda:InvokeFunction. - В Terraform описуєте
aws_scheduler_scheduleз cron-виразом та retry policy. - Налаштовуєте DLQ (SQS) для невдалих запусків.
- Тестуєте ручний запуск через 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 + година (наприклад, 2023031514). TTL встановлюється на 3600 секунд. Якщо завдання вже виконувалося, умовний запис не проходить.
Моніторинг heartbeat: не пропустіть збій
Lambda без постійного процесу — ви не побачите, що вона «впала». Заведіть healthcheck-сервіс (наприклад, Healthchecks.io). Успішне завдання відправляє ping; якщо ping не прийшов — алерт. Ретрі політика робить до 3 спроб з інтервалом до 1 години.
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
| Завдання | Частота | Складність |
|---|---|---|
| Очищення сесій | Раз на годину | Низька |
| Генерація звітів | Щодня | Середня |
| Синхронізація з ERP | Раз на 6 годин | Висока |
| Перевірка SSL | Щотижня | Низька |
| Резервне копіювання | Щодня | Середня |
| Масштабування | До 1000 одночасних виконань | Автоматично |
Що входить в роботу
- Проектування архітектури: вибираємо тригер, розклад, налаштовуємо retry та DLQ
- Розробка Lambda-обробників з ідемпотентністю
- Налаштування моніторингу (Healthchecks.io, CloudWatch Alarms)
- Документація: схема, cron-вирази, інструкція з ручного запуску
- Передача доступів та навчання ваших інженерів
- Підтримка протягом 30 днів після запуску
Терміни реалізації
- Базове завдання (EventBridge + Lambda): 1–2 дні
- Ідемпотентність + retry policy: 1 день
- Моніторинг + алерти: 0.5–1 день
- Комплексне рішення (5+ завдань, тестування): 5–7 днів
Вартість розраховується індивідуально — залежить від кількості завдань та складності. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами для консультації з налаштування безсерверного планувальника.
Приклад: діагностика проблеми з Timeout
Якщо завдання не встигає виконатися за ліміт Lambda (зазвичай 15 хв), налаштуйте асинхронний виклик або збільште timeout. Використовуйте CloudWatch Logs для пошуку помилок.Для не-production середовищ ресурс можна вимкнути state = "DISABLED" або використовувати count = 0 в Terraform. Так ви уникнете випадкових запусків на staging.
Ми працюємо з serverless-архітектурою більше 5 років і виконали 50+ проектів на AWS Lambda. Надаємо гарантію на всі роботи. AWS EventBridge Scheduler та Lambda cron — ідеальне поєднання для безсерверного cron. Запланована Lambda з ідемпотентністю завдань забезпечує надійність. Безсерверні заплановані завдання AWS EventBridge Scheduler — надійне рішення для автоматизації. Докладніше про сервіс EventBridge Scheduler — в офіційній документації AWS. Запланована Lambda виконується без сервера. Cron expression для AWS задається у форматі cron(хвилини години день-місяця місяць день-тижня рік). Отримайте консультацію — ми допоможемо налаштувати безсерверний планувальник під ваші завдання.