AWS Landing Zone Diyagramı: Organizations ve Control Tower ile Çok Hesaplı Yapı

Her şey için tek bir AWS hesabı, işe yaramadığı güne kadar işe yarar. Bir test betiği bir üretim bucket'ını siler. Finans faturayı ekiplere bölemez. Bir denetçi audit loglarını kimin değiştirebileceğini sorar ve dürüst cevap “admin yetkisi olan herkes” olur. Landing zone, iş yükleri gelmeden önce kurduğunuz çok hesaplı temeldir: her yeni hesabın miras aldığı hesap yapısı, kimlik, koruma kuralları, loglama ve ağ.

Bu yazı bir diyagram üzerinden bir landing zone tasarımını adım adım anlatıyor: neden birden fazla hesap, önerilen organizasyon birimleri, çekirdek hesaplar, hizmet kontrol politikaları (SCP), kaynak kontrol politikaları (RCP) ve bildirimsel politikalarla koruma kuralları, kimlik, merkezi loglama ve güvenlik araçları, ağ ve tüm bunların landing zone 4.0'daki değişiklikler dahil Control Tower ile ya da Terraform ile nasıl kurulacağı.

Neden birden fazla hesap

AWS hesabı, AWS'nin sunduğu en güçlü izolasyon sınırıdır. IAM izinleri, servis kotaları, maliyetler ve çoğu arıza onun kenarında durur. Ayrı hesaplar size şunları verir:

• Etki alanı. Bir sandbox'taki hata ya da ele geçirilmiş bir kimlik bilgisi üretime dokunamaz.
• Net sahiplik ve faturalama: ekip, uygulama ya da ortam başına.
• Daha basit izinler. Etiketlere bağlı koşullarla dolu tek bir hesap yerine, her hesap ekibinin ihtiyaç duyduğu erişimi alır.
• Bağımsız kotalar, böylece bir ekibin yük testi başka bir ekibin limitlerini tüketmez.

Bedeli koordinasyondur: Kimlik, loglama, koruma kuralları ve ağ onlarca hesap genelinde çalışmalıdır. Landing zone'un sağladığı da bu koordinasyondur.

Yapı: organizasyon birimleri

AWS Organizations hesapları organizasyon birimlerinde (OU) gruplar ve bir OU'ya bağlanan politikalar altındaki her hesaba uygulanır. AWS'nin ortamınızı düzenleme üzerine yazdığı teknik inceleme, başlangıç için bir OU seti önerir:

Workloads'u erkenden Prod ve Non-prod alt OU'larına bölün. Koruma kuralları ikisinde farklıdır ve hesapları sonradan taşımak zahmetlidir. Kapatılmayı bekleyen hesaplar için her şeyi reddeden bir politikayla bir Suspended OU ekleyin.

Yönetim hesabı

Yönetim hesabı organizasyonun, birleşik faturalamanın ve Control Tower'ın sahibidir. İş yüklerini ondan uzak tutun; bunun belirleyici bir nedeni var: Organizations belgelerinin belirttiği gibi SCP'ler yönetim hesabındaki kullanıcıları ya da rolleri etkilemez. Oraya dağıttığınız hiçbir şey koruma kurallarınızla sınırlanmaz; bu yüzden ona mümkün olduğunca az kullanıcı ve kaynak verin.

Çekirdek hesaplar

• Log Archive. Organizasyonun CloudTrail trail'ini ve AWS Config geçmişini S3'te alır. Neredeyse hiç kimseye yazma ya da silme erişimi verilmez; yöneticiler bile logları değiştiremesin diye S3 Object Lock'u değerlendirin.
• Security Tooling, diğer adıyla Audit. GuardDuty, Security Hub, IAM Access Analyzer ve AWS Config aggregator için yetkilendirilmiş yöneticidir; böylece güvenlik ekibi yönetim hesabına erişmeden her hesabı tek bir yerden görür.
• Network. Transit Gateway'in, veri merkezlerine özel bağlantının, DNS çözümleyicilerinin ve IP adresi yönetiminin sahibidir; bunları AWS Resource Access Manager ile iş yükü hesaplarıyla paylaşır.
• Shared Services. CI/CD, artefakt depoları ve birçok ekibin kullandığı diğer araçlar.

Koruma kuralları: SCP'ler, RCP'ler ve bildirimsel politikalar

Organizations birkaç politika türü sunar ve bunlar farklı sorulara cevap verir:

Politikalar yalnızca kısıtlar; asla izin vermez. Yüksek değerli, kısa bir koruma kuralı listesiyle başlayın:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

Bölge kısıtlamaları popülerdir ve yanlış yapılmaları kolaydır, çünkü IAM gibi global servislere izin verilmeye devam edilmelidir. Her yeni politikayı Workloads'a bağlamadan önce, temsili tek bir hesabı olan bir staging OU'sunda test edin.

