Amazon SAA-C03: Sunucusuz ve Olay Odaklı Mimariler / API Entegrasyonu — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

AWS Lambda: Yürütme Modeli, Çalışma Zamanı Yaşam Döngüsü ve Soğuk Başlangıçlar

Lambda, kodu iki aşamalı bir yaşam döngüsünü takip eden izole Firecracker mikro-VM’lerinde çalıştırır. INIT aşaması konteyneri hazırlar, çalışma zamanını (runtime) başlatır, dağıtım paketini indirip açar ve modül seviyesindeki tüm başlangıç işlemlerini çalıştırır — SDK istemci oluşturma, KMS ile şifresi çözülmüş gizli bilgilerin yüklenmesi, veritabanı bağlantı havuzu kurulumu, JVM sınıf yüklemesi ve JIT ısınması gibi. INVOKE aşaması ise handler’ı çalıştırır. Soğuk başlangıç (cold start), tam INIT maliyetini içerir; sıcak çağrı (warm invocation) ise ortamı yeniden kullanır, bu nedenle handler dışında önbelleğe alınan her şey (HTTP keep-alive havuzları, şifresi çözülmüş gizli bilgiler, veritabanı istemcileri) o konteyner üzerindeki çağrılar arasında kalıcı olur. Standart desenin, maliyetli nesneleri modül kapsamında oluşturup yeniden kullanmasının nedeni budur:

import boto3, os
ddb = boto3.client('dynamodb')          # reused across warm invokes
_secret = None
def _load_secret():
    global _secret
    if _secret is None:
        _secret = kms.decrypt(...)      # KMS call once per container, not per invoke
    return _secret

def handler(event, ctx):
    ...

Soğuk başlangıcın büyüklüğü çalışma zamanına göre değişir. Node.js ve Python’da bu süre onlarca ila birkaç yüz milisaniye arasındayken; JVM ve .NET’te bir saniyeyi aşabilir. VPC’ye bağlı fonksiyonlar için Hyperplane ENI’ları, geçmişteki ENI ekleme cezasını büyük ölçüde amorti etmiştir, ancak paket boyutu ve ağır INIT kodu hala baskın faktörlerdir.

Üç araç, soğuk başlangıçlara farklı şekillerde çözüm sunar:

SnapStart, kesin gecikme sözleşmeleri olmayan Java iş yükleri için maliyet-etkin ideal çözümdür — soğuk başlangıçlar, çağrı başına ek ücret olmadan kabaca on kat azalır. Provisioned concurrency, senkron bir API’nin yoğunluk anlarında p99 değerini, örneğin 100 ms’nin altında tutması gerektiğinde doğru cevaptır; bunu p95 yoğunluğuna göre boyutlandırmak, kuyruk gecikmesi (tail-latency) açığını kapatır. Bunu yetersiz boyutlandırmak klasik bir hatadır: isteğe bağlı mod, yalnızca bir istek geldiğinde yeni konteynerler başlatır, bu nedenle ani bir artış, gerçek kullanıcılar için çok saniyelik beklemelere neden olur.

# SAM: SnapStart on a Java 17 function
MyJavaFn:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java17
    SnapStart: { ApplyOn: PublishedVersions }
    AutoPublishAlias: live

Provisioned concurrency’nin kendisi Application Auto Scaling ile ölçeklendirilebilir — örneğin 07:45’te 10’dan 200’e çıkan ve 10:00’da geri dönen zamanlanmış bir eylem, gece boyunca sıcak kapasite için ödeme yapmayı önlerken sabah yoğunluğundaki soğuk başlangıçları ortadan kaldırır.

Bellek boyutlandırması aynı zamanda bir CPU ayarıdır: vCPU, vCPU başına ~1.769 MB’a kadar bellekle doğrusal olarak ölçeklenir. 128 MB’a sabitlenmiş bir fonksiyon, iki katına çıkan çalışma süresi genellikle iki katına çıkan ms başına fiyattan daha fazla olduğu için, toplamda 1.024 MB’lık bir fonksiyondan daha pahalıya mal olabilir. Tahmin etmeyin — temsili yüklere karşı yapılandırmaları taramak için AWS Lambda Power Tuning’i kullanın.

Lambda Eş Zamanlılık Kontrolleri ve Bağımlı Sistemlerin Korunması

Üç eş zamanlılık ayarı önemlidir ve her biri farklı bir iş yapar:

