Amazon SAP-C02: Hesaplama ve Auto Scaling — Çalışma kılavuzu

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Solutions Architect Professional SAP-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.

EC2 instance tasarımı, depolama ve ağ iletişimi

EC2 instance’larını tasarlamak, iş yükü özelliklerini instance aileleriyle eşleştirmekle başlar; bu süreçte vCPU, bellek, ağ ve yerel depolama dengelenir. Profillemeye dayanarak işlem (compute) optimize (C), bellek optimize (R/X), depolama optimize (I/D) veya GPU (P/G) türlerini seçin. Yüksek ağ verimi (throughput) ve düşük gecikme (latency) için Nitro tabanlı instance’lardan ve ENA/SR-IOV’den yararlanın. Gecikmeye duyarlı veya yüksek IOPS gerektiren geçici veriler için I3/I4 veya Nitro SSD’ler üzerindeki instance store’u (geçici/ephemeral) değerlendirin; dayanıklı blok depolama için Provisioned IOPS (io2/io2 Block Express) özellikli EBS kullanın ve anahtar yönetimi için KMS ile EBS şifrelemesini etkinleştirin. Instance’lar VPC’lerde Application Load Balancer’ların arkasındayken, internete yönelik ALB’lerin public subnet’lere, hedeflerin ise private subnet’lere yerleştirildiğinden emin olun; ALB’leri yanlış yerleştirmek veya security group’ları yanlış yapılandırmak sık karşılaşılan bir tuzaktır. Yerleşimi etkilemek için Placement Group’ları (düşük gecikmeli HPC için cluster, büyük ölçekli dağıtık stateful sistemler için partition, hata yalıtımı için spread) kullanın ancak ödünleşimleri kabul edin: cluster en iyi performansı verir ancak AZ seviyesinde hata toleransını azaltır. Aktarım halindeki şifreli veriler için ALB’de sonlandırılan TLS veya NLB passthrough ile uçtan uca TLS kullanın. Karar kriterleri maliyet ile performansı tartar: daha yoğun (denser) instance türleri maliyeti düşürür ancak etki alanını (blast radius) ve lisanslama maliyetlerini artırabilir; ezbere kurallar yerine CloudWatch, AWS Compute Optimizer ve yük testleri tarafından yönlendirilen doğru boyutlandırmayı (right-sizing) tercih edin.

Auto Scaling grupları, politikaları ve yaşam döngüsü yönetimi

Auto Scaling Group’lar (ASG’ler), launch template’ler, karma instance (mixed-instances) politikaları, yaşam döngüsü kancaları (lifecycle hooks) ve ölçeklendirme politikalarının bir kombinasyonu kullanılarak esneklik, dayanıklılık ve maliyet verimliliği için tasarlanmalıdır. AMI, instance türü geçersiz kılmaları, EBS yapılandırmaları ve user-data’yı versiyonlamak için launch template’leri kullanın; kapasite optimize Spot tahsisi veya çeşitlendirilmiş bir stratejiye sahip karma instance’lar, kesinti riskini azaltır ve maliyeti düşürür. Ölçeklendirme davranışı için, öngörülebilir metrikler (CPU, hedef başına istek sayısı) için hedef izleme (target-tracking) politikalarını ve eşik tabanlı çok aşamalı eylemler gerektiğinde adım ölçeklendirmeyi (step-scaling) tercih edin; tahmine dayalı ölçeklendirme (predictive scaling), bilinen günlük döngüler için kapasiteyi önceden sağlayabilir. Sonlandırmadan önce özel başlatma veya boşaltma (drain) görevlerini çalıştırmak için yaşam döngüsü kancalarını uygulayın; hizmete başlama süresini (time-to-serve) azaltmak için warm pool’ları ve mesai saatleri taban çizgileri için zamanlanmış ölçeklendirmeyi (scheduled scaling) birleştirin. Sağlık kontrolleri (health checks), erken değiştirmeyi önlemek için ELB ve EC2 sağlık kontrollerini entegre etmelidir. Agresif bekleme sürelerinin (cooldowns) neden olduğu küçülme sırasındaki sirkülasyon (scale-in churn), karma ASG’lerde yanlış instance ağırlıklandırması ve uygulama ısınma süresini (warm-up) hesaba katmama gibi tuzaklara dikkat edin. Stateful servisler için, bellek içi önbellekleri (in-memory caches) kaybettiren hızlı küçülmeden (scale-in) kaçının; maliyet ve dayanıklılık karşılaştırmasında, On-Demand yedekleriyle desteklenen Spot kapasitesi tasarruf sağlar ancak kesinti yönetimi gerektirir; %100 On-Demand ise daha yüksek maliyetle öngörülebilirliği en üst düzeye çıkarır.

