Amazon SAA-C03: Bilişim, Auto Scaling ve Örnek Yönetimi — Ç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.

EC2 Bulut Sunucusu Türleri ve AMI’ler

Doğru EC2 bulut sunucusu ailesini seçmek, iyi tasarlanmış bir işlem katmanının temelidir; çünkü aile, nesil ve boyut bir araya gelerek CPU mimarisini, bellek-vCPU oranını, ağ bant genişliğini ve mevcut hızlandırıcıları belirler. Genel amaçlı (M6i, M7g, T-serisi) bulut sunucuları, dengeli web katmanları ve karma iş yüklerine uygundur. İşlem için optimize edilmiş (C7i, C7gn) bulut sunucuları, CPU’ya bağlı simülasyonlar, kodlama, toplu işleme ve web ön uçları için idealdir. Bellek için optimize edilmiş (R7i, X2idn) bulut sunucuları, bellek içi veritabanlarını ve önbellekleri hedefler. Depolama için optimize edilmiş (I4i, D3) bulut sunucuları, NoSQL, HDFS ve veri ambarlarını hedefler. Hızlandırılmış (P5, G5, Trn1, Inf) bulut sunucuları, GPU’lar veya ML silikonu sağlar. Graviton (g soneki) bulut sunucuları, ARM64’e sorunsuz bir şekilde derlenen yatayda ölçeklenen iş yükleri için genellikle %20-40 daha iyi fiyat-performans sunar.

T-ailesi atılgan (burstable) olup varsayılan olarak standart modda çalışır; bu modda CPU kredileri boşta kalındığında birikir ve ani artışlar sırasında tükenir; krediler tükendiğinde performans temel seviyeye düşürülür. Öngörülemeyen ani artışlar gösteren iş yükleri (küçük web katmanları, geliştirme/test ortamları veya anlık artış gösteren bir ön ucu destekleyen Elastic Beanstalk ortamları) için sınırsız moddaki T-bulut sunucuları, bulut sunucusunun kredi ödünç almasına ve aşım yapılan her vCPU-saat için küçük bir ek ücret faturalandırmasına olanak tanıyarak kullanıcı tarafından fark edilen performans düşüşünü önler. Kısa süreli CPU doygunluğu yaşayan Beanstalk ortamlarının, daha maliyetli, işlem için optimize edilmiş bir aileye yükseltmek yerine genellikle sınırsız modun etkinleştirilmesiyle düzeltilmesinin nedeni budur. T-serisini gerçekten anlık artış gösteren, düşük ortalamalı iş yükleri için ayırmak önemlidir: standart modda sürekli CPU kullanımı, kredileri dakikalar içinde tüketir.

Dikey ölçeklendirme (aile içindeki daha büyük bir boyuta geçme), mevcut en büyük bulut sunucusuyla sınırlıdır, değişiklik için kesinti gerektirir, tek bir hata noktası oluşturur ve iş yükünü Kullanılabilirlik Alanları (Availability Zones) arasında dağıtamaz. Yükün önemli ölçüde değiştiği durumlarda, bir Auto Scaling grubu ile yatay ölçeklendirme doğru yanıttır.

Altın AMI’ler (Golden AMI), uygulama kodunu, çalışma zamanını ve bağımlılıkları kök anlık görüntüye (snapshot) dahil ederek hızlı ve deterministik başlatmalar sağlar; bu, Auto Scaling bir ani artışa tepki verdiğinde kritik öneme sahiptir. Her başlatmada user-data aracılığıyla önyükleme yapmak, tam da en yanlış anda dakikalarca gecikme ekler.

Depolama Seçenekleri: Instance Store ve EBS Karşılaştırması, Anlık Görüntüler ve Hızlı Anlık Görüntü Geri Yükleme

Bulut sunucuları iki depolama altyapısı sunar: instance store (fiziksel ana makineye bağlı geçici NVMe) ve Amazon EBS (ağa bağlı blok depolama). Instance store mümkün olan en düşük gecikmeyi sunar ancak verileri durdurma, hazırda bekletme, sonlandırma veya donanım arızası durumunda yok edilir. Bunu kalıcı depolama olarak değerlendirmek yaygın ve tehlikeli bir hatadır; yalnızca geçici çalışma alanı, arabellekler, önbellekler veya replikaları diğer düğümlerde bulunan bir HDFS veri düğümü gibi çoğaltılmış veriler için uygundur. Kalıcı veriler, S3’te depolanan anlık görüntülerle desteklenen EBS üzerinde bulunmalıdır.

