AWS'de Cron Job Scheduler ve Lambda Rehberi

AWS üzerinde günlük rapor hazırlamak veya bir kuyruğu düzenli kontrol etmek için sürekli açık bir sunucuya ihtiyacınız yoktur. EventBridge Scheduler tetikleme zamanını yönetir, Lambda ise iş kodunuzu çalıştırır. Ancak zamanlayıcının çağrıyı teslim etmesi, raporun başarıyla üretildiğini tek başına kanıtlamaz. Bu ayrımı kurulumdan itibaren izlemeniz gerekir.

Bu rehber, AWS hesabında Lambda çalıştırabilen ve IAM izinlerini düzenleyebilen geliştiriciler içindir. İstanbul saatine göre bir zamanlama kuracak, iki farklı yürütme rolünü ayıracak ve hatanın zamanlayıcıda mı uygulamada mı olduğunu bulacaksınız. Temel kavramlara yeniyseniz önce cron job çalışma mantığını inceleyin; buradaki örnek Linux sunucusunun crontab dosyasını kullanmaz.

Scheduler, Eski Kurallar ve Lambda Seçimi

Yeni bir kurulumda EventBridge Scheduler kullanın. Eski EventBridge scheduled rule yapısını aynı hizmet gibi değerlendirmeyin: kurallar UTC üzerinden zamanlanırken Scheduler için saat dilimi seçebilirsiniz. Mevcut kuralınızı taşırken önce hedefi ve giriş verisini kaydedin, ardından yeni zamanlamayı devreye alın. İki tanımı aynı anda açık bırakmak çift çalışmaya neden olabilir.

Bu rehberdeki standart Lambda fonksiyonu kısa görevler için uygundur; tek çağrı en fazla 15 dakika çalışır. Bundan uzun süren bir işi tek fonksiyona sıkıştırmayın. Konteyner işi için ECS, adımlar arasında durum takibi için Step Functions değerlendirin. Hizmet tercihini beklenen süre, ağ erişimi ve yeniden başlatılabilirlik üzerinden yapın. Lambda kotalarında farklı yürütme modellerinin sınırlarını karşılaştırın. Aynı bulut içi zamanlayıcı ihtiyacının Google Cloud karşılığı Cloud Scheduler'dır; hedef ve saat dilimi farkları Google Cloud cron job kurulumunda ayrıca ele alınır.

Adım Adım Lambda ve IAM Hazırlığı

1. AWS Console içinde bölgeyi seçin. Lambda ve Scheduler örneğini aynı bölgede tutun; aşağıdaki komutlar eu-west-1 kullanır. Hesap kimliğinizi ve kaynak adlarını kendi ortamınıza uyarlayın.
2. Lambda bölümünde CronRapor adlı Python fonksiyonu oluşturun. Lambda yürütme rolünde CloudWatch Logs yazma izni bulunmalıdır; AWSLambdaBasicExecutionRole yönetilen ilkesi kullanılabilir. Bu rol fonksiyon kodunun yetkisidir.
3. Aşağıdaki kodu lambda_function.py dosyasına koyun. Handler değerinin lambda_function.lambda_handler olduğunu doğrulayın. Kod yalnızca çalışma kaydı üretir; gerçek rapor oluşturmaz veya yedek almaz.
4. Test olayında scheduled_time alanına 2026-10-15T06:00:00Z verin. Testi çalıştırın, dönen sonucu ve CloudWatch kaydını birlikte kontrol edin. Hedef kodu bağımsız çalışmadan zamanlayıcı oluşturmayın.
5. Scheduler için ayrı bir IAM rolü hazırlayın. Güven ilişkisinde scheduler.amazonaws.com hizmetine sts:AssumeRole verin; izin ilkesinde yalnız CronRapor fonksiyonunun ARN değeri için lambda:InvokeFunction tanımlayın. ARN, kaynağın hesap ve bölge içeren tam kimliğidir.

