Diyagramlarla AWS ağ kavramları
(miparnisariblog.wordpress.com)- AWS VPC panosundaki karmaşık öğeleri anlamak için AWS ağ kaynakları arasındaki ilişkileri tek bakışta görebileceğiniz bir zihin haritası oluşturuldu
- Toni Pasanen’in AWS Networking Fundamentals kitabı ana başvuru kaynağı olarak kullanılarak, ağla ilgili kaynaklar bağlantı yapıları odağında düzenlendi
- AWS ağ yapısının karmaşıklaşmasının nedeni bağlantı türlerinin çeşitli olmasıdır; bunlara hesap-şirket içi ortam, hesap-hesap, VPC-VPC, alt ağ-alt ağ, VPC-internet ve VPC-AWS hizmeti bağlantıları dahildir
- Ortaya çıkan çıktı, AWS ağ bileşenlerini birbirine bağlayan bir zihin haritasıdır; Lucidchart kaynağı da birlikte görüntülenebilir
- AWS ağ yapısını ilk kez düzenlemeye çalışan geliştiriciler, çeşitli kaynakların hangi ilişkilerle birbirine bağlandığını görsel olarak kavramak için bundan yararlanabilir
VPC panosunda başlayan kafa karışıklığı
- Mart 2023’e kadar AWS VPC panosunda neler olup bittiğini anlamak zordu
- Sol paneldeki kaydırma çubuğu uzun olacak kadar çok öğe vardı; her kaynağın nasıl bağlandığını kavramak güçtü
Başvurulan kaynaklar ve düzenleme yönü
- AWS ağ yapısında rol alan çeşitli kaynakları anlamak için Toni Pasanen’in AWS Networking Fundamentals kitabının büyük bölümü okundu
- Kitabı okuduktan sonra, AWS ağ kaynaklarının çok olmasının nedeni mümkün olan bağlantı yöntemlerinin fazla olması şeklinde özetlendi
AWS ağ yapısında ele alınan bağlantı türleri
- AWS ağ yapısı çeşitli bağlantı türlerini içerir
- AWS hesabı ile şirket içi ortam arasındaki bağlantı
- Hesaplar arası bağlantı
- VPC’ler arası bağlantı
- Alt ağlar arası bağlantı
- VPC ile internet arasındaki bağlantı
- VPC ile belirli AWS hizmetleri arasındaki bağlantı
Zihin haritası çıktısı
- Çeşitli parçaları birbirine bağlamak için AWS ağ kavramları bir zihin haritası hâline getirildi
- Özgün düzenlenebilir sürüm Lucidchart bağlantısından görülebilir
- Yararlı olup olmadığı ve hata içerip içermediği konusunda geri bildirim isteniyor
1 yorum
Hacker News yorumları
AWS’de IAM politikaları ve kimlik doğrulama sorunlarını debug etmek neden bu kadar berbat, anlamıyorum
Rakip olmak istiyorsanız buraya odaklanmanız yeterli. Yetki yok hatasının nedenini bulmak için saatler harcadım; resmi dokümantasyon da SCP, IAM, kaynak politikaları vb. uygulanabilecek yaklaşık 8 farklı politikayı elle kurcalamamı söylüyor
Sonunda Athena ve CloudTrail kullanan dokümanı bulsanız bile isteklerin yarısı sebepsiz yere eksik ve hata mesajında istek ID’si olsa bile bununla kolayca arama yapılamıyor. İstek ID’siyle doğrudan sorgulayıp hangi politikanın reddettiğini net biçimde göstermeli
Baştan sona tam bir kargaşa; hatta belki de bu hali korudukça destek sözleşmelerini daha çok satabiliyorlar
Kişisel projelerde, çok nadir durumlar dışında neredeyse her zaman daha iyi değer sunan başka seçenekleri tercih ediyorum. Yaklaşık 10 yıl önce AWS, “sistemleri biz yönetiyoruz, tüm sistem yöneticilerini işten çıkarın” gibi pazarlanıyordu; şimdi ise iyi AWS DevOps mühendisleri pahalı ve bulunması zor, özellikle büyük kurulumlarda AWS’in önerilerini düzgün izlerseniz maliyet de muazzam oluyor
Bir function app’e SQL veritabanına erişim yetkisi verirken function app’in gerçek adını yazmak yetiyordu; takma ad varsa nesne tanımlayıcısıyla sınırlamak yeterli. Parola ya da sertifika gibi şeylere artık gerek yok, sadece çalışıyor
Kimlik doğrulama paketi ve Application Insights gibi şeylerle birlikte kullanınca, loglara bakmayı bildiğiniz varsayımıyla “burada ne oldu şimdi?” diye uzun süre takılıp kalmak pek yaşanmıyor
Yine de Azure’da da mayınların nerede olduğunu önceden bilmeniz gerekiyor; bilmiyorsanız benzer bir hayal kırıklığına düşüyorsunuz. Microsoft mayınların konumuna dair AWS’ten çok daha iyi ipuçları bıraksa da, son perdenin ötesine geçip maliyet ve karmaşıklığın 5–10 kat şişmesini önlemek için 20 yıllık deneyime sahip büyücü gibi birine ihtiyaç duyacak kadar bazı ipuçları uygun biçimde eksik bırakılmış
Hizmet hesabı debug etmek bazen makineyi ya da cluster’ı yeniden başlatmayı bile gerektirdiği için daha da zorlaşıyor. Sorunun tam olarak nerede çıktığını bulan “bulut traceroute” benzeri bir araç olsa harika olurdu
Hakkını vermek gerekirse henüz denemediğim en az ayrıcalık araçları var: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
Gerçekten sinir bozucu; tasarımı UX tasarımcıları ve mühendisleri bir araya getirerek yapmaları gerekirken bunu yapmıyorlar
Böyle bir hizmet müşteriye sunulursa potansiyel olarak saldırgana da sunulabilir ve bazı şirketlerin güvenlik/uyumluluk politikalarını fiilen ihlal edebilir
Yine de müşteri, “AWS root kullanıcısıyla tehlikeli işler yapmak” gibi büyük bir riski kabul eden bir belge imzalarsa bunun seçilebilir olması gerektiğini düşünüyorum
AWS istekleri zaten çok dağıtık olduğundan, kavramsal olarak GraphQL benzeri bir yapılandırma böyle bir sisteme uygun olabilir. OTEL gibi izleme sistemlerinden de çok uzak değil
Bu yüzden AWS ile uğraşmak zorunda kalmaktan hoşlanmıyorum. Bunu öğrenmek teknik bilgi değil, ürün bilgisi
TCP/IP Illustrated serisini baştan sona okuyup tamamen kavradım ve o bilgi onlarca yıl boyunca işe yaradı
Buna karşılık AWS bilgisi kendi içinde karmaşık olsa da her seferinde öğrenmeyi reddetmeme yol açıyor. Bu diyagrama bakınca hedef basitleştirmek idiyse ne kadar başarılı olunduğundan emin değilim
Örneğin amaç kurumsal müşterilerin sanal bir kurumsal ağı ya da sanal bir veri merkezi ağını yeniden oluşturmasını sağlamaksa, bunlar istemci TCP yığınından çok daha karmaşık
Basit kullanım için varsayılanlar da basit. Karmaşık durumlarda AWS'ye özgü ürün bilgisi gerekiyor gerçi, ama alttaki kavramların çoğu diğer bulutlarla veya şirket içi ağlarla ortak. N'inci programlama dilini öğrenmeye benziyor
TCP/IP, ağ programcıları için faydalı bir bilgi. Üniversitedeki ağ derslerinde ağları, alt ağları, yönlendirme tablolarını, RIP·OSPF·BGP gibi yönlendirme protokollerini, NAT'i vb. gerçek cihazlarla ele almıştık; Cisco sponsorluğu da çoktu ve dönem sonunda CCNA sertifikasyon seviyesine gelmiştik
Cisco ürünlerinin çalışma biçimi gibi çokça “ürün bilgisi” de öğrendim ama çoğunu unuttum; temel kavramlar Azure, AWS ve GCP'ye gayet iyi taşınıyor. Bulut VPC'leri, fiziksel ağların sanal karşılığı; tıpkı sanal makinelerin fiziksel makinelerin karşılığı olması gibi
Özellikle NAT insanları gerçekten çok karıştırıyor. Daha temel düzeyde, birçok mühendis CIDR gösterimini ya da TCP'nin kendisini bile zor buluyor. Örneğin
send()in verilen tamponu tek bir birim olarak gönderdiğini ya darecv()in her zaman eksiksiz bir “mesaj” aldığını düşünüyorlar. Bağlantı zaman aşımı ile eş tarafın bağlantıyı sıfırlaması arasındaki fark da sıkça karıştırılıyorYine de keşke bu bilgiye gerek olmasaydı. IPv6 ağları o kadar büyük hâle getiriyor ki alt ağ boyutu planlaması gibi şeylerin çoğunu ortadan kaldırıyor. NAT soğuk cehennemin dibine yok olup gidebilir. VPN'i de bir daha görmesek iyi olur; sadece TLS kullanalım. IP adreslerini kimlik doğrulama gibi kullanan bulut güvenlik duvarlarını ve bunların yol açtığı yanıltıcı hataları da ortadan kaldırmak isterim. Azure bu konuda berbat
Birçok profesyonel yazılım gibi başlangıçta ihtiyaç gereği basitti, ama zamanla karmaşıklaştı; AWS de tam yönetilen, isteğe bağlı altyapı hizmetlerinin cazibesi ve Amazon'un döktüğü kaynaklar yüzünden hızla şişti
Donanımla doğrudan uğraşmak zorunda olmamanın değeri hâlâ büyük, ama etiket fiyatının yanı sıra taşınması zor, satıcıya özgü bilgi bedelini de açıkça ödüyorsunuz
Bunun yerine “internet gateway”, “NAT gateway”, “egress only internet gateway”, “transit gateway” gibi tek seferlik kavramlarla dolu. Sonunda yalnızca “bulut”u anlayan ama gerçekte nasıl çalıştığını bilmeyen bir mühendis kuşağı ortaya çıkacak gibi
“Farklılaştırıcı olmayan” bileşenlerin hepsini AWS'ye devredip, iyi oldukları işe odaklanabilirler
Sadece genel küresel adresleme ve güvenlik duvarı sağlansaydı bu karmaşıklığın çoğu ortadan kalkardı
IP düzeyindeki internetin ne için olduğunu ve uçtan uca mimarinin hangi sorunları çözdüğünü kolayca unutuyoruz
AWS'nin “Well-Architected™” ağ mimarisi diye öğrettiği şey aslında kârlı bir kargo kültüne yakın; karmaşıklığa, birbirine benzeyen 10.x ağlardan oluşan bir labirente, adres çakışmalarına, birbirleriyle konuşturmaya çalışırken kullanılan kaba saba proxy'lere, düşen gerçek güvenliğe ve satıcı bağımlılığına yol açıyor. Karmaşıklık güvenliğin düşmanıdır
Eski sistem yöneticileri benim ücretimin yarısını ya da dörtte birini almıyordu; genelde tek bir kişi 100 geliştiriciyi kapsayacak kadar donanımı yönetiyordu. Geri kalanların bu kapsam genişlemesinden ve beyin hasarından kaçınması için gereken ek yük yaklaşık %0,5'ti
AWS'de bir kez daha kelimenin tam anlamıyla uzmanlığın ölümü yaşanıyor
Ayrıca küresel adresleme ve güvenlik duvarı, yalnızca public alt ağları olan bir VPC oluşturup güvenlik gruplarını güvenlik duvarı gibi kullanırsanız temelde mümkün değil mi? En iyi uygulama public/private alt ağlar ve NAT gateway olsa da, yalnızca güvenlik gruplarına dayanmak imkânsız değil gibi
O da küresel anycast IP'nin arkasında
Bu yüzden bulut ağlarında gördüğümüz gereksiz karmaşıklığın büyük kısmı ortaya çıkıyor
Bu zihin haritası birkaç ağ kavramına indirgenerek daha da basitleştirilebilir gibi görünüyor
O zaman ilişkilerin ve okların çoğu ortadan kalkar; AWS kavramlarını başka bulutlara ya da ev ağına da eşleyebilirsiniz
https://news.ycombinator.com/item?id=18925350 temelleri çok iyi görselleştiren bir kaynak. Ağın ne olduğu, içi ve dışının ne olduğu gibi noktalardan başlarsanız zihinsel model çok daha kolaylaşır ve tüm ayrıntıları bilmeseniz bile AWS özellikleri epey anlamlı gelir
Sonuç olarak karmaşık bir sistemi açık ve öz biçimde özetlemiş. Bir dahaki AWS ormanında yolumu bulmaya çalışırken başvuracağım bir kaynak olacak
Örneğin kullanılabilirlik bölgesi dikdörtgeninin içinde subnet olur, onun dışında VPC bulunur ve bu dikdörtgen de region’ın içinde yer alır. Kabaca buna benzer ama daha güzel çizilmiş hâli: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
Bulutun ilk günlerinde, AWS ağının basit olduğu o heyecanlı zamanları hatırlıyorum
Yine de bunun geleceğini biliyorduk. Herkes için her şey olabilmek için sonunda eski IPv4 veri merkezi ağlarının çılgınlığını kopyalamaktan başka çare yok
Yakın zamanda Azure’da kavramsal olarak basit bir şey yapmaya çalıştım. Veritabanı yedeklerinin bulunduğu storage account’u internete açıp herkesin yoklayabileceği hâlde bırakmamak
Sadece firewall’ı açmak yeterli olur sanmıştım ama allowlist’e yalnızca subnet eklenebiliyordu, o da her bir subnet’i tek tek eklemek şeklindeydi. Sanal ağ olmuyordu; başka yerlerde gayet çalışan “tüm sanal ağlarım” da olmuyordu
Private Endpoint özelliği de var ama performansı düşürüyor ve ek maliyet getiriyor. Yazılım tanımlı ağ ayarında adresi “public”ten “private”a çevirmek zor olsa gerek ki bulut perilerini telafi etmek gerekiyor
Ama pratikte çalışmıyor. İstemcinin bulabilmesi için DNS’i override etmeniz gerekiyor; bunu AD domain’ine bağlayınca da PaaS servisi erişemiyor
Sonunda daha pahalı bir private DNS zone oluşturup, bunu hub ağına bağlayıp, yine daha pahalı olan DNS Resolver servisini ekleyip, AD domain’inin çalışmaya devam etmesi için tonla kural ayarlarken bir hafta geçti
Başta yapmak istediğim tek şey, storage key sızsa bile Rus hacker’ın yedeklere erişememesiydi. Belki gelecek hafta, DNS ayarları güncellenmiş sanal ağı yeniden dağıtacak şekilde subscription template’ini güncelleyebilirim. İdempotent değil mi? Belki gelecek yıl preview olarak gelir
Sonrasında public’e açılacak kısım için public gateway ya da Front Door kullanabilirsiniz. Sevmiyorum ama eskiden de aşırı karmaşık değilmiş gibi bir durum yoktu. Sadece eskiden kesin biçimde operasyon ekibinin işi olan kurumsal ağların delice keşmekeşine artık geliştiriciler daha fazla maruz kalıyor
DNS ayarlarına doğrudan dokunmadığım bir alan olduğu için buna sihir diyorum. Özellikle App Service ve birden çok subscription kullanıyorsanız subnet paylaşamazsınız; app slot kullanırken IP adres alanınızın tükenmemesi için önceden plan yapmanız gerekir
Azure’da anlamadığım şey, kurumsal varsayılanın neden “hiçbiri internette değil” olmadığı. İnternete çıkarmak gerektiğinde açtırmalı. Zaten load balancer gibi birçok yapılandırma yapmak gerekiyor, dolayısıyla internete koyma süreci zaten karmaşık. En azından kurumsal ayarda varsayılan internet dışında olmalı
Microsoft Azure sertifikasyonu sattığı için işleri zorlaştırması mı gerekiyor bilmiyorum ama 2023’te neden daha varsayılanlardan itibaren bu karmaşıklığı düşünmemiz gerektiğini anlamıyorum. Çok özelleştirilebilir olması sorun değil
Bu kaynak çok iyi. Google Cloud dokümantasyonunun bu tür karmaşıklığı ihtiyaç doğdukça nispeten iyi anlattığını düşünüyordum ama bu kadar eksiksiz bir genel bakış görmemiştim
Yalnız görüntüyü görmek için epey uğraşmam gerekti. Sayfada çok küçük, tıklanamıyor; yeni sekmede açınca imgur benzeri işe yaramaz bir sayfaya gidiyor ve hâlâ küçük görünüyor. Sonunda düzgün görmek için görseli indirmem gerekti
Bu kaynak harika. Bulut ürünlerini ya da başka kavramları öğrenirken zihin haritaları ve diyagramların ne kadar güçlü olduğunu iyi gösteriyor
AWS sertifikasına çalışırken bunları çok kullandım; uzun notlar yazsam da servisleri sayfalar dizisi olarak görmektense harita üzerinde bağlantılı biçimde görmek çok daha iyi anlamamı sağladı. Elbette herkesin öğrenme biçimi farklı
Bu başlıktaki eleştirilerin hepsini anlayamıyorum. AWS’in sunduğu ağ sistemlerinin çoğu ihtiyaç duyduğunuzda kullandığınız şeyler
Zarif değil ama iş görüyor. Üstelik AWS’e özgü bileşenlerin önemli bir kısmı gerçek ağ kavramlarına doğrudan karşılık geliyor. AZ cage’e, VPC VLAN’a, PL de kabaca hesaplar arası P2P VPN’e denk geliyor
Geri kalanların çoğu da tipik büyük ölçekli ortamlarda görebileceğiniz sıradan ağ bileşenleri
Çalıştığım şirket oldukça karmaşık bir küresel ağ işletiyor ve birden çok PoP üzerinden DX ile AWS’e bağlanıyor. Bu diyagramdaki her şeyi kullanıyoruz ve her bileşenin iyi tanımlanmış bir amacı var
Bu diyagram size aşırı karmaşık görünüyorsa, büyük olasılıkla bunların hepsini kullanmıyor ya da amaçlandığı şekilde kullanmıyorsunuzdur; veya ağ mühendisi değilsinizdir
Görseli gerçekten okuyabilen var mı? Masaüstündeyim ama okunabilir çözünürlükte göremiyorum
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... de hâlâ bir web sayfası ve görsel daha büyük olsa da daha okunabilir değil
Yine de kaydedince en azından çalışıyor. Sonra da büyük bir ekrana ihtiyaç var. Boyutu 7.763 × 4.684 piksel
İnanılmaz karmaşık görünüyor. Üç büyük bulut sağlayıcısı arasında yalnızca GCP’yi biliyorum; orada da ağ tarafı basit değil ama yine de bir ölçüde sezgisel ve tutarlı.
Çoklu bulut deneyimi daha fazla olan birinin, iç ve dış iletişim yapılandırmasının kolaylık/zorluk düzeyini Büyük 3 temelinde karşılaştırmasını isterdim.
Bu şaşırtıcı değil; çünkü çoğunun ağ standartlarının kendisinde de doğrudan karşılığı var. İkisi de özünde yazılım tanımlı ağ dünyasına bakmanın farklı yolları.