Amazon SOA-C02: Sunucusuz ve Uygulama Entegrasyonu — Çalışma kılavuzu

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SysOps Administrator Associate SOA-C02 — Ç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.

Sunucusuz mimari ve uygulama entegrasyonu, sunucuları yönetmeden olay güdümlü uygulamaları çalıştırmayı ve servisleri güvenilir bir şekilde birbirine bağlamayı kapsar. Operasyonel önemi, maliyetleri öngörülebilir tutarken ölçeği, gecikmeyi, hata modlarını ve en az ayrıcalık ilkesiyle erişimi yönetmekte yatar. Bu alan, Lambda davranışlarına (soğuk başlangıçlar, eş zamanlılık), güvenilir olay teslimine (EventBridge, SNS, SQS), güvenlik kontrollerine (yürütme rolleri ve izinler) ve asenkron akışlar için gözlemlenebilirliğe odaklanır.

AWS Lambda operasyonel yönleri ve eş zamanlılık

Lambda performansı ve kullanılabilirliği; soğuk başlangıçlara, eş zamanlılık limitlerine ve kısıtlama kontrollerine bağlıdır. Soğuk başlangıçlar, Lambda’nın yeni bir yürütme ortamı başlatması gerektiğinde meydana gelir; gecikmeye duyarlı yollar için sağlanmış eş zamanlılık (

undefined

) kullanarak etkiyi azaltın ve daha hafif çalışma zamanlarını veya daha küçük başlatma işlerini tercih edin. Aşağı akış servislerini korumak ve fonksiyon başına kotaları zorunlu kılmak için ayrılmış eş zamanlılık (

undefined

) ile eş zamanlılığı ayırın ve sınırlayın; ConcurrentExecutions ve Throttles CloudWatch metriklerini izleyin.

Yeniden deneme ve çağırma modelleri moda göre farklılık gösterir: senkron çağrılar (API Gateway, doğrudan Invoke) hataları anında döndürür; asenkron çağrılar (EventBridge, SNS, S3 asenkron bildirimleri) Lambda’nın asenkron yeniden deneme politikasını (geri çekilme ile iki yeniden deneme) kullanır ve DLQ’ları veya hedefleri (destinations) kullanabilir. Olay kaynağı eşlemeleri (SQS, Kinesis, DynamoDB akışları) için, Lambda’nın yoklayıcısı (poller), mesajın süresi dolana veya olay kaynağının yeniden yönlendirme politikası bir işlenemeyen mesajı tetikleyene kadar yeniden dener. Yinelenen işlemeyi azaltmak için zaman aşımını ve belleği ihtiyatlı bir şekilde yapılandırın (

undefined

) ve SQS görünürlük zaman aşımını > fonksiyon zaman aşımı (önerilen: görünürlük >= fonksiyon zaman aşımı * 2) olarak ayarlayın.

EventBridge ile olay güdümlü mimariler

EventBridge, esnek yönlendirme, şema kaydı, hesaplar arası teslimat ve yeniden deneme/DLQ ayarlarına sahip yönetilen bir olay yolu (event bus) sağlar. Alan ayrımı için özel olay yollarını ve SaaS entegrasyonları için iş ortağı olay yollarını kullanın; desenlerle kurallar oluşturun (

undefined

) ve işlenemeyen mesaj ve yeniden deneme yapılandırmasıyla hedefler ekleyin (hedefler JSON’u DeadLetterConfig ve RetryPolicy’yi destekler). Olay şekillerini keşfetmek ve zorunlu kılmak için şema kaydını kullanın; üreticiler iyi tanımlandığında şemaları kaydedin ve yararlı olduğu durumlarda tipli modeller oluşturmak için Kod Bağlamalarını (Code Bindings) kullanın.

Şu durumlarda EventBridge’i seçin:

• Zengin olay desenleri veya hesaplar arası/olay yolu izolasyonu ile karmaşık yönlendirme ve filtreleme
• Birden çok hedef (Lambda, Step Functions, Kinesis, SQS, SNS) için yerel destek
• Ekipler arasında şema keşfi ve yönetişimi

Daha basit fan-out veya garantili kuyruk semantiği gerektiğinde doğrudan SNS/SQS’i seçin:

• Birçok aboneye fan-out ve push semantiği için SNS
• Görünürlük zaman aşımı ve yeniden yönlendirme politikaları ile dayanıklı, pull tabanlı işleme için SQS

SNS ve SQS ile mesajlaşma (DLQ’lar, görünürlük zaman aşımı)