Anlık görüntüler oluşturulduktan sonra artımlı ve bağımsızdır, bu nedenle birini yeni bir birime geri yüklemek kaynak birimi asla etkilemez. Büyük bir üretim veri setini bir test ortamına kopyalamanın standart yolu, kaynak birimin anlık görüntüsünü almak ve bu anlık görüntüden yeni birimler oluşturmaktır. Ancak, anlık görüntülerden geri yüklenen birimler, ilk okumada S3’ten blokları yavaş yükler (lazy-load), bu da her blok tamamen yüklenene kadar önemli G/Ç gecikmesine neden olur. Aynı yavaş yükleme, kök anlık görüntüleri büyük olan AMI’lerden başlatılan yeni bulut sunucularını da etkiler; bu sunucular başlatıldıktan sonra birkaç dakika boyunca yavaş görünürler.

EBS Fast Snapshot Restore (FSR) bu dezavantajı ortadan kaldırır. ASG’nin bulut sunucularını başlattığı AZ’ler için anlık görüntüde FSR’yi etkinleştirin; ondan oluşturulan birimler anında tam olarak sağlanan performansı sunar:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Bu, yatay ölçeklendirme olaylarının dakikalar yerine saniyeler içinde kapasite eklemesi gerektiğinde çok önemlidir.

ENA ve EFA ile Gelişmiş Ağ Özellikleri

Tanıtılan ağ verim oranı bulut sunucusu boyutuna göre ölçeklenir, ancak yalnızca Elastic Network Adapter (ENA) sürücüsü mevcut olduğunda elde edilebilir. ENA, SR-IOV tabanlı gelişmiş ağ özellikleri sunarak daha yeni bulut sunucularında 200 Gbps’ye kadar destek sağlar. Modern AMI’ler (Amazon Linux 2, güncel Ubuntu, Windows) ENA etkinleştirilmiş olarak gelir; doğrulamak için:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

ENA olmadan, bulut sunucuları sessizce daha düşük verim oranına ve daha yüksek titreşime (jitter) düşer, bu da seçilen yerleşim grubundan (placement group) bağımsız olarak herhangi bir düşük gecikmeli tasarımı baltalar.

Mikrosaniye ölçeğindeki kolektif işlemler (CFD, hava durumu modellemesi, moleküler dinamik, büyük model eğitimi) için Elastic Fabric Adapter (EFA) ekleyin. EFA, MPI ve NCCL’ye işletim sistemini atlayan bir taşıma katmanı (Libfabric) sunarak çekirdek ağ yığınını tamamen devre dışı bırakır. EFA, avantajını yalnızca desteklenen bulut sunucusu türlerinde (c7gn, hpc7a, p5) bir küme yerleşim grubu (cluster placement group) içinde sunar ve EFA sürücüsünün yanı sıra uyumlu bir MPI (Open MPI, Intel MPI) veya NCCL derlemesi gerektirir.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Yerleşim Grupları

Yerleşim grupları, instance’ların fiziksel topolojisini kontrol eder:

Yanlış seçim yapmak bu özelliğin boşa harcanmasına neden olur. Bir cluster grubu AZ’ler arasına yayılamaz — tasarımı gereği AZ içidir. Spread, AZ başına yedi tavanı nedeniyle yüzlerce web sunucusunu barındıramaz. 40 düğümlü bir Kafka kümesi için doğru araç spread değil, partition yerleşimidir, çünkü replica yerleşimini hata etki alanlarıyla (fault domain) hizalar. Genel yüksek erişilebilirlik için bir ASG’yi tek bir AZ’deki tek bir yerleşim grubuyla sınırlamayın — ASG’yi birden çok AZ’ye yayın.

Minimum düğümden düğüme gecikme gerektiren akış analitiği veya MPI iş yükleri için doğru kombinasyon, cluster yerleşim grubu artı ENA etkinleştirilmiş instance’lardır; cluster, atlama sayısını (hop count) azaltır ve ENA, bu gecikme avantajını gerçekleştirmek için gereken saniye başına paket kapasitesini sunar.