# lambda_function.py
import json
import logging
from datetime import datetime, timezone

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    result = {
        "job": "gunluk-rapor",
        "scheduled_time": event["scheduled_time"],
        "started_at": datetime.now(timezone.utc).isoformat(),
        "request_id": context.aws_request_id,
    }
    logger.info(json.dumps(result))
    return result

İki rolü karıştırmayın: ilki çağırmaya, ikincisi çağrı içindeki işlemlere izin verir. Oluşturmayı yapan kullanıcıda ilgili rolü geçirebilmek için iam:PassRole yetkisi de gerekebilir. Üretimde güven ilişkisini hesap ve schedule group kaynak koşullarıyla daraltın; ayrıntılar için resmi Scheduler rol kurulumu açıklamasını kullanın.

İstanbul Saatine Göre Zamanlama ve CLI

Console içinde EventBridge Scheduler → Schedules → Create schedule yolunu açın. Recurring schedule seçin, cron ifadesini cron(0 9 * * ? *) ve saat dilimini Europe/Istanbul yapın. Flexible time window seçeneğini Off olarak belirleyin. Hedef olarak Lambda Invoke ve CronRapor fonksiyonunu, execution role olarak hazırladığınız Scheduler rolünü seçin.

Console hedef girişine yalnız {"scheduled_time":"<aws.scheduler.scheduled-time>"} nesnesini girin. CLI kullanacaksanız aşağıdaki bütün hedef nesnesini target.json adıyla kaydedip ARN değerlerini değiştirin. Console'da oluşturduğunuz zamanlamaya ikinci bir etkin kopya eklemeyin. Planlanan zamanı gerçek başlangıçtan ayrı tutmak gecikmeyi ölçmenizi sağlar.

{
  "Arn": "arn:aws:lambda:eu-west-1:123456789012:function:CronRapor",
  "RoleArn": "arn:aws:iam::123456789012:role/SchedulerCronInvoke",
  "Input": "{\"scheduled_time\":\"<aws.scheduler.scheduled-time>\"}",
  "RetryPolicy": {
    "MaximumEventAgeInSeconds": 3600,
    "MaximumRetryAttempts": 3
  }
}

# Bash / AWS CloudShell; roller ve fonksiyon önceden oluşturulmalıdır.
aws scheduler create-schedule \
  --region eu-west-1 \
  --name GunlukRapor \
  --schedule-expression 'cron(0 9 * * ? *)' \
  --schedule-expression-timezone Europe/Istanbul \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target file://target.json

aws scheduler get-schedule --region eu-west-1 --name GunlukRapor

Kaydı okuyarak State, ScheduleExpressionTimezone ve Target alanlarını doğrulayın. Flexible window kapalıyken bile hedef çağrısı saniyesi kesin bir alarm değildir; planlanan dakikanın içinde yapılır. Kurulum ekranlarını karşılaştırmak için Lambda ile Scheduler bağlantısı belgesine başvurabilirsiniz.

Cron ve Rate İfadelerini Doğru Okuma

AWS cron ifadesinin sırası dakika, saat, ayın günü, ay, haftanın günü ve yıldır. İlk alan saniye değildir. Ayın günü ile haftanın günü alanlarının birinde soru işareti kullanın. Standart beş alanlı crontab sözdizimini aynen yapıştırmayın; Azure'un altı alanlı ifadesi de burada farklı anlam taşır ve Azure Timer Trigger kurulumundaki alan sırası tablosuyla karşılaştırmak karışıklığı önler.

Takvim saati gerektiğinde cron, başlangıçtan itibaren düzenli aralık gerektiğinde rate seçin. Yaz saati uygulanan bölgelerde atlanan veya tekrarlanan yerel saatleri ayrıca değerlendirin. Scheduler zamanlama ve saat dilimi kuralları bu davranışları açıklar.

İki Gerçek Kullanım Senaryosu