SNS bir pub/sub push servisidir; SQS ise pull semantiğine sahip dayanıklı bir kuyruktur. Yüksek güvenilirlikli işleme için, alımı (ingestion) işlemeden ayırmak ve yeniden denemeler ile görünürlük üzerinde kontrol sahibi olmak amacıyla SNS -> SQS -> Lambda desenlerini tercih edin. Mesajları maxReceiveCount’tan sonra bir DLQ’ya taşımak için SQS yeniden yönlendirme politikasını (

undefined

) yapılandırın ve erken yeniden teslimatı önlemek için görünürlük zaman aşımının yeterince uzun olduğundan emin olun (önerilen: görünürlük >= fonksiyon zaman aşımı * 2). FIFO ihtiyaçları için, sırayı korumak amacıyla mesaj grubu kimlikleriyle (message group IDs) ve tekrarları önlemek için tekilleştirme kimlikleriyle (deduplication IDs) SQS FIFO veya SNS FIFO kullanın.

İşlenemeyen mesajları yönetme seçenekleri ve nerede kullanılacakları:

• Lambda asenkron çağrıları: Başarısızlıkları SQS/SNS’e göndermek veya başka bir Lambda’yı çağırmak için DeadLetterConfig veya Hedefleri (Destinations - AsyncEventInvokeConfig) yapılandırın.
• SQS: Zehirli mesajlar (poison messages) için SQS DLQ’ya yeniden yönlendirme politikasını yapılandırın ve uygun maxReceiveCount değerini ayarlayın.
• EventBridge: Teslim edilemeyen olayları yakalamak için kural hedeflerinde DeadLetterConfig ve RetryPolicy’yi ayarlayın.

Idempotency esastır: DynamoDB koşullu yazmalarını (PutItem ile ConditionExpression attribute_not_exists(pk)), TTL ile saklanan idempotency belirteçlerini veya tam olarak bir kez işleme (exactly-once) semantiği için SQS FIFO tekilleştirmesini kullanarak idempotent işleyiciler (handler) uygulayın.

Fonksiyon izinleri, roller ve en az ayrıcalık ilkesi

Lambda yürütme rollerine ve fonksiyon kaynak politikalarına en az ayrıcalık ilkesini uygulayın. CloudWatch Logs için AWSLambdaBasicExecutionRole ile başlayın, ardından servisler için açık kaynak ARN’leri verin (örneğin, arn:aws:dynamodb:region:acct:table/MyTable üzerinde dynamodb:PutItem). Belirli ARN’lerin mümkün olduğu durumlarda Resource: “*” gibi joker karakterlerden kaçının. Eylem ve kaynağa göre kapsamı belirlenmiş yönetilen veya özel politikalar kullanın ve servisler için çağırma izinleri eklerken koşulları (aws:SourceAccount, aws:SourceArn) dahil edin:

• EventBridge için çağırma izni ekleme:

undefined

• SNS için: Fonksiyonu hangi konunun (topic) çağırabileceğini sınırlamak için source-arn koşulunu kullanın

Karar kriterleri:

• Servis çağrılarına (EventBridge, SNS, CloudWatch Events) izin vermek için fonksiyon kaynak tabanlı politikaları kullanın
• Çalışma zamanı izinleri (DynamoDB, S3, Secrets Manager) için IAM yürütme rolünü kullanın
• Etki alanını (blast radius) azaltmak için kaynak seviyesinde izinleri ve koşullu kısıtlamaları tercih edin

Sunucusuz (Serverless) için Gözlemlenebilirlik ve Sorun Giderme

Gözlemlenebilirlik; metrikleri, logları, izleri (trace) ve asenkron teslimat durumunu kapsamalıdır. Önemli CloudWatch metrikleri: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (stream ve SQS tetikleyicileri için). Asenkron hata görünürlüğü için “AsyncEventInvoke” metriklerini izleyin ve DeadLetterErrors ile Throttles üzerine CloudWatch Alarms kurun. Servisler arasında uçtan uca izler (trace) elde etmek ve cold-start’ları, aşağı akış (downstream) gecikmelerini ve istisnaları görselleştirmek için X-Ray izlemeyi etkinleştirin (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active).

Hata kalıplarını hızla bulmak için yapılandırılmış JSON logları ve CloudWatch Logs Insights sorgularını kullanın; idempotency kontrollerini kodunuza ekleyin ve korelasyon ID’lerini loglara kaydedin. Dağıtık izleme (distributed tracing) için, otomatik bağlamın kaybolduğu EventBridge/SNS akışlarında, izleme ID’lerini (trace ID) olay (event) yüklerinde açıkça yayın. SQS olay kaynağı eşleştirmeleri (event-source mappings) için ApproximateAgeOfOldestMessage metriğini izleyin ve bu değerin artması durumunda alarm kurun; bu durum geri basınç (backpressure) veya kısıtlamayı (throttling) gösterir. Lambda Throttles metriğini yakalayıp bu konuda uyarılar oluşturun ve atanan eş zamanlılık (provisioned concurrency) kullanım/maliyet dengesini takip edin.

