Amazon SAP-C02: Organizasyonel Karmaşıklık ve Çoklu Hesap Stratejisi — Ç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.

Çoklu hesap stratejisi ve hesap otomasyonu

Çoklu hesap stratejisi, sorumlulukların net bir şekilde ayrılmasıyla başlar: güvenlik ve denetim, paylaşılan ağ, üretim iş yükleri ve sandbox veya geliştirici hesapları. AWS Organizations’ı AWS Control Tower veya özel bir landing zone ile birlikte kullanmak, bu ayrımı ilk günden itibaren zorunlu kılar. Control Tower’ın Account Factory’si; hesap oluşturma, temel IAM rolleri, VPC şablonları ve koruma raylarını (guardrails) otomatikleştiren bir hesap otomasyonu (account vending) deseni sunarken, CloudFormation/CDK ve Service Catalog ile oluşturulmuş özel bir landing zone, ısmarlama ağlar ve yönetişim için daha fazla esneklik sağlar. Temel ödünleşim, operasyonel ek yük ile etki alanı (blast-radius) küçültme arasındadır: daha fazla hesap, yönetim yüzey alanını (otomasyon, hesaplar arası roller, faturalandırma görünürlüğü) artırır ancak bir alanın ele geçirilme riskini sınırlar ve hesap başına uyumluluğu basitleştirir. Ağ seçenekleri — AWS Resource Access Manager ile VPC paylaşımı, Transit Gateway hub-and-spoke modeli veya VPC peering ile yalıtılmış VPC’ler — maliyet ve gecikme ödünleşimlerini belirler. Paylaşılan hizmetler (DNS, NAT, Active Directory) genellikle bir ağ veya paylaşılan hizmetler hesabında bulunur; hesap otomasyonu, yeni hesapları bu paylaşılan kaynaklara otomatik olarak bağlamalı veya delege edilmiş VPC’ler sağlamalıdır. Kotaları ve otomasyonu planlayın: temel yapıların (artifact) dağıtımı için pipeline’ları merkezileştirin, böylece hesap sayısı arttıkça manuel iş yükü katlanarak artmaz.

Yönetişim: SCP’ler, Control Tower koruma rayları ve organizasyonel politikalar

Çoklu hesaplı bir AWS ortamında yönetişim, organizasyon düzeyinde politika uygulamasına ve delege edilmiş çalışma zamanı (runtime) kontrollerine dayanır. Service Control Policies (SCP’ler), hesaplar genelinde izin verilen eylemler için üst sınırı belirler; güçlüdürler ancak affetmezler — kök OU’daki (organizational unit) deny kuralları, açıkça izin verilmedikçe yöneticilerin bile hizmet bağlantılı roller (service-linked roles) oluşturmasını veya hizmetleri kullanmasını engeller. Control Tower, yaygın SCP’leri ve Config kurallarını uygulayan önceden oluşturulmuş koruma rayları (zorunlu, şiddetle tavsiye edilen, seçmeli) sunar, ancak gelişmiş hizmet desenleri için kısıtlayıcı olabilir. Tasarım kararı, merkezi ve delege edilmiş yönetişim arasında bir seçim yapmaya odaklanır: kök düzeyinde katı bir reddetme listesi (deny-list) uyumluluğu en üst düzeye çıkarır ancak ürün ekipleri ve otomasyon için sürtünmeyi artırırken, izin sınırları (permission boundaries) ve IAM rol kontrolleri ile daha esnek temel yapılandırmalar, geliştirici hızını artırır. Günlükleme ve denetim politikaları (organizasyonel CloudTrail, AWS Config aggregator, Security Hub ve GuardDuty delege edilmiş yöneticileri), değiştirilemez denetim izleri (audit trails) sağlamak için yönetim hesabından (management account) zorunlu kılınmalıdır. Pragmatik bir yaklaşım, katmanlı yönetişimdir: yüksek etkili kısıtlamalar için organizasyon SCP’leri, geliştirici kapsamı için izin sınırları (permission boundaries) ve manuel onay süreçleri (manual gating) olmadan tutarlılığı korumak için landing-zone CI/CD tarafından uygulanan otomatikleştirilmiş koruma rayları.

Güvenlik sınırları: hesaplar arası roller, KMS ve kaynak politikaları

Hesaplar arası erişim temel bir desendir ve en az ayrıcalık (least privilege) ilkesi ve güçlü güven kontrolleri ile uygulanmalıdır. Yaygın desen, güvenilir principal’ların STS ile üstlendiği (assume) her hesaptaki IAM rolleri aracılığıyla erişimi delege etmektir: CICD dağıtımı, izleme (CloudWatch/SSM) ve üçüncü taraf entegrasyonları için roller, uygun olduğunda MFA gerektirmeli ve iş ortağı erişimi için harici kimlikler (external IDs) kullanmalıdır. S3, SQS ve KMS anahtarları üzerindeki kaynak tabanlı politikalar doğrudan hesaplar arası erişime olanak tanır, ancak KMS karmaşıklık ekler: bir KMS anahtar politikası, güvenen hesabın (trusting account) principal’larını ve hizmetlerini açıkça yetkilendirmeli ve geçici erişim için grant’ler veya kısıtlamalı grant’ler (grants-with-constraints) gerekebilir. Günlükleme veya güvenlik hesabında merkezi bir KMS anahtarı kullanmak, merkezi şifrelemeyi basitleştirir ancak operasyonel bağımlılık ve potansiyel erişilebilirlik sorunları yaratır; hesap başına anahtarlar etki alanını (blast radius) küçültür ancak anahtar rotasyonu ve grant yönetimini çoğaltır. Yaygın tuzaklar arasında SCP’lerin farkında olmadan KMS veya hizmet bağlantılı rol (service-linked-role) oluşturulmasını engellemesi, SCP’lerle çakışan bucket politikaları ve toplayıcı (collector) hesaptaki Config/CloudTrail’e delegasyon rolünü eklemeyi unutmak yer alır. Tasarım kararları; yönetimsel basitliği, en az ayrıcalık ilkesini ve hesaplar arası gecikmeyi tartmalıdır.