• Ayrılmış eş zamanlılık (Reserved concurrency), bir fonksiyonun kullanabileceği eş zamanlı yürütme sayısını sınırlar ve rezerve eder. Hesap havuzundan kapasite ayırır ve bağımlı sistemleri (küçük bir RDS sunucusu, oran limitleri olan bir iş ortağı API’si) aşırı yüklenmekten korur.
• Sağlanmış eş zamanlılık (Provisioned concurrency), ortamları önceden başlatır — bu bir ölçeklendirme değil, gecikme ayarıdır.
• Ayrılmamış hesap eş zamanlılığı (Unreserved account concurrency), paylaşılan havuzdur ve Bölge başına varsayılan olarak 1.000’dir.

Lambda’nın “sonsuz ölçeklendiğini” varsaymak iki tavanı göz ardı etmektir. Birincisi, hesap düzeyindeki eş zamanlı yürütme sınırı gerçektir ve ani artış (burst) limitleri (Bölgeye bağlı olarak başlangıçta 500–3.000, ardından +500/dk) artış hızını yönetir. Aşıldığında, senkron çağrılar 429 TooManyRequestsException hatası alır ve API Gateway bunu 5xx olarak yansıtır. İkincisi, bağımlı sistemlerin kendi sınırları vardır: max_connections=85 olan bir db.t3.micro, her biri bir bağlantı açan binlerce eş zamanlı Lambda’ya dayanamaz. PostgreSQL, her bağlantı için ~10 MB RAM tüketen bir arka plan işlemi (backend process) çatallar (fork); CPU’da boşluk olsa bile, yalnızca bağlantı kurma ve sonlandırma işlemleri bile sunucuyu (instance) en yüksek seviyede zorlayabilir.

İki azaltma yöntemi şunlardır: (1) çok sayıda istemci tarafı bağlantısını havuzlayıp küçük bir kalıcı arka uç bağlantı setine çoklayan (multiplex) RDS Proxy ve (2) işleme hızının geliş hızından ayrıştırılması için bir kuyruk eklemek:

import psycopg2, os
conn = psycopg2.connect(
    host=os.environ['PROXY_ENDPOINT'],   # RDS Proxy, not the DB directly
    dbname='orders', user='app', password=get_secret())

RDS Proxy, minimum değişiklikle uygulanan bir çözümdür — sürücü ve bağlantı dizesi neredeyse hiç değişmez — bu da onu, “uygulamada en az değişiklik” ve bağlantı tükenmesi gereksinimleri olduğunda doğru cevap yapar. DynamoDB’de bu sorun yoktur: HTTPS API’si durumsuzdur (stateless), bu nedenle DynamoDB, yüksek fan-out’lu Lambda iş yükleriyle doğal olarak eşleşir.

Lambda IAM, Ortam Değişkenleri ve Ağ Yapılandırması

Her fonksiyon, çağrıldığında bir execution role üstlenir. Rolün güven ilkesi (trust policy), lambda.amazonaws.com hizmetine sts:AssumeRole izni verir; izin ilkesi (permission policy) ise fonksiyonun neler yapabileceğini tanımlar. Çalışma zamanı (runtime), kısa ömürlü STS kimlik bilgilerini otomatik olarak AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY ve AWS_SESSION_TOKEN ortam değişkenlerine enjekte eder. Asla IAM kullanıcı erişim anahtarlarını ortam değişkenlerine veya koda gömmeyin — bunlar statiktir, sızdırılmış kaynak kodlarında veya CloudTrail dışa aktarımlarında keşfedilebilir, manuel olarak döndürülmeleri gerekir ve tüm geçici kimlik bilgisi modelini devre dışı bırakırlar.

FnRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
      - Effect: Allow
        Principal: { Service: lambda.amazonaws.com }
        Action: sts:AssumeRole
    Policies:
      - PolicyName: ReadOrders
        PolicyDocument:
          Statement:
          - Effect: Allow
            Action: ["dynamodb:GetItem", "dynamodb:Query"]
            Resource: !GetAtt OrdersTable.Arn

Hassas yapılandırma bilgileri taşıyan ortam değişkenleri, müşteri tarafından yönetilen bir KMS anahtarı ile şifrelenmelidir. Bu işlem sırasında, konsolun istemci tarafında şifreleme yapabilmesi için “aktarım sırasında şifreleme yardımcıları” (helpers for encryption in transit) kullanılmalıdır. Şifreyi INIT aşamasında bir kez çözün ve düz metni (plaintext) modül seviyesinde bir değişkende önbelleğe alın — aksi takdirde her çağrı bir KMS API çağrısı maliyetine katlanır.

Varsayılan olarak bir fonksiyon, AWS tarafından yönetilen ve kısıtlanmamış giden internet erişimi olan bir VPC’de çalışır. Fonksiyonu kendi VPC’nize yalnızca VPC içindeki kaynaklara (özel alt ağlardaki RDS, ElastiCache, Direct Connect üzerinden şirket içi sistemler) erişmesi gerektiğinde bağlayın. Bu durumda Lambda, belirttiğiniz alt ağlara Hyperplane ENI’leri ekler ve bu alt ağların yönlendirme kurallarını devralır.