Auto Scaling Grupları ve Launch Template’ler

Bir Auto Scaling grubu (ASG), bir veya daha fazla AZ’de istenen sayıda EC2 instance’ını koruyan çalışma zamanı birimidir ve üç tamsayı — MinSize, DesiredCapacity, MaxSize — ve bir alt ağ (subnet) listesi ile tanımlanır. ASG’nin kendisi ne başlatılacağını tanımlamaz; bu, launch configuration’ların modern alternatifi olan bir launch template‘in sorumluluğundadır. Launch template’ler sürümlemeyi, karma instance politikalarını, Spot/On-Demand karışımını, IMDSv2 zorunluluğunu, kapasite rezervasyonlarını ve sınırsız modda T-instance’ları destekler. Bir launch template; bir AMI, instance türü/türleri, güvenlik grupları, IAM instance profili, kullanıcı verileri (user data) ve blok cihaz eşlemelerini (block device mappings) referans alır.

Standart durum bilgisi olmayan (stateless) web deseni AMI + Launch Template + ASG + ALB şeklindedir. AMI hızlı başlatma sağlar; ALB (veya TCP/UDP için NLB) trafiği dağıtır ve sağlık kontrollerini (health check) yürütür; ASG, yeni instance’ları hedef gruba (target group) otomatik olarak kaydeder ve sağlıksız olanları sonlandırır. Çoklu AZ dağıtımı (minimum iki AZ, quorum sistemleri için üç) zorunludur — tek bir alt ağa bağlı bir ASG, bir AZ kesintisinden sağ çıkamaz çünkü AZ arızalıyken ASG’nin kendisi yeni instance’lar başlatamaz.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Ölçeklendirme Politikaları: Target Tracking, Step, Scheduled, Predictive

ASG ölçeklendirmenin her biri farklı bir sorunu çözen dört modu vardır:

• Target tracking bir metrik seçer ve onu belirli bir ayar noktasında tutar (ör. ASGAverageCPUUtilization = %50, ALBRequestCountPerTarget = 1000). Kendi kendini ayarlayan bir yapıdadır — AWS alarmları yönetir ve metrik saptıkça hızı ayarlar. Bu, varsayılan tercih olmalıdır.
• Step scaling, bir metriğin aralık dışına ne kadar çıktığına bağlı olarak kademeli seviyelerde kapasite ekler veya çıkarır; bu, reaksiyon büyüklüğünün alarmın ciddiyetiyle ölçeklenmesi gerektiğinde kullanışlıdır.
• Simple scaling eski bir yöntemdir: alarm başına tek bir ayarlama yapar, bekleme (cooldown) süresi boyunca engellenir ve yeni tasarımlar için seçilmemelidir.
• Scheduled scaling, MinSize/DesiredCapacity/MaxSize değerlerini cron zamanlarında değiştirir.
• Predictive scaling, sonraki 48 saati tahmin etmek için 14 güne kadar olan geçmiş veriler üzerinde makine öğrenimini kullanır ve ani artıştan önce kapasiteyi önceden hazırlar.

Dinamik ölçeklendirme doğası gereği gecikmelidir — yalnızca bir metrik aşıldıktan sonra tepki verir ve yeni instance’ların başlatılması, kaydedilmesi ve ısınması dakikalar sürer. Tüm kullanıcıların saat 09:00’da geldiği ve ASG yetişene kadar 2-3 saatlik bir yavaşlık yaşadığı bir iş gücü uygulaması için tek başına dinamik ölçeklendirme yanlış cevaptır. Talebin gelmesinden önce MinSize ve DesiredCapacity değerlerini yükseltmek için zirve saatlerinden önce zamanlanmış eylemler (scheduled actions) katmanını ekleyin:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Ardından, kalan değişkenliği absorbe etmesi için target tracking’e izin verin. Predictive scaling, zirvenin şekli sabit ancak tam zamanlaması günden güne değiştiğinde doğru seçimdir. Öngörülebilir üretim dışı kapatmalar için (geliştirme ortamlarının geceleri ve hafta sonları kapalı olması gibi), Cuma akşamı desired=0, min=0 yapacak ve Pazartesi sabahı tekrar çalıştıracak bir zamanlanmış eylem en az ek yük getiren çözümdür — ASG’nin kendisi zamanlama motoru görevi görür, herhangi bir Lambda veya EventBridge yapıştırıcısına gerek yoktur.

