Azure ile Çoklu Bulut Stratejileri

Çoklu bulut, iş yüklerinin birden fazla bulut sağlayıcısı arasında çalıştırılması anlamına gelir — örneğin çoğu hizmet için Azure kullanırken belirli bir makine öğrenmesi platformu için AWS'yi veya BigQuery analizleri için Google Cloud'u kullanmak gibi. Kuruluşlar çoklu bulutu şu amaçlarla benimser: sağlayıcıya bağımlılığı önlemek, her sağlayıcının sınıfının en iyisi olan hizmetlerinden yararlanmak, tek bir sağlayıcıya bağımlılığı önlemek üzere sözleşmeden veya mevzuattan kaynaklanan gereksinimleri karşılamak ya da birleşme ve satın almalar sonucunda farklı bulutlarda standartlaşmış şirketlerin bir araya gelmesi. Günümüzde büyük kuruluşlarda çoklu bulut kullanımı standart yaklaşımdır.

Çoklu bulut, önemli operasyonel zorluklar getirir: Yetenek dağınıklığı — ekiplerin birden fazla bulut platformunda uzmanlığa sahip olması gerekir. Tutarsız yönetişim — her bulutun farklı IAM, ilke ve uyumluluk araçları vardır. Güvenlik karmaşıklığı — farklı tehdit modelleri, farklı güvenlik hizmetleri ve farklı denetim günlükleri bulunur. Maliyet yönetimi — ayrı faturalama portalları, farklı fiyatlandırma birimleri ve sağlayıcılar arasında birleşik bir maliyet görünümü yoktur. Ağ karmaşıklığı — bulutlar arası trafik, çıkış maliyetlerine ve gecikmeye neden olur. Microsoft, bu sorunların çoğunu Azure Arc ve Defender for Cloud'daki çoklu bulut desteğiyle ele alır.

Şirket içi sunucuları Azure Arc'a kaydeden aynı bağlı makine aracısı, AWS EC2, Google Cloud Compute Engine veya başka herhangi bir bulutta çalışan sanal makinelerde de çalışır. Arc'a kaydedildikten sonra bu sanal makineler, ARM portalında Azure'a özgü kaynakların yanında görünür. Azure Policy'yi uygulayabilir, aynı KQL sorgularıyla Azure Monitor'u kullanabilir ve AWS ile GCP sanal makineleri için Defender for Cloud güvenlik önerilerini görüntüleyebilirsiniz — Azure portalından ayrılmadan veya AWS'ye özgü araçları öğrenmeden.

Microsoft Defender for Cloud, AWS ve Google Cloud Platform için yerel bağlayıcıları destekler. AWS hesabınızı veya GCP projenizi bağlayarak Defender for Cloud, Azure için kullandığı aynı Secure Score çerçevesini kullanarak EC2 örneklerinin, S3 klasörlerinin, RDS veritabanlarının ve GCP kaynaklarının güvenlik durumunu değerlendirebilir. Bulguları CIS AWS Foundations Benchmark gibi standartlarla eşleştirir ve yanlış yapılandırmaları (herkese açık S3 klasörleri, aşırı izinlere sahip IAM rolleri) Azure önerileriyle birlikte tek bir panoda algılar.

Azure Cost Management + Billing, AWS Cost and Usage Report (CUR) raporunuzu bir Azure Connector'a bağlayarak AWS maliyetlerini içeri alabilir. Bu işlem, birleşik bir maliyet analizi görünümünde AWS harcamalarını Azure harcamalarının yanında göstererek bulutlar arası maliyet karşılaştırması ve dağıtımı yapmanızı sağlar. Her iki sağlayıcıyı kapsayan bütçeler ve uyarılar oluşturabilir, gösterim/masraf yansıtma için aynı etiketleme stratejisini uygulayabilirsiniz. Bu çoklu bulut maliyet görünürlüğü, çeşitli sağlayıcılardaki harcamaları tek bir merkezden yöneten FinOps ekipleri için değerlidir.

Birçok çoklu bulut stratejisinde, herhangi bir bulutta aynı şekilde çalışan soyutlama katmanı olarak Kubernetes kullanılır. Azure'da AKS, AWS'de EKS ve GCP'de GKE standart Kubernetes çalıştırır. Azure Arc etkin Kubernetes, tümünü Azure'dan yönetebilir ve GitOps tabanlı dağıtımları ile Azure Policy'yi (OPA Gatekeeper) tutarlı biçimde uygulayabilir. Azure Container Registry'de depolanan kapsayıcı görüntüleri, herhangi bir buluttaki Kubernetes kümesinden çekilebilir; bu da Azure ACR'yi doğal bir çoklu bulut görüntü kayıt defteri merkezi hâline getirir.