Klasik tuzak, bir Lambda’yı, AWS servis trafiği için bir NAT gateway dışında bir rotası olmayan — veya daha kötüsü, kendi yönettiğiniz bir NAT instance’ı olan — özel bir alt ağa yerleştirmektir. NAT instance’ları tek bir NIC ile doygunluğa ulaşır, tek bir hata noktasıdır (SPOF) ve GB başına faturalandırılır. NAT gateway’ler bile GB başına ücretlendirilir ve AWS servis trafiği için gereksizdir. Doğru desen şudur:

• S3 ve DynamoDB için Gateway VPC endpoint’leri (ücretsiz)
• KMS, Secrets Manager, SQS, SNS, STS ve benzeri servisler için Interface (PrivateLink) endpoint’leri

Bu, trafiği AWS omurgasında tutar, NAT’ın verim tavanını ortadan kaldırır ve sürpriz giden trafik (egress) faturalarını önler. Unutmayın ki Lambda ENI’leri asla genel bir IP almaz; fonksiyonu “genel” (public) bir alt ağa yerleştirmek ona internet erişimi sağlamaz — yine de ayrı bir genel alt ağda uygun bir rotaya sahip bir NAT gateway’e ihtiyacınız olacaktır.

Amazon API Gateway: Endpoint Türleri, Yetkilendirme ve Entegrasyon

API Gateway üç farklı API türü sunar:

API anahtarları ve kullanım planları, JSON Schema istek doğrulaması, VTL eşleme şablonları, metot başına kapsam (scope) belirleyebilen Cognito yetkilendiricileri veya WAF’a ihtiyacınız olduğunda REST’i seçin; maliyet ve gecikmenin daha önemli olduğu hafif JWT kimlik doğrulamalı proxy desenleri için HTTP’yi seçin.

Endpoint türleri, API’nin nerede sonlandırıldığını (fronted) yönetir:

• Edge-optimized: Gateway tarafından yönetilen bir CloudFront dağıtımı tarafından sonlandırılır; TLS en yakın POP’ta (Point of Presence) sonlanır. Küresel olarak dağıtılmış istemciler için en iyisidir.
• Regional: Tek bir Region’dan CloudFront olmadan sunulur. İstemciler aynı Region’daysa, önüne kendi CloudFront’unuzu koymak istediğinizde veya birden çok Region arasında Route 53 gecikme tabanlı yönlendirme kullanırken en iyisidir.
• Private: Yalnızca bir interface VPC endpoint aracılığıyla erişilebilir. Genel internet üzerinden geçmemesi gereken dahili mikroservisler için en iyisidir.

Dahili, tek bir Region’da çalışan bir API için edge-optimized seçmek, gereksiz bir CloudFront atlaması ekler ve dağıtım yayılımını yavaşlatır. Küresel olarak tüketilen genel bir API için regional seçmek, her isteği genel internet üzerinden tek bir Region’a gitmeye zorlar.

Özel alan adları (Custom domains), konumu endpoint türüne bağlı olan ACM sertifikaları gerektirir: edge-optimized için us-east-1 (CloudFront küreseldir ve TLS’i orada sonlandırır); regional endpoint’ler için ise API’nin kendi Region’ı. Bunu karıştırmak, sık yapılan bir yanlış yapılandırmadır. Taban yolu eşlemeleri (Base path mappings), tek bir alan adının birden çok API’yi yönlendirmesine olanak tanır (/orders → orders API, /users → users API).

Yetkilendirmenin dört modeli vardır ve yerleşik mekanizmaların dışına çıkmak klasik bir anti-desendir:

Özel bir Lambda yetkilendiricisi, her istek başına (veya önbellek TTL’i başına) fazladan bir çağrı, yamalanması ve izlenmesi gereken bir fonksiyon daha ve imza doğrulama hatalarının sessizce erişime izin verebileceği bir kod yolu ekler. Yalnızca yerleşik mekanizmaların gereksinimi gerçekten karşılayamadığı durumlarda kullanın.

Lambda proxy entegrasyonu varsayılan desendir — isteğin tamamı bir olay (event) olarak iletilir ve fonksiyonun yanıt zarfı (envelope) şeklini döndürmesi gerekir:

{
  "statusCode": 200,
  "headers": {"Content-Type": "application/json"},
  "body": "{\"orderId\":\"abc123\"}",
  "isBase64Encoded": false
}