Control Tower koruma kurallarını üç tür kontrol olarak paketler: SCP'ler ve RCP'lerle uygulanan önleyici kontroller, AWS Config kurallarıyla uygulanan tespit edici kontroller ve kaynakları CloudFormation oluşturmadan önce denetleyen proaktif kontroller.

Kimlik

İnsanların iş yükü hesaplarında uzun ömürlü anahtarlara sahip IAM kullanıcıları asla olmamalıdır. IAM Identity Center'ı kurumsal kimlik sağlayıcınıza bağlayın, kullanıcıları ve grupları SCIM ile sağlayın ve erişimi hesap başına gruplara atanan izin setleriyle verin: Örneğin geliştiriciler Non-prod'da power-user, Prod'da salt okunur erişim alır.

Donanım MFA'lı, çevrimdışı saklanan ve izlenen iki acil durum (break-glass) kimliği tutun. Root kullanıcılar için IAM artık üye hesapların root erişimini merkezi olarak yönetebiliyor. Kasım 2024'te gelen bu özellik sayesinde root kimlik bilgilerini üye hesaplardan tamamen kaldırabilir ve yalnızca root'un yapabildiği birkaç işi merkezi bir yerden yürütebilirsiniz.

Loglama ve tespit

1. CloudTrail'deki bir organizasyon trail'i, her hesap ve bölgedeki API etkinliğini Log Archive hesabına kaydeder.
2. AWS Config her yerde kaynak yapılandırmasını kaydeder; aggregator Security Tooling'de durur.
3. GuardDuty ve Security Hub, Security Tooling yetkilendirilmiş yönetici olacak şekilde organizasyon genelinde etkinleştirilir; böylece yeni hesaplar otomatik olarak kapsanır.
4. Bulgular güvenlik bilgi ve olay yönetimi (SIEM) sisteminize ya da nöbet araçlarınıza gider.

Ağ

İş yükü hesapları VPC'lerinin sahibidir ama bağlantılarının değil. Network hesabı, Resource Access Manager ile paylaşılan bir Transit Gateway, merkezi çıkış ve inceleme, bulut ile veri merkezi arasında DNS çözümleme ve bir IP adres planı sağlar. Bu plan tercihen Amazon VPC IP Address Manager ile yönetilir ki iki VPC çakışmasın. AWS VPC diyagramı her iş yükü VPC'sinin içinde neler olduğunu, AWS çok bölgeli mimari diyagramı ise tasarımı bölgeler arasında genişletmeyi ele alıyor.

Kurulum: Control Tower ya da Terraform

AWS Control Tower organizasyonu, çekirdek hesapları, bir organizasyon trail'ini, Config'i ve bir kontrol kataloğunu kurar; yeni hesaplar oluşturmak için de Account Factory'yi sunar. Control Tower sürüm notlarına göre 17 Kasım 2025'te yayımlanan landing zone 4.0 sürümü onu çok daha esnek hâle getirdi:

• AWS Config, CloudTrail, güvenlik rolleri ve AWS Backup entegrasyonları isteğe bağlı oldu.
• Security OU artık zorunlu değil; kendi OU yapınızı tanımlayabilirsiniz.
• Minimal bir kurulum yalnızca Organizations entegrasyonunu ve kontrolleri kullanabilir.
• Config ve CloudTrail kendilerine ayrılmış kaynaklar alıyor ve servise bağlı bir Config aggregator eski toplama yönteminin yerini alıyor.

Terraform ekipleri Control Tower'ı çoğu zaman, hesapları bir Git deposundan sağlayıp özelleştiren Account Factory for Terraform (AFT) ile birleştirir. Eylül 2026'dan beri AFT, değişiklikleri uygulamadan önce önizlemek için özelleştirmeleri yalnızca plan modunda çalıştırabiliyor. Diğerleri Organizations'ı tamamen Terraform ile yönetir ya da Landing Zone Accelerator on AWS çözümünü kullanır. Üçü de işe yarar; önemli olan hesap oluşturmanın otomatik ve tekrarlanabilir olmasıdır.

Hesap dağıtımı

Yeni hesaplar kullanıma hazır gelmelidir: Bir talep, çoğu zaman bir pull request, hesabı doğru OU'da oluşturur, temel yapılandırmayı (Identity Center atamaları, bütçeler ve uyarılar, Transit Gateway'e bağlı bir VPC, varsayılan güvenlik servisleri) uygular ve hesabı ekibe teslim eder. Organizations bir organizasyonu varsayılan olarak 10 hesapla sınırlar. Bu sınır Service Quotas üzerinden ayarlanabilir; bu yüzden ihtiyaç duymadan önce artış talep edin.