Container’lar ve orkestrasyon: ECS, EKS ve Fargate seçimleri

Amazon ECS, EKS ve Fargate arasında seçim yapmak operasyonel modele, kontrol ihtiyaçlarına ve iş yükü desenlerine bağlıdır. Fargate, node yönetimini ortadan kaldırır ve operasyonel basitliğe öncelik veren ekipler için idealdir, ancak vCPU başına daha yüksek fiyatlandırmaya ve geçici (ephemeral) depolama sınırlarına sahiptir; maliyet tasarrufu için Fargate Spot’u destekler. ECS, Kubernetes karmaşıklığı olmadan container orkestrasyonu isteyen müşteriler için sıkı AWS entegrasyonu ve basitlik sağlar. Kubernetes ekosistemi, taşınabilirlik veya gelişmiş zamanlama (scheduling) gerektiğinde EKS uygundur; dinamik doğru boyutlandırma (right-sizing) için yönetilen node gruplarını (managed node groups) veya Self-Managed + Karpenter’ı değerlendirin. Ağ limitleri (ENI/pod yoğunluğu) ve CNI davranışı, pod yoğunluğunu ve node boyutlandırmasını etkiler; EKS üzerinde, Service Account’lar için IAM Rolleri (IAM Roles for Service Accounts) ve kalıcı birimler (persistent volumes) için EBS CSI, kimlik bilgisi dağınıklığını (credential sprawl) azaltır ve pod başına depolamayı mümkün kılar. Paylaşılan dosya sistemleri için, verim (throughput) ve gecikme (latency) ihtiyaçlarına bağlı olarak EFS (NFS) veya FSx (Lustre) kullanın; yüksek metadata işlemleri için NFS destekli container’lardan kaçının—iş yüküne göre ayarlanmış verim modlarına (throughput modes) sahip EFS’yi tercih edin. Node ölçeklendirmesi için cluster autoscaler veya Karpenter’ı ve ALB/ECS servis metrikleriyle servis otomatik ölçeklendirmesini uygulayın. Sık karşılaşılan tuzaklar arasında pod disruption budget’larını göz ardı etmek, Kubernetes control plane kotasını hafife almak ve bin-pack stratejileri kullanmak yerine node’ları aşırı sağlamak (overprovisioning) yer alır; kontrol, maliyet ve operasyonel yük arasındaki ödünleşimler seçimi yönlendirmelidir.

Sunucusuz (Serverless) işlem desenleri, Lambda kısıtlamaları ve olay güdümlü (event-driven) tasarım

Sunucusuz mimari, operasyonel yükü azaltır ancak eş zamanlılık, durum (state) ve alt sistem (downstream) limitlerini ele alan mimari desenler gerektirir. Lambda, kısa ömürlü, olay güdümlü görevler, API Gateway veya ALB aracılığıyla API arka uçları (backend) ve SQS veya SNS ile asenkron işlemler için mükemmeldir. Uzun süren iş akışlarını düzenlemek (orchestrate) için Step Functions’ı, veritabanı erişimi için ise bağlantı fırtınalarını (connection storms) azaltmak amacıyla DynamoDB veya RDS Proxy’yi kullanın. ENI oluşturulmasından kaynaklanan Lambda VPC soğuk başlatma (cold-start) ek yüküne dikkat edin; gecikmeye duyarlı (latency-sensitive) uç noktalar için ‘provisioned concurrency’ (sağlanmış eş zamanlılık) ile bunu azaltın veya bağlantıları sınırlamak için VPC uç noktaları (endpoints) ve RDS Proxy kullanın. Sıralı akış işleme (stream processing) için SNS + SQS veya Kinesis/MKS aracılığıyla fan-out/fan-in uygulayın; yeniden denemeleri ve yinelenen işlemleri yönetmek için SQS ‘dead-letter queue’lerini (işlenemeyen mesaj kuyrukları) ve ‘idempotent’ (tekrarlandığında aynı sonucu veren) işleyicileri (handler) kullanın. Zincirleme arızaları (cascading failures) önlemek için eş zamanlılık limitleri, ‘reserved concurrency’ (ayrılmış eş zamanlılık) ve ’throttling’ (kısıtlama) planlanmalıdır; ’throttles’ (kısıtlayıcılar), ‘jitter’ (rastgele gecikme) ile yeniden denemeler ve ‘circuit breaker’ (devre kesici) (API Gateway veya özel) mekanizmaları kullanarak ‘backpressure’ (geri basınç) için tasarım yapın. Maliyet-performans dengesi nettir: Lambda, ani yükselen (spiky) ve kısa süreli işler için maliyet etkin iken, Fargate veya EC2 sürekli yüksek CPU kullanımı gerektiren veya uzun süren görevler için daha iyidir. Yaygın tuzaklar arasında, alt sistemleri aşırı yükleyen senkron yeniden denemelere güvenmek, kalıcılık beklentisiyle durumu yerel /tmp dizininde saklamak ve gecikmenin kritik olduğu akışlarda soğuk başlatmalar için hazırlık yapmamak yer alır.

