Davet edin, önce ayrılıp sonra katılmayın: organizasyon taşınması sonrası AWS hesaplarını yönetmek

dev.to üzerindeki uygulamaya dayalı bir rehber, bir AWS hesabını organizasyonlar arasında taşımanın işin kolay kısmı olduğunu savunuyor: hesap yeni organizasyonda görünüyor, Control Tower dashboard'u hesabı kayıtlı olarak gösteriyor ve kullanıcılar yeni portal üzerinden oturum açarken, arka planda eski organizasyon hâlâ hesabı yönetebiliyor ve hedef organizasyonun kendi guardrail politikaları hesaba hiç ulaşmayabiliyor. Üretim hesapları içeren bir çok hesaplı yönetim projesinden yola çıkan yazı, hem işe yarayan göç rotasını hem de taşınan bir hesabın gerçekten yönetim altında olup olmadığını belirleyen takip adımlarını ortaya koyuyor.

Önce ayrıl-sonra-katıl rotası tıkanıyor

Klasik yaklaşım — hesabın organizasyondan ayrılmasını sağlamak, bir süre bağımsız çalışmasını beklemek, sonra bir daveti kabul etmek — bağımsız çalışma ön koşullarında tıkanıyor. Bir organizasyon içinde oluşturulan hesapların genellikle ödeme yöntemi yoktur ve dev.to yazısına göre kart eklemek bile AWS'yi tatmin etmemiş: ayrılma işlemi, başka neyin eksik olduğunu belirtmeden reddedilmeye devam etmiş. Yazar ayrıca, bir ödeme aracının var olup olmadığını gösteren herhangi bir public API'nin bulunmadığını belirtiyor — billing, account, budget ve cost-explorer yüzeylerinin hepsi boş dönmüş — bu da konsolun Billing ve Payment preferences sayfalarını tek kontrol noktası olarak bırakıyor.

Önemli bir uyarı öne çıkıyor: reddedilen bir ayrılma çağrısı zararsızdır, ancak ön koşullar bir kez karşılandığında aynı çağrı başarılı olur ve üretim hesabını anında ayırır. Yazarın tavsiyesi, o çağrıyı asla hazırlık testi olarak kullanmamaktır.

Bunun yerine hedeften davet gönderin

AWS, doğrudan hesap aktarımlarını 19 Kasım 2025'te duyurdu. Hedef organizasyonun management account'u bir davet gönderir, member account kabul eder ve hesap eski organizasyonundan hiç ayrılmadan ya da arada bağımsız çalışmadan yeni tarafa geçer. Yazar bir dokümantasyon pürüzüne dikkat çekiyor: InviteAccountToOrganization API referansı hâlâ ALREADY_IN_AN_ORGANIZATION'yı hata nedeni olarak listeliyor, ancak bu liste bazı nedenlerin işlem için geçerli olmayabileceği şeklindeki bir uyarının altında yer alıyor; hesap göç kılavuzu ise doğrudan aktarımı anlatıyor. İkisi çeliştiğinde yazar kullanıcı kılavuzunun tarafını tutuyor.

Mekanik olarak iki kısa çağrıdan ibaret:

hedef management account içinde

aws organizations invite-account-to-organization --target Id=123456789012,Type=ACCOUNT

member account içinde

aws organizations accept-handshake --handshake-id h-examplehandshakeid111

Kılavuzdaki ön koşullar arasında hesabın ve organizasyonun yaşıyla ilgili kurallar, eşleşmesi gereken bir Seller of Record ve hesabın yeni organizasyonun root'una yerleşmesi yer alıyor. Yazıda alıntılanan davet dokümantasyonuna göre davetler 15 gün sonra sona eriyor ve hedefin politikaları, hesap katılır katılmaz uygulanıyor.

Control Tower sırası

Hedefte AWS Control Tower bulunduğunda, yazıya göre bir taşınma ancak hesap doğru organizational unit'e kaydedildiğinde tamamlanmış sayılıyor. İşlem sırası:

1. Landing OU'yu hâlâ boşken Control Tower'a kaydedin — yazarın deneyiminde yaklaşık iki dakika sürüyor, ancak AWS on dakika ve üzerinde plan yapılmasını öneriyor. Control Tower'ın aws-guardrails-* service control policy'lerini eklemesi beklenen bir durumdur, drift değil.
2. Herhangi bir hesap gelmeden önce OU ile güvenlik izlemesini ilişkilendirin.
3. Daveti hedeften gönderin ve member account'ta kabul edin.
4. Member account'ta, hedefin management account'una güvenen ve AdministratorAccess managed policy taşıyan AWSControlTowerExecution rolünü oluşturun — bu rol olmadan kayıt işlemi başarısız olur.
5. Hesabı aynı gün Control Tower üzerinden kaydedin; kayıt tamamlanana kadar hesap, root altında oraya eklenmiş politikalar ne ise ona tabi şekilde bekler.

Yazar son adım için bilinçli olarak aws organizations move-account komutundan kaçınıyor: otomatik kayıt kapalıyken bir hesabı Control Tower OU'suna elle taşımak hesabı kaydetmez ve kalıtım drift'ine yol açar. Landing zone 3.1 ve sonrası bunun yerine otomatik kayıt yapabiliyor. Yazı ayrıca her şeyi aynı anda taşımak yerine göçleri kademeli yapmayı, hesapları erişim riskine göre sıralamayı ve izin setleri henüz hedefte bulunmayan hesapları geri tutmayı öneriyor.

Önemli olan üç kontrol

Bitmiş görünen bir taşınma da, yazıya göre üç cephede doğrulama gerektiriyor: insanlar bekildiği gibi oturum açabiliyor mu, hedefin kendi guardrail politikaları hesaba gerçekten uygulanıyor mu ve eski organizasyonun yönetimsel erişimi kesilmiş mi.

Neden önemli

Çok hesaplı AWS ortamları, tam da bu yazının sessizce drift edebileceği konusunda uyardığı mekanizmalarla yönetilir: OU'lardan kalıtılan SCP'ler, Control Tower kaydı ve management account'a bağlı IAM güven ilişkileri. Dashboard üzerinde sağlıklı görünen ama guardrail setinin dışında duran taşınmış bir hesap, hiçbir hata mesajı içermeyen bir uyum açığıdır. Davet yolu ayrıca pratik bir engeli kaldırıyor — her member account'a ödeme kartlarını elle girmek zorunluluğunu — ve konsolide faturalandırma dışında geçen bağımsız bir dönemin fatura boşluğunu ortadan kaldırıyor. Göç planlayan ekipler için kontrol listesi değerli ve somut: önce landing OU'yu ve güvenlik izlemesini hazırlayın, taşımadan hemen sonra kaydedin ve herhangi bir hesabı bitmiş saymadan önce oturum açmayı, guardrail'leri ve bayat yönetimsel erişimi doğrulayın.