Günlük Satış Raporu

Her gün İstanbul saatiyle 09:00'da önceki iş gününün satışlarını raporlayın. Dönemin başlangıç ve bitişini açıkça hesaplayın; yalnız sunucunun o anki tarihini kullanmak gece yarısı sınırında yanlış sonuç verebilir. Raporu S3 üzerinde iş günüyle belirlenen sabit bir anahtara yazmak, aynı dönemin tekrar işlenmesini yönetmeyi kolaylaştırır. S3 yazma yetkisini yalnız rapor klasörüyle sınırlandırın.

On Beş Dakikalık Entegrasyon Kontrolü

Bir tedarikçi API'sindeki değişiklikleri her on beş dakikada bir alın. Son başarılı imleci veritabanında tutun ve yalnız işlenen kayıtların ardından ilerletin. API yanıtı kesilirse son tamamlanan sayfadan devam edin. Her dış kayıt kimliği için benzersiz kısıt kullanarak tekrar teslim edilen verinin ikinci kez eklenmesini engelleyin.

Yeniden Deneme, DLQ ve Başarı Takibi

Scheduler, Lambda'yı asenkron çağırır. Çağrının kabul edilmesi ile fonksiyonun tamamlanması farklı aşamalardır. Scheduler retry ilkesi hedef API'ye teslim hatalarını, Lambda asenkron hata ayarları ise fonksiyon yürütmesini ilgilendirir. Lambda hata verdiğinde Scheduler kaydının başarılı görünmesi bu nedenle mümkündür. Lambda asenkron hata yönetimi belgesindeki ayarları ayrıca inceleyin.

Teslim edilemeyen olaylar için SQS dead-letter queue, yani başarısız olay kuyruğu tanımlayabilirsiniz; Scheduler rolüne kuyruğa mesaj yazma yetkisini de verin. Uygulamanızda iş adı ve planlanan dönemden bir benzersiz işlem anahtarı üretin. Idempotent tasarım, aynı isteğin tekrar gelmesinin ikinci fatura veya ikinci e-posta oluşturmamasıdır. Teşhis yaklaşımı için cron hata çözümleri rehberini de kullanabilirsiniz.

Sık Hatalar ve Çözümleri

AccessDeniedException veya Rolü Üstlenememe

Scheduler rolünün güven ilkesini, lambda:InvokeFunction kaynağını ve kurulum kullanıcısının iam:PassRole yetkisini ayrı ayrı inceleyin. Yanlış hesap veya bölgedeki ARN de sorun çıkarabilir. Tüm kaynaklara yıldız yetkisi vermek yerine reddedilen eylemi ve kaynağı kayıttan bulun.

ValidationException ve Geçersiz Zamanlama

Beş alanlı Linux ifadesi, iki gün alanının birlikte doldurulması veya yanlış JSON kaçışı oluşturmayı engelleyebilir. Önce tablodaki günlük ifadeyle deneyin. Hedef dosyasının geçerli JSON olduğunu doğrulayın; Input alanı JSON metni taşıdığı için iç tırnaklar kaçışlanmalıdır.

Task timed out after

Bu ifade Lambda kaydında görülüyorsa hangi ağ veya veritabanı çağrısının beklediğini bulun. Uygun timeout ayarını seçin; on beş dakikayı aşacak işi bölün. Fonksiyonu VPC içine aldığınızda dış API erişimi de gerekiyorsa ağ çıkışını ayrıca kontrol edin.

KeyError: 'scheduled_time'

Örnek fonksiyon bu alanı zorunlu bekler. Console testi boş olayla çalıştırılmış veya Scheduler Input alanı boş bırakılmış olabilir. Test olayını ve hedef girişini düzeltin. Eksik alanı sessizce güncel saatle değiştirmek yanlış dönemin raporlanmasına yol açabilir.

Beklenen Saatte Çalışmama