Çok yüksek TPS’de (saniye başına işlem) ‘ateşle ve unut’ (fire-and-forget) tarzı veri alımı için, Lambda atlamasını tamamen ortadan kaldırarak doğrudan SQS veya Kinesis’e veri göndermek için Gateway’in doğrudan AWS servis entegrasyonunu kullanın. Bu, yazma yolundaki soğuk başlatmaları (cold starts) ortadan kaldırır ve veri alım oranını işleme kapasitesinden ayırır.

Güvenli sürüm geçişleri için bir aşamada (stage) kanarya dağıtımları (canary deployments) kullanın: trafiğin bir yüzdesi yeni dağıtıma giderken çoğunluk kararlı sürümde kalır, kanarya başına CloudWatch metrikleri yükseltme veya geri alma kararını bilgilendirir.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10 \
    op=replace,path=/canarySettings/deploymentId,value=xyz789

API Gateway seremonisinin aşırıya kaçtığı basit bir webhook için (tek kiracılı bir Slack geri araması, bir GitHub push işleyicisi gibi), doğrudan fonksiyon üzerinde özel bir HTTPS endpoint’i sağlayan Lambda fonksiyon URL’lerini kullanın. Çağrıyı yapanlar AWS kimlikleri ise bunları AuthType: AWS_IAM ile güvence altına alın; eğer NONE ise, istek imzasını fonksiyon içinde doğrulamanız zorunludur. AuthType: NONE olan ve fonksiyon içi doğrulama yapmayan bir fonksiyon URL’si, genel internet üzerinde anonim bir işlem (compute) endpoint’idir.

Çağırma Türleri, Yeniden Denemeler ve Idempotency

Olay kaynakları, birbirinden çok farklı davranışlara sahip iki kategoriye ayrılır. Push tabanlı kaynaklar (API Gateway, ALB, S3, SNS, EventBridge, Cognito) Lambda’yı doğrudan çağırır ve doğru Principal (ör. events.amazonaws.com) ve SourceArn ile lambda:InvokeFunction iznini veren bir AWS::Lambda::Permission kaynak tabanlı politika gerektirir. Bu olmadan kural olaylarla eşleşir ancak her çağırma sessizce reddedilir; fonksiyon asla çalışmaz ve hatalar yalnızca CloudTrail’de görünür. Bu, fonksiyonun kimin çağırabileceğini değil, ne yapabileceğini yöneten yürütme rolünden farklıdır.

Poll tabanlı kaynaklar (SQS, Kinesis, DynamoDB Streams, MSK), Lambda hizmeti tarafından bir olay kaynağı eşlemesi (event source mapping) aracılığıyla okunur; kaynak tabanlı bir politika gerekmez, ancak yürütme rolünün okuma izinleri vermesi gerekir.

Çağırma türleri, yeniden deneme davranışını daha da dallandırır:

• Senkron (API Gateway, ALB, RequestResponse SDK): hatalar anında döndürülür; yeniden denemelerden çağıran taraf sorumludur.
• Asenkron (S3, SNS, EventBridge): Lambda, dahili bir kuyrukta arabelleğe alır ve hata durumunda gecikmeli olarak iki kez yeniden dener, ardından bir DLQ‘ya (Dead-Letter Queue) veya hata durumunda hedefe (on-failure destination) gönderir.
• SQS olay kaynağı eşlemesi: SQS, maxReceiveCount değeri kaynak kuyruğun DLQ’suna taşımayı tetikleyene kadar yeniden teslim etmeye devam eder.
• Kinesis / DynamoDB Streams: başarılı olana veya süresi dolana kadar tek bir shard yığınını yeniden dener ve bu sırada shard’ı bloke eder — takılıp kalmış bir yığın, o bölüm için tüm aşağı akış (downstream) işlemeyi durdurur.

Yeniden denemeler her katmana dahil edildiğinden, idempotency isteğe bağlı değil, zorunludur. Yavaş bir yazma işlemi sırasında bir SQS görünürlük zaman aşımının (visibility timeout) sona ermesi veya aşağı akıştaki bir 5xx hatasından sonra asenkron bir yeniden deneme, yinelenen kayıtlar (duplicate) üretecektir. Kanonik model, deterministik bir anahtar ve DynamoDB koşullu yazma işlemi kullanır:

def handler(event, context):
    msg_id = event['Records'][0]['messageId']
    try:
        ddb.put_item(
            TableName='processed',
            Item={'id': {'S': msg_id}, 'ttl': {'N': str(ttl)}},
            ConditionExpression='attribute_not_exists(id)')
    except ddb.exceptions.ConditionalCheckFailedException:
        return  # already processed
    process(event)

AWS Lambda Powertools’daki @idempotent dekoratörü, DynamoDB desteğiyle tam olarak bu modeli uygular.

SQS ve SNS ile Ayrıştırma (Decoupling)