Sık yapılan hatalar

• Hiçbir SCP'nin uygulanmadığı yönetim hesabında iş yükleri.
• Tek ve düz bir Workloads OU'su; böylece üretim ve geliştirme aynı koruma kurallarını paylaşır.
• Ekipler, koruma kurallarının bozduğu varsayımlar üzerine çoktan inşa ettikten sonra yazılan koruma kuralları.
• Yöneticilerin değiştirebildiği bir Log Archive hesabı.
• Elle oluşturulmuş, her biri biraz farklı hesaplar.

Landing zone diyagramı

Nasıl okunur:

• Üstteki yönetim hesabı organizasyonu ve politikaları tutar; her OU'ya giden kenarları koruma kuralı bağlantılarıdır.
• Security OU'su, her hesaptan log alan Log Archive'ı ve GuardDuty ile Security Hub'ı yöneten Security Tooling'i içerir.
• Infrastructure OU'su, Transit Gateway'i iş yükü VPC'lerini bağlayan Network hesabını ve CI/CD için Shared Services'i barındırır.
• Workloads OU'su Prod ve Non-prod hesaplarını ayırır; Sandbox OU'su yalıtılmış kalır.
• Sağdaki IAM Identity Center insanlara izin setleri üzerinden erişim verir.
• Markdown bloğu başlangıç koruma kurallarını listeler.

Hesap yapılarını net çizmek

• OU'ları kapsayıcı olarak çizin ve hesapları içlerine yerleştirin; hiyerarşi, politika modelinin ta kendisidir.
• Yönetim hesabını ayrı gösterin. Koruma kurallarınızın dışındadır ve resim bunu söylemelidir.
• Yalnızca hesap sınırlarını aşan akışları çizin: arşive giden loglar, ağ bağlantıları, yetkilendirilmiş yönetim, kimlik.
• Hesapları numarayla değil, işlevle adlandırın.

Arkasındaki güvenlik modeli için sıfır güven mimari diyagramına bakın. Altyapıyı kod olarak yönetiyorsanız, Terraform mimari diyagramı Terraform ile yönetilen ortamların nasıl çizileceğini gösteriyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Yönetim hesabı için Güvenlik paketinden bir Politika düğümü, IAM Identity Center için de bir Kimlik sağlayıcı ekleyin.
3. OU'lar için dört Temel Çerçeve düğümü ekleyin: Security, Infrastructure, Workloads ve Sandbox.
4. Security'nin içine Log Archive için Bulut paketinden bir Nesne depolama düğümü, Security Tooling için de DevOps paketinden bir Uyarı düğümü ekleyin. Infrastructure'ın içine Network hesabı için Ağ paketinden bir Yönlendirici, Shared Services için de DevOps paketinden bir İş hattı ekleyin.
5. Prod, Non-prod ve Sandbox hesapları için Bulut paketinden Hesaplama düğümleri ekleyin.
6. Yönetim hesabını her OU'ya, hesapları Log Archive'a ve Network hesabını iş yüklerine bağlayın; koruma kurallarıyla Temel paketinden bir Markdown bloğu ekleyin.

Örnek 14 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

AWS landing zone nedir? İş yükleri taşınmadan önce güvenlik ve operasyon standartlarınıza göre kurulmuş çok hesaplı bir AWS ortamı: organizasyon birimleri, çekirdek hesaplar, kimlik, koruma kuralları, loglama ve ağ.

Landing zone için AWS Control Tower gerekir mi? Hayır. Control Tower bir landing zone kurmanın yönetilen yoludur ve 4.0 sürümü onu daha esnek hâle getirdi. Organizations'ı Terraform, Account Factory for Terraform ya da Landing Zone Accelerator ile de yönetebilirsiniz.

SCP ile RCP arasındaki fark nedir? SCP, üye hesaplardaki principal'ların neler yapabileceğini sınırlar. RCP ise üye hesaplardaki kaynaklara neler yapılabileceğini sınırlar; örneğin bucket'ların organizasyon dışıyla paylaşılmasını engeller. İkisi de izin vermez.

Yönetim hesabı neden boş kalmalı? SCP'ler yönetim hesabındaki kullanıcılara ve rollere uygulanmaz; dolayısıyla oradaki her şey koruma kurallarınızın dışındadır. Ayrıca faturalamayı ve organizasyonun kendisini kontrol eder; bu da onu sahip olduğunuz en hassas hesap yapar.

Bir organizasyonda kaç hesap olabilir? Varsayılan olarak on. Kota Service Quotas üzerinden ayarlanabilir ve artışı yalnızca yönetim hesabı talep edebilir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.