Bir Azure Landing Zone, yönetişim, kimlik, güvenlik ve ağ iletişimiyle ilgili en iyi uygulamaları hayata geçiren, önceden yapılandırılmış bir ortamdır. Çoklu bulut benimsenirken kuruluşlar, tüm sağlayıcılara uygulanacak standartları tanımlamak için landing zone kavramını genişletir. Microsoft Cloud Adoption Framework (CAF), kaynak Azure'da, AWS'de veya şirket içinde bulunsa da tutarlı biçimde çalışan yönetim grubu hiyerarşilerinin, adlandırma kurallarının ve etiketleme stratejilerinin nasıl yapılandırılacağına ilişkin çoklu bulut kılavuzları içerir.

Azure ve AWS (veya GCP) iş yüklerini birbirine bağlamak, bulutlar arası ağ iletişimi gerektirir. Yaygın modeller şunlardır: VPN tünelleri — Azure VPN Gateway ile AWS Virtual Private Gateway veya GCP VPN arasında kurulur; basittir ancak bant genişliği sınırlıdır ve gecikme değişkenlik gösterebilir. Üçüncü taraf SD-WAN (ör. Megaport, Equinix Fabric) — ExpressRoute'a benzer özel bulutlar arası devreler oluşturur. Uygulama katmanı tümleştirmesi — hizmetler genel uç noktalar üzerinden HTTPS ile iletişim kurar (en basit seçenektir ancak interneti kullanır). AWS ve GCP'deki çıkış bant genişliği maliyetleri, yüksek hacimli bulutlar arası veri aktarımını pahalı hâle getirir.

Microsoft Entra ID, çoklu bulut erişimi için kimlik sağlayıcısı (IdP) olarak hizmet verebilir. AWS için Entra ID'yi AWS IAM Identity Center için SAML 2.0 IdP olarak yapılandırabilir; böylece kullanıcıların ayrı AWS IAM kullanıcıları olmadan Entra ID kimlik bilgileri ve MFA ile AWS konsoluna erişmesini sağlayabilirsiniz. GCP için de benzer bir federasyon mümkündür. Bu yaklaşım kimlik yönetişimini merkezileştirir — işe başlayanlar, görev yeri değişenler ve ayrılanlar Entra ID'de yönetilir, erişim de otomatik olarak tüm bulut sağlayıcılarına aktarılır.

FinOps (Bulut Finansal Operasyonları) uygulamaları, her sağlayıcının farklı fiyatlandırma modelleri, indirim mekanizmaları ve faturalama ayrıntı düzeyi olması nedeniyle çoklu bulutta daha karmaşık hâle gelir. En iyi uygulamalar şunlardır: maliyet dağıtımı için tüm sağlayıcılarda etiketlemeyi standartlaştırmak; birleşik görünürlük için Azure Cost Management + Billing'in AWS bağlayıcısını kullanmak; Reserved Instances (Azure), Savings Plans (AWS/Azure) ve Committed Use Discounts (GCP) konularını bilen bir FinOps ekibi oluşturmak; eşdeğer iş yüklerinin maliyetlerini karşılaştıran düzenli sağlayıcılar arası maliyet incelemeleri yapmak.

Çoklu bulut dikkatli yönetilmezse sorunlar oluşturabilir. Kaçınılması gereken yaygın hatalı tasarım kalıpları şunlardır: Plansız çoklu bulut — strateji olmadan birden fazla bulut kullanmak, kontrolsüz dağınıklığa ve maliyete yol açar. Yeteneklerin aşırı zorlanması — tüm mühendislerin her bulutta uzman olmasını beklemek yerine her platform için bulut sorumluları belirleyin. Tutarsız güvenlik — her bulutta farklı güvenlik temelleri uygulamak yerine tutarlılığı zorunlu kılmak için Azure Arc ve Defender for Cloud'u kullanın. Çıkış maliyetlerini göz ardı etmek — bulutlar arası veri aktarımı, sağlayıcıların çıkış ücretleri üzerinden faturalandırılır ve FinOps ekipleri için beklenmedik maliyetler oluşturabilir.

Bu derste şunları öğrendiniz: Azure Arc, aynı bağlı makine aracısını kullanarak Azure yönetimini AWS ve GCP sanal makinelerine genişletir; Microsoft Defender for Cloud çoklu bulut bağlayıcıları, sağlayıcılar arası güvenlik bulgularını birleşik bir Secure Score'da gösterir; Microsoft Entra ID federasyonu, tek bir kurumsal kimlik üzerinden AWS ve GCP konsollarında çoklu oturum açmayı sağlar. Böylece Azure Hibrit ve Çoklu Bulut kursu tamamlanır — sıradaki konu, Azure mimarilerinizi değerlendirmek ve geliştirmek için Well-Architected Framework'tür.