Yüksek fan-out oranına sahip push kaynaklarını doğrudan Lambda’ya bağlamak kırılgandır. Örneğin, S3 olay bildirimleri her olay için senkrondur ve Lambda’nın eş zamanlılık tavanına (concurrency ceiling) tabidir; anlık bir yükleme sırasında (bir pazarlama kampanyasının saniyeler içinde binlerce belge bırakması gibi) çağırmalar mevcut eş zamanlılığı aşarsa, S3’ün yeniden deneme penceresi kısadır ve olaylar etkili bir şekilde kaybolabilir. Çözüm bir arabellek kullanmaktır:

SNS, pub/sub modelidir: bir yayın, birçok abone (SQS, Lambda, HTTPS, e-posta). Mesaj filtreleme öznitelik tabanlıdır. SQS, mesajları 14 güne kadar tutan dayanıklı bir noktadan noktaya kuyruktur. En sık kullanılan kombinasyon, her bir tüketiciye bağımsız ölçeklendirme ve yeniden oynatma için kendi arabelleğe alınmış kuyruğunu veren SNS → SQS fan-out modelidir.

Kesin sıralama için (örneğin, müşteri başına siparişlerin sırayla işlenmesi), MessageGroupId değeri sıralama anahtarına ayarlanmış bir SQS FIFO kuyruğu kullanın. Bir grup içindeki mesajlar sırayla teslim edilir; farklı gruplar paralel olarak işlenir. Standart SQS yalnızca en iyi çaba (best-effort) sıralaması sunar.

Kanonik ayrıştırılmış veri alım modeli, anlık yoğunlukları emmek için Gateway’in doğrudan SQS entegrasyonunu ve hızı sınırlandırılmış bir işlemciyi kullanır:

Resources:
  OrdersQueue:
    Type: AWS::SQS::Queue
    Properties:
      FifoQueue: true
      ContentBasedDeduplication: true
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrdersDLQ.Arn
        maxReceiveCount: 5

  ProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      ReservedConcurrentExecutions: 20   # cap the DB write rate

  Mapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt OrdersQueue.Arn
      FunctionName: !Ref ProcessorFunction
      BatchSize: 10

Ayrılmış eş zamanlılık (reserved concurrency) kasıtlıdır — veritabanının yazmaları ne kadar hızlı göreceğini sınırlar, böylece anlık yoğunluğu RDS değil, kuyruk emer. Başarısız olan mesajlar, çevrimdışı inceleme için maxReceiveCount sonrasında bir DLQ’ya yönlendirilir.

EventBridge: Kurallar, Girdi Dönüşümü ve API Hedefleri

EventBridge; zengin JSON model eşleştirme, SaaS iş ortağı kaynakları, şema kaydı (schema registry) ve arşivleme/yeniden oynatma özelliklerine sahip, şema duyarlı bir olay veri yoludur (event bus). Kurallar, olay modelleriyle eşleşir ve 30’dan fazla hedef türüne (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose) fan-out yapar. SNS’teki gibi sadece özniteliklere değil, mesaj gövdesine göre de içeriğe dayalı filtreleme sunar:

{
  "source": ["tenant.energy"],
  "detail-type": ["UsageReported"],
  "detail": { "kWh": [{ "numeric": [">", 100] }] }
}

Bir kuralın en fazla beş hedefi olabilir ve her biri ham olayı veya dönüştürülmüş bir alt kümeyi alabilir. Girdi dönüştürücüler (Input transformers) gevşek bağlılığı (loose coupling) zorunlu kılar: bir InputPathsMap olaydan JSON yollarını çıkarır ve bir InputTemplate bunları tam olarak hedefin beklediği şekle dönüştürür:

EventPattern:
  source: ["com.acme.orders"]
  detail-type: ["OrderPlaced"]
Targets:
  - Arn: !GetAtt PaymentValidator.Arn
    InputTransformer:
      InputPathsMap:
        orderId: "$.detail.orderId"
        amount: "$.detail.total"
        card: "$.detail.payment.cardToken"
      InputTemplate: |
        {"orderId": <orderId>, "amount": <amount>, "cardToken": <card>}

Her doğrulama Lambda’sı yalnızca ihtiyacı olanı alır; adres doğrulayıcı kart token’ını asla görmez. Bu, olayın tamamını alan ve dahili olarak dallanan monolitik bir Lambda’dan kesinlikle daha üstündür — monolitik bir yapı IAM izinlerini tek bir yerde toplar (tek bir rolün tüm aşağı akış izinlerine sahip olması gerekir), bir hatanın etki alanını (blast radius) genişletir, dağıtım (deployment) döngülerini birbirine bağlar, sorumluluğa göre bellek/zaman aşımı ayarını engeller ve tüm fonksiyonu en gürültülü dalın oranına göre ölçeklenmeye zorlar.

