Bulut bili\u015fim d\u00fcnyas\u0131nda, b\u00fcy\u00fck \u015firketlerin altyap\u0131lar\u0131n\u0131 farkl\u0131 bulut sa\u011flay\u0131c\u0131lar\u0131na ta\u015f\u0131mak giderek yayg\u0131nla\u015f\u0131yor. Ancak bu ge\u00e7i\u015fler, \u00f6zellikle a\u011f altyap\u0131s\u0131 s\u00f6z konusu oldu\u011funda, ciddi planlama gerektirir. Azure ve AWS gibi iki farkl\u0131 bulut platformu aras\u0131nda bir ge\u00e7i\u015f yaparken kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, bu platformlar\u0131n kendine \u00f6zg\u00fc IP adresleme \u015femalar\u0131d\u0131r. Bu makalede, Azure ve AWS’nin CIDR (Classless Inter-Domain Routing) planlamas\u0131 yakla\u015f\u0131mlar\u0131n\u0131 inceleyecek, bu iki farkl\u0131 adres alan\u0131n\u0131 birbiriyle uyumlu hale getirmenin yollar\u0131n\u0131 arayaca\u011f\u0131z. \u00d6zellikle, bu uyumla\u015ft\u0131rman\u0131n neden karma\u015f\u0131k oldu\u011funu ve ba\u015far\u0131l\u0131 bir ge\u00e7i\u015f i\u00e7in nelere dikkat edilmesi gerekti\u011fini derinlemesine ele alaca\u011f\u0131z. Bu s\u00fcre\u00e7, do\u011fru planlama ile sorunsuz bir \u015fekilde y\u00f6netilebilir ve bulut stratejinizin ba\u015far\u0131s\u0131n\u0131 do\u011frudan etkiler.<\/p>\n
Bulut sa\u011flay\u0131c\u0131lar\u0131, a\u011f altyap\u0131lar\u0131n\u0131 y\u00f6netmek i\u00e7in kendi standartlar\u0131n\u0131 belirlerler. Azure ve AWS de bu konuda farkl\u0131 yakla\u015f\u0131mlara sahiptir. Bu farkl\u0131l\u0131klar, \u00f6zellikle \u015firketlerin kendi veri merkezlerinden buluta ge\u00e7i\u015f yaparken veya iki bulut aras\u0131nda bir ge\u00e7i\u015f (multi-cloud) stratejisi izlerken karma\u015f\u0131kl\u0131k yarat\u0131r. Temel sorun, her iki platformun da kendi i\u00e7inde tutarl\u0131 bir IP adresleme yap\u0131s\u0131 sunmas\u0131na ra\u011fmen, bu yap\u0131lar\u0131n birbirleriyle do\u011fal bir uyum i\u00e7inde olmamas\u0131d\u0131r. \u00d6rne\u011fin, Azure’da bir sanal a\u011f (Virtual Network – VNet) olu\u015ftururken belirledi\u011finiz CIDR bloklar\u0131, AWS’de olu\u015fturaca\u011f\u0131n\u0131z bir sanal \u00f6zel bulut (Virtual Private Cloud – VPC) ile do\u011frudan \u00e7ak\u0131\u015fabilir veya VPN (Virtual Private Network) ba\u011flant\u0131lar\u0131 kurarken y\u00f6nlendirme (routing) sorunlar\u0131na yol a\u00e7abilir. Bu durum, iki platformun da IP adreslerini atama ve y\u00f6netme bi\u00e7imlerinden kaynaklan\u0131r. Bir \u00f6rnek vermek gerekirse, Azure’da bir VNet’e 10.0.0.0\/16 gibi bir adres aral\u0131\u011f\u0131 atayabilirsiniz. Ayn\u0131 \u015fekilde AWS’de de bir VPC’ye 10.0.0.0\/16 gibi bir adres aral\u0131\u011f\u0131 atayabilirsiniz. E\u011fer bu iki a\u011f aras\u0131nda do\u011frudan bir ba\u011flant\u0131 kurmaya \u00e7al\u0131\u015f\u0131rsan\u0131z, her iki taraf da ayn\u0131 adres aral\u0131\u011f\u0131na sahip oldu\u011fu i\u00e7in \u00e7ak\u0131\u015fma ya\u015fanacakt\u0131r. Bu da paketlerin do\u011fru hedefe ula\u015fmas\u0131n\u0131 engelleyecektir. Bu t\u00fcr \u00e7ak\u0131\u015fmalar, sadece do\u011frudan ba\u011flant\u0131larda de\u011fil, ayn\u0131 zamanda karma\u015f\u0131k a\u011f topolojilerinde, g\u00fcvenlik duvar\u0131 kurallar\u0131nda ve DNS \u00e7\u00f6z\u00fcmlemelerinde de beklenmedik sorunlara yol a\u00e7abilir. Bu nedenle, ge\u00e7i\u015f \u00f6ncesinde detayl\u0131 bir CIDR planlamas\u0131 yapmak, gelecekteki olas\u0131 sorunlar\u0131 \u00f6nlemenin en etkili yoludur.<\/p>\n
CIDR (Classless Inter-Domain Routing), internet \u00fczerindeki IP adreslerini daha verimli bir \u015fekilde tahsis etmek ve y\u00f6nlendirmek i\u00e7in kullan\u0131lan bir y\u00f6ntemdir. Geleneksel IP adresleme s\u0131n\u0131flar\u0131ndan (A, B, C) farkl\u0131 olarak CIDR, adres bloklar\u0131n\u0131 daha esnek bir \u015fekilde alt a\u011flara b\u00f6lebilir. Bir CIDR blo\u011fu, bir IP adresi ve bir alt a\u011f maskesinden olu\u015fur. \u00d6rne\u011fin, Azure’da sanal a\u011flar (VNet) ve AWS’de sanal \u00f6zel bulutlar (VPC), bulut ortam\u0131n\u0131zda kendi \u00f6zel a\u011f\u0131n\u0131z\u0131 olu\u015fturman\u0131za olanak tan\u0131r. Bu a\u011flar, sanal makineleriniz (VMs), veritabanlar\u0131n\u0131z ve di\u011fer hizmetleriniz i\u00e7in bir yal\u0131t\u0131m katman\u0131 sa\u011flar. VNet ve VPC’ler, kendi IP adres aral\u0131klar\u0131n\u0131z\u0131 tan\u0131mlaman\u0131za ve bu aral\u0131klar\u0131 kullanarak kaynaklar\u0131n\u0131za IP adresleri ataman\u0131za imkan verir. Bu, kendi veri merkezinizdeki a\u011f yap\u0131s\u0131n\u0131 buluta ta\u015f\u0131ma esnekli\u011fi sunar. Ancak, bu esneklik, farkl\u0131 bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n IP adresleme mekanizmalar\u0131n\u0131 anlamadan kullan\u0131ld\u0131\u011f\u0131nda ciddi sorunlara yol a\u00e7abilir. \u00d6rne\u011fin, Azure VNet’leri ve AWS VPC’leri, birbirleriyle do\u011frudan ileti\u015fim kurabilmeleri i\u00e7in \u00f6zel IP adres aral\u0131klar\u0131 kullan\u0131r. Bu \u00f6zel IP adres aral\u0131klar\u0131, genel internetten eri\u015filemeyen ancak kendi a\u011f\u0131n\u0131z i\u00e7inde kullan\u0131lan adreslerdir. Bu, g\u00fcvenlik a\u00e7\u0131s\u0131ndan \u00f6nemlidir ancak farkl\u0131 bulutlar aras\u0131nda ileti\u015fim kurarken dikkatli planlama gerektirir.<\/p>\n Azure ve AWS, IP adreslerini y\u00f6netme ve atama konusunda baz\u0131 temel farkl\u0131l\u0131klara sahiptir. Azure’da, bir VNet olu\u015ftururken belirli bir CIDR blo\u011fu tan\u0131mlars\u0131n\u0131z ve bu bloktan alt a\u011flar olu\u015fturabilirsiniz. Azure, bu alt a\u011flara otomatik olarak IP adresleri atar veya siz manuel olarak belirleyebilirsiniz. AWS’de ise, bir VPC olu\u015ftururken bir CIDR blo\u011fu tan\u0131mlars\u0131n\u0131z ve bu VPC i\u00e7inde alt a\u011flar (subnets) olu\u015fturursunuz. AWS’nin alt a\u011flar\u0131, belirli bir CIDR blo\u011fu i\u00e7inde yer al\u0131r ve bu alt a\u011flara atanan EC2 \u00f6rnekleri (instances) veya di\u011fer kaynaklar, AWS taraf\u0131ndan otomatik olarak IP adresleri al\u0131r. En belirgin farklardan biri, Azure’da varsay\u0131lan olarak atanan IP adres aral\u0131klar\u0131n\u0131n AWS’den farkl\u0131 olmas\u0131d\u0131r. \u00d6rne\u011fin, Azure genellikle Bu farkl\u0131l\u0131klar, \u00f6zellikle \u015firketler mevcut IP adres alanlar\u0131n\u0131 korumak istediklerinde veya mevcut a\u011f yap\u0131lar\u0131n\u0131 buluta ta\u015f\u0131maya \u00e7al\u0131\u015ft\u0131klar\u0131nda \u00f6nemli bir zorluk te\u015fkil eder. \u00d6rne\u011fin, bir \u015firket veri merkezinde Azure ve AWS aras\u0131ndaki CIDR \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nlemek, \u00f6zellikle hibrit (hem \u015firket i\u00e7i veri merkezi hem de bulut) veya \u00e7oklu bulut (multi-cloud) ortamlar\u0131nda kritik \u00f6neme sahiptir. Ba\u015far\u0131l\u0131 bir planlama, IP adres \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nleyerek a\u011f ileti\u015fimini kesintisiz hale getirir ve karma\u015f\u0131k y\u00f6nlendirme sorunlar\u0131n\u0131 ortadan kald\u0131r\u0131r.<\/p>\n Her \u015feyden \u00f6nce, mevcut IP adres alanlar\u0131n\u0131z\u0131n tam bir envanterini \u00e7\u0131karman\u0131z gerekir. Bu, \u015firket i\u00e7i veri merkezinizde kulland\u0131\u011f\u0131n\u0131z t\u00fcm CIDR bloklar\u0131n\u0131, mevcut bulut ortam\u0131n\u0131zda (e\u011fer varsa) kulland\u0131\u011f\u0131n\u0131z CIDR bloklar\u0131n\u0131 ve ge\u00e7i\u015f yapmay\u0131 planlad\u0131\u011f\u0131n\u0131z bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n (Azure veya AWS) varsay\u0131lan IP adres aral\u0131klar\u0131n\u0131 i\u00e7ermelidir. Bu envanteri \u00e7\u0131kard\u0131ktan sonra, olas\u0131 \u00e7ak\u0131\u015fmalar\u0131 belirlemek i\u00e7in detayl\u0131 bir analiz yapmal\u0131s\u0131n\u0131z.<\/p>\n * \u00d6zel IP Adres Alanlar\u0131n\u0131 Yeniden Yap\u0131land\u0131rma:<\/strong> E\u011fer mevcut IP adres alanlar\u0131n\u0131z \u00e7ak\u0131\u015f\u0131yorsa, en g\u00fcvenli yakla\u015f\u0131m, bu alanlar\u0131 yeniden yap\u0131land\u0131rmakt\u0131r. Azure ve AWS, RFC 1918’e uygun \u00f6zel IP adres alanlar\u0131 (\u00f6rne\u011fin, Bir finans \u015firketi, veri analizi ve i\u015flem platformlar\u0131n\u0131 AWS ve Azure aras\u0131nda da\u011f\u0131tmak istiyordu. \u015eirketin veri merkezinde \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n \u015eirket, \u00f6ncelikle mevcut IP adres alanlar\u0131n\u0131n kapsaml\u0131 bir envanterini \u00e7\u0131kard\u0131. Ard\u0131ndan, a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 izleyerek bir plan olu\u015fturdular:<\/p>\n * Azure VNet IP Alan\u0131 Yeniden Yap\u0131land\u0131rmas\u0131:<\/strong> Azure VNet’lerinde kullan\u0131lan Bu planlama sayesinde \u015firket, veri merkezi, Azure ve AWS aras\u0131ndaki a\u011f ileti\u015fimini kesintisiz bir \u015fekilde s\u00fcrd\u00fcrebildi ve karma\u015f\u0131k IP \u00e7ak\u0131\u015fmalar\u0131ndan ka\u00e7\u0131nd\u0131.<\/p>\n Alt a\u011flar\u0131 (subnets) ak\u0131ll\u0131ca planlamak, hem Azure’da VNet’ler hem de AWS’de VPC’ler i\u00e7in a\u011f\u0131n\u0131z\u0131n verimlili\u011fini, g\u00fcvenli\u011fini ve y\u00f6netilebilirli\u011fini art\u0131rman\u0131n temelidir. Alt a\u011flar, daha b\u00fcy\u00fck bir IP adres blo\u011funu daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara b\u00f6ler. Bu, belirli kaynak gruplar\u0131n\u0131 (\u00f6rne\u011fin, web sunucular\u0131, veritabanlar\u0131) mant\u0131ksal olarak ay\u0131rman\u0131za, g\u00fcvenlik politikalar\u0131n\u0131 daha hassas bir \u015fekilde uygulaman\u0131za ve a\u011f trafi\u011fini daha iyi kontrol etmenize olanak tan\u0131r.<\/p>\n Alt a\u011flar\u0131 planlarken en \u00f6nemli ad\u0131mlardan biri, her alt a\u011fda ihtiya\u00e7 duyulacak IP adresi say\u0131s\u0131n\u0131 do\u011fru bir \u015fekilde tahmin etmektir. Bu, gelecekteki b\u00fcy\u00fcmeyi de hesaba katarak yap\u0131lmal\u0131d\u0131r. A\u015f\u0131r\u0131 b\u00fcy\u00fck alt a\u011flar, IP adresi israf\u0131na yol a\u00e7arken, a\u015f\u0131r\u0131 k\u00fc\u00e7\u00fck alt a\u011flar ise kaynak ekledik\u00e7e s\u0131k s\u0131k alt a\u011flar\u0131 yeniden boyutland\u0131rma ihtiyac\u0131n\u0131 do\u011furabilir.<\/p>\n * \u00d6rnek:<\/strong> Bir web sunucusu alt a\u011f\u0131 i\u00e7in 10 adet sunucu planl\u0131yorsan\u0131z, ancak gelecekte 20-30 sunucuya \u00e7\u0131kma olas\u0131l\u0131\u011f\u0131n\u0131z varsa, Alt a\u011flar, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131 (firewall rules) ve a\u011f eri\u015fim kontrol listelerini (network access control lists – ACLs) uygulamak i\u00e7in m\u00fckemmel bir temel olu\u015fturur. Farkl\u0131 g\u00fcvenlik gereksinimlerine sahip kaynaklar\u0131 farkl\u0131 alt a\u011flara yerle\u015ftirerek, a\u011f trafi\u011fini daha s\u0131k\u0131 bir \u015fekilde kontrol edebilirsiniz.<\/p>\n * \u00d6rnek:<\/strong> Bir uygulamada, yaln\u0131zca \u00f6n u\u00e7 (frontend) sunucular\u0131n\u0131n eri\u015febilece\u011fi bir veritaban\u0131 alt a\u011f\u0131 olu\u015fturabilirsiniz. \u00d6n u\u00e7 alt a\u011f\u0131ndan veritaban\u0131 alt a\u011f\u0131na yaln\u0131zca belirli portlardan (\u00f6rne\u011fin, 3306 – MySQL, 1433 – SQL Server) izin veren g\u00fcvenlik kurallar\u0131 tan\u0131mlayabilirsiniz. Bu, veritaban\u0131na yetkisiz eri\u015fimi engeller.<\/p>\n * Azure VNet Alt A\u011flar\u0131:<\/strong> Azure’da, bir VNet olu\u015fturduktan sonra bu VNet i\u00e7ine alt a\u011flar eklersiniz. Her alt a\u011f\u0131n kendine \u00f6zg\u00fc bir CIDR blo\u011fu vard\u0131r ve bu blok, VNet’in ana CIDR blo\u011fundan al\u0131n\u0131r. Azure, alt a\u011flara otomatik olarak IP adresleri atar, ancak siz bu atamalar\u0131 y\u00f6netebilirsiniz. Bir e-ticaret \u015firketi, hem Azure hem de AWS \u00fczerinde da\u011f\u0131t\u0131lm\u0131\u015f bir altyap\u0131ya sahipti. M\u00fc\u015fteri verileri ve i\u015flem bilgileri hassas oldu\u011fu i\u00e7in, a\u011f g\u00fcvenli\u011fini en \u00fcst d\u00fczeyde tutmak istiyorlard\u0131.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n \u015eirket, a\u015fa\u011f\u0131daki alt a\u011f planlama stratejisini benimsedi:<\/p>\n * Azure VNet:<\/strong> Bu planlama sayesinde:<\/p>\n * Her katman (\u00f6n u\u00e7, arka u\u00e7, veritaban\u0131) kendi alt a\u011f\u0131nda izole edildi. Bu detayl\u0131 alt a\u011f planlamas\u0131, \u015firketin hem g\u00fcvenlik gereksinimlerini kar\u015f\u0131lamas\u0131n\u0131 hem de a\u011f altyap\u0131s\u0131n\u0131 verimli bir \u015fekilde y\u00f6netmesini sa\u011flad\u0131.<\/p>\n Azure ve AWS aras\u0131ndaki a\u011f ba\u011flant\u0131s\u0131n\u0131 sa\u011flamak, ge\u00e7i\u015fin en kritik ad\u0131mlar\u0131ndan biridir. Bu ba\u011flant\u0131 genellikle VPN veya \u00f6zel ba\u011flant\u0131 hizmetleri (AWS Direct Connect, Azure ExpressRoute) arac\u0131l\u0131\u011f\u0131yla kurulur. Bu ba\u011flant\u0131lar\u0131n do\u011fru bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131, IP adres \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nlemek ve veri ak\u0131\u015f\u0131n\u0131 sorunsuz hale getirmek i\u00e7in hayati \u00f6nem ta\u015f\u0131r.<\/p>\n VPN ba\u011flant\u0131lar\u0131, internet \u00fczerinden \u015fifrelenmi\u015f bir t\u00fcnel olu\u015fturarak iki a\u011f\u0131 birbirine ba\u011flar. Azure’da VPN Gateway ve AWS’de Virtual Private Gateway hizmetleri bu ama\u00e7la kullan\u0131l\u0131r.<\/p>\n * IP Adres \u00c7ak\u0131\u015fmas\u0131 Sorunu:<\/strong> E\u011fer Azure VNet’iniz ve AWS VPC’niz ayn\u0131 IP adres aral\u0131\u011f\u0131n\u0131 kullan\u0131yorsa, VPN ba\u011flant\u0131s\u0131 kuramazs\u0131n\u0131z. Bu nedenle, daha \u00f6nce bahsetti\u011fimiz gibi, her iki platformda da benzersiz ve \u00e7ak\u0131\u015fmayan CIDR bloklar\u0131 kullanmak zorunludur. AWS Direct Connect ve Azure ExpressRoute, do\u011frudan bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n a\u011f\u0131na \u00f6zel, y\u00fcksek bant geni\u015fli\u011fine sahip ve d\u00fc\u015f\u00fck gecikmeli ba\u011flant\u0131lar sunar. Bu hizmetler, internet \u00fczerinden de\u011fil, telekom\u00fcnikasyon sa\u011flay\u0131c\u0131lar\u0131 arac\u0131l\u0131\u011f\u0131yla kurulur.<\/p>\n * Avantajlar\u0131:<\/strong> Bir finansal veri i\u015fleme \u015firketi, y\u00fcksek frekansl\u0131 i\u015flem verilerini analiz etmek i\u00e7in hem Azure hem de AWS \u00fczerinde da\u011f\u0131t\u0131lm\u0131\u015f bir altyap\u0131 kullan\u0131yordu. Veri aktar\u0131m\u0131n\u0131n h\u0131z\u0131 ve g\u00fcvenli\u011fi, i\u015f s\u00fcreklili\u011fi i\u00e7in kritik \u00f6neme sahipti.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n \u015eirket, a\u015fa\u011f\u0131daki ba\u011flant\u0131 stratejisini benimsedi:<\/p>\n * Veri Merkezi ve Azure Ba\u011flant\u0131s\u0131:<\/strong> \u015eirket, veri merkezini Azure’a ba\u011flamak i\u00e7in Azure ExpressRoute kulland\u0131. Bu, y\u00fcksek bant geni\u015fli\u011fi ve d\u00fc\u015f\u00fck gecikme sa\u011flayarak, b\u00fcy\u00fck veri setlerinin h\u0131zl\u0131 bir \u015fekilde Azure’a aktar\u0131lmas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131ld\u0131. ExpressRoute’un yap\u0131land\u0131rmas\u0131 s\u0131ras\u0131nda, veri merkezindeki IP adres alanlar\u0131 ile Azure VNet’lerindeki IP adres alanlar\u0131n\u0131n \u00e7ak\u0131\u015fmad\u0131\u011f\u0131ndan emin olundu. Bu strateji sayesinde \u015firket, veri aktar\u0131m h\u0131z\u0131n\u0131 ve g\u00fcvenilirli\u011fini en \u00fcst d\u00fczeye \u00e7\u0131kard\u0131, IP adres \u00e7ak\u0131\u015fmalar\u0131ndan ka\u00e7\u0131nd\u0131 ve kritik finansal verilerinin kesintisiz bir \u015fekilde i\u015flenmesini sa\u011flad\u0131.<\/p>\n Azure ve AWS aras\u0131nda CIDR planlamas\u0131 yaparken, a\u011f g\u00fcvenli\u011fi her zaman \u00f6ncelikli olmal\u0131d\u0131r. IP adres alanlar\u0131n\u0131n do\u011fru bir \u015fekilde planlanmas\u0131, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131n (firewall rules) ve a\u011f eri\u015fim kontrol listelerinin (network access control lists – ACLs) etkin bir \u015fekilde uygulanmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\n G\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131 yap\u0131land\u0131r\u0131rken, en az ayr\u0131cal\u0131k prensibini benimsemek esast\u0131r. Bu, yaln\u0131zca belirli bir kayna\u011fa eri\u015fmesi gereken trafi\u011fe izin vermek anlam\u0131na gelir. Gereksiz t\u00fcm eri\u015fimler reddedilmelidir.<\/p>\n * \u00d6rnek:<\/strong> Bir web sunucusuna yaln\u0131zca belirli bir IP adresinden veya IP aral\u0131\u011f\u0131ndan (\u00f6rne\u011fin, \u015firket VPN’inden gelen trafik) ve yaln\u0131zca HTTP\/HTTPS portlar\u0131ndan (80 ve 443) eri\u015fim izni verilebilir. Di\u011fer t\u00fcm portlar ve IP adreslerinden gelen trafi\u011fe izin verilmemelidir.<\/p>\n * Azure G\u00fcvenlik Duvar\u0131 (Azure Firewall):<\/strong> Azure Firewall, merkezi bir a\u011f g\u00fcvenlik hizmetidir. VNet’inizdeki t\u00fcm trafi\u011fi izleyebilir, filtreleyebilir ve y\u00f6netebilir. CIDR planlaman\u0131z, Azure Firewall kurallar\u0131n\u0131 olu\u015ftururken temel te\u015fkil eder. Belirli alt a\u011flardan veya belirli kaynaklardan gelen trafi\u011fe izin vermek veya reddetmek i\u00e7in Azure Firewall’u kullanabilirsiniz. Do\u011fru CIDR planlamas\u0131, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131 basitle\u015ftirir. E\u011fer IP adres aral\u0131klar\u0131n\u0131z iyi organize edilmi\u015f ve \u00e7ak\u0131\u015fmalardan ar\u0131nd\u0131r\u0131lm\u0131\u015fsa, g\u00fcvenlik kurallar\u0131n\u0131 yazmak ve y\u00f6netmek \u00e7ok daha kolay olacakt\u0131r.<\/p>\n * \u00d6rnek:<\/strong> E\u011fer t\u00fcm web sunucular\u0131n\u0131z Bir sa\u011fl\u0131k hizmetleri sa\u011flay\u0131c\u0131s\u0131, hasta verilerini hem Azure hem de AWS \u00fczerinde bar\u0131nd\u0131r\u0131yordu. Bu verilerin gizlili\u011fi ve g\u00fcvenli\u011fi en \u00fcst d\u00fczeyde olmal\u0131yd\u0131.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n \u015eirket, a\u015fa\u011f\u0131daki g\u00fcvenlik \u00f6nlemlerini CIDR planlamas\u0131yla entegre etti:<\/p>\n * Azure VNet:<\/strong> G\u00fcvenlik Yap\u0131land\u0131rmas\u0131:<\/p>\n * Azure Firewall:<\/strong> Hasta Kay\u0131t Sunucular\u0131 alt a\u011f\u0131na yaln\u0131zca \u015firket VPN’inden ve belirli y\u00f6netim IP’lerinden gelen trafi\u011fe izin verildi. Analiz Sunucular\u0131 alt a\u011f\u0131na ise yaln\u0131zca Hasta Kay\u0131t Sunucular\u0131 alt a\u011f\u0131ndan ve y\u00f6netim IP’lerinden gelen trafi\u011fe izin verildi. Bu entegre yakla\u015f\u0131m sayesinde, hasta verileri hem Azure hem de AWS \u00fczerinde g\u00fcvenli bir \u015fekilde bar\u0131nd\u0131r\u0131ld\u0131 ve yaln\u0131zca yetkili personel ve sistemler taraf\u0131ndan eri\u015filebilir hale getirildi.<\/p>\n Temel CIDR planlamas\u0131n\u0131 tamamlad\u0131ktan sonra, daha karma\u015f\u0131k senaryolar ve optimizasyonlar i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 mevcuttur. Bu ipu\u00e7lar\u0131, ge\u00e7i\u015f s\u00fcrecini daha da sorunsuz hale getirebilir ve uzun vadede maliyet ve performans avantajlar\u0131 sa\u011flayabilir.<\/p>\n B\u00fcy\u00fck ve karma\u015f\u0131k a\u011f altyap\u0131lar\u0131nda, IP adreslerini manuel olarak y\u00f6netmek zor ve hataya a\u00e7\u0131kt\u0131r. IPAM (IP Address Management) ara\u00e7lar\u0131, IP adres atamalar\u0131n\u0131, alt a\u011flar\u0131 ve DNS kay\u0131tlar\u0131n\u0131 merkezi olarak y\u00f6netmenize yard\u0131mc\u0131 olur. Azure’da Azure IPAM veya \u00fc\u00e7\u00fcnc\u00fc taraf IPAM \u00e7\u00f6z\u00fcmleri, AWS’de ise AWS Systems Manager Parameter Store veya \u00fc\u00e7\u00fcnc\u00fc taraf IPAM \u00e7\u00f6z\u00fcmleri kullan\u0131labilir. Bu ara\u00e7lar, \u00e7ak\u0131\u015fmalar\u0131 \u00f6nlemeye, IP adresi kullan\u0131m\u0131n\u0131 izlemeye ve envanter \u00e7\u0131karmaya yard\u0131mc\u0131 olur.<\/p>\n Terraform, CloudFormation (AWS) veya ARM \u015fablonlar\u0131 (Azure) gibi IaC ara\u00e7lar\u0131 kullanarak, a\u011f altyap\u0131n\u0131z\u0131 kod olarak tan\u0131mlayabilirsiniz. Bu, CIDR bloklar\u0131, alt a\u011flar, g\u00fcvenlik gruplar\u0131 ve VPN ba\u011flant\u0131lar\u0131 gibi t\u00fcm a\u011f bile\u015fenlerinin otomatik olarak olu\u015fturulmas\u0131n\u0131 ve y\u00f6netilmesini sa\u011flar. Otomasyon, hata oran\u0131n\u0131 azalt\u0131r, tutarl\u0131l\u0131\u011f\u0131 art\u0131r\u0131r ve ge\u00e7i\u015f s\u00fcrecini h\u0131zland\u0131r\u0131r.<\/p>\n * \u00d6rnek Kod Blo\u011fu (Terraform):<\/strong><\/p>\n Bu kod par\u00e7ac\u0131\u011f\u0131, Terraform kullanarak AWS VPC ve Azure VNet kaynaklar\u0131n\u0131, belirtilen benzersiz CIDR bloklar\u0131yla nas\u0131l olu\u015fturabilece\u011finizi g\u00f6stermektedir.<\/p>\n IP adres alanlar\u0131n\u0131z\u0131 planlarken, gelecekteki b\u00fcy\u00fcme ve olas\u0131 de\u011fi\u015fiklikleri g\u00f6z \u00f6n\u00fcnde bulundurun. A\u011f\u0131n\u0131z\u0131n ne kadar b\u00fcy\u00fcyece\u011fini ve hangi yeni hizmetlerin entegre edilebilece\u011fini tahmin etmeye \u00e7al\u0131\u015f\u0131n. IP adres alanlar\u0131n\u0131z\u0131 \u00e7ok s\u0131k\u0131 bir \u015fekilde doldurmak yerine, gelecekteki ihtiya\u00e7lar i\u00e7in bir miktar bo\u015fluk b\u0131rakmak faydal\u0131 olacakt\u0131r.<\/p>\n \u0130htiya\u00e7lar\u0131n\u0131z de\u011fi\u015ftik\u00e7e, CIDR bloklar\u0131n\u0131z\u0131 b\u00f6lerek daha fazla alt a\u011f olu\u015fturabilir veya birle\u015ftirerek daha b\u00fcy\u00fck alt a\u011flar elde edebilirsiniz. \u00d6rne\u011fin, ba\u015flang\u0131\u00e7ta bir IP adresleme planlamas\u0131, DNS \u00e7\u00f6z\u00fcmlemesi ile yak\u0131ndan ili\u015fkilidir. Azure ve AWS’nin kendi DNS hizmetleri (Azure DNS, AWS Route 53) bulunur. Farkl\u0131 bulutlardaki kaynaklar\u0131n\u0131z\u0131n birbirini IP adresleri yerine alan adlar\u0131 (domain names) ile bulabilmesi i\u00e7in DNS kay\u0131tlar\u0131n\u0131z\u0131n do\u011fru bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 \u00f6nemlidir. Bu, \u00f6zellikle CIDR bloklar\u0131n\u0131z de\u011fi\u015fti\u011finde veya yeni a\u011flar eklendi\u011finde kritik hale gelir.<\/p>\n B\u00fcy\u00fck bir k\u00fcresel finans kurumu, t\u00fcm altyap\u0131s\u0131n\u0131 Azure ve AWS’ye ta\u015f\u0131ma karar\u0131 ald\u0131. Kurumun veri merkezinde karma\u015f\u0131k ve uzun y\u0131llard\u0131r kullan\u0131lan bir IP adresleme \u015femas\u0131 vard\u0131.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\n Kurum, a\u015fa\u011f\u0131daki ileri d\u00fczey stratejileri uygulad\u0131:<\/p>\n * Merkezi IPAM Sistemi:<\/strong> K\u00fcresel \u00e7apta t\u00fcm IP adres atamalar\u0131n\u0131 y\u00f6netmek i\u00e7in bir IPAM \u00e7\u00f6z\u00fcm\u00fc benimsendi. Bu, hem \u015firket i\u00e7i hem de bulut ortamlar\u0131ndaki t\u00fcm IP adres alanlar\u0131n\u0131n merkezi olarak izlenmesini sa\u011flad\u0131. Bu kapsaml\u0131 planlama ve optimizasyon stratejileri sayesinde kurum, b\u00fcy\u00fck \u00f6l\u00e7ekli ve karma\u015f\u0131k bir bulut ge\u00e7i\u015fini ba\u015far\u0131yla tamamlad\u0131, a\u011f altyap\u0131s\u0131n\u0131 modernize etti ve operasyonel verimlili\u011fi art\u0131rd\u0131.<\/p>\n Azure’dan AWS’ye veya tam tersine bir ge\u00e7i\u015f yaparken CIDR planlamas\u0131, projenin ba\u015far\u0131s\u0131 i\u00e7in kritik bir \u00f6neme sahiptir. Birbirini tamamlamayan iki farkl\u0131 IP adresleme \u015femas\u0131n\u0131 uyumlu hale getirmek, dikkatli bir haz\u0131rl\u0131k, detayl\u0131 analiz ve do\u011fru stratejiler gerektirir. Temel olarak, IP adres alanlar\u0131n\u0131z\u0131n tam bir envanterini \u00e7\u0131karmak, olas\u0131 \u00e7ak\u0131\u015fmalar\u0131 \u00f6nceden belirlemek ve her iki bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n da IP adresleme politikalar\u0131n\u0131 anlamak ilk ad\u0131md\u0131r. \u00d6zel IP adres alanlar\u0131n\u0131 ak\u0131ll\u0131ca se\u00e7mek, alt a\u011flar\u0131 g\u00fcvenlik ve performans odakl\u0131 planlamak, VPN ve \u00f6zel ba\u011flant\u0131lar\u0131 do\u011fru yap\u0131land\u0131rmak, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131 en az ayr\u0131cal\u0131k prensibine g\u00f6re uygulamak ve ileri d\u00fczeyde IPAM ara\u00e7lar\u0131 ile otomasyondan yararlanmak, bu s\u00fcreci sorunsuz hale getirecektir. Unutmay\u0131n ki, iyi planlanm\u0131\u015f bir CIDR stratejisi, sadece teknik bir gereklilik de\u011fil, ayn\u0131 zamanda bulut altyap\u0131n\u0131z\u0131n g\u00fcvenli\u011fini, performans\u0131n\u0131 ve y\u00f6netilebilirli\u011fini do\u011frudan etkileyen stratejik bir yat\u0131r\u0131md\u0131r. Bu ad\u0131mlar\u0131 izleyerek, iki farkl\u0131 bulut adres alan\u0131n\u0131 ba\u015far\u0131yla uyumlu hale getirebilir ve bulut ge\u00e7i\u015finizi hedeflerinize ula\u015farak tamamlayabilirsiniz.<\/p>\n * Azure ve AWS’de ayn\u0131 IP adres aral\u0131\u011f\u0131n\u0131 kullanabilir miyim?<\/strong> * Mevcut IP adres alanlar\u0131m\u0131 de\u011fi\u015ftirmek zorunda m\u0131y\u0131m?<\/strong> * IPAM ara\u00e7lar\u0131 neden \u00f6nemlidir?<\/strong> * Bulutlar aras\u0131 VPN ba\u011flant\u0131s\u0131 kurmak i\u00e7in hangi protokoller kullan\u0131l\u0131r?<\/strong> * Ge\u00e7i\u015f s\u0131ras\u0131nda IP adres \u00e7ak\u0131\u015fmalar\u0131n\u0131 nas\u0131l tespit edebilirim?<\/strong>192.168.1.0\/24<\/code> ifadesinde 192.168.1.0<\/code> IP adresini, \/24<\/code> ise alt a\u011f maskesini belirtir. Bu \/24<\/code> de\u011feri, ilk 24 bitin a\u011f k\u0131sm\u0131n\u0131, kalan 8 bitin ise ana bilgisayar (host) k\u0131sm\u0131n\u0131 temsil etti\u011fini g\u00f6sterir. Bu sayede, tek bir IP adresi blo\u011fu ile daha fazla say\u0131da cihaz adreslenebilir ve a\u011f y\u00f6netimi kolayla\u015f\u0131r.<\/p>\nAzure ve AWS IP Adresleme Farkl\u0131l\u0131klar\u0131 Nelerdir?<\/h3>\n
10.0.0.0\/8<\/code>, 172.16.0.0\/12<\/code> veya 192.168.0.0\/16<\/code> gibi RFC 1918 standartlar\u0131na uygun \u00f6zel IP adres aral\u0131klar\u0131n\u0131 kullan\u0131r. AWS de benzer \u00f6zel IP adres aral\u0131klar\u0131n\u0131 kullan\u0131r ancak varsay\u0131lan VPC CIDR bloklar\u0131 veya alt a\u011f atamalar\u0131 farkl\u0131l\u0131k g\u00f6sterebilir.<\/p>\n10.1.0.0\/16<\/code> adres aral\u0131\u011f\u0131n\u0131 kullan\u0131yorsa ve Azure’da da ayn\u0131 aral\u0131\u011f\u0131 kullanmaya \u00e7al\u0131\u015f\u0131rsa, bu bir \u00e7ak\u0131\u015fmaya yol a\u00e7acakt\u0131r. Benzer \u015fekilde, AWS’de bir VPC olu\u015ftururken de bu aral\u0131\u011f\u0131 kullanmak, iki bulut aras\u0131ndaki VPN ba\u011flant\u0131s\u0131n\u0131 imkans\u0131z hale getirebilir. Bu nedenle, ge\u00e7i\u015f planlamas\u0131 s\u0131ras\u0131nda her iki bulut sa\u011flay\u0131c\u0131s\u0131n\u0131n da IP adresleme politikalar\u0131n\u0131 ve varsay\u0131lanlar\u0131 anlamak ve bunlara g\u00f6re bir strateji olu\u015fturmak kritik \u00f6nem ta\u015f\u0131r. Ayr\u0131ca, her iki platformda da IP adres \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nlemek i\u00e7in \u00f6zel IP adres aral\u0131klar\u0131n\u0131n dikkatli bir \u015fekilde se\u00e7ilmesi ve y\u00f6netilmesi gerekmektedir.<\/p>\n\u00c7ak\u0131\u015fmalar\u0131 \u00d6nleme: Hibrit ve Multi-Cloud Senaryolar\u0131 \u0130\u00e7in Stratejiler<\/h3>\n
1. IP Adres Alan\u0131 Envanteri ve Analizi<\/h4>\n
2. IP Adres \u00c7ak\u0131\u015fmalar\u0131ndan Ka\u00e7\u0131nma Y\u00f6ntemleri<\/h4>\n
10.0.0.0\/8<\/code>, 172.16.0.0\/12<\/code>, 192.168.0.0\/16<\/code>) kullanman\u0131za izin verir. Bu alanlar, genel internetten y\u00f6nlendirilmez ve kendi \u00f6zel a\u011f\u0131n\u0131z i\u00e7inde kullan\u0131labilir. E\u011fer mevcut alanlar\u0131n\u0131z \u00e7ak\u0131\u015f\u0131yorsa, bu alanlardan birini veya her ikisini de daha az kullan\u0131lan veya hi\u00e7 kullan\u0131lmayan farkl\u0131 bir \u00f6zel IP aral\u0131\u011f\u0131na ta\u015f\u0131yabilirsiniz.
\n* Adres Alan\u0131 Daraltma veya Geni\u015fletme:<\/strong> Baz\u0131 durumlarda, mevcut CIDR bloklar\u0131n\u0131z\u0131 daraltarak veya geni\u015fleterek \u00e7ak\u0131\u015fmalar\u0131 \u00f6nleyebilirsiniz. \u00d6rne\u011fin, bir \/16<\/code> blo\u011funuz varsa ve bu blo\u011fun yaln\u0131zca k\u00fc\u00e7\u00fck bir k\u0131sm\u0131 kullan\u0131l\u0131yorsa, bunu bir \/20<\/code> veya \/22<\/code> blo\u011funa daraltarak di\u011fer bulut sa\u011flay\u0131c\u0131s\u0131 i\u00e7in daha fazla alan a\u00e7abilirsiniz.
\n* Bulut Sa\u011flay\u0131c\u0131lar\u0131na \u00d6zg\u00fc Alanlar\u0131 Kullanma:<\/strong> Azure ve AWS, kendi \u00f6zel IP adres aral\u0131klar\u0131n\u0131 tan\u0131mlaman\u0131za olanak tan\u0131r. Bu, her iki platformda da benzersiz ve \u00e7ak\u0131\u015fmayan CIDR bloklar\u0131 se\u00e7erek ba\u015flayabilece\u011finiz anlam\u0131na gelir. \u00d6rne\u011fin, Azure VNet’leriniz i\u00e7in 10.1.0.0\/16<\/code> ve AWS VPC’leriniz i\u00e7in 10.2.0.0\/16<\/code> gibi farkl\u0131 alanlar kullanabilirsiniz.
\n* VPN ve Direct Connect\/ExpressRoute Yap\u0131land\u0131rmas\u0131:<\/strong> E\u011fer VPN veya \u00f6zel ba\u011flant\u0131lar (AWS Direct Connect, Azure ExpressRoute) kullan\u0131yorsan\u0131z, y\u00f6nlendirme tablolar\u0131n\u0131z\u0131 (routing tables) dikkatlice yap\u0131land\u0131rman\u0131z gerekir. Her iki taraf\u0131n da birbirlerinin a\u011flar\u0131n\u0131 do\u011fru \u015fekilde tan\u0131yabilmesi i\u00e7in, y\u00f6nlendirme tablolar\u0131nda \u00e7ak\u0131\u015fan IP adres bloklar\u0131n\u0131n do\u011fru bir \u015fekilde e\u015flenmesi \u00f6nemlidir.<\/p>\n3. Vaka Analizi: Bir Finans \u015eirketinin AWS ve Azure Ge\u00e7i\u015fi<\/h4>\n
10.10.0.0\/16<\/code> gibi bir IP adres aral\u0131\u011f\u0131 kullan\u0131l\u0131yordu. Azure’da yeni VNet’ler olu\u015ftururken de ayn\u0131 aral\u0131\u011f\u0131 kullanmaya \u00e7al\u0131\u015ft\u0131lar. AWS’de ise, varsay\u0131lan VPC CIDR blo\u011fu olarak 10.0.0.0\/16<\/code> atanm\u0131\u015ft\u0131. Bu durum, hem veri merkezi ile bulut aras\u0131ndaki hem de iki bulut aras\u0131ndaki ileti\u015fimde ciddi \u00e7ak\u0131\u015fmalara yol a\u00e7\u0131yordu.<\/p>\n10.10.0.0\/16<\/code> adres aral\u0131\u011f\u0131, 10.100.0.0\/16<\/code> gibi daha az kullan\u0131lan bir alana ta\u015f\u0131nd\u0131. Bu, veri merkezi ile Azure aras\u0131ndaki VPN ba\u011flant\u0131s\u0131n\u0131n sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flad\u0131.
\n* AWS VPC IP Alan\u0131 Optimizasyonu:<\/strong> AWS VPC’lerinde kullan\u0131lan varsay\u0131lan 10.0.0.0\/16<\/code> aral\u0131\u011f\u0131, 10.200.0.0\/16<\/code> gibi farkl\u0131 bir \u00f6zel IP aral\u0131\u011f\u0131na g\u00fcncellendi. Bu, Azure VNet’leri ile AWS VPC’leri aras\u0131nda kurulacak olan VPN ba\u011flant\u0131s\u0131 i\u00e7in benzersiz bir alan sa\u011flad\u0131.
\n* Y\u00f6nlendirme Tablolar\u0131n\u0131n G\u00fcncellenmesi:<\/strong> Hem Azure hem de AWS’deki y\u00f6nlendirme tablolar\u0131, yeni IP adres aral\u0131klar\u0131n\u0131 yans\u0131tacak \u015fekilde g\u00fcncellendi. Bu, trafi\u011fin do\u011fru hedefe y\u00f6nlendirilmesini sa\u011flad\u0131.<\/p>\nAlt A\u011flar\u0131 (Subnets) Ak\u0131ll\u0131ca Planlamak<\/h3>\n
1. Alt A\u011f Boyutland\u0131rmas\u0131: \u0130htiya\u00e7lar\u0131 Tahmin Etmek<\/h4>\n
\/24<\/code> yerine \/23<\/code> gibi daha b\u00fcy\u00fck bir CIDR blo\u011fu se\u00e7mek daha mant\u0131kl\u0131 olabilir. Bu, her alt a\u011f\u0131n kendine \u00f6zg\u00fc bir CIDR blo\u011fu olmas\u0131n\u0131 sa\u011flar ve \u00e7ak\u0131\u015fma riskini azalt\u0131r.<\/p>\n2. G\u00fcvenlik ve Yal\u0131t\u0131m \u0130\u00e7in Alt A\u011f Kullan\u0131m\u0131<\/h4>\n
3. Azure ve AWS’de Alt A\u011f Planlamas\u0131<\/h4>\n
\n* AWS VPC Alt A\u011flar\u0131:<\/strong> AWS’de, bir VPC olu\u015fturduktan sonra bu VPC i\u00e7ine alt a\u011flar (subnets) olu\u015fturursunuz. Her alt a\u011f, VPC’nin ana CIDR blo\u011fundan al\u0131nan bir CIDR blo\u011funa sahiptir. AWS, alt a\u011flara atanan EC2 \u00f6rneklerine ve di\u011fer kaynaklara otomatik olarak IP adresleri atar.<\/p>\n4. Vaka Analizi: E-ticaret Platformu \u0130\u00e7in Alt A\u011f Planlamas\u0131<\/h4>\n
\n * 10.1.0.0\/16<\/code> VNet CIDR blo\u011fu.
\n * 10.1.1.0\/24<\/code> – \u00d6n U\u00e7 (Web Sunucular\u0131)
\n * 10.1.2.0\/24<\/code> – Arka U\u00e7 (Uygulama Sunucular\u0131)
\n * 10.1.3.0\/24<\/code> – Veritaban\u0131 Sunucular\u0131 (Yaln\u0131zca Arka U\u00e7’tan eri\u015filebilir)
\n * 10.1.4.0\/24<\/code> – Y\u00f6netim Alt A\u011f\u0131 (Yaln\u0131zca VPN \u00fczerinden eri\u015filebilir)
\n* AWS VPC:<\/strong>
\n * 10.2.0.0\/16<\/code> VPC CIDR blo\u011fu.
\n * 10.2.1.0\/24<\/code> – \u00d6n U\u00e7 (Web Sunucular\u0131)
\n * 10.2.2.0\/24<\/code> – Arka U\u00e7 (Uygulama Sunucular\u0131)
\n * 10.2.3.0\/24<\/code> – Veritaban\u0131 Sunucular\u0131 (Yaln\u0131zca Arka U\u00e7’tan eri\u015filebilir)
\n * 10.2.4.0\/24<\/code> – Y\u00f6netim Alt A\u011f\u0131 (Yaln\u0131zca VPN \u00fczerinden eri\u015filebilir)<\/p>\n
\n* Veritaban\u0131 alt a\u011flar\u0131na yaln\u0131zca arka u\u00e7 sunucular\u0131ndan eri\u015fim izni verildi.
\n* Y\u00f6netim alt a\u011flar\u0131, yaln\u0131zca g\u00fcvenli VPN ba\u011flant\u0131lar\u0131 \u00fczerinden eri\u015filebilir hale getirildi.
\n* Azure ve AWS aras\u0131ndaki ileti\u015fim, VPN ba\u011flant\u0131lar\u0131 ve do\u011fru y\u00f6nlendirme tablolar\u0131 ile sa\u011fland\u0131.<\/p>\nVPN ve Direct Connect\/ExpressRoute Yap\u0131land\u0131rmas\u0131<\/h3>\n
1. VPN Ba\u011flant\u0131lar\u0131 \u0130\u00e7in Dikkat Edilmesi Gerekenler<\/h4>\n
\n* T\u00fcnel Yap\u0131land\u0131rmas\u0131:<\/strong> VPN t\u00fcnelinin her iki taraf\u0131nda da do\u011fru kimlik do\u011frulama (authentication) ve \u015fifreleme (encryption) ayarlar\u0131n\u0131n yap\u0131lmas\u0131 gerekir. Ayr\u0131ca, her iki taraftaki y\u00f6nlendirme tablolar\u0131n\u0131n, kar\u015f\u0131 a\u011fdaki IP adres aral\u0131klar\u0131n\u0131 tan\u0131mas\u0131 \u00f6nemlidir.
\n* Performans ve G\u00fcvenilirlik:<\/strong> VPN ba\u011flant\u0131lar\u0131, internetin genel yap\u0131s\u0131 nedeniyle performansta dalgalanmalar ya\u015fayabilir. Kritik uygulamalar i\u00e7in daha y\u00fcksek performans ve g\u00fcvenilirlik gerekiyorsa, \u00f6zel ba\u011flant\u0131 hizmetleri tercih edilmelidir.<\/p>\n2. Direct Connect ve ExpressRoute: \u00d6zel Ba\u011flant\u0131 \u00c7\u00f6z\u00fcmleri<\/h4>\n
\n * Y\u00fcksek Performans:<\/strong> Sabit ve \u00f6ng\u00f6r\u00fclebilir bant geni\u015fli\u011fi sunar.
\n * D\u00fc\u015f\u00fck Gecikme (Latency):<\/strong> Veri transfer s\u00fcrelerini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.
\n * G\u00fcvenilirlik:<\/strong> \u0130nternet dalgalanmalar\u0131ndan etkilenmez.
\n * IP Adres \u00c7ak\u0131\u015fma Y\u00f6netimi:<\/strong> \u00d6zel ba\u011flant\u0131lar da IP adres \u00e7ak\u0131\u015fmalar\u0131ndan etkilenir. Ancak, bu ba\u011flant\u0131lar \u00fczerinden veri aktar\u0131m\u0131 yaparken, her iki taraf\u0131n da a\u011flar\u0131n\u0131 do\u011fru \u015fekilde y\u00f6nlendirmesi ve \u00e7ak\u0131\u015fmalar\u0131 \u00f6nlemesi gerekir.
\n* Yap\u0131land\u0131rma:<\/strong> Direct Connect ve ExpressRoute, genellikle bir telekom\u00fcnikasyon sa\u011flay\u0131c\u0131s\u0131 arac\u0131l\u0131\u011f\u0131yla yap\u0131land\u0131r\u0131l\u0131r. Bu, fiziksel bir ba\u011flant\u0131 kurulmas\u0131n\u0131 ve ard\u0131ndan sanal aray\u00fczlerin (virtual interfaces) yap\u0131land\u0131r\u0131lmas\u0131n\u0131 i\u00e7erir. Bu sanal aray\u00fczler, bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n a\u011f\u0131na ba\u011flanman\u0131z\u0131 sa\u011flar.<\/p>\n3. Vaka Analizi: Finansal Veri \u0130\u015fleme Platformu \u0130\u00e7in G\u00fcvenli Ba\u011flant\u0131<\/h4>\n
\n* Veri Merkezi ve AWS Ba\u011flant\u0131s\u0131:<\/strong> Benzer \u015fekilde, veri merkezini AWS’ye ba\u011flamak i\u00e7in AWS Direct Connect kullan\u0131ld\u0131. Bu, AWS \u00fczerindeki i\u015flem platformlar\u0131na verilerin g\u00fcvenli ve h\u0131zl\u0131 bir \u015fekilde ula\u015fmas\u0131n\u0131 sa\u011flad\u0131. Direct Connect yap\u0131land\u0131rmas\u0131 da, veri merkezi IP adres alanlar\u0131 ile AWS VPC IP adres alanlar\u0131 aras\u0131nda \u00e7ak\u0131\u015fma olmad\u0131\u011f\u0131n\u0131 garanti etti.
\n* Azure ve AWS Aras\u0131 Ba\u011flant\u0131:<\/strong> Azure VNet’leri ve AWS VPC’leri aras\u0131nda do\u011frudan bir ileti\u015fim ihtiyac\u0131 olmad\u0131\u011f\u0131ndan, bu iki bulut aras\u0131ndaki ba\u011flant\u0131, her iki bulutun da kendi i\u00e7inde kurdu\u011fu y\u00f6nlendirme tablolar\u0131 ve olas\u0131 bir felaket kurtarma senaryosu i\u00e7in yedekli VPN ba\u011flant\u0131lar\u0131 ile y\u00f6netildi.<\/p>\nG\u00fcvenlik Duvar\u0131 Kurallar\u0131 ve A\u011f G\u00fcvenli\u011fi<\/h3>\n
1. En Az Ayr\u0131cal\u0131k (Least Privilege) Prensibi<\/h4>\n
2. Azure G\u00fcvenlik Duvar\u0131 ve AWS G\u00fcvenlik Gruplar\u0131\/A\u011f ACL’leri<\/h4>\n
\n* AWS G\u00fcvenlik Gruplar\u0131 (Security Groups) ve A\u011f ACL’leri (Network ACLs):<\/strong> AWS’de, g\u00fcvenlik gruplar\u0131 ve a\u011f ACL’leri, kaynak d\u00fczeyinde (\u00f6rne\u011fin, EC2 \u00f6rnekleri) ve alt a\u011f d\u00fczeyinde g\u00fcvenlik kontrolleri sa\u011flar.
\n * G\u00fcvenlik Gruplar\u0131:<\/strong> Durum bilgisi olan (stateful) g\u00fcvenlik duvarlar\u0131d\u0131r. Gelen ve giden trafi\u011fi filtrelerler. Bir g\u00fcvenlik grubuna eklenen kurallar, o gruba dahil olan t\u00fcm kaynaklar i\u00e7in ge\u00e7erlidir.
\n * A\u011f ACL’leri:<\/strong> Durum bilgisi olmayan (stateless) g\u00fcvenlik duvarlar\u0131d\u0131r. Alt a\u011f d\u00fczeyinde gelen ve giden trafi\u011fi filtrelerler. Daha kat\u0131 eri\u015fim kontrol\u00fc gerektiren durumlar i\u00e7in kullan\u0131l\u0131rlar.<\/p>\n3. CIDR Planlamas\u0131n\u0131n G\u00fcvenlik \u00dczerindeki Etkisi<\/h4>\n
10.1.1.0\/24<\/code> alt a\u011f\u0131ndaysa, web sunucular\u0131na eri\u015fim izni veren bir g\u00fcvenlik kural\u0131 yazarken yaln\u0131zca bu CIDR blo\u011funu belirtmeniz yeterli olur. E\u011fer IP adresleri da\u011f\u0131n\u0131k ve \u00e7ak\u0131\u015f\u0131yorsa, her bir sunucu i\u00e7in ayr\u0131 ayr\u0131 kural yazmak zorunda kalabilirsiniz ki bu da hem zaman kayb\u0131na hem de hata riskine yol a\u00e7ar.<\/p>\n4. Vaka Analizi: Hassas Veri Aktar\u0131m\u0131 \u0130\u00e7in G\u00fcvenlik Katmanlar\u0131<\/h4>\n
\n * 10.1.0.0\/16<\/code> VNet CIDR blo\u011fu.
\n * 10.1.1.0\/24<\/code> – Hasta Kay\u0131t Sunucular\u0131 (Yaln\u0131zca VPN ve belirli y\u00f6netim IP’lerinden eri\u015filebilir)
\n * 10.1.2.0\/24<\/code> – Analiz Sunucular\u0131 (Yaln\u0131zca Hasta Kay\u0131t Sunucular\u0131 ve belirli y\u00f6netim IP’lerinden eri\u015filebilir)
\n* AWS VPC:<\/strong>
\n * 10.2.0.0\/16<\/code> VPC CIDR blo\u011fu.
\n * 10.2.1.0\/24<\/code> – Hasta Kay\u0131t Sunucular\u0131 (Yaln\u0131zca VPN ve belirli y\u00f6netim IP’lerinden eri\u015filebilir)
\n * 10.2.2.0\/24<\/code> – Analiz Sunucular\u0131 (Yaln\u0131zca Hasta Kay\u0131t Sunucular\u0131 ve belirli y\u00f6netim IP’lerinden eri\u015filebilir)<\/p>\n
\n* AWS G\u00fcvenlik Gruplar\u0131\/A\u011f ACL’leri:<\/strong> Benzer \u015fekilde, AWS’deki Hasta Kay\u0131t Sunucular\u0131 ve Analiz Sunucular\u0131 alt a\u011flar\u0131 i\u00e7in g\u00fcvenlik gruplar\u0131 ve a\u011f ACL’leri yap\u0131land\u0131r\u0131ld\u0131.
\n* Veri \u015eifreleme:<\/strong> Hem Azure ExpressRoute hem de AWS Direct Connect ba\u011flant\u0131lar\u0131 \u00fczerinden aktar\u0131lan veriler, ek g\u00fcvenlik katman\u0131 olarak \u015fifrelendi.<\/p>\n\u0130leri D\u00fczey Planlama ve Optimizasyon \u0130pu\u00e7lar\u0131<\/h3>\n
1. IP Adres Y\u00f6netim (IPAM) Ara\u00e7lar\u0131 Kullan\u0131m\u0131<\/h4>\n
2. Otomasyon ve Altyap\u0131y\u0131 Kod Olarak (Infrastructure as Code – IaC) Yakla\u015f\u0131m\u0131<\/h4>\n
resource "aws_vpc" "main" {\n cidr_block = "10.2.0.0\/16" # AWS VPC i\u00e7in benzersiz CIDR\n tags = {\n Name = "main-vpc"\n }\n }\n\n resource "azurerm_virtual_network" "main" {\n name = "main-vnet"\n location = "eastus"\n resource_group_name = "my-resource-group"\n address_space = ["10.1.0.0\/16"] # Azure VNet i\u00e7in benzersiz CIDR\n }<\/code><\/pre>\n3. Gelecekteki B\u00fcy\u00fcme ve De\u011fi\u015fiklikler \u0130\u00e7in Esneklik<\/h4>\n
4. CIDR Bloklar\u0131n\u0131 B\u00f6lme ve Birle\u015ftirme (Sizing Up\/Down)**<\/p>\n
\/22<\/code> blo\u011fu kullan\u0131rken, daha sonra daha fazla kaynak eklemek i\u00e7in bu blo\u011fu iki adet \/23<\/code> blo\u011funa b\u00f6lebilirsiniz. Bu, esneklik sa\u011flar ancak her zaman mevcut IP adresi kullan\u0131m\u0131n\u0131 ve olas\u0131 \u00e7ak\u0131\u015fmalar\u0131 dikkate alarak yap\u0131lmal\u0131d\u0131r.<\/p>\n5. DNS \u00c7\u00f6z\u00fcmlemesi (DNS Resolution) Entegrasyonu<\/h4>\n
6. Vaka Analizi: B\u00fcy\u00fck Kurumsal A\u011f Ge\u00e7i\u015fi ve Optimizasyon<\/h4>\n
\n* IaC ile Altyap\u0131 Olu\u015fturma:<\/strong> Terraform kullan\u0131larak, Azure ve AWS’deki t\u00fcm VNet’ler, VPC’ler, alt a\u011flar ve g\u00fcvenlik kurallar\u0131 kod olarak tan\u0131mland\u0131 ve otomatik olarak olu\u015fturuldu. Bu, ge\u00e7i\u015f s\u0131ras\u0131nda tutarl\u0131l\u0131\u011f\u0131 ve tekrarlanabilirli\u011fi sa\u011flad\u0131.
\n* Adres Alan\u0131 Yeniden Tasar\u0131m\u0131:<\/strong> Mevcut IP adres alanlar\u0131, \u00e7ak\u0131\u015fmalar\u0131 \u00f6nlemek ve gelecekteki b\u00fcy\u00fcmeyi desteklemek i\u00e7in tamamen yeniden tasarland\u0131. Azure i\u00e7in 10.0.0.0\/8<\/code> aral\u0131\u011f\u0131n\u0131n farkl\u0131 alt bloklar\u0131, AWS i\u00e7in ise 172.16.0.0\/12<\/code> aral\u0131\u011f\u0131n\u0131n farkl\u0131 alt bloklar\u0131 kullan\u0131ld\u0131.
\n* DNS Entegrasyonu:<\/strong> Azure DNS ve AWS Route 53, birbirleriyle entegre edilerek, bulutlar aras\u0131 kaynaklar\u0131n alan adlar\u0131 ile kolayca eri\u015filebilir olmas\u0131 sa\u011fland\u0131.
\n* A\u015famal\u0131 Ge\u00e7i\u015f:<\/strong> T\u00fcm altyap\u0131 tek seferde de\u011fil, a\u015famal\u0131 olarak ge\u00e7irilerek, olas\u0131 sorunlar\u0131n erken tespiti ve \u00e7\u00f6z\u00fcm\u00fc i\u00e7in zaman tan\u0131nd\u0131. Her a\u015famada, a\u011f ba\u011flant\u0131lar\u0131 ve g\u00fcvenlik kurallar\u0131 titizlikle test edildi.<\/p>\nSonu\u00e7: Ba\u015far\u0131l\u0131 Bir Ge\u00e7i\u015f \u0130\u00e7in Kilit Noktalar<\/h3>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h4>\n
\n Hay\u0131r, Azure VNet’leriniz ve AWS VPC’leriniz aras\u0131nda do\u011frudan bir ba\u011flant\u0131 (VPN veya \u00f6zel ba\u011flant\u0131) kurmay\u0131 planl\u0131yorsan\u0131z, her iki platformda da ayn\u0131 IP adres aral\u0131\u011f\u0131n\u0131 kullanamazs\u0131n\u0131z. Bu, IP adresi \u00e7ak\u0131\u015fmalar\u0131na yol a\u00e7ar ve a\u011f ileti\u015fimini engeller. Her iki platform i\u00e7in de benzersiz ve \u00e7ak\u0131\u015fmayan CIDR bloklar\u0131 se\u00e7melisiniz.<\/p>\n
\n E\u011fer mevcut IP adres alanlar\u0131n\u0131z Azure ve AWS’deki planlad\u0131\u011f\u0131n\u0131z a\u011flarla \u00e7ak\u0131\u015f\u0131yorsa, evet, de\u011fi\u015ftirmek zorunda kalabilirsiniz. Ancak, bazen her iki bulut sa\u011flay\u0131c\u0131s\u0131nda da farkl\u0131 \u00f6zel IP aral\u0131klar\u0131 kullanarak veya a\u011flar\u0131n\u0131z\u0131 daha k\u00fc\u00e7\u00fck alt a\u011flara b\u00f6lerek \u00e7ak\u0131\u015fmalardan ka\u00e7\u0131nmak m\u00fcmk\u00fcn olabilir. En iyi yakla\u015f\u0131m, kapsaml\u0131 bir analiz yaparak karar vermektir.<\/p>\n
\n IPAM (IP Address Management) ara\u00e7lar\u0131, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k a\u011flarda IP adres atamalar\u0131n\u0131, alt a\u011flar\u0131 ve DNS kay\u0131tlar\u0131n\u0131 merkezi olarak y\u00f6netmenize yard\u0131mc\u0131 olur. Bu ara\u00e7lar, \u00e7ak\u0131\u015fmalar\u0131 \u00f6nlemeye, IP adresi kullan\u0131m\u0131n\u0131 izlemeye, envanter \u00e7\u0131karmaya ve a\u011f planlamas\u0131n\u0131 kolayla\u015ft\u0131rmaya yard\u0131mc\u0131 olur, b\u00f6ylece manuel hatalar\u0131 azalt\u0131r.<\/p>\n
\n Genellikle IPsec (Internet Protocol Security) protokol\u00fc kullan\u0131l\u0131r. Azure VPN Gateway ve AWS Virtual Private Gateway, IPsec tabanl\u0131 VPN t\u00fcnelleri olu\u015fturmak i\u00e7in yayg\u0131n olarak kullan\u0131l\u0131r.<\/p>\n
\n A\u011f tarama ara\u00e7lar\u0131, ping komutlar\u0131, traceroute komutlar\u0131 ve bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n kendi a\u011f ara\u00e7lar\u0131 (\u00f6rne\u011fin, Azure Network Watcher, AWS VPC Flow Logs) ile \u00e7ak\u0131\u015fmalar\u0131 tespit edebilirsiniz. Ayr\u0131ca, VPN ba\u011flant\u0131s\u0131 kurmaya \u00e7al\u0131\u015f\u0131rken hata mesajlar\u0131 da size IP adresi \u00e7ak\u0131\u015fmalar\u0131 hakk\u0131nda bilgi verebilir. En iyi y\u00f6ntem, ge\u00e7i\u015f \u00f6ncesinde detayl\u0131 bir planlama yaparak \u00e7ak\u0131\u015fmalar\u0131 ba\u015ftan \u00f6nlemektir.<\/p>\n