Amazon CLF-C02: Bulut Mimarisi ve Well-Architected Framework — Çalışma kılavuzu

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Şunun bir parçası: AWS Cloud Practitioner CLF-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.

Tasarım ilkeleri ve işlem gücü satın alma kararları

İyi bir bulut mimarisi, bir uygulamanın parçalarını bağımsız olarak ölçeklendirebilmeniz için küçük, yinelemeli değişiklikler, otomasyon ve gevşek bağlılık (loose coupling) ile başlar. Mümkün olan yerlerde durum bilgisi olmayan (stateless) hizmetler tasarlayarak esneklik için mimari oluşturun, değişmezliği (immutability) ve geçici (ephemeral) işlem gücünü teşvik edin ve erişim için en az ayrıcalık ilkesini (principle of least privilege) uygulayın. İşlem gücü fiyatlandırma modellerini seçerken zaman ufkunu, kullanım öngörülebilirliğini ve kesintiye karşı toleransı tartın: uzun süreli, kararlı iş yükleri taahhütlü fiyatlandırmayı tercih ederken; anlık artış gösteren (bursty) veya öngörülemeyen iş yükleri uygun durumlarda On-Demand veya Spot’u tercih eder. Yaygın bir tuzak, değişken büyümeyi anlamadan uzun vadeli Reserved Instances veya Savings Plans’e taahhütte bulunmaktır; bu durum israfa yol açabilir veya sizi yanlış instance ailesine kilitleyebilir. Başka bir hata ise, kesinti için tasarım yapmadan kritik, durum bilgisi olan (stateful) iş yükleri için Spot kullanmaktır. Lisanslama ve yerleştirme ihtiyaçlarını göz önünde bulundurun: Dedicated Hosts yazılıma bağlı lisansları ve fiziksel izolasyonu desteklerken, Savings Plans işlem gücü harcamaları için aileler ve bölgeler arasında esneklik sağlar. Etiketleme ve otomatik maliyet tahsisi esastır — tutarlı etiketler olmadan Savings Plans uygulamak veya doğru boyutlandırma (rightsizing) analizleri yapmak zordur. Verimsizliği erken tespit etmek için izleme ve uyarıları kullanın ve kullanım değiştikçe satın alma kararlarını üç ayda bir gözden geçirin.

On-Demand: saat/saniye başına ödeme, en yüksek esneklik, taahhüt yok
Reserved Instances / Standard RIs: belirli instance özellikleri için uzun vadeli indirim, kararlı durumlar için uygun maliyetli
Savings Plans: taahhüt edilen harcama karşılığında instance aileleri arasında esnek indirimler
Spot Instances: kesintiye uğrayabilecek iş yükleri için yüksek indirimler
Dedicated Hosts: lisans veya uyumluluk kısıtlamaları için fiziksel sunucu tahsisi

Kod olarak altyapı, hazırlama ve izolasyon