Merkezi loglama, faturalandırma ve otomasyon kalıpları

Merkezi loglama ve faturalandırma, kurumsal görünürlüğün bel kemiğidir. Merkezi bir güvenlik veya denetim hesabındaki bir S3 bucket’ına gönderilen izlere (trail) sahip bir kuruluş CloudTrail’i, kurcalamaya karşı korumalı olay kaydını sağlar; analitik için Kinesis Data Firehose’a yönlendiren CloudWatch Logs abonelik filtreleriyle bunu destekleyin ve Config verilerini bir aggregator ile aynı hesapta toplayın. Maliyet görünürlüğü, Organizations’da birleştirilmiş faturalandırma, Cost Explorer, Budgets ve merkezi olarak teslim edilen Cost and Usage Reports gerektirir; etiket yönetişimi ve Config kuralları aracılığıyla otomatik etiket zorlaması, geri ödeme (chargeback) doğruluğunu artırır. Hesaplar arasında ölçeklenen otomasyon kalıpları genellikle, hesaplar arası dağıtım rollerini üstlenen (assume) paylaşılan bir CI/CD pipeline’ı veya dağıtım hesabı ya da toplu provizyonlama için delege edilmiş bir yöneticiye (delegated administrator) sahip CloudFormation StackSets kullanır. Hesaplar arası yama ve yapılandırma için Systems Manager Automation ve State Manager’ı kullanın, ancak her hesabın gerekli rolleri ve SSM izinlerini vermesi gerektiğini unutmayın. Artıları ve eksileri, merkezileştirme ile gecikme arasında bir denge kurar: merkezi toplama, yinelenen depolamayı azaltır ve analizi basitleştirir ancak ağ ve erişilebilirlik bağımlılıkları yaratır; dağıtık loglama ise veriyi kopyalar ancak hataları izole eder. Saklama (retention), yaşam döngüsü (lifecycle) kuralları, DR için bölgeler arası replikasyon ve uyumluluk gereksinimleriyle tutarlı şifreleme anahtarı yönetimi için planlama yapın.

Pratik Problem: Kullanım Senaryosu

Senaryo: Contoso Media, Organizations ve Control Tower’ın kurulu olduğu kurumsal bir AWS ortamını yönetmektedir. Bir yönetim hesabına, bir paylaşılan hizmetler ağ hesabına ve iki Bölge’de (Region) üretim, hazırlık (staging) ve geliştirici iş yüklerini çalıştıran 20 üye hesaba sahiptirler.

Zorluk: Contoso’nun, merkezi loglamayı, uygun SCP koruma önlemlerini (guardrail), Transit Gateway aracılığıyla paylaşılan hizmetler hesabına otomatik ağ bağlantısını ve hesap başına manuel IAM kurulumu gerektirmeyen dağıtım pipeline’larını sağlayarak 15 yeni proje hesabını hızla sisteme dahil etmesi (onboard) gerekiyor.

Önerilen Yaklaşım:

1. Hesabı AWS Config’e kaydeden, denetim hesabının S3 bucket’ını işaret eden bir kuruluş CloudTrail’ini etkinleştiren ve gerekli etiketleri uygulayan temel bir CloudFormation/CDK şablonuyla hesapları dağıtmak (vend) için Control Tower Account Factory’yi veya otomatik bir AWS Organizations API iş akışını kullanın.
2. Geliştirme iznine sahip OU’ları daha az kısıtlayıcı tutarken, yüksek etkili engellemeleri (örneğin, bölgeler arası anahtar silmeyi ve izin verilmeyen bölgeleri engelleme) zorunlu kılan SCP’leri OU seviyesinde ekleyin; geniş çapta uygulamadan önce SCP’leri bir sanal alanda (sandbox) doğrulayın.
3. Paylaşılan hizmetler ağ hesabında Transit Gateway’i yapılandırın ve attachment oluşturma ile rota yayılımını otomatikleştirmek için dağıtım (vending) sürecinin üstlendiği (assume) bir delege edilmiş yönetici (delegated admin) veya hesaplar arası rol ve Kod Olarak Altyapı (Infrastructure-as-Code) kullanarak her yeni hesabın Transit Gateway VPC attachment’ı için attachment’lar oluşturun.
4. Bir araç (tooling) hesabında, hesap dağıtım (account-vending) süreci tarafından oluşturulan hesaplar arası IAM rollerini (assume-role) kullanan merkezi bir CI/CD dağıtım pipeline’ı sağlayın; ilk temel provizyonlama ve devam eden güncellemeler için CloudFormation StackSets (delegated admin) veya hesaplar arası CodePipeline eylemlerini kullanın.

Gerekçe: Hesap dağıtımını (vending) temel yapılarla (artifact) otomatikleştirmek, manuel adımları en aza indirirken yönetişimi zorunlu kılar; ağ ve dağıtım görevlerini hesaplar arası roller ve Transit Gateway aracılığıyla delege etmek, paylaşılan hizmetleri merkezileştirir, etki alanını (blast radius) azaltır ve güvenlik veya denetlenebilirlikten ödün vermeden sisteme dahil etme (onboarding) sürecini ölçeklendirir.

Tüm alanlar · Ağ ve Hibrit Bağlantı →

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

Amazon'a göz atın →