Metrik seçimi, politika seçimi kadar önemlidir. CPU, CPU’ya bağlı web iş yükleri için işe yarar, ancak SQS’ten veri çeken birikmiş iş (backlog) odaklı worker’lar için CPU’ya göre değil, kuyruk derinliğine göre ölçeklendirme yapmalısınız: I/O’da engellenen bir worker, milyonlarca mesaj birikirken %10 CPU kullanımı gösterebilir. Instance başına ApproximateNumberOfMessagesVisible metriğini, özel bir metrik olarak veya yerleşik SQSQueueBacklogPerInstance hedefi aracılığıyla kullanın:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Benzer şekilde, gecikmeye duyarlı HTTP katmanları TargetResponseTime veya RequestCountPerTarget metriklerini izlemelidir; bellek, disk veya alt sistem gecikmesine bağlı uygulamalar, gerçek darboğazı yansıtan özel bir metrik yayınlamalıdır. CPU kısıt değilken CPU’ya göre ölçeklendirme yapmak, tam olarak instance’ların hiçbir zaman scale out olmadığı, kuyrukların sınırsızca büyüdüğü ve ALB’nin 5xx hataları döndürdüğü arıza modunu üretir.

Sağlık Denetimleri ve Yaşam Döngüsü Kancaları

ASG’ler varsayılan olarak EC2 durum denetimlerini kullanır; bu denetimler hipervizör arızalarını yakalar ancak uygulama arızalarını yakalamaz. ASG üzerinde ELB sağlık denetimlerini etkinleştirmek, değiştirme kararını yük dengeleyicinin uygulama seviyesindeki yoklamasına devreder. Bu, işletim sistemi iyi durumdayken ancak işlem takılıp kaldığında çok önemlidir. HealthCheckGracePeriod süresini, kullanıcı verilerinin (user data) tamamlanması için yeterince uzun ayarlayın; aksi takdirde yeni başlatılan örnekler bir döngü içinde önyükleme (bootstrap) sırasında sonlandırılır.

Yük dengeleyici seçimi, “sağlıklı” olmanın anlamını etkiler:

Yalnızca TCP sağlık denetimleri yapan bir NLB’nin arkasındaki bir HTTP uygulaması, bağlantıları kabul eden ancak 500’lü hatalar döndüren bir örnekten trafik sunmaya devam edecektir. Anlamlı sinyallemeyi yeniden sağlamak için bir ALB’ye geçin veya NLB üzerinde HTTP sağlık denetimlerini yapılandırın.

Yaşam döngüsü kancaları (Lifecycle hooks), harici otomasyonların harekete geçebilmesi için örnekleri Pending:Wait veya Terminating:Wait durumlarında duraklatır. Başlatma sırasında bir kanca, ALB trafik göndermeden önce bir yapılandırma yönetimi sistemine kaydolmanıza, önbellekleri ısıtmanıza veya gizli bilgileri (secrets) çekmenize olanak tanır. Sonlandırma sırasında bir kanca, oturumları boşaltmanıza (drain), logları göndermenize (flush) ve bir servis ağından (service mesh) kaydı silmenize olanak tanır. Kancalar EventBridge olayları yayar; işleyiciler (handler) CompleteLifecycleAction çağrısını yapmalıdır, aksi takdirde kanca zaman aşımına uğrayarak varsayılan eylemine (CONTINUE veya ABANDON) döner.

Sıcak Havuzlar ve Hazırda Bekletme

Soğuk başlatma süresi, hizmet vermeden önce büyük modeller yükleyen, önbellekleri ısıtan veya JIT derlemesi yapan uygulamalar için gerçek bir sorundur. Sıcak havuz (Warm pool), ASG’ye bağlı, önceden başlatılmış bir rezervdir: örnekler başlatılır, önyükleme betiğini çalıştırır, ardından durdurulur, çalışır durumda tutulur veya hazırda bekletilir (hibernation) ve ASG dışa doğru ölçeklenene kadar havuzda tutulur. Havuzdan çekmek, dakikalar süren önyükleme sürecini atlar.

Hazırda bekletme (Hibernation), işletim sistemini şifrelenmiş EBS kök birimine askıya alır, böylece JVM yığını (heap), ML ağırlıkları ve işletim sistemi sayfa önbelleği (page cache) devam ettirildiğinde geri gelir. Gereksinimler: RAM’i tutacak kadar büyük şifrelenmiş bir kök birim, desteklenen bir ailede 150 GB’den az veya eşit örnek RAM’i ve başlatma sırasında HibernationOptions.Configured = true ayarı. PoolState: Hibernated durumuna sahip bir sıcak havuz her ikisini de birleştirir — örnekler durdurulmuşken işlem gücü için maliyeti olmaz ve dolu bellek ile saniyeler içinde devam eder. Bu, bir uygulamanın “üretken olmadan önce belleği yüklemesinin uzun sürdüğü” durumlar için doğru desendir.

Ölçeklenemeyen İş Yükleri için Otomatik Kurtarma

Her iş yükü yatay olarak ölçeklenmez. MAC’e bağlı lisanslara, dosya tabanlı kilitlere veya paylaşılan bir depo olmadan bellek içi oturum durumuna sahip eski uygulamalar birden fazla örnekte çalışamaz — ek düğümler (node) başlatmak veri bozulmasına veya lisans ihlallerine neden olur. Bunlar için dayanıklılık, dışa ölçeklenmeden değil, otomatik kurtarmadan (automatic recovery) gelir.

İki desen işe yarar. StatusCheckFailed_System üzerinde bir CloudWatch alarmı ile eşleştirilmiş EC2 kurtarma eylemi, altta yatan ana bilgisayar arızası boyunca örnek ID’sini, özel IP’yi, Elastic IP’yi ve EBS eklentilerini korur. Daha da basiti: birden çok AZ’ye yayılan MinSize=MaxSize=1 ayarına sahip bir ASG, arızalı bir örneği değiştirir ve kurtarma eyleminin aksine, AZ arızasından kurtulabilir — durumun kök birimden harici bir yere taşınması veya AMI’nin yeniden oluşturulabilir olması koşuluyla.

Yük Dengeleyiciler ve Alt Ağ Yerleşimi

ALB, L7’de çalışır; HTTP/HTTPS’i sonlandırır, ana bilgisayar/yol/başlık tabanlı yönlendirme, HTTP/2, WebSockets, WAF/Cognito/OIDC entegrasyonu sunar. NLB, L4’te çalışır; istemci IP’sini korur, statik IP’leri ve TLS geçişini (passthrough), PrivateLink’i destekler ve saniyede milyonlarca bağlantıyı sürdürür. Gateway Load Balancer, trafik yoluna üçüncü taraf cihazları (güvenlik duvarları, IDS) ekler.

Alt ağ (subnet) yerleşimi, mimarilerin en sık bozulduğu yerdir. İnternete yönelik bir ALB, genel alt ağlara (public subnets) — yani bir İnternet Ağ Geçidi’ne (Internet Gateway) 0.0.0.0/0 rotası olan alt ağlara — hedeflerin yaşadığı her AZ için bir tane olacak şekilde bağlanmalıdır. Hedeflerin kendileri özel alt ağlarda (private subnets) kalır. Eğer ALB özel alt ağlara yerleştirilirse veya “genel” alt ağlarda bir IGW varsayılan rotası eksikse, istemciler bağlantı zaman aşımları görür. Hedef erişilebilirliği, hedef güvenlik grubunun hedef bağlantı noktasında ALB’nin güvenlik grubundan gelen trafiğe izin vermesini gerektirir; aynı VPC içindeki ALB ve hedefler arasında NAT gerekmez.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Sağlıksız hedeflerin yalnızca kaydının silinmesi yerine değiştirilmesi için ASG üzerinde ELB sağlık denetimlerini etkinleştirin. Bölgeler arası yük dengeleme (Cross-zone load balancing) (ALB’de varsayılan, NLB’de isteğe bağlı), her AZ’deki örnek sayısından bağımsız olarak istek dağılımını eşitler. Route 53, ALB’ye bir takma ad kaydı (alias record) (veya birden çok ALB arasında ağırlıklı/gecikme tabanlı politika) aracılığıyla çözümlenmelidir — Route 53’ü asla tek tek EC2 IP’lerine yönlendirmeyin, çünkü arızalı bir örnek TTL süresi dolana kadar trafik almaya devam eder ve ASG tarafından değiştirilen örneğin IP’si farklı olur.

Satın Alma Modelleri ve Karma Örnek Filoları

Satın alma modeli seçimi, mimari modelden bağımsız olarak EC2 harcamalarını azaltmanın en büyük tek kaldıracıdır.

Rasyonel strateji: temel yükü Reserved Instance’lar veya bir Savings Plan üzerinde, ani artışları İsteğe Bağlı’da, hataya dayanıklı işleri ise Spot’ta çalıştırmaktır. Bir ASG’de bu, bir karma örnek (mixed-instances) politikası olarak ifade edilir:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Örnek türlerini çeşitlendirmek Spot havuzunu derinleştirir ve birbiriyle ilişkili kesintileri azaltır. price-capacity-optimized (veya capacity-optimized) fiyatı havuz derinliğiyle dengeleyerek örneklerin geri alınma olasılığını düşürür.

Spot; durum bilgisi tutmayan (stateless), kontrol noktası alınabilen (checkpointable), yeniden denenebilen veya yatay olarak yedekli iş yükleri için uygundur: bir ALB arkasındaki web çalışanları, otomatik yeniden denemeli Batch işleri, Spark yürütücüleri, CI koşucuları. Kritik, sürekli çalışan hizmetler, durum bilgisi tutan birincil veritabanları veya kurtarma yolu olmayan lider düğümler için tek kapasite kaynağı olarak uygun değildir — iki dakikalık bildirim güvenli bir kapatmayı garanti edemez ve belirli bir örnek türünün filo genelinde ilişkili bir şekilde geri alınması gerçek bir arıza modudur. Gereksinim “kesintiye uğramamalıdır” dediğinde, Spot seçenek dışı kalır.

Tersi bir tuzak ise RI’ları veya Savings Plan’leri gerçekten değişken olan iş yüklerine uygulamaktır: saatlik taahhüdü kullansanız da kullanmasanız da ödersiniz, bu nedenle 168 saatlik bir taahhüt altında haftada 40 saat çalışan bir iş yükü, rezervasyonun %76’sını boşa harcar. Endişe konusu fiyat değil de kapasitenin kendisi olduğunda (olay güdümlü ani artışlar, felaket kurtarma), bir On-Demand Capacity Reservation kullanın: İsteğe Bağlı fiyatlarında, AZ kapsamlı saf bir garantidir ve indirim için bir Savings Plan ile birleştirilebilir.

Sunucusuz Bilişim: Lambda ve Fargate

Sunucusuz mimari, kapasite yönetimini platforma devreder. Lambda, olay güdümlü, kısa ömürlü işlere uygundur: S3 ObjectCreated tetikleyicileri, DynamoDB Streams, düşük hacimli SQS tüketicileri, API Gateway arka uçları, yapıştırıcı mantık (glue logic). Bellek (128 MB – 10.240 MB), CPU’yu orantılı olarak tahsis eder, bu nedenle belleği yukarı doğru ayarlamak genellikle süreyi kısaltarak maliyeti düşürür. Kesin sınırlar kapsamını belirler: 15 dakika maksimum yürütme süresi, 10 GB bellek, 10 GB /tmp, 250 MB sıkıştırılmamış dağıtım paketi (veya container imajı aracılığıyla 10 GB), 6 MB senkron yük (payload). 30 dakikalık bir video dönüştürme, çok saatli bir ETL veya GPU eğitimi için Lambda kullanmak mimari olarak yanlıştır — fonksiyon işin ortasında zaman aşımına uğrar ve yeniden deneme mantığı sadece israfı katlar. Gecikmeye duyarlı yollar için, Provisioned Concurrency ile soğuk başlatmaları (cold start) ve VPC’ye bağlı ENI başlatma süresini azaltın.

Fargate, EC2 sunucularını yönetmeden container’ları çalıştırır. Görevler 15 dakikayı aştığında, özel çalışma zamanlarına (runtime) ihtiyaç duyduğunda veya ECS/EKS orkestrasyonuna uyduğunda ancak ekip kapasite yönetmek istemediğinde doğru seçimdir. Fargate, vCPU-saat başına EC2 Spot’tan daha pahalıdır, bu nedenle kararlı durum kullanımı yüksek ve öngörülebilir olduğunda, ECS üzerinde Spot içeren karma örnekli bir ASG daha ucuzdur. Ani veya öngörülemeyen trafik için Fargate’in saniye başına faturalandırması avantajlıdır.

Çok sayıda Lambda arasında orkestrasyon için, SNS/SQS aracılığıyla zincirleme yapmaktansa Step Functions tercih edilir çünkü görsel yürütme geçmişi, yeniden deneme semantiği, merkezi hata yönetimi ve dayanıklı durum (durable state) sunar. Standart iş akışları durum geçişi başına faturalandırılır ve bir yıla kadar çalışabilir; Ekspres iş akışları ise yüksek hacimli, kısa süreli olay işleme için optimize edilmiştir.

Binlerce parametreli container’lı işin (genomik, Monte Carlo, ETL) paralel olarak dağıtılması (fan-out) için AWS Batch, yönetilen EC2, Spot veya Fargate üzerinde kuyruklama, bağımlılık çözümleme, yeniden denemeler ve kaynak sağlamayı yönetir. İşler bir iş tanımına (container + vCPU/bellek + IAM rolü) referans verir ve Batch bunları doğru boyutlandırılmış örneklere en verimli şekilde yerleştirir (bin-packing). Step Functions genellikle Batch, Lambda ve ECS’yi tek bir durum makinesi içinde yönetir.

Elastic Beanstalk

Beanstalk, bir uygulama paketinden ALB, ASG, EC2 örneklerini ve isteğe bağlı olarak RDS’i sağlayan yönetilen bir PaaS’tır. CloudWatch entegrasyonu ile rolling, rolling-with-additional-batch, immutable ve blue/green dağıtımlarını destekler. Ölçeklendirme politikaları ortam seçenekleri (metrik, eşikler, min/maks) olarak sunulur. Beanstalk varsayılan olarak anlık olarak yüksek performans gösterebilen (burstable) örnek türlerini kullandığından, kısa süreli CPU doygunluğu için T-unlimited modunu etkinleştirmek en zahmetsiz çözümdür. Zamanlanmış ölçeklendirme eylemleri, diğerleri gibi Beanstalk tarafından yönetilen ASG’ye eklenir. Ekip, standart bir web uygulaması topolojisini elle CloudFormation yazmadan istediğinde ve sıralı güncellemeler (rolling updates) ile sürüm kontrollü paketler yayın temposuna uyduğunda Beanstalk’ı seçin.

Systems Manager ile Filo Yönetimi

SSH ve bastion kalıpları kırılgandır ve güvenliğini sağlamak maliyetlidir. AWS Systems Manager bunların yerini alır. SSM Agent (Amazon Linux 2, Ubuntu, Windows üzerinde önceden yüklenmiştir) ve AmazonSSMManagedInstanceCore iznini veren bir instance profili yeterlidir.

• Run Command, etiketlenmiş filolar genelinde shell/PowerShell komutlarını çalıştırır ve birleştirilmiş bir çıktı sunar.
• Session Manager, AWS API aracılığıyla etkileşimli shell’ler açar — gelen 22 portuna, bastion’a gerek yoktur, tam IAM kimlik doğrulaması kullanılır ve oturumlar S3 veya CloudWatch Logs’a kaydedilir.
• Patch Manager, bakım pencerelerini kullanarak zamanlanmış şekilde işletim sistemi yamalarını uygular.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Zamanlanmış Başlatma/Durdurma Otomasyonu

Mesai saatleri dışında kapalı olması gereken üretim dışı EC2 ve RDS için az bakım gerektiren kalıp EventBridge Scheduler → Lambda şeklindedir. Bir cron kuralı (cron(0 19 ? * MON-FRI *)) etiketlenmiş kaynakları durduran bir Lambda’yı tetikler; saat 07:00’deki ikinci bir kural ise onları başlatır.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Bu yapı sunucusuzdur, yama yapılacak bir filosu yoktur ve etikete göre ölçeklenir. AWS Instance Scheduler çözümü de benzer şekilde çalışır. Bir incelik: durdurulmuş bir RDS instance’ı yedi gün sonra otomatik olarak başlar, bu nedenle durdurma zamanlaması onu tekrar durdurmak için yinelenmelidir. Hafta sonları kapasiteyi sıfırlayan zamanlanmış eylemlere sahip ASG’ler ile birleştirildiğinde, boşta kalma saati maliyeti sıfıra yaklaşır.

Ölçeklenmiş İşlem Gücü Çevresindeki Ağ Tuzakları

NAT Gateway yerleşimi. Bir NAT gateway tek bir AZ’de bulunur. Üç AZ’ye yayılan ve tüm giden trafiğini us-east-1a‘daki tek bir NAT üzerinden yönlendiren bir filo, us-east-1b/us-east-1c‘den gelen her paket için AZ’ler arası transfer ücreti öder ve us-east-1a‘da bir sorun yaşandığında giden trafiği tamamen kaybeder. Doğru kalıp, her AZ için bir NAT gateway kullanmak ve her özel alt ağın rota tablosunu kendi AZ’sindeki NAT’a yönlendirmektir. Bu, trafiği yerelleştirir ve tek AZ’lik hata modunu ortadan kaldırır.

NAT instance’ları. Tek bir EC2 tabanlı NAT, filo büyüdükçe bir bant genişliği ve PPS (saniye başına paket) darboğazı haline gelir ve bir SPOF’tur (Tek Hata Noktası). Yönetilen NAT Gateway’ler, gateway başına 100 Gbps’ye kadar ölçeklenir. AWS servis trafiği için VPC endpoint’leri (S3/DynamoDB için Gateway, diğerleri için Interface) NAT’ı tamamen atlayarak maliyeti düşürür ve ölçeklenme olayları sırasında doygunluk riskini ortadan kaldırır.

Tekrarlayan Tasarım Tuzakları

• Tek AZ’li ASG’ler bir AZ kesintisinden sağ çıkamaz — her zaman en az iki AZ’den (quorum sistemleri için üç) alt ağlar ekleyin ve MinSize ≥ 2 olarak tutun.
• Her iş yükünün yatay olarak ölçeklendiğini varsaymak. Durum bilgisi tutan (stateful), tek yazıcılı (single-writer) veya kümelenemeyen lisanslı uygulamalar bir ASG altında daha kötü performans gösterir. Önce otomatik kurtarma kullanın veya yeniden düzenleme (refactor) yapın.
• Öngörülebilir zirveler için reaktif ölçeklendirme kullanmak “ilk 2-3 saat boyunca yavaş kalma” belirtisine yol açar. Önceden ısıtmak (pre-warm) için zamanlanmış veya tahmine dayalı ölçeklendirme kullanın.
• Asıl kısıt CPU değilken CPU’ya göre ölçeklendirme yapmak. Gerçek darboğazı yansıtan bir metrik yayınlayın — kuyruk derinliği, yanıt süresi, bağlantı sayısı gibi.
• Simple scaling ve launch configuration’lar artık eskide kalmıştır — target tracking ve launch template‘leri tercih edin.
• HTTP uygulamalarında yalnızca TCP sağlık kontrolleri kullanmak bozuk instance’ların rotasyonda kalmasına neden olur. HTTP kontrolleri kullanın (ALB aracılığıyla veya HTTP modlu NLB kontrolleri).
• Durum bilgisi tutan veya kesintiye uğramaması gereken iş yükleri için Spot kullanmak — Spot, checkpoint alınabilen ve değiştirilebilir worker’lar gerektirir.
• Gerçekten değişken iş yüklerinde Reserved Instance veya Savings Plan kullanmak — kullanılmayan taahhüt tamamen israftır; bunun yerine doğru boyutlandırma ve Spot ile maliyeti düşürün.
• Route 53’ü tekil EC2 IP’lerine yönlendirmek — DNS’in filo değişimini yansıtması için ALB alias’ına yönlendirin.
• Instance store’u kalıcı olarak görmek — veriler durdurma, sonlandırma veya host arızasında kaybolur.
• Snapshot geri yüklemesi veya AMI başlatılmasından sonraki lazy-load gecikmesini göz ardı etmek — hedef AZ’lerde Fast Snapshot Restore’u etkinleştirin.

Tüm alanlar · Konteynerler ve Orkestrasyon →

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

Amazon'a göz atın →