Yaygın Hatalar ve Karar Kriterleri

• DLQ’ları yapılandırmamak veya yalnızca varsayılan yeniden denemelere güvenmek: Zehirli mesajları (poison messages) manuel inceleme için yakalamak amacıyla asenkron Lambda’lar için DLQ’ları veya Destinations’ı ve kuyruklar için SQS redrive özelliğini yapılandırın.
• SQS’te yanlış visibility timeout ayarı nedeniyle yinelenen işlem yapılması: Yinelenen işlemleri önlemek için visibility timeout değerini >= fonksiyon zaman aşımı * 2 olarak ayarlayın ve yeniden denemeleri ile aşağı akış (downstream) çağrılarını hesaba katın.
• Aşırı izinli Lambda yürütme rolleri: Resource: “*” kullanımından kaçının ve çağırma (invocation) ve kaynak politikalarına servis/kaynak koşulları (aws:SourceArn, aws:SourceAccount) ekleyin.
• Kısıtlamaya (throttling) neden olan eş zamanlılık limitlerini göz ardı etmek: Fonksiyonları sınırlamak için ayrılmış eş zamanlılık (reserved concurrency), gecikmeye duyarlı fonksiyonlar için atanan eş zamanlılık (provisioned concurrency) kullanın ve ConcurrentExecutions/Throttles metriklerini izleyin.
• Asenkron sınırlar arasında izlemenin (tracing) eksik olması: Akışları yeniden oluşturmak için olaylara (event) korelasyon ID’leri ekleyin ve X-Ray’i etkinleştirin veya izleme başlıklarını (trace headers) yayın.
• Dayanıklılık (durability) ihtiyaçları için SNS’ten doğrudan Lambda’ya yönlendirmeyi yanlış kullanmak: Dayanıklı arabelleğe alma (buffering), görünürlük kontrolü ve daha kolay DLQ yönetimi gerektiğinde SNS->SQS->Lambda modelini tercih edin.

Pratik Problem: Örnek Senaryo

AcmePayments, EventBridge üzerinden yüksek hacimli ödeme olayları (event) alıyor ve yoğun zamanlarda aralıklı olarak Lambda kısıtlaması (throttling) ve yinelenen işlemlerle karşılaşıyor. Güvenilir işlemeye, veri kaybı olmamasına ve DynamoDB üzerindeki aşağı akış (downstream) yükünün sınırlı olmasına ihtiyaçları var.

1. Ödeme olaylarını eşleştirmek için bir EventBridge özel veri yolu (custom bus) ve kural oluşturun; hedef yapılandırmasında DeadLetterConfig ve RetryPolicy ile dayanıklı bir hedef olarak bir SQS FIFO kuyruğu ekleyin.
2. Lambda’yı, aşağı akış (downstream) kapasitesine göre ayarlanmış batch size ve >= fonksiyon zaman aşımı * 2 olarak ayarlanmış visibility timeout ile SQS kuyruğunu yoklayacak (event source mapping) şekilde yapılandırın.
3. DynamoDB yazma patlamalarını sınırlamak için Lambda için eş zamanlılık ayırın (aws lambda put-function-concurrency …); düşük gecikme gerekiyorsa küçük bir havuz için atanan eş zamanlılık (provisioned concurrency) uygulayın.
4. payment-id ile anahtarlanmış DynamoDB koşullu yazmalarını (conditional writes) kullanarak idempotency’yi uygulayın ve idempotency kayıtlarını temizlik için TTL ile saklayın.
5. İşlemeyi izlemek için olayda (event) bir korelasyon ID’si ile X-Ray izlemeyi ve yapılandırılmış logları etkinleştirin; ApproximateAgeOfOldestMessage, Throttles ve DLQ metrikleri üzerine CloudWatch alarmları kurun.

Gerekçe: EventBridge’i SQS ile ayrıştırmak, dayanıklı arabelleğe alma (buffering) ve yeniden deneme semantiği sağlar; ayrılmış eş zamanlılık (reserved concurrency) aşağı akış (downstream) DynamoDB’yi ani yük patlamalarından korur, idempotency yinelenen işlemleri önler ve izleme/alarmlar hata modlarına karşı operasyonel görünürlük sağlar.

← Veritabanları ve Önbelleğe Alma · Tüm alanlar · Maliyet Yönetimi ve Kaynak Etiketleme →

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

Amazon'a göz atın →