Pratik Problem: NovaTel Enterprise çağrı merkezi geçişi

Senaryo: NovaTel Enterprise, şirket içi (on-premises) çağrı yönlendirmesi ve AWS’e bir Direct Connect bağlantısı olan hibrit bir çağrı merkezi işletmektedir. İki Erişilebilirlik Alanı’nda (Availability Zone) EC2 üzerinde oturum aracıları (session brokers) çalıştırmaktadırlar ve şirket içi PBX ile bulut hizmetleri arasında yüksek erişilebilirlik ve öngörülebilir gecikme süresi sunan, AWS tarafından yönetilen bir çağrı merkezine geçiş yapmak istemektedirler.

Zorluk: SIP trafiği için düşük gecikmeli bağlantıya, Spot kesintilerini tolere edebilen ses işleme için ölçeklenebilir bir işlem katmanına ve operasyonel karmaşıklığı artırmadan Bölgeler (Regions) arası bir felaket kurtarma (DR) stratejisine ihtiyaçları var.

Önerilen Yaklaşım:

Çağrı merkezi işlevselliği için Amazon Connect’i sağlayın ve düşük gecikmeli SIP trunking için bir AWS Transit Gateway ile Site-to-Site VPN veya Direct Connect kullanın. Bu bağlantıyı, oturum aracılarının önündeki TLS passthrough özellikli bir NLB’de sonlandırın.
Oturum işleme bileşenlerini, kapasite optimizasyonlu Spot ve yedek olarak On-Demand kullanan başlatma şablonları (launch templates) ile karma bir Auto Scaling Group olarak çalıştırın ve kritik aracıların hata izolasyonu için ‘Placement Groups’ (spread) kullanın.
Geçici, düşük gecikmeli depolama gerektiren durum bilgili (stateful) çağrı medyası için, medya arabelleğe alma (buffering) amacıyla ‘instance store’ destekli (Nitro) bulut sunucuları kullanın ve oturum meta verilerini çoklu AZ (multi-AZ) replikasyonu ile DynamoDB veya ElastiCache’e çoğaltın; kalıcı veriler için RDS (Multi-AZ) veya DR amacıyla Bölgeler arası okuma replikaları (read replicas) olan Aurora Global DB kullanın.
Aracıların soğuk başlatmasını en aza indirmek için ’lifecycle hooks’ ve ‘warm pools’ uygulayın, Bölgeler arası DR için Route 53 ağırlıklı yük devretme (weighted failover) kullanın ve uyarı (alerting) ile otomatik yük devretme ‘runbook’ları için CloudWatch + SNS/SQS’i kullanın.

Gerekçe: Yönetilen çağrı merkezi hizmetlerini kullanmak operasyonel yükü azaltırken, Spot içeren karma ASG’ler maliyeti optimize eder; geçici medyanın ‘instance store’larda izole edilmesi performansı korur ve DynamoDB/ElastiCache’e dayanıklı durum çoğaltması ile çoklu AZ RDS/Aurora, profesyonel mimari en iyi uygulamalarıyla tutarlı bir şekilde esneklik ve hızlı yük devretme sağlar.

← Güvenlik · Tüm alanlar · Depolama ve Veri Yönetimi →

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