API hedefleri (API destinations) yönü tersine çevirir: EventBridge harici bir HTTPS uç noktasını çağırır. Secrets Manager’da Basic, API anahtarı veya OAuth kimlik bilgilerini saklayan bir bağlantı (connection) ile eşleştirildiğinde bu, örneğin bir AWS Batch işi başarılı olduğunda üçüncü taraf bir SaaS’ı bilgilendirmenin sunucusuz yoludur — Lambda gerekmez. EventBridge durum değişikliği olayını yakalar, bir kural JobSucceeded ile eşleşir ve API hedefi, bağlantıdan enjekte edilen kimlik bilgileriyle satıcıya POST isteği gönderir.

Zamanlanmış kurallar (cron/rate ifadeleri) veya daha yeni olan EventBridge Scheduler, periyodik görevler (gecelik raporlar, saatlik önbellek yenileme) için kullanılan “heartbeat” EC2 sunucularının yerini alır.

Filtreleme mesaj gövdesi içeriğine (sadece özniteliklere değil) dayalı olduğunda, yeni tüketicilerin üretici değişiklikleri olmadan sonradan eklenmesi gerektiğinde veya yönlendirme hesapları ya da SaaS kaynaklarını kapsadığında SNS yerine EventBridge’i seçin. Fan-out, kararlı bir abone kümesine basit, öznitelik filtreli bir bildirim olduğunda SNS’i seçin.

Step Functions: Orkestrasyon ve Dağıtık Harita (Distributed Map)

Bir iş akışı birkaç adımdan, dallanmadan, yeniden denemelerden, insan onayından veya uzun beklemelerden fazlasını içerdiğinde, bu mantığı zincirleme Lambda’lar arasına gömmek sürdürülemez hale gelir. Step Functions, durum makinesini Amazon States Language ile dışsallaştırır.

• Standart iş akışları: bir yıla kadar, tam olarak bir kez (exactly-once) semantiği, tam yürütme geçmişi, insan/harici kapılar için .waitForTaskToken. Sipariş karşılama, ETL, onay akışları.
• Ekspres iş akışları: beş dakikaya kadar, en az bir kez (at-least-once), yüksek hacimli, yürütme başına ucuz. API Gateway arkasında kısa senkron orkestrasyonlar; IoT ve akış dönüşümleri.

Her görev açıkça Retry ve Catch bildirmelidir:

"ValidatePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "PaymentValidator", "Payload.$": "$"},
  "Retry": [{
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
    "IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
  }],
  "Catch": [{"ErrorEquals": ["PaymentDeclined"], "Next": "RefundStep"}],
  "Next": "ShipOrder"
}

Parallel ve Map durumları, dalları eş zamanlı olarak çalıştırır ve sonuçları birleştirir — bağımsız doğrulayıcılara (adres, envanter, ödeme) sahip sipariş sistemleri için temiz bir çözümdür. Adımlar arasındaki durum, yürütmenin JSON belgesi üzerinden akar ve yalnızca iş akışı koordinasyonu için kullanılan paylaşılan bir veritabanı ihtiyacını ortadan kaldırır.

.waitForTaskToken deseni, harici bir aktör token ile SendTaskSuccess çağrısı yapana kadar yürütmeyi duraklatır — bir iş akışı Lambda’ları, EC2’yi, container’ları, şirket içi (on-prem) sistemleri kapsadığında ve minimum operasyonel yük ile manuel onay gerektirdiğinde standart cevaptır:

"ManagerApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111:approvals",
    "Message": { "TaskToken.$": "$$.Task.Token", "OrderId.$": "$.orderId" }
  },
  "Next": "Fulfill"
}

Distributed Map, standart Map durumunu 10.000’e kadar paralel alt yürütmeyi işlemek üzere genişletir ve otomatik gruplama (batching), kontrol noktası oluşturma (checkpointing) ve hata toleransı ile doğrudan bir S3 bucket’ındaki nesneler veya bir CSV/JSONL dosyasındaki satırlar üzerinde yineleme yapabilir. Binlerce yarı yapılandırılmış S3 nesnesi için operasyonel olarak en verimli seçenektir — bir prefix’e yönlendirin, öğe başına görevi tanımlayın ve Step Functions fan-out, MaxConcurrency, yeniden denemeler ve sonuç birleştirmeyi yönetir:

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "raw-events", "Prefix": "2024/" }
  },
  "MaxConcurrency": 1000,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
    "StartAt": "ProcessObject",
    "States": { "ProcessObject": { "Type": "Task", "Resource": "arn:aws:lambda:...:function:ProcessOne", "End": true } }
  }
}

