Bir kuruluş, sekiz üye hesabı ve maksimum 20 hesap beklentisiyle AWS Organizations kullanıyor. Şirket, tüm iş yüklerini AWS üzerinde çalıştırıyor ve yeni bir güvenlik politikası gerektiriyor: • Hiçbir hesap, o hesap içindeki bir VPC'de iş yükü çalıştırmaz. • Tüm iş yükleri, tüm hesaplar tarafından erişilebilen, merkezi olarak yönetilen bir VPC'nin alt ağlarına başlatılmalıdır. • Hiçbir hesap, paylaşılan VPC içindeki başka bir hesabın uygulama kaynaklarını değiştiremez. • Merkezi olarak yönetilen VPC, kuruluş içindeki Account-A adlı mevcut bir hesapta bulunmalıdır. Account-A'daki bir CloudFormation şablonu, VPC'yi ve birden çok alt ağı oluşturur ve alt ağ kimliklerini yığın çıktıları olarak dışa aktarır. Bu gereksinimleri karşılamak için kurulumu hangi çözüm tamamlar?

Doğru cevap, Account-A'daki VPC alt ağlarını üye hesaplarıyla paylaşmak için AWS Resource Access Manager (AWS RAM) kullanmaktır. AWS RAM, kaynakları (bu durumda VPC alt ağlarını) AWS Kuruluşunuzdaki diğer AWS hesaplarıyla güvenli bir şekilde paylaşmanıza olanak tanır. Bu, üye hesaplarının kendi VPC'lerini oluşturmak zorunda kalmadan merkezi olarak yönetilen VPC'de iş yüklerini başlatma gereksinimini karşılar. Ayrıca, her hesap kendi kaynaklarını paylaşılan alt ağlarda dağıttığı için, bir hesabın başka bir hesabın uygulama kaynaklarını değiştirmesini engeller. Diğer seçenekler neden yanlış: Her üye hesabında CloudFormation şablonu kullanmak, her hesabın kendi VPC'sini oluşturmasına yol açar ve bu, gereksinimle çelişir. Bir transit gateway oluşturmak, hesaplar arasında bağlantı sağlar ancak iş yüklerinin merkezi VPC'nin alt ağlarına doğrudan başlatılmasına izin vermez. VPC peering, iki VPC arasında bire bir bağlantı kurar ve sekiz veya daha fazla hesap için ölçeklenebilir değildir; ayrıca, iş yüklerinin doğrudan eşlenmiş VPC'ye başlatılmasına izin vermez, yalnızca iletişim kurmasına izin verir.