State değerinin ENABLED olduğunu, bitiş tarihini, saat dilimini ve flexible window seçimini kontrol edin. CloudWatch içindeki hedef hata metriklerini uygulama günlükleriyle karşılaştırın. Scheduler sorun giderme belgesi ile teslim ve çalışma hatalarını ayırın.

cronjob.com.tr ile HTTP Tabanlı Alternatif

İşiniz HTTPS üzerinden çağrılabiliyorsa cronjob.com.tr paneline URL, POST metodu, X-Cron-Token özel header değeri ve beş dakikalık aralık girin. Bu yöntem IAM kimlik doğrulamasının yerine kendiliğinden geçmez. API Gateway arkasındaki uygulamanız token doğrulamalıdır; yalnız IAM kabul eden hedefi bu ayarlarla çağırmayı beklemeyin.

Aşağıdaki Python parçası API Gateway HTTP API payload 2.0 biçimi için ayrı bir Lambda handler örneğidir. CRON_HTTP_TOKEN değerini ortamda gizli tutun. Örnek erişim kontrolünü gösterir; iş mantığınızı başarılı yanıt dönmeden önce ekleyin. Uç noktanızı tokensız, yanlış token ile ve doğru token ile sınayın.

import hmac
import os

def http_handler(event, context):
    expected = os.environ["CRON_HTTP_TOKEN"]
    headers = {k.lower(): v for k, v in (event.get("headers") or {}).items()}
    supplied = headers.get("x-cron-token", "")
    if not expected or not hmac.compare_digest(supplied, expected):
        return {"statusCode": 401, "body": "Unauthorized"}
    if event["requestContext"]["http"]["method"] != "POST":
        return {"statusCode": 405, "body": "Method Not Allowed"}
    # İş mantığınızı burada çalıştırın.
    return {"statusCode": 200, "body": "Erisim dogrulandi"}

Beş dakikalık hazır aralıkta yanıt bekleme sınırı 290 saniyedir; bir dakikada 55, iki dakikada 115 saniyedir. Bağlantı hatası olmadan HTTP 200–399 başarı sayılır. Ardışık hata eşiği varsayılan olarak üçtür; eşiğe göre erişim sorunu ve düzelme e-postaları gönderilir, aynı işte bildirimler arasında en az 60 dakika bulunur. Loglar yedi gün tutulur. Uzun rapor için HTTP kabul yanıtını işin tamamlanma kaydından ayrı izleyin.

Sıkça Sorulan Sorular (SSS)

AWS cron ifadesinde altıncı alan saniye mi?

Hayır. AWS cron ifadesinde altıncı alan yıldır; dakika ilk alandır. Azure Timer Trigger örneklerindeki saniye alanıyla karıştırmayın.

Scheduler için Lambda rolünü kullanabilir miyim?

İki rolün görevi farklıdır. Scheduler rolü hedefi çağırır; Lambda yürütme rolü fonksiyon içindeki kaynak erişimini yönetir. Ayrı roller tanımlayın.

Scheduler başarılıysa rapor da tamamlanmış mıdır?

Hayır. Lambda asenkron çağrısının kabul edilmesi iş kodunun tamamlandığını göstermez. Lambda hata kayıtlarını ve uygulamanın tamamlanma kaydını da izleyin.

AWS cron job tamamen ücretsiz midir?

Maliyet Scheduler çağrılarına, Lambda süresine, günlüklere ve kullanılan diğer kaynaklara bağlıdır. Ücretsiz kullanım koşullarını hesabınız için AWS fiyatlandırmasından kontrol edin; bütün kurulumun ücretsiz olduğunu varsaymayın.

İstanbul saatini UTC değerine çevirmek zorunlu mu?

EventBridge Scheduler üzerinde Europe/Istanbul seçtiğinizde yerel saati doğrudan yazabilirsiniz. Eski zamanlanmış EventBridge kuralları için UTC üzerinden hesaplama gerekir.

İlgili Rehberler