Aynısını SQS veya EventBridge üzerinde yeniden oluşturmak, tamamlama, yeniden denemeler ve sonuçların birleştirilmesi için özel kayıt tutma gerektirir.

Step Functions vs. EventBridge: Sırayı ve sonucu sizin yönettiğiniz durumlarda — durum, dallanmalar, yeniden denemeler, onaylar — Step Functions doğrudur. Üreticilerin kimin tükettiğini bilmediği veya umursamadığı ve tüketicilerin bağımsız olarak bağlandığı durumlarda ise EventBridge doğrudur.

S3 Olay Bildirimleri

Yüklemelerin neredeyse gerçek zamanlı işlenmesi için, bir Lambda hedefiyle s3:ObjectCreated:* (veya Put, Post, CompleteMultipartUpload gibi belirli bir varyant) üzerinde S3 olay bildirimlerini yapılandırın — yukarıdaki ani artış (burst) uyarılarına tabidir. Koruma mekanizmaları:

• Alt sistemdeki bir veritabanını korumak için ayrılmış eşzamanlılık (reserved concurrency) ayarlayın.
• Zehirli mesajlar (poison messages) için bir DLQ veya on-failure destination etkinleştirin.
• Birden fazla tüketicinin aynı olaylara ihtiyacı olduğunda S3 olaylarını EventBridge üzerinden yönlendirin. Doğrudan S3 bildirim yapılandırmaları sayı ve ifade yeteneği açısından sınırlıdır; hedef başına girdi dönüştürücüler (input transformers) ile EventBridge fan-out çok daha iyi ölçeklenir.

Akış: Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS), 24 saatten 365 güne kadar saklama süresine sahip, parçalara (shard) ayrılmış, sıralı, yeniden oynatılabilir bir log’dur. Sıra, bölüm anahtarına (partition key) göre shard başına korunur — bu, cihaz veya kiracı (tenant) başına toplama için kritiktir. Birden fazla tüketici bağımsız olarak okuma yapar (tüketici başına izole edilmiş verim için enhanced fan-out). Sıralı yeniden oynatma, birden fazla bağımsız tüketici veya shard başına yüksek verim (throughput) gerektiğinde KDS’yi seçin.

Kinesis Data Firehose, S3, Redshift, OpenSearch veya Splunk’a veri teslimi için tam olarak yönetilen bir akıştır ve dahili arabelleğe alma (60 sn veya 1–128 MB), isteğe bağlı Lambda dönüşümü, sıkıştırma (GZIP, Snappy) ve Parquet/ORC formatına dönüştürme özelliklerine sahiptir. Yönetilecek shard yoktur. Özel tüketicilere ve yeniden oynatmaya ihtiyaç duyulmadığında — sadece neredeyse gerçek zamanlı verileri bir yere indirmek gerektiğinde — Firehose, düşük operasyonel yük sunan bir seçenektir.

Standart neredeyse gerçek zamanlı analitik ardışık düzeni şöyledir: üreticiler → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, Firehose içinde isteğe bağlı Lambda zenginleştirmesi ile birlikte.

Yönetilen SFTP için AWS Transfer Family

İş ortakları S3 veya EFS’ye/EFS’den SFTP, FTPS veya FTP gerektirdiğinde, AWS Transfer Family, istemcilerin zaten kullandığı protokolü konuşan, yönetilen, çoklu AZ (multi-AZ) bir uç nokta sağlar. Kimlik doğrulama, hizmet tarafından yönetilen kullanıcıları, SSH anahtarlarını veya API Gateway/Lambda aracılığıyla özel IdP’leri (Kimlik Sağlayıcıları) destekler. Dosyalar, SSE ve yaşam döngüsü politikaları uygulanmış olarak doğrudan S3’e iner; IAM kapsam daraltma (scope-down) politikaları her kullanıcıyı belirli bir prefix ile kısıtlar.

Bunu EC2 üzerinde kendiniz oluşturmak, OpenSSH sağlamlaştırması, yama yönetimi, AZ’ler arasında yüksek erişilebilirlik (HA), anahtar rotasyonu ve log gönderimi gerektirir — Transfer Family tüm bunları üstlenir. Gereksinim “iş ortakları bize SFTP üzerinden dosya gönderiyor” olduğunda ve dosyaları minimum operasyonel yük ile S3’te istediğinizde bu hizmeti seçin.

Standart Bir Sunucusuz Desen Oluşturma