Kod olarak altyapı (Infrastructure as code - IaC), altyapıya tekrarlanabilirlik, gözden geçirilebilirlik ve sürüm kontrolü kazandırır. AWS CloudFormation, yığınları (stack) tanımlamak ve hazırlamak için kullanılan yerel bildirimsel (declarative) IaC hizmetidir; şablonlar kaynakları, bağımlılıkları ve parametrelendirmeyi kod haline getirir. AWS Cloud Development Kit (CDK), daha üst düzey yapılar sunar ve birden çok dili (TypeScript, Python, Java, C# ve Go dahil) destekleyerek geliştiricilerin bildikleri dillerden CloudFormation sentezlemesine olanak tanır. Programatik hazırlama (provisioning) ayrıca AWS CLI, SDK’lar, AWS CDK ve Terraform gibi üçüncü taraf araçlar aracılığıyla da yapılabilir; sıkı AWS özellik denkliği ve CloudFormation sapma tespiti (drift detection) istediğinizde yerel araçları seçin. Mantıksal izolasyon, alt ağlar (subnet), yönlendirme tabloları (route table), güvenlik grupları (security group) ve ağ ACL’leri ile birleştirildiğinde ağ sınırlarını oluşturan Amazon Virtual Private Cloud (VPC) tarafından sağlanır. IAM, kimlikleri ve izinleri (kullanıcılar, roller, gruplar ve politikalar) kontrol eder ve programatik kimlik bilgilerini ve kaynaklara erişimi yönetmek için kullanılır. Uygulayıcıların düştüğü yaygın tuzaklar arasında kök hesap (root account) erişim anahtarlarını saklamak, otomasyon için hesaplar arası roller (cross-account roles) oluşturmamak ve şablonlarda etiketleme politikalarını zorunlu kılmamak yer alır. CloudFormation şablonları kod gibi ele alınmalıdır: yapılandırma sapmasını (configuration drift) önlemek ve öngörülebilir dağıtımları mümkün kılmak için gözden geçirilmeli, lint işleminden geçirilmeli ve sürüm kontrol sisteminde saklanmalıdır.

Well-Architected sütunları — pratik odak

Well-Architected Framework (İyi Tasarlanmış Mimari Çerçevesi), tasarım kararlarına ve ödünleşimlere (trade-off) rehberlik eden beş temel sütun üzerine odaklanır. Hizmetleri her bir sütunla eşleştirmek ve anlamak, işleri önceliklendirmeye ve alternatifleri karşılaştırmaya yardımcı olur.

Operasyonel Mükemmellik: gözlemlenebilir operasyonlar için tasarım yapın, CloudWatch metriklerini, log’larını ve Systems Manager otomasyonunu kullanın; runbook’ları ve sürekli iyileştirmeyi teşvik edin.
Güvenlik: IAM ile en az ayrıcalık ilkesini uygulayın, bekleyen veriyi (data at rest) KMS ile şifreleyin, denetim ve tespit için CloudTrail ve GuardDuty’yi etkinleştirin ve uç noktaları (edge) WAF ve Shield ile koruyun.
Güvenilirlik: kurtarma hedeflerini karşılamak için Multi-AZ, otomatik kurtarma, Route 53 sağlık kontrolleri (health check) ve yedeklemeler (EBS anlık görüntüleri, RDS otomatik yedeklemeleri, AWS Backup) kullanarak hataya karşı tasarım yapın.
Performans Verimliliği: Compute Optimizer ile doğru boyutlandırma yapın, önbelleklemeden (caching) yararlanın (CloudFront, ElastiCache), yönetilen hizmetleri (Aurora, DynamoDB) ve G/Ç (I/O) ile gecikmeyi optimize etmek için uygun depolama katmanlarını seçin.
Maliyet Optimizasyonu: yaşam döngüsü politikaları (nadiren erişilen ancak anında erişim gerektiren nesneler için S3 Intelligent-Tiering veya Standard-IA) ile maliyet odaklı mimari uygulayın, Savings Plans kullanın ve üretim dışı ortamların kapatılmasını zamanlayın.

Sık karşılaşılan bir karar kriteri, operasyonel yükü maliyetle takas etmek için yönetilen hizmetlerin kullanılıp kullanılmayacağıdır. Yaygın bir tuzak, daha düşük maliyetle performansı sürdürmek için otomatik ölçeklendirme (autoscaling) ve önbelleklemeden yararlanmak yerine en kötü durumdaki zirve (peak) için aşırı kaynak sağlamaktır (overprovisioning).

Operasyonel araçlar, veri servisleri, güvenlik ve uç (edge) nokta seçimleri

Operasyonel görünürlük ve güvenlik araçları, iyi tasarlanmış bir mimarinin (well-architected) bel kemiğidir. AWS CloudTrail, denetim için API etkinliğini kaydederken, Amazon GuardDuty hesap düzeyindeki anormal davranışlara karşı sürekli tehdit tespiti sağlar. CloudWatch, metrikleri ve logları toplar ve EBS volüm yazma (write) artışları gibi olaylar için alarmları destekler; yerel metrikler yetersizse işletim sistemi seviyesindeki metrikler için CloudWatch Agent’ı kullanın. Yönetilen veri servisleri için, RDS ilişkisel veritabanları için otomatik yama ve yedekleme sağlar, DynamoDB NoSQL, tam yönetilen bir anahtar-değer ve doküman deposudur ve Amazon Neptune yüksek düzeyde bağlantılı veri setleri için optimize edilmiş yönetilen bir graf veritabanıdır. Küresel içerik dağıtımı ve düşük gecikmeli dağıtım için, uç (edge) noktalardaki CloudFront, Shield ve WAF ile birleşerek CDN artı DDoS koruması ve uygulama katmanı filtrelemesi sağlar. Uç (edge) veya şirket içi (on-prem) düşük gecikme ihtiyaçları için AWS Outposts veya Local Zones’u değerlendirin; Outposts, mümkün olan en düşük gecikme süresi ve tutarlı API’ler için AWS donanımını şirket içine yerleştirir. Kullanıcılar için kimlik federasyonu ve hesap erişimi, AWS IAM Identity Center (eski adıyla AWS SSO) aracılığıyla yönetilir. İzleme tasarlarken, alarmları otomatik iyileştirme (Lambda veya Systems Manager) ile birleştirin ve tek bir kullanılabilirlik alanına (availability zone) güvenmek, root kimlik bilgilerini kullanmak veya anında alınması gereken nesneler için derin arşiv depolaması (Glacier) seçmek gibi yaygın hatalardan kaçının.

Temel servis seçimleri ve kullanım alanları: Yönetilen ilişkisel veritabanları için RDS; NoSQL için DynamoDB; graf için Neptune; chatbot’lar için Lex; küresel web dağıtımı ve DDoS koruması için CloudFront + WAF + Shield

Pratik Problem: Kullanım Senaryosu

Senaryo: Acme Manufacturing, bir VPC içinde production EC2 sunucuları, sipariş işleme için bir RDS veritabanı ve S3 ile CloudFront aracılığıyla dağıtılan statik varlıklara sahip bir web sitesi ile AWS üzerinde karma bir iş yükü çalıştırmaktadır. Ekip, AWS CLI ve CloudFormation kullanmaktadır ve geliştiricilerin CI/CD için güvenli, hesaplar arası erişime ihtiyacı vardır.

Zorluk: Sürekli çalışan uygulama sunucuları için işlem (compute) maliyetlerini düşürmeleri, root kimlik bilgilerini kullanmadan otomasyonu güvence altına almaları ve EBS destekli bir sunucunun minimum kesinti süresiyle hızlı bir şekilde kurtarılmasını sağlamaları gerekmektedir.

Önerilen Yaklaşım:

Sürekli işlem (compute) saatlik harcamasına uyan bir Savings Plan taahhüt edin ve anında tasarruf için uygun sunucuları Savings Plans kullanacak şekilde dönüştürün.
Kullanımı analiz ettikten sonra yalnızca uzun ömürlü, belirli sunucu tipi ihtiyaçlarını Reserved Instances’a geçirin ve uygun olan yerlerde sunucu boyutu esnekliğini (instance size flexibility) uygulayın.
Tüm root hesabı erişimlerini IAM kullanıcıları ve rolleri ile değiştirin: CI/CD için en az ayrıcalık (least-privilege) politikalarına sahip bir IAM rolü oluşturun ve hesaplar arası otomasyon için STS AssumeRole aracılığıyla kısa ömürlü kimlik bilgileri kullanın.
AWS Backup veya zamanlanmış Data Lifecycle Manager politikalarını kullanarak otomatik EBS anlık görüntüleri (snapshot) uygulayın ve hızlı sunucu değişimi için AMI’ler ile kullanıcı verilerini (user-data), minimum kesinti için ise ekli EBS anlık görüntü geri yüklemesi olan bir Auto Scaling grubu kullanın.

Gerekçe: Taahhüt edilen fiyatlandırmayı öngörülebilir harcamalarla eşleştirmek, kullanılabilirlikten ödün vermeden maliyetleri düşürür; root kullanımını IAM rolleri ve kısa ömürlü kimlik bilgileriyle değiştirmek, en az ayrıcalık (least-privilege) en iyi uygulamalarını takip eder; otomatik anlık görüntüler ve AMI’ler, Güvenilirlik (Reliability) ve Operasyonel Mükemmellik (Operational Excellence) sütunlarıyla tutarlı hızlı kurtarmayı destekler.

← Faturalandırma · Tüm alanlar · Yönetim →

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