Bulut altyap\u0131lar\u0131nda, \u00f6zellikle Amazon Web Services (AWS) \u00fczerinde \u00e7al\u0131\u015f\u0131rken, farkl\u0131 sanal \u00f6zel bulut (VPC) ortamlar\u0131 aras\u0131nda g\u00fcvenli ve verimli ileti\u015fim kurmak kritik bir \u00f6neme sahiptir. Uygulamalar\u0131n\u0131z\u0131n farkl\u0131 VPC’lerde bar\u0131nd\u0131r\u0131lmas\u0131, g\u00fcvenlik, izolasyon veya organizasyonel nedenlerle s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir durumdur. Ancak bu VPC’ler aras\u0131nda nas\u0131l k\u00f6pr\u00fc kuraca\u011f\u0131n\u0131z, a\u011f mimarinizin \u00f6l\u00e7eklenebilirli\u011fini, y\u00f6netim kolayl\u0131\u011f\u0131n\u0131 ve maliyet etkinli\u011fini do\u011frudan etkiler. Peki, bu ba\u011flant\u0131lar\u0131 kurarken hangi y\u00f6ntemi tercih etmelisiniz: geleneksel VPC Peering mi, yoksa daha modern ve merkezi bir \u00e7\u00f6z\u00fcm olan Transit Gateway mi? Bu makale, her iki yakla\u015f\u0131m\u0131n temelini, avantajlar\u0131n\u0131, s\u0131n\u0131rlamalar\u0131n\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l bir se\u00e7im yapman\u0131z gerekti\u011fini ad\u0131m ad\u0131m a\u00e7\u0131klayacakt\u0131r.<\/p>\n
Modern bulut mimarileri genellikle tek bir monolitik VPC yerine, \u00e7e\u015fitli ama\u00e7lar i\u00e7in ayr\u0131lm\u0131\u015f birden fazla VPC kullan\u0131r. Bu yakla\u015f\u0131m\u0131n ard\u0131nda yatan bir\u00e7ok ge\u00e7erli sebep bulunmaktad\u0131r. \u00d6ncelikle, g\u00fcvenlik ve izolasyon en \u00f6nemli fakt\u00f6rlerden biridir. \u00d6rne\u011fin, bir \u00fcretim ortam\u0131 VPC’si ile bir geli\u015ftirme veya test ortam\u0131 VPC’si birbirinden tamamen izole edilmek istenebilir. Bu, olas\u0131 bir g\u00fcvenlik ihlalinin veya yanl\u0131\u015f yap\u0131land\u0131rman\u0131n etkisini s\u0131n\u0131rlamaya yard\u0131mc\u0131 olur. \u0130kinci olarak, farkl\u0131 ekiplerin veya departmanlar\u0131n kendi kaynaklar\u0131n\u0131 y\u00f6netebilmesi i\u00e7in ayr\u0131 VPC’ler tahsis edilebilir. Her ekip, kendi VPC’sinde tam kontrol sahibi olurken, di\u011fer ekiplerin kaynaklar\u0131na yanl\u0131\u015fl\u0131kla eri\u015fmesini veya onlar\u0131 etkilemesini engeller. Bu, \u00f6zellikle b\u00fcy\u00fck kurulu\u015flarda operasyonel verimlili\u011fi art\u0131r\u0131r ve sorumluluklar\u0131 netle\u015ftirir.<\/p>\n
\u00dc\u00e7\u00fcnc\u00fc bir neden ise, farkl\u0131 co\u011frafi b\u00f6lgelerde (AWS Region) veya farkl\u0131 AWS hesaplar\u0131nda kaynak bar\u0131nd\u0131rma ihtiyac\u0131d\u0131r. K\u00fcresel \u00f6l\u00e7ekte hizmet veren bir \u015firket, kullan\u0131c\u0131lar\u0131na daha d\u00fc\u015f\u00fck gecikme s\u00fcreleri sunmak veya veri ikametgah\u0131 (data residency) gereksinimlerini kar\u015f\u0131lamak i\u00e7in birden fazla b\u00f6lgede altyap\u0131 kurabilir. Benzer \u015fekilde, bir ana \u015firket ve onun alt \u015firketleri veya farkl\u0131 i\u015f birimleri, kendi AWS hesaplar\u0131na sahip olabilir ve bu hesaplardaki VPC’lerin birbiriyle ileti\u015fim kurmas\u0131 gerekebilir. Ortak hizmetlerin, \u00f6rne\u011fin merkezi bir Active Directory sunucusunun veya bir izleme (monitoring) sisteminin ayr\u0131 bir VPC’de bar\u0131nd\u0131r\u0131lmas\u0131 ve di\u011fer t\u00fcm VPC’lerin bu hizmetlere eri\u015fmesi gereken durumlar da \u00e7ok yayg\u0131nd\u0131r. Bu senaryolar\u0131n her birinde, VPC’ler aras\u0131 g\u00fcvenli ve etkili bir ileti\u015fim mekanizmas\u0131 zorunlu hale gelir. Bu ba\u011flamda, do\u011fru a\u011f \u00e7\u00f6z\u00fcm\u00fcn\u00fc se\u00e7mek, sadece mevcut ihtiya\u00e7lar\u0131 kar\u015f\u0131lamakla kalmaz, ayn\u0131 zamanda gelecekteki b\u00fcy\u00fcme ve karma\u015f\u0131kl\u0131k kar\u015f\u0131s\u0131nda mimarinizin ne kadar dayan\u0131kl\u0131 olaca\u011f\u0131n\u0131 da belirler. Dolay\u0131s\u0131yla, bu ihtiya\u00e7lar\u0131 kar\u015f\u0131lamak i\u00e7in VPC Peering ve Transit Gateway gibi \u00e7\u00f6z\u00fcmler devreye girer.<\/p>\n
AWS VPC Peering, iki farkl\u0131 VPC’yi do\u011frudan bir a\u011f ba\u011flant\u0131s\u0131yla birbirine ba\u011flaman\u0131n en temel ve geleneksel yoludur. Bu ba\u011flant\u0131 sayesinde, her iki VPC’deki kaynaklar (\u00f6rne\u011fin EC2 \u00f6rnekleri, RDS veritabanlar\u0131) birbirleriyle \u00f6zel IP adresleri \u00fczerinden ileti\u015fim kurabilir, sanki ayn\u0131 a\u011fdaym\u0131\u015f gibi. Peering ba\u011flant\u0131lar\u0131, AWS’nin kendi k\u00fcresel a\u011f altyap\u0131s\u0131n\u0131 kullanarak kurulur ve tamamen \u00f6zeldir; yani trafik internet \u00fczerinden ge\u00e7mez, bu da hem g\u00fcvenlik hem de performans a\u00e7\u0131s\u0131ndan \u00f6nemli bir avantaj sa\u011flar. Peering ba\u011flant\u0131s\u0131 kurmak olduk\u00e7a basittir: bir VPC sahibi di\u011fer VPC’ye bir ba\u011flant\u0131 iste\u011fi g\u00f6nderir ve di\u011fer VPC sahibi bu iste\u011fi kabul eder. Kabul edildikten sonra, her iki VPC’nin y\u00f6nlendirme tablolar\u0131na (route table) di\u011fer VPC’nin CIDR blo\u011funu (IP adresi aral\u0131\u011f\u0131) ve peering ba\u011flant\u0131s\u0131n\u0131 hedef g\u00f6steren rotalar eklenmesi gerekir. Bu manuel ad\u0131m, ba\u011flant\u0131n\u0131n aktif hale gelmesi i\u00e7in zorunludur.<\/p>\n
Bir VPC Peering ba\u011flant\u0131s\u0131, tam bir a\u011f ge\u00e7idi (gateway) veya VPN ba\u011flant\u0131s\u0131 de\u011fildir; daha ziyade, iki VPC aras\u0131nda do\u011frudan bir a\u011f yolu olu\u015fturur. Bu, \u00f6zellikle ayn\u0131 AWS hesab\u0131 i\u00e7inde veya farkl\u0131 AWS hesaplar\u0131 aras\u0131nda az say\u0131da VPC’yi birbirine ba\u011flaman\u0131z gerekti\u011finde ideal bir \u00e7\u00f6z\u00fcmd\u00fcr. \u00d6rne\u011fin, bir e-ticaret \u015firketinin ana uygulamas\u0131 bir VPC’de \u00e7al\u0131\u015f\u0131rken, \u00f6deme i\u015flemcisi veya envanter y\u00f6netimi gibi arka u\u00e7 hizmetleri ba\u015fka bir VPC’de bar\u0131nd\u0131r\u0131labilir. Bu iki VPC’nin birbirine do\u011frudan eri\u015fmesi gerekti\u011finde VPC Peering devreye girer. Ancak, peering ba\u011flant\u0131s\u0131n\u0131n \u00e7al\u0131\u015fabilmesi i\u00e7in dikkat edilmesi gereken \u00f6nemli bir nokta, her iki VPC’nin CIDR bloklar\u0131n\u0131n \u00e7ak\u0131\u015fmamas\u0131d\u0131r. E\u011fer CIDR bloklar\u0131 \u00e7ak\u0131\u015f\u0131rsa, AWS bu iki VPC aras\u0131nda peering ba\u011flant\u0131s\u0131 kurulmas\u0131na izin vermez. Bu k\u0131s\u0131tlama, a\u011f planlamas\u0131n\u0131n ba\u015flang\u0131c\u0131nda g\u00f6z \u00f6n\u00fcnde bulundurulmas\u0131 gereken kritik bir fakt\u00f6rd\u00fcr. Ayr\u0131ca, peering ba\u011flant\u0131lar\u0131 transit (ge\u00e7i\u015f) y\u00f6nlendirmeyi desteklemez; yani A VPC’si B VPC’si ile peer edilmi\u015fse ve B VPC’si de C VPC’si ile peer edilmi\u015fse, A VPC’si do\u011frudan C VPC’si ile ileti\u015fim kuramaz. Her ba\u011flant\u0131 ikili (point-to-point) bir yap\u0131dad\u0131r. Bu durum, a\u011f\u0131n\u0131zdaki VPC say\u0131s\u0131 artt\u0131k\u00e7a y\u00f6netim karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir.<\/p>\n
VPC Peering’in temelini anlamak i\u00e7in, bir \u00f6rnek \u00fczerinden gidelim. Diyelim ki, iki VPC’niz var: Bu ad\u0131mlar tamamland\u0131\u011f\u0131nda, VPC Peering, basit ve do\u011frudan bir ba\u011flant\u0131 \u00e7\u00f6z\u00fcm\u00fc sunar; bu da onu belirli senaryolar i\u00e7in olduk\u00e7a cazip k\u0131lar. En b\u00fcy\u00fck avantajlar\u0131ndan biri, kurulumunun nispeten kolay ve h\u0131zl\u0131 olmas\u0131d\u0131r. \u0130ki VPC’yi birbirine ba\u011flamak i\u00e7in birka\u00e7 t\u0131klama ve y\u00f6nlendirme tablosu g\u00fcncellemesi yeterlidir. Maliyet a\u00e7\u0131s\u0131ndan da olduk\u00e7a avantajl\u0131d\u0131r, \u00e7\u00fcnk\u00fc AWS, peering ba\u011flant\u0131lar\u0131n\u0131n kendisi i\u00e7in ek bir \u00fccret talep etmez; yaln\u0131zca veri transferi i\u00e7in standart \u00fccretler ge\u00e7erlidir. Bu, \u00f6zellikle s\u0131n\u0131rl\u0131 b\u00fct\u00e7eye sahip k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli i\u015fletmeler veya sadece birka\u00e7 VPC aras\u0131nda ba\u011flant\u0131 kurmas\u0131 gereken projeler i\u00e7in ekonomik bir se\u00e7enektir. Ayr\u0131ca, trafik AWS’nin \u00f6zel omurga a\u011f\u0131 \u00fczerinden ge\u00e7ti\u011fi i\u00e7in, internet \u00fczerinden ge\u00e7en trafi\u011fe k\u0131yasla daha d\u00fc\u015f\u00fck gecikme s\u00fcresi ve daha y\u00fcksek bant geni\u015fli\u011fi sunar, bu da performans a\u00e7\u0131s\u0131ndan \u00f6nemlidir. G\u00fcvenlik taraf\u0131nda ise, trafik internete \u00e7\u0131kmad\u0131\u011f\u0131 i\u00e7in d\u0131\u015far\u0131dan gelebilecek tehditlere kar\u015f\u0131 daha korunakl\u0131d\u0131r.<\/p>\n Ancak, VPC Peering’in \u00f6nemli s\u0131n\u0131rlamalar\u0131 vard\u0131r ve bu s\u0131n\u0131rlamalar, a\u011f mimarisi b\u00fcy\u00fcd\u00fck\u00e7e veya karma\u015f\u0131kla\u015ft\u0131k\u00e7a belirginle\u015fir. En \u00f6nemli s\u0131n\u0131rlama, “transit y\u00f6nlendirme” (transit routing) deste\u011finin olmamas\u0131d\u0131r. Yani, e\u011fer A VPC’si B VPC’si ile peer edilmi\u015fse ve B VPC’si de C VPC’si ile peer edilmi\u015fse, A VPC’si do\u011frudan C VPC’si ile ileti\u015fim kuramaz. Her VPC \u00e7ifti aras\u0131nda ayr\u0131 bir peering ba\u011flant\u0131s\u0131 kurman\u0131z gerekir. Bu durum, a\u011f\u0131n\u0131zdaki VPC say\u0131s\u0131 artt\u0131k\u00e7a bir “tam \u00f6rg\u00fc” (full-mesh) yap\u0131s\u0131na yol a\u00e7ar. N adet VPC i\u00e7in Bir di\u011fer \u00f6nemli s\u0131n\u0131rlama ise CIDR blok \u00e7ak\u0131\u015fmas\u0131d\u0131r. Peering ba\u011flant\u0131s\u0131 kuraca\u011f\u0131n\u0131z iki VPC’nin CIDR bloklar\u0131 \u00e7ak\u0131\u015fmamal\u0131d\u0131r. E\u011fer \u00e7ak\u0131\u015f\u0131rsa, ba\u011flant\u0131 kurulamaz. Bu, \u00f6zellikle b\u00fcy\u00fck kurulu\u015flarda, farkl\u0131 ekiplerin veya departmanlar\u0131n VPC’lerini ba\u011f\u0131ms\u0131z olarak olu\u015fturdu\u011fu durumlarda bir sorun te\u015fkil edebilir. A\u011f planlamas\u0131n\u0131n ba\u015f\u0131nda bu konuya dikkat edilmezse, sonradan \u00e7ak\u0131\u015fan CIDR bloklar\u0131n\u0131 d\u00fczeltmek ciddi yeniden yap\u0131land\u0131rma \u00e7abalar\u0131 gerektirebilir. Ayr\u0131ca, peering ba\u011flant\u0131lar\u0131 yaln\u0131zca ayn\u0131 AWS B\u00f6lgesi i\u00e7inde veya farkl\u0131 b\u00f6lgeler aras\u0131nda (Inter-Region VPC Peering) kurulabilir, ancak farkl\u0131 AWS hesaplar\u0131 aras\u0131nda da desteklenir. Ancak her durumda, y\u00f6netimi ve \u00f6l\u00e7eklenebilirli\u011fi s\u0131n\u0131rl\u0131d\u0131r. Bu s\u0131n\u0131rlamalar, \u00f6zellikle 5-10 VPC’den fazla ba\u011flant\u0131 kurman\u0131z gerekti\u011finde veya karma\u015f\u0131k bir a\u011f topolojisine sahip oldu\u011funuzda, Transit Gateway gibi daha geli\u015fmi\u015f \u00e7\u00f6z\u00fcmlere y\u00f6nelmeyi zorunlu k\u0131lar. \u00d6zetle, VPC Peering basit senaryolar i\u00e7in harika bir ba\u015flang\u0131\u00e7 noktas\u0131 olsa da, b\u00fcy\u00fcyen ve dinamik bulut ortamlar\u0131 i\u00e7in s\u00fcrd\u00fcr\u00fclebilir bir \u00e7\u00f6z\u00fcm olmaktan uzakt\u0131r.<\/p>\n AWS Transit Gateway (TGW), VPC Peering’in yukar\u0131da bahsedilen s\u0131n\u0131rlamalar\u0131na, \u00f6zellikle de transit y\u00f6nlendirme eksikli\u011fi ve artan y\u00f6netim karma\u015f\u0131kl\u0131\u011f\u0131na bir yan\u0131t olarak ortaya \u00e7\u0131km\u0131\u015f merkezi bir a\u011f hub’\u0131d\u0131r. Ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, “transit” (ge\u00e7i\u015f) \u00f6zelli\u011fini merkeze al\u0131r. Transit Gateway, farkl\u0131 VPC’leri, AWS hesaplar\u0131n\u0131 ve hatta \u015firket i\u00e7i a\u011flar\u0131 (VPN veya Direct Connect arac\u0131l\u0131\u011f\u0131yla) birbirine ba\u011flayarak merkezi bir a\u011f mimarisi olu\u015fturman\u0131za olanak tan\u0131r. Art\u0131k her VPC’nin di\u011fer her VPC ile do\u011frudan ba\u011flant\u0131 kurmas\u0131 gerekmez; t\u00fcm VPC’ler Transit Gateway’e ba\u011flan\u0131r ve Transit Gateway, bu ba\u011flant\u0131lar aras\u0131ndaki trafi\u011fi y\u00f6nlendirir. Bu, bir “hub-and-spoke” (merkez ve kollar\u0131) mimarisi olu\u015fturur ve a\u011f topolojisini \u00f6nemli \u00f6l\u00e7\u00fcde basitle\u015ftirir.<\/p>\n Transit Gateway’in ortaya \u00e7\u0131k\u0131\u015f\u0131, i\u015fletmelerin bulut adaptasyonuyla birlikte a\u011f karma\u015f\u0131kl\u0131\u011f\u0131n\u0131n artmas\u0131yla do\u011frudan ili\u015fkilidir. B\u00fcy\u00fck kurulu\u015flar, y\u00fczlerce hatta binlerce VPC’ye sahip olabilirler. Bu kadar \u00e7ok VPC’yi VPC Peering ile y\u00f6netmek, kabus gibi bir g\u00f6rev haline gelir. Her yeni VPC eklendi\u011finde, mevcut t\u00fcm VPC’lerle ba\u011flant\u0131 kurmak ve her birinin y\u00f6nlendirme tablosunu g\u00fcncellemek, insan hatas\u0131na a\u00e7\u0131k, zaman al\u0131c\u0131 ve y\u00f6netimi imkans\u0131z bir s\u00fcre\u00e7tir. Transit Gateway, bu sorunu tek bir merkezi noktada \u00e7\u00f6zerek, t\u00fcm bu ba\u011flant\u0131lar\u0131n tek bir yerden y\u00f6netilmesini sa\u011flar. Bir VPC’yi Transit Gateway’e ba\u011flad\u0131\u011f\u0131n\u0131zda, o VPC art\u0131k Transit Gateway’e ba\u011fl\u0131 di\u011fer t\u00fcm VPC’lerle ve \u015firket i\u00e7i a\u011flarla ileti\u015fim kurabilir (y\u00f6nlendirme politikalar\u0131 izin verdi\u011fi s\u00fcrece).<\/p>\n Transit Gateway, kendi y\u00f6nlendirme tablolar\u0131na sahiptir ve bu tablolar, ba\u011fl\u0131 t\u00fcm a\u011flar\u0131n (VPC’ler, VPN’ler, Direct Connect a\u011f ge\u00e7itleri) CIDR bloklar\u0131n\u0131 \u00f6\u011frenir ve trafi\u011fi do\u011fru hedefe y\u00f6nlendirir. Bu merkezi y\u00f6nlendirme yetene\u011fi, a\u011f y\u00f6neticilerine b\u00fcy\u00fck bir esneklik sunar. \u00d6rne\u011fin, belirli VPC’lerin sadece belirli di\u011fer VPC’lerle veya sadece \u015firket i\u00e7i a\u011flarla ileti\u015fim kurmas\u0131na izin veren ince taneli (fine-grained) y\u00f6nlendirme politikalar\u0131 olu\u015fturulabilir. Ayr\u0131ca, Transit Gateway, farkl\u0131 AWS hesaplar\u0131ndaki VPC’leri de kolayca ba\u011flayabilir, bu da \u00e7oklu hesap stratejisi izleyen kurulu\u015flar i\u00e7in hayati bir \u00f6zelliktir. Her hesap sahibi, kendi VPC’sini Transit Gateway’e bir “eklenti” (attachment) olarak ekler ve merkezi a\u011f ekibi, bu ba\u011flant\u0131lar\u0131 y\u00f6netir. Bu yap\u0131, hem \u00f6l\u00e7eklenebilirlik hem de g\u00fcvenlik a\u00e7\u0131s\u0131ndan VPC Peering’e g\u00f6re \u00e7ok daha \u00fcst\u00fcn bir \u00e7\u00f6z\u00fcm sunar. Transit Gateway’in maliyeti olsa da (saatlik \u00fccret ve veri i\u015fleme \u00fccreti), sa\u011flad\u0131\u011f\u0131 y\u00f6netim kolayl\u0131\u011f\u0131, esneklik ve \u00f6l\u00e7eklenebilirlik genellikle bu maliyetin \u00f6n\u00fcne ge\u00e7er, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k a\u011f ortamlar\u0131nda.<\/p>\n Bir Transit Gateway olu\u015fturmak ve VPC’leri ona ba\u011flamak i\u00e7in izlenecek temel ad\u0131mlar \u015funlard\u0131r:<\/p>\n Bu merkezi model, a\u011f mimarisini basitle\u015ftirir ve gelecekteki geni\u015flemeler i\u00e7in sa\u011flam bir temel sunar.<\/p>\n AWS Transit Gateway, sadece VPC’leri birbirine ba\u011flaman\u0131n \u00f6tesinde, karma\u015f\u0131k a\u011f mimarileri i\u00e7in bir dizi g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcm ve esnek mimari yakla\u015f\u0131m sunar. En temel faydas\u0131, daha \u00f6nce de belirtildi\u011fi gibi, merkezi bir “hub” g\u00f6revi g\u00f6rmesidir. Bu, t\u00fcm VPC’lerin (veya di\u011fer a\u011flar\u0131n) tek bir noktaya ba\u011flanarak birbirleriyle ileti\u015fim kurmas\u0131n\u0131 sa\u011flar, b\u00f6ylece N-kare (N^2) peering ba\u011flant\u0131 karma\u015fas\u0131 ortadan kalkar. Bu merkezile\u015fme, a\u011f y\u00f6netimini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftirir ve hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 azalt\u0131r.<\/p>\n Transit Gateway’in sundu\u011fu \u00f6nemli bir mimari yakla\u015f\u0131m, “payla\u015f\u0131lan hizmetler VPC’si” (shared services VPC) modelidir. Bu modelde, Active Directory, DNS sunucular\u0131, izleme ara\u00e7lar\u0131 veya merkezi g\u00fcvenlik duvarlar\u0131 gibi t\u00fcm kurulu\u015f i\u00e7in kritik olan hizmetler \u00f6zel bir VPC’de bar\u0131nd\u0131r\u0131l\u0131r. Di\u011fer t\u00fcm i\u015f y\u00fck\u00fc VPC’leri, Transit Gateway \u00fczerinden bu payla\u015f\u0131lan hizmetler VPC’sine eri\u015fir. Bu, kaynaklar\u0131n daha verimli kullan\u0131lmas\u0131n\u0131 sa\u011flar ve g\u00fcvenlik politikalar\u0131n\u0131n tek bir noktadan uygulanmas\u0131na olanak tan\u0131r. \u00d6rne\u011fin, t\u00fcm giden internet trafi\u011fini merkezi bir g\u00fcvenlik duvar\u0131 VPC’sinden ge\u00e7irmek isteyebilirsiniz. Transit Gateway, bu trafi\u011fi kolayca y\u00f6nlendirerek bu t\u00fcr bir mimariyi m\u00fcmk\u00fcn k\u0131lar. Bu, bir bankac\u0131l\u0131k uygulamas\u0131n\u0131n t\u00fcm mikro servislerinin ayr\u0131 VPC’lerde \u00e7al\u0131\u015f\u0131rken, merkezi bir denetim ve g\u00fcvenlik VPC’sine ba\u011fl\u0131 olmas\u0131n\u0131 sa\u011flayabilir.<\/p>\n Ayr\u0131ca, Transit Gateway, \u015firket i\u00e7i a\u011flarla bulut aras\u0131ndaki ba\u011flant\u0131y\u0131 da merkezi hale getirir. AWS Direct Connect Gateway veya VPN ba\u011flant\u0131lar\u0131, do\u011frudan Transit Gateway’e ba\u011flanabilir. Bu sayede, \u015firket i\u00e7i a\u011f\u0131n\u0131z, Transit Gateway’e ba\u011fl\u0131 t\u00fcm VPC’lerle tek bir ba\u011flant\u0131 noktas\u0131 \u00fczerinden ileti\u015fim kurabilir. Bu, hibrit bulut mimarileri i\u00e7in hayati bir \u00f6zelliktir ve a\u011f topolojisini daha da basitle\u015ftirir. Transit Gateway’in y\u00f6nlendirme tablolar\u0131, a\u011f segmentasyonunu ve g\u00fcvenlik politikalar\u0131n\u0131 uygulamak i\u00e7in de kullan\u0131labilir. Farkl\u0131 y\u00f6nlendirme tablolar\u0131 olu\u015fturarak ve bunlar\u0131 farkl\u0131 eklentilerle ili\u015fkilendirerek, hangi VPC’lerin birbirini g\u00f6rebilece\u011fini, hangi trafi\u011fin \u015firket i\u00e7i a\u011fa y\u00f6nlendirilece\u011fini veya hangi trafi\u011fin bir g\u00fcvenlik duvar\u0131 VPC’sine y\u00f6nlendirilece\u011fini hassas bir \u015fekilde kontrol edebilirsiniz. Bu esneklik, karma\u015f\u0131k g\u00fcvenlik ve uyumluluk gereksinimleri olan kurulu\u015flar i\u00e7in \u00e7ok de\u011ferlidir.<\/p>\n Transit Gateway ayr\u0131ca, “Inter-Region Peering” (B\u00f6lgeler Aras\u0131 Peering) \u00f6zelli\u011fi sayesinde, farkl\u0131 AWS B\u00f6lgelerindeki Transit Gateway’leri birbirine ba\u011flayabilir. Bu, k\u00fcresel bir a\u011f omurgas\u0131 olu\u015fturman\u0131za ve farkl\u0131 b\u00f6lgelerdeki uygulamalar\u0131n\u0131z\u0131n d\u00fc\u015f\u00fck gecikme s\u00fcresiyle ileti\u015fim kurmas\u0131n\u0131 sa\u011flaman\u0131za olanak tan\u0131r. \u00d6rne\u011fin, Avrupa’daki bir veri merkezi ile Asya’daki bir veri merkezi aras\u0131nda g\u00fcvenli ve y\u00fcksek performansl\u0131 bir ba\u011flant\u0131 kurmak i\u00e7in Inter-Region Transit Gateway Peering kullan\u0131labilir. Bu \u00f6zellik, k\u00fcresel \u00f6l\u00e7ekte faaliyet g\u00f6steren \u015firketler i\u00e7in bulut a\u011flar\u0131n\u0131 y\u00f6netmeyi ve geni\u015fletmeyi \u00e7ok daha kolay hale getirir. T\u00fcm bu \u00f6zellikler bir araya geldi\u011finde, Transit Gateway, modern ve \u00f6l\u00e7eklenebilir bulut a\u011f mimarileri i\u00e7in vazge\u00e7ilmez bir ara\u00e7 haline gelmektedir.<\/p>\n VPC Peering ve Transit Gateway aras\u0131ndaki se\u00e7im, genellikle a\u011f\u0131n\u0131z\u0131n b\u00fcy\u00fckl\u00fc\u011f\u00fcne, karma\u015f\u0131kl\u0131\u011f\u0131na, y\u00f6netim ihtiya\u00e7lar\u0131na ve b\u00fct\u00e7enize ba\u011fl\u0131d\u0131r. Her iki \u00e7\u00f6z\u00fcm de VPC’ler aras\u0131 ba\u011flant\u0131 sa\u011flasa da, bunu farkl\u0131 yakla\u015f\u0131mlarla ve farkl\u0131 \u00f6l\u00e7eklerde yaparlar. Bu b\u00f6l\u00fcmde, her iki \u00e7\u00f6z\u00fcm\u00fcn temel farklar\u0131n\u0131 bir tablo halinde \u00f6zetleyerek, hangi senaryoda hangisinin daha uygun olabilece\u011fine dair net bir rehber sunaca\u011f\u0131z.<\/p>\n A\u015fa\u011f\u0131daki tablo, iki \u00e7\u00f6z\u00fcm aras\u0131ndaki anahtar farklar\u0131 g\u00f6stermektedir:<\/p>\n VPC Peering Ne Zaman Tercih Edilmeli?<\/strong><\/p>\n Transit Gateway Ne Zaman Tercih Edilmeli?<\/strong><\/p>\n Sonu\u00e7 olarak, VPC Peering basit ve maliyet etkin bir \u00e7\u00f6z\u00fcmd\u00fcr, ancak \u00f6l\u00e7eklenebilirlik ve y\u00f6netim a\u00e7\u0131s\u0131ndan s\u0131n\u0131rl\u0131d\u0131r. Transit Gateway ise daha y\u00fcksek bir maliyetle gelse de, karma\u015f\u0131k ve b\u00fcy\u00fcyen bulut a\u011flar\u0131 i\u00e7in vazge\u00e7ilmez bir esneklik, \u00f6l\u00e7eklenebilirlik ve y\u00f6netim kolayl\u0131\u011f\u0131 sunar. Se\u00e7im, mevcut ve gelecekteki a\u011f gereksinimlerinize g\u00f6re dikkatlice yap\u0131lmal\u0131d\u0131r.<\/p>\n Teorik bilgileri ger\u00e7ek d\u00fcnya senaryolar\u0131na uygulamak, do\u011fru karar\u0131 vermenin anahtar\u0131d\u0131r. \u0130\u015fte farkl\u0131 sekt\u00f6rlerden ve kullan\u0131m durumlar\u0131ndan al\u0131nm\u0131\u015f baz\u0131 \u00f6rnekler ve bu \u00f6rneklerde VPC Peering ile Transit Gateway aras\u0131ndaki se\u00e7im kriterleri:<\/p>\n Senaryo 1: K\u00fc\u00e7\u00fck Bir Startup’\u0131n \u0130lk Bulut Altyap\u0131s\u0131<\/strong><\/p>\n Senaryo 2: Orta \u00d6l\u00e7ekli Bir Yaz\u0131l\u0131m \u015eirketinin Geni\u015fleyen Mikroservis Mimarisi<\/strong><\/p>\n Senaryo 3: B\u00fcy\u00fck Bir Kurumun \u00c7oklu Hesap ve K\u00fcresel Altyap\u0131s\u0131<\/strong><\/p>\n Bu senaryolar, se\u00e7im yaparken sadece mevcut ihtiya\u00e7lar\u0131 de\u011fil, ayn\u0131 zamanda gelecekteki b\u00fcy\u00fcme ve karma\u015f\u0131kl\u0131\u011f\u0131 da g\u00f6z \u00f6n\u00fcnde bulundurman\u0131n \u00f6nemini vurgulamaktad\u0131r. Ba\u015flang\u0131\u00e7ta VPC Peering ile ba\u015flay\u0131p, a\u011f b\u00fcy\u00fcd\u00fck\u00e7e Transit Gateway’e ge\u00e7i\u015f yapmak da ge\u00e7erli bir strateji olabilir. Ancak, bu ge\u00e7i\u015fin de planlanmas\u0131 ve potansiyel kesintilerin minimize edilmesi gerekir.<\/p>\n AWS bulut altyap\u0131s\u0131nda \u00f6l\u00e7eklenebilir ve y\u00f6netilebilir a\u011flar olu\u015fturmak, ba\u015far\u0131l\u0131 bir operasyon i\u00e7in temel bir gerekliliktir. VPC Peering ve Transit Gateway, bu amaca hizmet eden iki anahtar \u00e7\u00f6z\u00fcmd\u00fcr, ancak her birinin kendi g\u00fc\u00e7l\u00fc y\u00f6nleri ve s\u0131n\u0131rlamalar\u0131 bulunmaktad\u0131r. VPC Peering, az say\u0131da VPC aras\u0131nda do\u011frudan, basit ve maliyet etkin ba\u011flant\u0131lar kurmak i\u00e7in idealdir. Kurulumu kolayd\u0131r ve d\u00fc\u015f\u00fck gecikme s\u00fcresi sunar. Ancak, a\u011f\u0131n\u0131z b\u00fcy\u00fcd\u00fck\u00e7e, transit y\u00f6nlendirme eksikli\u011fi ve N-kare ba\u011flant\u0131 karma\u015fas\u0131 nedeniyle y\u00f6netimi h\u0131zla zorla\u015f\u0131r. \u00d6te yandan, AWS Transit Gateway, bu karma\u015f\u0131kl\u0131\u011f\u0131 \u00e7\u00f6zmek i\u00e7in tasarlanm\u0131\u015f merkezi bir a\u011f hub’\u0131d\u0131r. \u00c7ok say\u0131da VPC’yi, farkl\u0131 AWS hesaplar\u0131n\u0131 ve \u015firket i\u00e7i a\u011flar\u0131 tek bir noktada birle\u015ftirerek “hub-and-spoke” mimarisi sunar. Bu, a\u011f y\u00f6netimini basitle\u015ftirir, \u00f6l\u00e7eklenebilirli\u011fi art\u0131r\u0131r ve geli\u015fmi\u015f a\u011f segmentasyonu ile g\u00fcvenlik politikalar\u0131n\u0131n uygulanmas\u0131na olanak tan\u0131r. Maliyeti VPC Peering’e g\u00f6re daha y\u00fcksek olsa da, sa\u011flad\u0131\u011f\u0131 esneklik ve y\u00f6netim kolayl\u0131\u011f\u0131, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k bulut ortamlar\u0131nda bu maliyeti fazlas\u0131yla hakl\u0131 \u00e7\u0131kar\u0131r. Do\u011fru se\u00e7imi yapmak i\u00e7in mevcut ve gelecekteki a\u011f b\u00fcy\u00fckl\u00fc\u011f\u00fcn\u00fcz\u00fc, y\u00f6netim kapasitenizi, g\u00fcvenlik gereksinimlerinizi ve b\u00fct\u00e7enizi dikkatlice de\u011ferlendirmeniz gerekmektedir.<\/p>\n Evet, belirli senaryolarda bu m\u00fcmk\u00fcnd\u00fcr. \u00d6rne\u011fin, iki kritik VPC aras\u0131nda \u00e7ok d\u00fc\u015f\u00fck gecikmeli ve \u00f6zel bir ba\u011flant\u0131 i\u00e7in VPC Peering kullan\u0131rken, di\u011fer t\u00fcm VPC’leri Transit Gateway’e ba\u011flayabilirsiniz. Ancak, a\u011f karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 art\u0131rabilece\u011fi i\u00e7in dikkatli planlama gerektirir.<\/p>\n<\/li>\n Transit Gateway, teknik olarak farkl\u0131 y\u00f6nlendirme tablolar\u0131 kullanarak \u00e7ak\u0131\u015fan CIDR’lara sahip VPC’leri ba\u011flayabilir, ancak bu kesinlikle \u00f6nerilmez. \u00c7ak\u0131\u015fan CIDR’lar, a\u011f sorunlar\u0131na, ileti\u015fim hatalar\u0131na ve y\u00f6netim karma\u015f\u0131kl\u0131\u011f\u0131na yol a\u00e7ar. En iyi uygulama, her VPC’nin benzersiz bir CIDR blo\u011funa sahip olmas\u0131d\u0131r.<\/p>\n<\/li>\n Transit Gateway’in iki ana maliyeti vard\u0131r: saatlik \u00fccret ve veri i\u015fleme (data processing) \u00fccreti. Saatlik \u00fccret, Transit Gateway’in aktif oldu\u011fu her saat i\u00e7in \u00f6denir. Veri i\u015fleme \u00fccreti ise Transit Gateway \u00fczerinden ge\u00e7en trafik miktar\u0131na g\u00f6re belirlenir. Bu maliyetler, VPC Peering’e g\u00f6re daha y\u00fcksek olabilir, ancak sa\u011flad\u0131\u011f\u0131 y\u00f6netim kolayl\u0131\u011f\u0131 ve \u00f6l\u00e7eklenebilirlik genellikle bu maliyetin \u00f6n\u00fcne ge\u00e7er.<\/p>\n<\/li>\n Evet, AWS, b\u00f6lgeler aras\u0131 VPC Peering (Inter-Region VPC Peering) \u00f6zelli\u011fini destekler. Bu, farkl\u0131 AWS B\u00f6lgelerindeki iki VPC’yi birbirine ba\u011flaman\u0131za olanak tan\u0131r. Ancak, bu da hala noktadan noktaya bir ba\u011flant\u0131d\u0131r ve transit y\u00f6nlendirme s\u0131n\u0131rlamas\u0131 devam eder.<\/p>\n<\/li>\n Her iki \u00e7\u00f6z\u00fcm de trafik internet \u00fczerinden ge\u00e7medi\u011fi i\u00e7in g\u00fcvenlidir. G\u00fcvenlik, daha \u00e7ok uygulanan g\u00fcvenlik gruplar\u0131 (Security Groups), a\u011f eri\u015fim kontrol listeleri (Network ACLs) ve Transit Gateway’in y\u00f6nlendirme tablolar\u0131ndaki do\u011fru yap\u0131land\u0131rmalarla ilgilidir. Transit Gateway, merkezi bir kontrol noktas\u0131 sundu\u011fu i\u00e7in g\u00fcvenlik politikalar\u0131n\u0131 daha tutarl\u0131 ve kolay bir \u015fekilde uygulaman\u0131za olanak tan\u0131yarak daha kapsaml\u0131 bir g\u00fcvenlik duru\u015fu sa\u011flayabilir.<\/p>\n<\/li>\n<\/ol>\n #AWS #VPC #TransitGateway #BulutA\u011f\u0131 #A\u011fMimarisi #DevOps<\/p>\n","protected":false},"excerpt":{"rendered":"Bulut altyap\u0131lar\u0131nda, \u00f6zellikle Amazon Web Services (AWS) \u00fczerinde \u00e7al\u0131\u015f\u0131rken, farkl\u0131 sanal \u00f6zel bulut (VPC) ortamlar\u0131 aras\u0131nda g\u00fcvenli ve verimli ileti\u015fim kurmak kritik bir \u00f6neme sahiptir.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1406],"tags":[],"class_list":{"0":"post-45081","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-aws","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nvpc-prod<\/code> (CIDR: 10.0.0.0\/16) ve vpc-dev<\/code> (CIDR: 10.1.0.0\/16). Bu iki VPC aras\u0131nda bir peering ba\u011flant\u0131s\u0131 olu\u015fturmak i\u00e7in a\u015fa\u011f\u0131daki ad\u0131mlar izlenir:<\/p>\n\n
vpc-prod<\/code> hesab\u0131ndan vpc-dev<\/code> hesab\u0131na bir peering ba\u011flant\u0131s\u0131 iste\u011fi g\u00f6nderilir.<\/li>\nvpc-dev<\/code> hesab\u0131, gelen peering iste\u011fini kabul eder.<\/li>\n\n
vpc-prod<\/code>‘daki y\u00f6nlendirme tablolar\u0131na, hedef olarak 10.1.0.0\/16<\/code> (vpc-dev<\/code>‘in CIDR’\u0131) ve hedef a\u011f ge\u00e7idi olarak olu\u015fturulan peering ba\u011flant\u0131s\u0131 (\u00f6rne\u011fin, pcx-xxxxxxxxxxxxxxxxx<\/code>) eklenir.<\/li>\nvpc-dev<\/code>‘deki y\u00f6nlendirme tablolar\u0131na, hedef olarak 10.0.0.0\/16<\/code> (vpc-prod<\/code>‘un CIDR’\u0131) ve hedef a\u011f ge\u00e7idi olarak ayn\u0131 peering ba\u011flant\u0131s\u0131 eklenir.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\nvpc-prod<\/code>‘daki bir EC2 \u00f6rne\u011fi, vpc-dev<\/code>‘deki bir EC2 \u00f6rne\u011fi ile ping<\/code> atabilir veya di\u011fer a\u011f tabanl\u0131 ileti\u015fimleri kurabilir. Bu basitlik, az say\u0131da ba\u011flant\u0131 i\u00e7in cazip olsa da, daha karma\u015f\u0131k senaryolarda s\u0131n\u0131rlamalar\u0131n\u0131 beraberinde getirir.<\/p>\nVPC Peering’in Avantajlar\u0131 ve S\u0131n\u0131rlamalar\u0131 Nelerdir?<\/h3>\n
N * (N-1) \/ 2<\/code> adet peering ba\u011flant\u0131s\u0131 kurman\u0131z gerekir. \u00d6rne\u011fin, 10 VPC’niz varsa 45 peering ba\u011flant\u0131s\u0131, 20 VPC’niz varsa 190 ba\u011flant\u0131 kurman\u0131z ve y\u00f6netmeniz gerekir. Bu ba\u011flant\u0131lar\u0131n her biri i\u00e7in ayr\u0131 ayr\u0131 y\u00f6nlendirme tablolar\u0131n\u0131 g\u00fcncellemek, hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r ve y\u00f6netim y\u00fck\u00fcn\u00fc katlanarak b\u00fcy\u00fct\u00fcr.<\/p>\nAWS Transit Gateway Nedir ve Neden Ortaya \u00c7\u0131kt\u0131?<\/h3>\n
\n
aws ec2 create-transit-gateway --description \"MyCentralTGW\"<\/code><\/pre>\n<\/p><\/div>\n<\/li>\naws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-xxxxxxxxxxxxxxxxx --vpc-id vpc-yyyyyyyyyyyyyyyyy --subnet-ids subnet-zzzzzzzzzzzzzzzzz<\/code><\/pre>\n<\/p><\/div>\n<\/li>\n10.0.0.0\/8<\/code> (t\u00fcm dahili a\u011flar) i\u00e7in hedef olarak Transit Gateway g\u00f6sterilebilir.<\/li>\nTransit Gateway’in Sundu\u011fu \u00c7\u00f6z\u00fcmler ve Mimari Yakla\u015f\u0131mlar<\/h3>\n
VPC Peering ve Transit Gateway Kar\u015f\u0131la\u015ft\u0131rmas\u0131: Hangi Durumda Hangisi?<\/h3>\n
\n\n
\n \n\u00d6zellik<\/th>\n VPC Peering<\/th>\n Transit Gateway<\/th>\n<\/tr>\n<\/thead>\n \n Ba\u011flant\u0131 Modeli<\/strong><\/td>\n Noktadan noktaya (Point-to-point)<\/td>\n Merkezi hub-and-spoke<\/td>\n<\/tr>\n \n Transit Y\u00f6nlendirme<\/strong><\/td>\n Desteklemez<\/td>\n Destekler<\/td>\n<\/tr>\n \n \u00d6l\u00e7eklenebilirlik<\/strong><\/td>\n D\u00fc\u015f\u00fck (az say\u0131da VPC i\u00e7in uygun)<\/td>\n Y\u00fcksek (y\u00fczlerce VPC ve a\u011f i\u00e7in uygun)<\/td>\n<\/tr>\n \n Y\u00f6netim Karma\u015f\u0131kl\u0131\u011f\u0131<\/strong><\/td>\n VPC say\u0131s\u0131 artt\u0131k\u00e7a h\u0131zla artar<\/td>\n Merkezi y\u00f6netim, karma\u015f\u0131kl\u0131k az<\/td>\n<\/tr>\n \n CIDR \u00c7ak\u0131\u015fmas\u0131<\/strong><\/td>\n \u00c7ak\u0131\u015fan CIDR’lara izin vermez<\/td>\n \u00c7ak\u0131\u015fan CIDR’lar\u0131 farkl\u0131 y\u00f6nlendirme tablolar\u0131yla y\u00f6netebilir (ancak \u00f6nerilmez)<\/td>\n<\/tr>\n \n Farkl\u0131 AWS Hesaplar\u0131<\/strong><\/td>\n Evet, destekler<\/td>\n Evet, daha kolay ve merkezi y\u00f6netimle destekler<\/td>\n<\/tr>\n \n \u015eirket \u0130\u00e7i Ba\u011flant\u0131<\/strong><\/td>\n Her VPC i\u00e7in ayr\u0131 VPN\/DX ba\u011flant\u0131s\u0131 gerekebilir<\/td>\n Merkezi VPN\/DX ba\u011flant\u0131s\u0131 \u00fczerinden t\u00fcm VPC’lere eri\u015fim<\/td>\n<\/tr>\n \n Maliyet<\/strong><\/td>\n Ba\u011flant\u0131 i\u00e7in \u00fccret yok, veri transferi \u00fccretli<\/td>\n Saatlik \u00fccret ve veri i\u015fleme \u00fccreti, veri transferi \u00fccretli<\/td>\n<\/tr>\n \n A\u011f Segmentasyonu<\/strong><\/td>\n G\u00fcvenlik gruplar\u0131 ve ACL’lerle s\u0131n\u0131rl\u0131<\/td>\n Y\u00f6nlendirme tablolar\u0131 ile geli\u015fmi\u015f segmentasyon<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
\n
Ger\u00e7ek D\u00fcnya Senaryolar\u0131nda Se\u00e7im Kriterleri<\/h3>\n
\n
\n
\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
S\u0131k\u00e7a Sorulan Sorular<\/h4>\n
\n