Kiracı başına saatlik metrikler için düşük operasyonel yüke sahip bir veri alım tasarımı: sensörler API Gateway’e (HTTP API, bölgesel) POST yapar → Lambda doğrular ve EventBridge’e yayınlar → kurallar bir DynamoDB yazıcı Lambda’sına (partition key olarak kiracı ID’si, sort key olarak saat dilimi) ve paralel olarak analitik için Firehose → S3 (Parquet)’e yönlendirir. Yeni tüketiciler, üreticilere dokunmadan ek EventBridge kuralları olarak bağlanır — bu, yalnızca SNS’in o kadar temiz bir şekilde karşılayamayacağı bir genişletilebilirlik gereksinimidir. Sürekli yüksek verim ve sıralamanın önemli olduğu yerlerde (fatura mutabakatı, finansal olay akışları), EventBridge’i Kinesis Data Streams ile değiştirin ve bağımsız tüketiciler için enhanced fan-out kullanın.

Tuzak Kataloğu: Yaygın Yanlış Kalıplar Neden Başarısız Olur

Private subnet’teki Lambda’lardan gelen AWS servis trafiği için NAT instance/gateway kullanmak. NAT instance’lar, verimi tek bir EC2 NIC’ine bağlar ve tek bir hata noktası (SPOF) oluşturur; NAT gateway’ler ise GB başına faturalandırılır. Her ikisi de AWS servis hedefleri için gereksizdir. S3/DynamoDB için gateway endpoint’leri, diğer her şey için interface endpoint’leri kullanın.

Gecikmeye duyarlı (latency-critical) API’lerde cold start’ları göz ardı etmek. On-demand, container’ları yalnızca bir istek geldiğinde hazırlar, bu nedenle ani trafik artışları (burst) SLA’ları kaçırır. Provisioned concurrency’yi p95 burst seviyesine göre boyutlandırın; katı SLA’ları olmayan Java iş yükleri için SnapStart kullanın.

Tüm event’i alan ve dahili olarak dallanan monolitik bir Lambda. En az ayrıcalık ilkesini (least privilege) ihlal eder (tek bir rol tüm alt sistem izinlerini tutar), dağıtım döngülerini birbirine bağlar, sorumluluğa göre ayarlama yapmayı engeller ve tüm fonksiyonu en gürültülü dalın oranına göre ölçeklendirir. Sorumluluğa göre ayırın; EventBridge veya Step Functions ile birleştirin.

Çok sayıda Lambda’dan doğrudan veritabanı bağlantıları. Container’lar pool’ları paylaşmadığı için toplam bağlantı sayısı, eş zamanlı çağrı sayısına (concurrent invocations) eşit olur. RDS Proxy (pooling), reserved concurrency (rate cap) veya SQS (buffering) ile düzeltin.

Ani veri alımı (bursty ingestion) için senkron Lambda kullanmak. Concurrency aşıldığında API Gateway’e 429, istemcilere 5xx döner; ani artışlar sırasında S3’ten gelen doğrudan bildirimler event’leri sessizce düşürür. Araya SQS ekleyin veya Gateway → SQS doğrudan entegrasyonunu kullanın.

AuthType: NONE ayarlı ve fonksiyon içinde imza doğrulaması olmayan herkese açık (public) Lambda function URL’leri. Herkese açık internet üzerinde anonim işlem gücü. AWS üzerinden çağıranlar için AWS_IAM kullanın veya üçüncü parti webhook’lar için imzaları doğrulayın.

Yerleşik bir çözümün işe yaradığı durumlarda özel Lambda authorizer kullanmak. Gecikme ekler, yama gerektiren bir fonksiyon daha ortaya çıkarır ve imza kontrolü hatalarının sessizce erişime izin verdiği bir kod yolu oluşturur. AWS principal’ları için IAM yetkilendirmesini; user pool’lar için Cognito authorizer’ı tercih edin.

Custom domain’ler için yanlış ACM sertifika Region’ı kullanmak. Edge-optimized endpoint’ler sertifikanın us-east-1’de olmasını gerektirir; regional endpoint’ler ise API’nin kendi Region’ında olmasını gerektirir.

Push kaynakları (EventBridge, S3, SNS) için AWS::Lambda::Permission izninin eksik olması. Event’ler kurallarla eşleşir ancak çağrılar (invocations) sessizce reddedilir. Execution role’dan farklıdır — bu, fonksiyonun ne yapabileceğini değil, fonksiyonu kimin çağırabileceğini yönetir.

Idempotency eksikliği. Her katman yeniden dener — asenkron çağrılar, visibility-timeout dolduğunda SQS’in yeniden teslim etmesi, Kinesis batch yeniden denemeleri. Deterministik bir tekilleştirme anahtarı (dedup key) ve koşullu yazma (conditional write) olmadan, yinelenen kayıtlar (duplicates) kaçınılmazdır.

← Konteynerler ve Orkestrasyon · Tüm alanlar · Depolama ve Veri Yaşam Döngüsü →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →