AWS Solutions Architect · Ders

Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar

Q: “Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar” dersi ücretsiz mi?

Evet — “Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve AWS Solutions Architect kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. AWS Solutions Architect kursu toplamda 4 dersten oluşur.

Q: AWS Solutions Architect öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te AWS Solutions Architect, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.

Q: “Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Q: Bu AWS Solutions Architect dersinde kod yazıp çalıştırabilir miyim?

Evet. Her AWS Solutions Architect dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Önbellekleme stratejileri, veri gölü sorgu optimizasyonu, Rezerve Edilmiş ve Spot seçeneklerinin ödünleşimleri ve okuma replikası mimarileri hakkındaki senaryo sorularını yanıtlayın.

Yüksek Performanslı ve Maliyet Optimize Edilmiş Senaryolar, CoddyKit'te ücretsiz bir AWS Solutions Architect dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, AWS Solutions Architect öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. AWS Solutions Architect kursu toplamda 4 dersten oluşur.

Senaryo 1: Veritabanı Yükünü Azaltmak için Önbelleğe Alma

Senaryo: Bir haber sitesinin RDS MySQL veritabanı, en fazla saatte bir değişen makale içeriği için okuma trafiğinin %90'ını sunuyor. Veritabanı CPU kullanımı ortalama %80, maliyetler artıyor ve sorgu başına gecikme 200 ms. Çözüm: lazy loading (cache-aside) desenini kullanarak RDS'nin önüne bir ElastiCache Redis kümesi ekleyin. Uygulama önce önbelleği kontrol eder; önbellek isabetinde önbelleğe alınmış makaleyi <1 ms içinde döndürür. Önbellek isabetsizliğinde RDS'yi sorgular, sonucu döndürür ve 1 saatlik TTL ile önbelleğe yazar. Beklenen sonuç: %90 önbellek isabet oranı, RDS CPU kullanımının %20'nin altına düşmesi ve önbelleğe alınmış yanıtlar için gecikmenin 5 ms'nin altına inmesi.

import boto3, json

elasticache = boto3.client('elasticache')
redis_client = None  # assume redis-py client connected to ElastiCache endpoint

def get_article(article_id):
    cache_key = 'article:' + str(article_id)
    # Check cache first
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)  # cache hit: <1ms
    # Cache miss: query RDS
    article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
    # Write to cache with 1-hour TTL
    redis_client.setex(cache_key, 3600, json.dumps(article))
    return article

Senaryo 2: Statik Varlık Sunumu için CloudFront

Senaryo: Asya Pasifik'teki kullanıcılar, us-east-1'de EC2 üzerinde barındırılan bir web uygulamasının 2-4 saniyelik yükleme sürelerinden şikâyet ediyor. Uygulama büyük statik varlıklar (görseller, JS, CSS) sunuyor. Çözüm: ALB'nin önüne bir CloudFront dağıtımı yerleştirin. /static/* yolu için uzun TTL'ye (örneğin 1 hafta) sahip bir önbellek davranışı yapılandırın; böylece statik dosyalar Asya'daki kullanıcılara yakın CloudFront uç konumlarında önbelleğe alınır. Dinamik API istekleri TTL=0 ile önbelleği atlar. Asya'daki kullanıcılar statik varlıkları us-east-1'e gidiş-dönüş beklemek yerine Singapur veya Tokyo uç konumundan 100 ms'nin altında yükler.

# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
  'Origins': {
    'Quantity': 1,
    'Items': [{
      'Id': 'alb-origin',
      'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
      'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
    }]
  },
  'CacheBehaviors': {
    'Quantity': 1,
    'Items': [{
      'PathPattern': '/static/*',
      'DefaultTTL': 604800,
      'MaxTTL': 604800
    }]
  },
  'DefaultCacheBehavior': {"DefaultTTL": 0}
}'

Senaryo 3: Compute Optimizer ile Doğru Boyutlandırma

Senaryo: Bir şirketin 500 EC2 bulut sunucusu var ve bunların çoğu 3 yıl önce büyük bulut sunucusu türleriyle oluşturulmuş. AWS faturası yüksek, ancak hangi bulut sunucularının gereğinden fazla kaynakla yapılandırıldığını bilmiyorlar. Çözüm: AWS Compute Optimizer'ı etkinleştirin (ücretsizdir ve 14 günlük CloudWatch metriklerini kullanır). Compute Optimizer her bulut sunucusunun gerçek CPU, bellek, ağ ve disk kullanımını analiz eder ve doğru boyutlandırma önerileri sunar. Ortalama CPU kullanımı %8 olan bir t3.xlarge için t3.small'a küçültme önerilebilir. Önerilerin 500 bulut sunucusuna uygulanması genellikle EC2 maliyetlerini %20-40 azaltır.

# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
  --status Active

# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=Finding,Values=OVER_PROVISIONED \
  --query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
  --output table

Senaryo 4: Toplu İşleme için Spot Instances

Senaryo: Bir genom bilimi şirketi, 8 saat süren ve kesintiye uğrarsa yeniden çalıştırılabilen gece toplu işlerini yürütüyor. Bu işler için EC2 On-Demand maliyeti aylık 10.000 $. Çözüm: Toplu işleme filosu için EC2 Spot Instances kullanın. Spot Instances, %90'a varan indirimle kullanılabilen atıl EC2 kapasitesidir. Kesintiye dayanıklı toplu işler için, başarısız Spot işlerini otomatik olarak yeniden kuyruğa alan ve karma bir filo (Spot + minimum On-Demand fallback) kullanan AWS Batch'i kullanın. Beklenen tasarruf: işlem maliyetlerinde %70-90 azalma; aylık 10.000 $'dan 1.000-3.000 $'a düşüş.

# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
  --compute-environment-name spot-genomics \
  --type MANAGED \
  --state ENABLED \
  --compute-resources '{
    "type": "SPOT",
    "bidPercentage": 60,
    "minvCpus": 0,
    "maxvCpus": 256,
    "instanceTypes": ["optimal"],
    "subnets": ["subnet-1a", "subnet-1b"],
    "securityGroupIds": ["sg-batch"],
    "instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
    "spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
  }' \
  --service-role arn:aws:iam::123456789012:role/AWSBatchServiceRole

Senaryo 5: Değişken Trafik için DynamoDB On-Demand

Senaryo: Bir oyun sıralama tablosu, sağlanan aktarım kapasitesine sahip DynamoDB kullanıyor. Oyun lansmanları sırasında trafik 50 kat artıyor ve tablo istekleri kısıtlıyor. Lansmanlar dışında aktarım kapasitesi neredeyse sıfır; sağlanan kapasite boşa harcanıyor. Çözüm: DynamoDB'yi On-Demand kapasite moduna geçirin. On-Demand, manuel kapasite planlaması olmadan her türlü aktarım kapasitesine anında ölçeklenir ve sağlanan birim başına değil, istek başına ücretlendirir. Yalnızca yaptığınız istekler için ödeme yaparsınız; lansmanlar arasındaki kullanılmayan kapasite için ücret alınmaz. On-Demand, istek başına biraz daha yüksek maliyet karşılığında isteklerin kısıtlanmamasını ve kapasite yönetimi gerekmemesini sağlar.

# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
  --table-name Leaderboard \
  --billing-mode PAY_PER_REQUEST

# Verify the change
aws dynamodb describe-table \
  --table-name Leaderboard \
  --query 'Table.BillingModeSummary.BillingMode'

Senaryo 6: Öngörülemeyen Erişim için S3 Intelligent-Tiering

Senaryo: Bir şirket, kullanıcılar tarafından oluşturulan milyonlarca görseli S3 Standard'da depolamaktadır. Erişim düzenleri öngörülemeyen şekilde değişmektedir; bazı görsellere her gün erişilirken bazılarına aylarca erişilmemektedir. Şirket, yaşam döngüsü ilkelerini manuel olarak yönetmeden depolama maliyetlerini azaltmak istemektedir. Çözüm: S3 Intelligent-Tiering kullanın. Bu özellik, erişim düzenlerine göre nesneleri katmanlar arasında otomatik olarak taşır: Frequent Access (Standard), seyrek erişim (30+ gün boyunca erişilmemiş), Archive Instant Access (90+ gün) ve Archive Access (90+ gün, isteğe bağlı etkinleştirme). Intelligent-Tiering içinde veri alma ücreti yoktur. İzleme ücreti, ayda 1.000 nesne başına 0,0025 ABD dolarıdır; büyük veri kümeleri için ihmal edilebilir düzeydedir.

# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket user-images-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "AutoTier",
      "Status": "Enabled",
      "Filter": {},
      "Transitions": [{
        "Days": 0,
        "StorageClass": "INTELLIGENT_TIERING"
      }]
    }]
  }'

Senaryo 7: Athena ve Redshift Arasındaki Tercih

Senaryo: Bir girişim, S3 veri gölündeki tabloları sorgulamak istemektedir. Haftada yaklaşık 10 geçici sorgu çalıştırmaktadır. Bir tedarikçi, dc2.large kümesine sahip Amazon Redshift'i önermektedir. Bir girişim için çözüm: Amazon Athena ile başlayın; altyapı maliyeti yoktur, yalnızca taranan veri için ödeme yapılır (yaklaşık 5 ABD doları/TB). İyi bölümlenmiş Parquet verileri üzerinde haftada 10 sorgu, ayda 5 ABD dolarından daha düşük bir maliyete mal olabilir. Redshift dc2.large sürekli çalıştığında ayda yaklaşık 180 ABD doları tutar. Redshift yalnızca sorgu eşzamanlılığı yüksek olduğunda (günde 50+ sorgu) veya saniyenin altında yanıt gerektiğinde maliyet açısından avantajlı hale gelir. 'Geçici, seyrek' anahtar sözcükleri kesin olarak Athena'yı işaret eder.

# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshift

Senaryo 8: EBS Birim Türü Seçimi

Senaryo: Bir ilişkisel veritabanı sunucusu, tutarlı ve düşük gecikmeyle 64.000 IOPS gerektirmektedir. Mevcut gp3 EBS birimi, IOPS sınırına ulaşmaktadır. Çözüm: io2 Block Express'e yükseltin (G/Ç yoğun veritabanları için tasarlanmış EBS birim türü). io2 Block Express, birim başına 256.000 IOPS'ye kadar ve milisaniyenin altında gecikmeyi destekler. gp3'ten daha pahalıdır (aylık 0,125 ABD doları/GB + sağlanan IOPS başına 0,065 ABD doları), ancak 64.000+ IOPS gereksinimini karşılayan tek EBS seçeneğidir. gp3'ün 16.000 IOPS sınırının yetersiz kaldığı, gecikmeye duyarlı veritabanı iş yüklerinde io2 tek uygulanabilir EBS tercihidir.

# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
  --volume-type io2 \
  --size 500 \
  --iops 64000 \
  --availability-zone us-east-1a \
  --encrypted

# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed data

Senaryo 9: Sürekli İş Yükleri için Reserved Instances

Senaryo: Bir şirket, üretim uygulaması için 20 r6i.4xlarge EC2 Instance'ını sürekli çalıştırmakta ve 3 yıl boyunca gereksinimlerinde değişiklik beklememektedir. Bu Instance'lar için mevcut On-Demand harcaması yıllık 80.000 ABD dolarıdır. Çözüm: En yüksek indirimden yararlanmak için 3 yıllık Standard Reserved Instances (veya Compute Savings Plans) satın alın ve All Upfront ödeme yapın. Standard Reserved Instances, On-Demand'a göre %72'ye varan indirim sunar. Instance'lar öngörülebilir bir iş yüküyle 7/24 çalışmaktadır; bu, Reserved Instances için klasik kullanım profilidir. Beklenen maliyet azalması: 80.000 ABD doları × 0,72 = On-Demand ile yıllık 22.400 ABD doları; yani yıllık 57.600 ABD doları tasarruf.

# Reserved Instance purchase decision matrix:
# On-Demand:          No commitment, highest price, any workload
# 1-yr RI (All Up):   40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up):   60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot:           90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savings

Senaryo 10: Değişken Trafikte Lambda ve EC2 Maliyeti

Senaryo: Bir şirket, aylık 8 ABD dolarına mal olan bir t3.micro EC2 Instance üzerinde REST API çalıştırmaktadır. API ayda 1 milyon istek almakta ve her isteğin işlenmesi 100 ms sürmektedir. Ekip, Lambda'nın daha ucuz olup olmayacağını sormaktadır. Analiz: Lambda fiyatlandırması: 1.000.000 istek × 0,0000002 ABD doları = 0,20 ABD doları (istek maliyeti) + 1.000.000 × 0,1 sn × 128 MB bellek × oran = yaklaşık 1,67 ABD doları (Compute maliyeti) = aylık yaklaşık 1,87 ABD doları. Bu düşük trafikli API için Lambda, EC2'den daha ucuzdur. Trafik ayda yaklaşık 40 milyon isteğin üzerine çıktığında EC2 daha ucuz hale gelir. Her iş yükü için başa baş noktasını bulmak üzere Lambda Cost Calculator kullanın.

# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
#   GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
#   Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
#   + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)

Senaryo 11: Dinamik API'ler için Global Accelerator

Senaryo: Avrupa, US ve Asya'daki kullanıcılara hizmet veren küresel bir API'de, trafiğin öngörülemeyen internet yollarından geçmesi nedeniyle gecikme tutarsızdır. CloudFront değerlendirilmiştir, ancak API yanıtları dinamiktir (önbelleğe alınamaz). Çözüm: AWS Global Accelerator kullanın. Bu hizmet, dünya genelinde iki statik anycast IP adresi sağlar. Kullanıcı trafiği en yakın AWS edge konumundan AWS küresel omurgasına girer ve AWS'nin özel ağı üzerinden hedef Region'daki kaynak sunucuya ulaşır; böylece yoğun kamuya açık internetin orta bölümünden kaçınılır. Global Accelerator, dinamik API yanıt süresini %20-60 oranında iyileştirir ve bir Region Endpoint'i sağlıksız hale geldiğinde anında yük devretme sağlar.

# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
  --name my-api-accelerator \
  --ip-address-type IPV4 \
  --enabled

# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
  --accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
  --protocol TCP \
  --port-ranges '[{"FromPort": 443, "ToPort": 443}]'

# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
  --listener-arn arn:aws:globalaccelerator::123:listener/xyz \
  --endpoint-group-region us-east-1 \
  --endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'

Kısa Kontrol

Bu dersteki AWS Solutions Architect (SAA-C03) kavramlarını anlayıp anlamadığınızı test edin.

Ders Özeti

Bu derste şu senaryoları ele aldınız: RDS CPU kullanımını %80'den %20'ye düşürmek için ElastiCache lazy loading, toplu iş maliyetlerinde %70-90 tasarruf için Spot Instances ve AWS Batch, seyrek geçici sorgular için Athena ve yüksek eşzamanlılıklı analiz için Redshift ve veri alma ücreti olmadan öngörülemeyen erişim düzenleri için S3 Intelligent-Tiering. Sırada, hazır olup olmadığınızı ölçmek için süre sınırlı, farklı alanları kapsayan bir mini sınavdan oluşan son bitirme çalışması var.

Sıkça Sorulan Sorular