Bulut ortamında ağ yapılandırması, birçok mühendis için karmaşık bir labirent gibi görünebilir. Bu makale, “Bulut Mühendisleri İçin Ağ Temelleri” serimizin ikinci bölümü olup, sanal özel bulut (VPC) kavramını ve bulut ağ güvenliğinin temel taşlarını derinlemesine inceliyor. VPC’lerin neden bu kadar kritik olduğunu, bileşenlerinin nasıl çalıştığını ve uygulamalarınızı siber tehditlere karşı nasıl koruyacağınızı adım adım keşfedin.
Bulut teknolojileri, günümüzün dijital dünyasında işletmeler için vazgeçilmez bir altyapı haline gelmiştir. Ancak, geleneksel on-premise veri merkezlerinden buluta geçiş yapan mühendisler için en büyük zorluklardan biri genellikle ağ yönetimidir. Geleneksel ağlarda fiziksel donanımlar, kablolama ve manuel yapılandırmalar ön plandayken, bulut ağlarında her şey yazılım tanımlıdır (Software-Defined Networking – SDN). Bu değişim, mühendislerin bakış açısını temelden değiştirmeyi gerektirir. Fiziksel donanımlar yerine sanal bileşenlerle çalışmak, ağ tasarımlarının daha esnek ve ölçeklenebilir olmasını sağlarken, aynı zamanda karmaşıklığı da beraberinde getirebilir.
Peki, bu karmaşıklık nereden kaynaklanıyor? Öncelikle, bulut sağlayıcılarının sunduğu geniş hizmet yelpazesi başlı başına bir öğrenme eğrisi yaratır. Her bir hizmetin kendi ağ gereksinimleri ve entegrasyon yöntemleri vardır. İkinci olarak, güvenlik, bulut ağlarında hayati bir rol oynar ve doğru yapılandırılmadığında ciddi risklere yol açabilir. Güvenlik grupları, ağ erişim kontrol listeleri (NACL’ler), VPN’ler ve ağ geçitleri gibi çeşitli güvenlik katmanları, birbirleriyle uyumlu bir şekilde çalışacak şekilde tasarlanmalıdır. Son olarak, bulut ağlarının dinamik yapısı, sürekli izleme ve optimizasyon gerektirir. Kaynaklar anlık olarak ölçeklenebilir, bu da IP adreslemesi, yönlendirme ve güvenlik politikalarında esneklik ve otomasyon ihtiyacını doğurur. Bu makalede, bu karmaşıklığı sadeleştirerek, bulut mühendislerinin en temel yapı taşı olan Sanal Özel Bulut (VPC) kavramını ve onunla ilişkili güvenlik mekanizmalarını derinlemesine inceleyeceğiz. Part 1’de edindiğimiz temel IP adresleme ve ağ protokolleri bilgilerinin üzerine inşa ederek, bulut ortamında güvenli ve verimli ağlar kurmanın yollarını keşfedeceğiz. Amacımız, bulut ağlarını sadece anlamak değil, aynı zamanda onları ustaca yönetebilecek becerileri kazanmanıza yardımcı olmaktır. Bu yolculukta, teorik bilgileri gerçek dünya senaryolarıyla birleştirerek, karşılaşabileceğiniz pratik sorunlara çözümler sunacağız.
Sanal Özel Bulut (VPC) Nedir ve Neden Bulut Ortamında Hayatidir?
Sanal Özel Bulut (VPC), bulut ortamında oluşturduğunuz sanal, izole bir ağdır. Tıpkı kendi veri merkezinizde fiziksel sunucularınız ve ağ cihazlarınızla oluşturduğunuz özel bir ağ gibi, VPC de bulut sağlayıcısının paylaşımlı altyapısı üzerinde tamamen sizin kontrolünüzde olan mantıksal olarak izole edilmiş bir alan sunar. Bu izolasyon, VPC’lerin bulut ortamında hayati olmasının en önemli nedenidir.
VPC’nizi oluşturduğunuzda, ona kendi IP adresi aralığını (CIDR bloğu) atarsınız. Örneğin, 10.0.0.0/16 gibi özel bir IP aralığı seçebilirsiniz. Bu aralık içindeki IP adresleri, sizin VPC’niz dışında başka hiçbir bulut müşterisi tarafından kullanılamaz. Bu da, verilerinizin ve uygulamalarınızın diğer bulut kullanıcılarının ağlarından tamamen ayrılmış olduğu anlamına gelir. Bu düzeydeki izolasyon, güvenlik ve veri gizliliği açısından son derece kritik bir avantaj sunar. Geleneksel veri merkezlerinde, fiziksel ağ segmentasyonu pahalı ve karmaşık olabilirken, VPC’ler bu segmentasyonu yazılım tanımlı bir şekilde ve çok daha esnek bir maliyetle sağlar. Böylelikle, farklı departmanlar, projeler veya müşteri uygulamaları için ayrı ayrı, güvenli ağ ortamları oluşturmak mümkün hale gelir.
Bir VPC içinde, alt ağlar (subnets) oluşturarak ağınızı daha da bölümlendirebilirsiniz. Alt ağlar, VPC’nizin IP aralığını daha küçük, yönetilebilir parçalara ayırır. Örneğin, genel erişime açık web sunucularınız için bir “genel alt ağ” ve veritabanlarınız için internet erişimi olmayan “özel alt ağ” oluşturabilirsiniz. Bu ayrım, güvenlik duruşunuzu güçlendirir, çünkü özel alt ağlardaki kaynaklara doğrudan internetten erişim engellenir. VPC’ler sadece izolasyon sağlamakla kalmaz, aynı zamanda size ağ topolojisi üzerinde tam kontrol yeteneği de verir. Yönlendirme tabloları aracılığıyla trafik akışını yönlendirebilir, ağ geçitleri ile internete veya diğer ağlara bağlantı kurabilir, güvenlik grupları ve ağ ACL’leri ile trafik filtreleme kurallarını belirleyebilirsiniz. Bu kontrol seviyesi, bulut mühendislerinin uygulamalarının gerektirdiği özel ağ yapılarını esnek bir şekilde tasarlamasına ve uygulamasına olanak tanır. Kısacası, VPC’ler bulut üzerinde kendi “sanal veri merkezinizi” inşa etmenizi sağlar, bu da güvenlik, kontrol ve yönetilebilirlik açısından paha biçilmezdir. Bu sanal alan, bulut üzerinde barındırdığınız tüm kritik iş yüklerinizin temelini oluşturur ve onların güvenli, performanslı ve erişilebilir olmasını sağlar.
VPC Bileşenlerini Anlamak: Alt Ağlar, Yönlendirme Tabloları ve Ağ Geçitleri Nasıl Çalışır?
Bir VPC’nin gücü ve esnekliği, onu oluşturan temel bileşenlerin birbiriyle uyumlu çalışmasından gelir. Bu bölümde, bir VPC’yi inşa etmek için gerekli olan ana yapı taşlarını, yani alt ağları, yönlendirme tablolarını ve çeşitli ağ geçitlerini detaylı bir şekilde inceleyeceğiz.
Alt Ağlar (Subnets): Ağınızı Bölümlendirme Sanatı
Daha önce bahsettiğimiz gibi, bir VPC oluşturduğunuzda ona bir CIDR bloğu (örneğin, 10.0.0.0/16) atarsınız. Bu büyük IP bloğunu daha küçük, yönetilebilir parçalara ayırmak için alt ağlar (subnets) kullanırız. Alt ağlar, VPC içindeki kaynaklarınızı mantıksal olarak gruplandırmanıza ve her bir alt ağ için farklı güvenlik veya yönlendirme kuralları uygulamanıza olanak tanır. Genellikle, alt ağları iki ana kategoriye ayırırız:
- Genel Alt Ağlar (Public Subnets): Doğrudan internet erişimine sahip olması gereken kaynakları (örn. web sunucuları, yük dengeleyiciler) barındırır. Bu alt ağlardaki kaynaklara atanmış genel IP adresleri veya elastik IP’ler bulunur ve genellikle bir İnternet Ağ Geçidi’ne (Internet Gateway – IGW) yönlendirilmiş bir yol tablosuyla ilişkilendirilirler.
- Özel Alt Ağlar (Private Subnets): Doğrudan internet erişimi olmaması gereken hassas kaynakları (örn. veritabanları, uygulama sunucuları) barındırır. Bu alt ağlardaki kaynaklara yalnızca özel IP adresleri atanır. Özel alt ağların internete çıkması gerektiğinde (örneğin yazılım güncellemeleri için), bu trafik bir NAT Ağ Geçidi (NAT Gateway) veya NAT Örneği (NAT Instance) üzerinden yönlendirilir.
Her alt ağ, bir kullanılabilirlik alanına (Availability Zone – AZ) bağlıdır. Bu, uygulamanızın yüksek erişilebilirlik (High Availability) ve hata toleransı için farklı AZ’lere yayılan alt ağlarda dağıtılması gerektiği anlamına gelir. Örneğin, bir web uygulamasının farklı AZ’lerdeki iki genel alt ağda çalışan web sunucuları olabilir, böylece bir AZ’nin çökmesi durumunda uygulama çalışmaya devam eder.
Yönlendirme Tabloları (Route Tables): Trafik Nereye Gidecek?
Yönlendirme tabloları, ağ trafiğinin alt ağlar arasında, VPC içinde ve VPC dışına nasıl yönlendirileceğini belirleyen kurallar (yollar) koleksiyonudur. Her alt ağ, bir yönlendirme tablosuyla ilişkilendirilmek zorundadır. Bir alt ağdaki bir örnekten gelen trafik, ilişkilendirilmiş yönlendirme tablosundaki yollara göre hedef IP adresine doğru yönlendirilir. Bir yönlendirme tablosundaki anahtar bileşenler şunlardır:
- Hedef (Destination): Trafiğin gitmek istediği IP adresi aralığı (CIDR bloğu). Örneğin,
0.0.0.0/0tüm internet trafiğini temsil eder. - Hedef (Target): Trafiğin belirtilen hedefe ulaşmak için geçmesi gereken ağ geçidi, ağ arayüzü veya başka bir hedef.
Örneğin, bir genel alt ağın yönlendirme tablosunda, hedef 0.0.0.0/0 (herhangi bir yere) olan trafiğin bir İnternet Ağ Geçidi’ne (IGW) gitmesi gerektiğini belirten bir yol bulunabilir. Özel bir alt ağın yönlendirme tablosunda ise, hedef 0.0.0.0/0 olan trafiğin bir NAT Ağ Geçidi’ne gitmesi gerektiğini belirten bir yol bulunabilir.
# Genel Alt Ağ için Yönlendirme Tablosu Örneği (Pseudo Kod)
# Hedef: 0.0.0.0/0 (Tüm internet) -> Hedef: igw-xxxxxxxx (İnternet Ağ Geçidi)
# Hedef: 10.0.0.0/16 (VPC İçi) -> Hedef: local (Yerel VPC yönlendirmesi)
# Özel Alt Ağ için Yönlendirme Tablosu Örneği (Pseudo Kod)
# Hedef: 0.0.0.0/0 (Tüm internet) -> Hedef: nat-xxxxxxxx (NAT Ağ Geçidi)
# Hedef: 10.0.0.0/16 (VPC İçi) -> Hedef: local (Yerel VPC yönlendirmesi)
Ağ Geçitleri (Gateways): Dünya ile Köprüler Kurmak
Ağ geçitleri, VPC'nizin dış dünya veya diğer bulut hizmetleriyle iletişim kurmasını sağlayan temel bileşenlerdir.
- İnternet Ağ Geçidi (Internet Gateway - IGW): Bir VPC'nin internete çıkış ve internetten gelen trafiği kabul etmesini sağlayan yatay ölçeklenen, yedekli ve yüksek erişilebilir bir VPC bileşenidir. Genel alt ağların internete erişebilmesi için bir IGW'ye yönlendirilmiş bir yola sahip olması gerekir.
- NAT Ağ Geçidi (NAT Gateway) / NAT Örneği (NAT Instance): Özel alt ağlardaki kaynakların internete çıkış yapmasını sağlar ancak internetten gelen bağlantıları doğrudan kabul etmez. Bu, veritabanları gibi hassas kaynakların internetten izole kalmasını sağlarken, gerekli güncellemeleri yapmalarına veya dış API'leri kullanmalarına olanak tanır. NAT Ağ Geçidi, genellikle daha yönetilebilir ve ölçeklenebilir bir seçenekken, NAT Örneği daha fazla kontrol sağlar ancak yönetimi size aittir.
- Sanal Özel Ağ (VPN) Ağ Geçidi (Virtual Private Gateway - VPG): VPC'niz ile şirket içi ağınız arasında şifreli bir VPN bağlantısı kurmanızı sağlar. Bu, şirket içi kaynaklarınızın buluttaki kaynaklarınızla güvenli bir şekilde iletişim kurmasına olanak tanır.
- Doğrudan Bağlantı (Direct Connect) Ağ Geçidi: Şirket içi ağınız ile bulut sağlayıcınız arasında özel, ayrılmış bir ağ bağlantısı kurmanızı sağlar. Bu, VPN'e göre daha yüksek bant genişliği ve daha düşük gecikme süresi sunar.
Bu bileşenlerin her biri, bulut ağınızın belirli bir ihtiyacını karşılamak üzere tasarlanmıştır. Onları doğru bir şekilde bir araya getirerek, güvenli, ölçeklenebilir ve yüksek performanslı bir ağ altyapısı oluşturabilirsiniz. Bu yapı, modern bulut uygulamalarının omurgasını oluşturur ve bulut mühendisleri için vazgeçilmez bir bilgi setidir.
Güvenliği Katmanlara Ayırmak: Güvenlik Grupları (Security Groups) ve Ağ ACL'leri (NACLs) Nasıl Kullanılır?
Bulut ağlarında güvenlik, yalnızca ağ trafiğini yönlendirmekten ibaret değildir; aynı zamanda bu trafiği kiminle ve ne şekilde paylaşacağınızı da kontrol etmeyi içerir. İşte bu noktada Güvenlik Grupları (Security Groups - SG) ve Ağ Erişim Kontrol Listeleri (Network Access Control Lists - NACL) devreye girer. Bu iki temel güvenlik mekanizması, VPC'nizdeki kaynaklarınızı dış tehditlerden korumak için katmanlı bir savunma stratejisi sunar. Her ikisi de güvenlik duvarı görevi görse de, çalışma prensipleri ve uygulama seviyeleri açısından önemli farklılıkları vardır.
Güvenlik Grupları (Security Groups - SG): Örnek Seviyesinde Güvenlik Duvarları
Güvenlik Grupları, bulut ortamındaki örnekleriniz (sanal makineleriniz, veritabanlarınız vb.) için sanal güvenlik duvarlarıdır. SG'ler, "izin verilenler" prensibiyle çalışır; yani açıkça izin vermediğiniz sürece tüm trafik reddedilir. Bu durum, varsayılan olarak her şeyin kapalı olduğu ve sizin sadece ihtiyaç duyduğunuz bağlantı noktalarını açtığınız anlamına gelir. İşte Güvenlik Grupları'nın temel özellikleri:
- Durum Bilgisi (Stateful): Bu, Güvenlik Gruplarının en önemli özelliğidir. Eğer bir giden (outbound) kuralı ile trafik başlatırsanız, dönen (inbound) trafik için ayrı bir kurala ihtiyaç duymazsınız; SG otomatik olarak geri dönen trafiğe izin verir. Örneğin, bir sunucu internetten bir paket indirdiğinde, indirilen verilerin geri dönüşüne otomatik olarak izin verilir.
- Örnek Seviyesinde Uygulama: SG'ler belirli bir örnek veya örnek grubuna atanır. Aynı alt ağdaki farklı örneklere farklı Güvenlik Grupları atayabilirsiniz. Bir örnek birden fazla Güvenlik Grubuna sahip olabilir.
- Yalnızca İzin Kuralları (Allow Rules Only): SG'lerde yalnızca trafiğe izin veren kurallar tanımlarsınız. Reddetme (deny) kuralı yoktur; izin verilmeyen her şey otomatik olarak reddedilir.
- Trafik Türleri: SG kuralları, protokol (TCP, UDP, ICMP), port aralığı ve kaynak/hedef IP adresleri veya başka bir Güvenlik Grubu kimliği temelinde tanımlanır.
Örnek Senaryo: Web Sunucusu Güvenlik Grubu
Bir web sunucusunun Güvenlik Grubu şu kuralları içerebilir:
- Gelen (Inbound) Trafik:
- Tip: HTTP (80/TCP), Kaynak:
0.0.0.0/0(Her yerden) - Tip: HTTPS (443/TCP), Kaynak:
0.0.0.0/0(Her yerden) - Tip: SSH (22/TCP), Kaynak: Kendi IP'niz veya belirli bir yönetim ağı CIDR bloğu
- Tip: HTTP (80/TCP), Kaynak:
- Giden (Outbound) Trafik:
- Tip: Tüm Trafik (All Traffic), Hedef:
0.0.0.0/0(Her yere) - Genellikle varsayılan olarak izin verilir.
- Tip: Tüm Trafik (All Traffic), Hedef:
# Basit bir Güvenlik Grubu Yapılandırma Örneği (Pseudo Kod)
# Web Sunucusu Güvenlik Grubu
# Inbound Kurallar:
# - Port: 80 (HTTP), Protokol: TCP, Kaynak: 0.0.0.0/0
# - Port: 443 (HTTPS), Protokol: TCP, Kaynak: 0.0.0.0/0
# - Port: 22 (SSH), Protokol: TCP, Kaynak: 203.0.113.45/32 (Yönetici IP'si)
# Outbound Kurallar:
# - Port: Tümü, Protokol: Tümü, Hedef: 0.0.0.0/0
Ağ Erişim Kontrol Listeleri (Network Access Control Lists - NACL): Alt Ağ Seviyesinde Güvenlik Duvarları
NACL'ler, alt ağlar için çalışan durum bilgisiz (stateless) güvenlik duvarlarıdır. Güvenlik Gruplarından farklı olarak, hem izin verme (allow) hem de reddetme (deny) kuralları tanımlayabilirsiniz ve her kurala bir numara atarsınız. NACL'ler, düşük numaralı kuraldan başlayarak sırayla değerlendirilir ve ilk eşleşen kural uygulanır. İşte NACL'lerin temel özellikleri:
- Durum Bilgisiz (Stateless): Bu, NACL'lerin kritik bir özelliğidir. Eğer bir gelen trafiğe izin verirseniz, geri dönen trafik için de ayrı bir giden kuralı tanımlamanız gerekir. Örneğin, internetten gelen HTTP isteğine izin verdiğinizde, web sunucusunun cevabının dışarı çıkması için de açıkça bir giden kuralı olmalıdır.
- Alt Ağ Seviyesinde Uygulama: Bir NACL, bir veya daha fazla alt ağa atanır. Bir alt ağ, aynı anda yalnızca bir NACL ile ilişkilendirilebilir.
- Hem İzin Hem de Reddetme Kuralları: NACL'ler, belirli trafik türlerini izin vermek veya engellemek için kullanılabilir.
- Kural Numaraları: Her kurala 1'den 32766'ya kadar bir numara atanır. Kurallar, en düşük numaralı kuraldan başlayarak işlenir. Genellikle 10'un katları şeklinde numaralar kullanılır (10, 20, 30 vb.) araya yeni kurallar eklemeyi kolaylaştırmak için.
- Varsayılan Reddetme: Varsayılan olarak, bir NACL'nin sonunda, açıkça eşleşmeyen tüm trafiği reddeden bir "yıldız" veya "reddetme" kuralı (örneğin kural numarası 32767) bulunur.
Örnek Senaryo: Genel Alt Ağ NACL'si
Genel bir alt ağın NACL'si şu kuralları içerebilir:
- Gelen (Inbound) Kurallar:
- 100: İzin Ver (Allow) - HTTP (80/TCP) - Kaynak:
0.0.0.0/0 - 110: İzin Ver (Allow) - HTTPS (443/TCP) - Kaynak:
0.0.0.0/0 - 120: İzin Ver (Allow) - SSH (22/TCP) - Kaynak: Kendi IP'niz
- *: Reddet (Deny) - Tüm Trafik (Varsayılan)
- 100: İzin Ver (Allow) - HTTP (80/TCP) - Kaynak:
- Giden (Outbound) Kurallar:
- 100: İzin Ver (Allow) - HTTP (80/TCP) - Hedef:
0.0.0.0/0 - 110: İzin Ver (Allow) - HTTPS (443/TCP) - Hedef:
0.0.0.0/0 - 120: İzin Ver (Allow) - SSH (22/TCP) - Hedef: Kendi IP'niz
- 130: İzin Ver (Allow) - Ephemeral Portlar (1024-65535/TCP) - Hedef:
0.0.0.0/0(Dönen trafiğe izin vermek için kritik) - *: Reddet (Deny) - Tüm Trafik (Varsayılan)
- 100: İzin Ver (Allow) - HTTP (80/TCP) - Hedef:
# Basit bir NACL Yapılandırma Örneği (Pseudo Kod)
# Genel Alt Ağ NACL - Gelen Kurallar:
# - Kural No: 100, Eylem: İzin Ver, Port: 80 (HTTP), Protokol: TCP, Kaynak: 0.0.0.0/0
# - Kural No: 110, Eylem: İzin Ver, Port: 443 (HTTPS), Protokol: TCP, Kaynak: 0.0.0.0/0
# - Kural No: 120, Eylem: İzin Ver, Port: 22 (SSH), Protokol: TCP, Kaynak: 203.0.113.45/32
# - Kural No: * (Son kural), Eylem: Reddet, Port: Tümü, Protokol: Tümü, Kaynak: 0.0.0.0/0
# Genel Alt Ağ NACL - Giden Kurallar:
# - Kural No: 100, Eylem: İzin Ver, Port: 80 (HTTP), Protokol: TCP, Hedef: 0.0.0.0/0
# - Kural No: 110, Eylem: İzin Ver, Port: 443 (HTTPS), Protokol: TCP, Hedef: 0.0.0.0/0
# - Kural No: 120, Eylem: İzin Ver, Port: 22 (SSH), Protokol: TCP, Hedef: 203.0.113.45/32
# - Kural No: 130, Eylem: İzin Ver, Port: 1024-65535 (Ephemeral), Protokol: TCP, Hedef: 0.0.0.0/0
# - Kural No: * (Son kural), Eylem: Reddet, Port: Tümü, Protokol: Tümü, Hedef: 0.0.0.0/0
NACL'ler ve Güvenlik Grupları Arasındaki Farklar ve Ne Zaman Hangisini Kullanmalısınız?
| Özellik | Güvenlik Grupları (SG) | Ağ ACL'leri (NACL) |
|---|---|---|
| Uygulama Seviyesi | Örnek (Instance) seviyesi | Alt ağ (Subnet) seviyesi |
| Durum Bilgisi | Durum bilgisidir (Stateful) | Durum bilgisizdir (Stateless) |
| Kural Türü | Yalnızca izin (Allow) kuralları | İzin (Allow) ve reddetme (Deny) kuralları |
| Kural Değerlendirme | Tüm kurallar değerlendirilir | Kural numarasına göre sırayla, ilk eşleşen uygulanır |
| Varsayılan Davranış | Varsayılan olarak her şeyi reddeder, giden trafiğe izin verir | Varsayılan olarak her şeyi reddeder |
Genel olarak, Güvenlik Gruplarını tek tek örneklerinizin önünde ilk savunma hattı olarak kullanırız, çünkü durum bilgisidir ve yönetimi daha kolaydır. NACL'leri ise, alt ağ seviyesinde daha geniş, kaba taneli bir güvenlik katmanı olarak düşünün. Genellikle, bir alt ağa girmesine veya çıkmasına izin verilen maksimum trafik türünü kontrol etmek için kullanılır. Hassas alt ağları (örneğin veritabanı alt ağları) daha katı bir şekilde kısıtlamak için NACL'ler harika bir araçtır. Çoğu durumda, Güvenlik Grupları yeterli olacaktır, ancak ek bir güvenlik katmanı veya belirli reddetme kurallarına ihtiyacınız olduğunda NACL'lere başvurmalısınız.
Gerçek Dünya Senaryosu: Yüksek Erişilebilir Bir Web Uygulaması için VPC Tasarımı
Şimdiye kadar öğrendiğimiz tüm VPC bileşenlerini ve güvenlik mekanizmalarını bir araya getirerek, gerçek bir senaryo üzerinden yüksek erişilebilir (High Availability - HA) bir web uygulamasının buluttaki ağ tasarımını ele alalım. Bu vaka analizi, bulut mühendislerinin günlük görevlerinde karşılaşabileceği tipik bir mimariyi temsil etmektedir.
Senaryo: E-ticaret Sitesi İçin HA Web Uygulaması
Bir e-ticaret şirketi, mevcut on-premise uygulamasını buluta taşımak istiyor. Uygulama, müşterilere ürünleri gösterecek bir web katmanından ve siparişleri, ürün bilgilerini depolayan bir veritabanı katmanından oluşacak. Şirket, uygulamanın kesintisiz çalışmasını, yüksek performans göstermesini ve siber saldırılara karşı güvenli olmasını talep ediyor.
VPC Tasarım Adımları ve Bileşenleri:
- VPC Oluşturma:
- İlk adım, tüm kaynaklarımızı barındıracak bir VPC oluşturmaktır. Diyelim ki
10.0.0.0/16CIDR bloğunu seçtik. Bu, VPC'miz için 65.536 adet özel IP adresi anlamına gelir. - Görsel Betimleme: Büyük bir dikdörtgen düşünün, içinde "E-ticaret VPC (10.0.0.0/16)" yazıyor. Bu dikdörtgenin içinde farklı renkte bölgeler olacak.
- İlk adım, tüm kaynaklarımızı barındıracak bir VPC oluşturmaktır. Diyelim ki
- Kullanılabilirlik Alanları (Availability Zones - AZ) ve Alt Ağlar:
- Yüksek erişilebilirlik sağlamak için en az iki, tercihen üç farklı Kullanılabilirlik Alanında kaynaklarımızı dağıtacağız. Her AZ'de hem genel hem de özel alt ağlar oluşturacağız.
- AZ1 (Örn: eu-central-1a):
- Genel Alt Ağ 1:
10.0.1.0/24(Web sunucuları ve Yük Dengeleyici için) - Özel Alt Ağ 1:
10.0.2.0/24(Uygulama sunucuları ve Veritabanı için)
- Genel Alt Ağ 1:
- AZ2 (Örn: eu-central-1b):
- Genel Alt Ağ 2:
10.0.3.0/24(Web sunucuları ve Yük Dengeleyici için) - Özel Alt Ağ 2:
10.0.4.0/24(Uygulama sunucuları ve Veritabanı için)
- Genel Alt Ağ 2:
- Görsel Betimleme: Büyük VPC dikdörtgeninin içinde iki eşit boyutta, birbirinden ayrı "AZ1" ve "AZ2" bölmeleri var. Her AZ bölmesinin içinde iki küçük dikdörtgen var: biri "Genel Alt Ağ" (dışa dönük), diğeri "Özel Alt Ağ" (içe dönük).
- İnternet Ağ Geçidi (IGW) ve NAT Ağ Geçidi (NAT Gateway):
- İnternetten gelen trafiğin VPC'ye ulaşması ve genel alt ağlardaki web sunucularımızın internete çıkabilmesi için bir IGW'ye ihtiyacımız var.
- Özel alt ağlardaki uygulama ve veritabanı sunucularımızın internete (örneğin yazılım güncellemeleri için) güvenli bir şekilde çıkabilmesi, ancak doğrudan internetten erişilememesi için her AZ'deki genel alt ağa birer NAT Ağ Geçidi konuşlandıracağız.
- Görsel Betimleme: VPC'nin dış kenarında bir "İnternet Ağ Geçidi" (IGW) ikonu var. Her AZ'deki Genel Alt Ağ'ın içinde bir "NAT Ağ Geçidi" ikonu var. IGW'den Genel Alt Ağlara çift yönlü oklar, NAT Ağ Geçidinden Özel Alt Ağlara tek yönlü (outbound) oklar.
- Yönlendirme Tabloları:
- Genel Alt Ağ Yönlendirme Tablosu (AZ1 & AZ2 için ayrı): Varsayılan yol (
0.0.0.0/0) IGW'ye yönlendirilir. - Özel Alt Ağ Yönlendirme Tablosu (AZ1 & AZ2 için ayrı): Varsayılan yol (
0.0.0.0/0) kendi AZ'sindeki NAT Ağ Geçidi'ne yönlendirilir.
- Genel Alt Ağ Yönlendirme Tablosu (AZ1 & AZ2 için ayrı): Varsayılan yol (
- Uygulama Yük Dengeleyici (Application Load Balancer - ALB):
- Gelen web trafiğini genel alt ağlardaki web sunucularımıza eşit şekilde dağıtmak ve AZ'ler arası hata toleransı sağlamak için bir ALB konuşlandırılır. ALB'nin kendisi genel alt ağlarda yer alır ve internete yönelik bir DNS adıyla erişilebilir.
- Görsel Betimleme: Genel Alt Ağların önünde, IGW ile Web Sunucuları arasında bir "Uygulama Yük Dengeleyici" ikonu.
- Güvenlik Grupları (SG):
- ALB Güvenlik Grubu: Gelen HTTP (80) ve HTTPS (443) trafiğine
0.0.0.0/0'dan (her yerden) izin verir. Giden (outbound) olarak web sunucularının SG'sine izin verir. - Web Sunucusu Güvenlik Grubu: Gelen trafiği yalnızca ALB Güvenlik Grubu'ndan HTTP (80) ve HTTPS (443) portlarında kabul eder. SSH (22) trafiğine ise yalnızca belirli bir yönetim IP aralığından (
192.168.1.0/24gibi) izin verir. Giden olarak uygulama sunucusunun SG'sine ve internete izin verir. - Uygulama Sunucusu Güvenlik Grubu: Gelen trafiği yalnızca Web Sunucusu Güvenlik Grubu'ndan belirli uygulama portlarında (örneğin 8080/TCP) kabul eder. Giden olarak Veritabanı Güvenlik Grubu'na izin verir ve NAT Ağ Geçidi üzerinden internete çıkışa izin verir.
- Veritabanı Güvenlik Grubu: Gelen trafiği yalnızca Uygulama Sunucusu Güvenlik Grubu'ndan veritabanı portunda (örneğin PostgreSQL için 5432/TCP, MySQL için 3306/TCP) kabul eder. Giden olarak yalnızca gerekli yerlere (örneğin bulut sağlayıcının depolama hizmetlerine) izin verir.
# Basit Terraform / AWS CLI ile VPC oluşturma pseudo kodu # Bu, bir VPC, iki genel ve iki özel alt ağ, bir IGW ve iki NAT Gateway'in yapılandırmasını gösterir. # VPC Oluşturma resource "aws_vpc" "ecommerce_vpc" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true enable_dns_support = true tags = { Name = "ECommerceVPC" } } # İnternet Ağ Geçidi resource "aws_internet_gateway" "ecommerce_igw" { vpc_id = aws_vpc.ecommerce_vpc.id tags = { Name = "ECommerceIGW" } } # Genel Alt Ağlar (AZ1 ve AZ2) resource "aws_subnet" "public_subnet_az1" { vpc_id = aws_vpc.ecommerce_vpc.id cidr_block = "10.0.1.0/24" availability_zone = "eu-central-1a" # Gerçek AZ'nizi belirtin map_public_ip_on_launch = true tags = { Name = "ECommercePublicSubnetAZ1" } } resource "aws_subnet" "public_subnet_az2" { vpc_id = aws_vpc.ecommerce_vpc.id cidr_block = "10.0.3.0/24" availability_zone = "eu-central-1b" # Gerçek AZ'nizi belirtin map_public_ip_on_launch = true tags = { Name = "ECommercePublicSubnetAZ2" } } # Özel Alt Ağlar (AZ1 ve AZ2) resource "aws_subnet" "private_subnet_az1" { vpc_id = aws_vpc.ecommerce_vpc.id cidr_block = "10.0.2.0/24" availability_zone = "eu-central-1a" tags = { Name = "ECommercePrivateSubnetAZ1" } } resource "aws_subnet" "private_subnet_az2" { vpc_id = aws_vpc.ecommerce_vpc.id cidr_block = "10.0.4.0/24" availability_zone = "eu-central-1b" tags = { Name = "ECommercePrivateSubnetAZ2" } } # Elastic IP'ler (NAT Gateway için) resource "aws_eip" "nat_eip_az1" { domain = "vpc" tags = { Name = "NAT_EIP_AZ1" } } resource "aws_eip" "nat_eip_az2" { domain = "vpc" tags = { Name = "NAT_EIP_AZ2" } } # NAT Gateway (Her genel alt ağa bir tane) resource "aws_nat_gateway" "nat_gateway_az1" { allocation_id = aws_eip.nat_eip_az1.id subnet_id = aws_subnet.public_subnet_az1.id tags = { Name = "ECommerceNATGatewayAZ1" } } resource "aws_nat_gateway" "nat_gateway_az2" { allocation_id = aws_eip.nat_eip_az2.id subnet_id = aws_subnet.public_subnet_az2.id tags = { Name = "ECommerceNATGatewayAZ2" } } # Yönlendirme Tabloları ve Yollar # Genel Alt Ağ Yönlendirme Tablosu resource "aws_route_table" "public_route_table" { vpc_id = aws_vpc.ecommerce_vpc.id route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.ecommerce_igw.id } tags = { Name = "ECommercePublicRT" } } # Genel Alt Ağları Yönlendirme Tablosuna Bağlama resource "aws_route_table_association" "public_rt_association_az1" { subnet_id = aws_subnet.public_subnet_az1.id route_table_id = aws_route_table.public_route_table.id } resource "aws_route_table_association" "public_rt_association_az2" { subnet_id = aws_subnet.public_subnet_az2.id route_table_id = aws_route_table.public_route_table.id } # Özel Alt Ağ Yönlendirme Tablosu AZ1 resource "aws_route_table" "private_route_table_az1" { vpc_id = aws_vpc.ecommerce_vpc.id route { cidr_block = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.nat_gateway_az1.id } tags = { Name = "ECommercePrivateRTAZ1" } } # Özel Alt Ağ Yönlendirme Tablosu AZ2 resource "aws_route_table" "private_route_table_az2" { vpc_id = aws_vpc.ecommerce_vpc.id route { cidr_block = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.nat_gateway_az2.id } tags = { Name = "ECommercePrivateRTAZ2" } } # Özel Alt Ağları Yönlendirme Tablosuna Bağlama resource "aws_route_table_association" "private_rt_association_az1" { subnet_id = aws_subnet.private_subnet_az1.id route_table_id = aws_route_table.private_route_table_az1.id } resource "aws_route_table_association" "private_rt_association_az2" { subnet_id = aws_subnet.private_subnet_az2.id route_table_id = aws_route_table.private_route_table_az2.id } - ALB Güvenlik Grubu: Gelen HTTP (80) ve HTTPS (443) trafiğine
- Ağ ACL'leri (NACL):
- Genellikle Güvenlik Grupları daha esnek olduğu için çoğu senaryoda yeterli olur. Ancak, ek bir güvenlik katmanı veya alt ağ seviyesinde net "reddetme" kuralları gerekiyorsa NACL'ler kullanılır.
- Örneğin, hassas veri tabanı alt ağlarına (özel alt ağlar) yalnızca uygulama sunucularından gelen belirli portlardaki trafiğe izin veren ve diğer her şeyi açıkça reddeden bir NACL atanabilir.
Bu tasarımla, e-ticaret uygulaması yüksek erişilebilir bir yapıya sahip olur. Web trafiği ALB üzerinden farklı AZ'lerdeki web sunucularına dağıtılır. Web sunucuları yalnızca ALB ve yöneticilerin SSH erişimine izin verir. Uygulama sunucuları, veritabanına erişirken, veritabanı sunucuları da sadece uygulama sunucularından gelen isteklere yanıt verir. Tüm hassas sunucular özel alt ağlarda bulunur ve internete yalnızca NAT Ağ Geçidi üzerinden güvenli bir şekilde erişebilirler. Bu katmanlı güvenlik ve dağıtık yapı, uygulamanın hem performanslı hem de dayanıklı olmasını sağlar.
Bulut Ortamında Ağ Performansı ve Optimizasyon İpuçları Nelerdir?
Bulut ağlarını kurmak yalnızca doğru bileşenleri bir araya getirmekle kalmaz, aynı zamanda uygulamalarınızın en iyi performansı sergilemesini sağlamak için bu ağları optimize etmek de büyük önem taşır. Ağ performansının düşük olması, kullanıcı deneyimini olumsuz etkileyebilir, iş süreçlerini yavaşlatabilir ve hatta maliyetleri artırabilir. İşte bulut ortamında ağ performansını optimize etmek için bazı temel ipuçları ve stratejiler:
1. Doğru Ağ Bant Genişliğini Seçmek
Bulut sağlayıcıları, farklı örnek türleri (VM boyutları) ve ağ arabirimleri için çeşitli ağ bant genişliği seçenekleri sunar. Uygulamanızın trafik yükünü doğru bir şekilde tahmin etmek ve buna uygun bant genişliğine sahip örnekleri seçmek kritiktir. Yetersiz bant genişliği, darboğazlara yol açarken, gereksiz yüksek bant genişliği de maliyet artışı demektir. Uygulamanızın pik zamanlardaki trafik ihtiyaçlarını belirlemek için testler yapın ve dinamik olarak ölçeklenebilen ağ arabirimlerini veya örnekleri tercih edin.
2. Gecikme Süresini (Latency) En Aza İndirmek
Ağ gecikmesi, verilerin bir noktadan diğerine ulaşması için geçen süredir ve özellikle coğrafi olarak dağıtılmış kullanıcılar veya kritik iş yükleri için önemli bir faktördür. Gecikmeyi azaltmak için şunları göz önünde bulundurun:
- Coğrafi Konum: Uygulama sunucularınızı kullanıcılarınıza veya veri kaynaklarınıza coğrafi olarak en yakın bulut bölgelerine (regions) konuşlandırın.
- Kullanılabilirlik Alanı (AZ) Seçimi: Bir bölge içindeki farklı AZ'ler arasında dahi düşük gecikme süreleri önemlidir. Uygulamanızın katmanlarını mümkün olduğunca birbirine yakın AZ'lerde tutmaya çalışın.
- Ağ Bağlantı Türleri: Şirket içi ağınızdan buluta bağlantı için VPN yerine Direct Connect (veya muadili) gibi özel ve düşük gecikmeli bağlantı hizmetlerini değerlendirin.
3. VPC Flow Logs ile Trafiği İzlemek ve Analiz Etmek
VPC Flow Logs, VPC'nizdeki ağ arabirimlerinden geçen tüm IP trafiği hakkındaki bilgileri yakalar. Bu loglar, ağ sorunlarını teşhis etmek, güvenlik açıklarını belirlemek, ağ trafiği modellerini anlamak ve ağ performansını optimize etmek için paha biçilmez bir araçtır. Flow Logs'u düzenli olarak inceleyerek, beklenmedik trafik akışlarını, aşırı bant genişliği tüketimini veya engellenen bağlantı girişimlerini tespit edebilirsiniz. Bu logları merkezi bir log yönetimi çözümüne (örn. ELK Stack, Splunk, CloudWatch Logs Insights) aktararak daha etkin analizler yapabilirsiniz.
# AWS CLI ile VPC Flow Log oluşturma komutu örneği (Pseudo Kod)
# Bu komut, belirtilen VPC'deki tüm ağ arabirimlerinden gelen trafiği CloudWatch Logs'a gönderir.
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0abcdef1234567890 \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name my-vpc-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogRole
4. Ağ Güvenliğini Optimize Etmek
Güvenlik grupları ve NACL'ler doğru yapılandırıldığında ağ performansını artırabilir. Gereksiz açık portlar veya çok geniş IP aralıklarına izin vermek, hem güvenlik risklerini artırır hem de güvenlik duvarı kurallarının işlenmesi için daha fazla kaynak tüketebilir. En az ayrıcalık prensibini (least privilege) uygulayarak, yalnızca kesinlikle gerekli olan portları ve IP adreslerini açın. Bu, güvenlik taramalarının daha hızlı çalışmasına ve ağdaki gereksiz gürültüyü azaltmaya yardımcı olur.
5. İç Ağ Trafiğini Optimize Etmek
VPC içindeki bileşenler arası trafiği (örneğin uygulama sunucusu ile veritabanı arasındaki trafik) mümkün olduğunca optimize edin. Aynı AZ içindeki kaynaklar arasında düşük gecikmeli ve yüksek bant genişliğine sahip bağlantılar kullanılır. Eğer veritabanınız ve uygulama sunucunuz farklı AZ'lerde ise, bu durum ek gecikmelere yol açabilir. Mümkünse, uygulamanızın kritik katmanlarını aynı AZ'de tutun veya veri transferlerini en aza indirecek şekilde tasarlayın.
6. Ağ Otomasyonu ve İzleme
Bulut ağları dinamik olduğu için manuel yönetim zor ve hata yapmaya açıktır. Infrastructure as Code (IaC) araçları (Terraform, CloudFormation gibi) kullanarak VPC'nizi, alt ağlarınızı, yönlendirme tablolarınızı ve güvenlik kurallarınızı otomatikleştirin. Ayrıca, ağ performansını (bant genişliği kullanımı, gecikme, paket kaybı) sürekli izlemek için bulut sağlayıcınızın izleme araçlarını (örn. CloudWatch, Azure Monitor, Google Cloud Monitoring) kullanın. Bu araçlar, anormallikleri hızla tespit etmenize ve proaktif adımlar atmanıza olanak tanır.
| Optimizasyon Alanı | Açıklama | Etki |
|---|---|---|
| Bant Genişliği Yönetimi | Uygulamanın gerçek ihtiyaçlarına göre örnek ve ağ arabirimi seçimi. | Maliyet ve performans dengesi, darboğazları önler. |
| Gecikme Azaltma | Kaynakları coğrafi ve mantıksal olarak yakın konumlandırma. | Kullanıcı deneyimi iyileşir, uygulama tepki süresi artar. |
| Trafik İzleme | VPC Flow Logs ve izleme araçlarıyla ağ trafiğini sürekli analiz etme. | Sorun giderme kolaylaşır, güvenlik açıkları tespit edilir. |
| Güvenlik Kuralları | Güvenlik Grupları ve NACL'leri en az ayrıcalık prensibiyle yapılandırma. | Güvenlik artar, gereksiz trafik işleme maliyetleri azalır. |
| Otomasyon | Altyapıyı kod olarak yönetme (IaC). | Hata oranı azalır, yönetim kolaylaşır, ölçeklenebilirlik artar. |
Bu ipuçları, bulut ağlarınızın sadece çalışmasını değil, aynı zamanda en yüksek verimlilikle ve güvenli bir şekilde çalışmasını sağlamanıza yardımcı olacaktır. Ağ performansı ve optimizasyonu, bulut mühendislerinin sürekli odaklanması gereken bir alandır.
Sonuç: Bulut Ağlarında Uzmanlaşmak Neden Hayati Önem Taşıyor?
Bulut bilişim, modern teknoloji dünyasının vazgeçilmez bir parçası haline gelmiştir. Bu serinin ikinci bölümünde, bulut mühendislerinin temel yapı taşlarından biri olan Sanal Özel Bulut (VPC) kavramını, onun hayati bileşenlerini (alt ağlar, yönlendirme tabloları, ağ geçitleri) ve en önemlisi, ağ güvenliğini sağlayan mekanizmaları (Güvenlik Grupları ve Ağ ACL'leri) detaylı bir şekilde inceledik. Gerçek dünya senaryoları ve vaka analizleriyle bu kavramları somutlaştırdık ve bulut ortamında ağ performansını optimize etme stratejilerini ele aldık.
Günümüzün dijitalleşen dünyasında, uygulamaların ve verilerin güvenli, hızlı ve kesintisiz bir şekilde akışı, bir işletmenin başarısı için kritik öneme sahiptir. Bulut ağları, bu akışın temelini oluşturur. Bulut ağlarında uzmanlaşmak, sadece altyapıyı doğru bir şekilde kurmak anlamına gelmez; aynı zamanda potansiyel güvenlik açıklarını belirleyebilmek, performans darboğazlarını giderebilmek, maliyetleri optimize edebilmek ve iş sürekliliğini sağlayabilmek demektir. Karmaşık gibi görünen bu yapıların arkasındaki mantığı kavramak, bulut mühendislerinin sadece operasyonel görevleri yerine getirmesine değil, aynı zamanda stratejik kararlar almasına ve geleceğin ağ mimarilerini tasarlamasına olanak tanır.
Bu makalede edindiğiniz bilgiler, bulut kariyerinizde size güçlü bir temel sunacaktır. Unutmayın ki bulut teknolojileri sürekli gelişiyor ve bu alandaki güncel bilgileri takip etmek, sürekli öğrenmek hayati öneme sahiptir. Bir sonraki bölümde, bulut ağlarında gelişmiş bağlantı seçenekleri ve ağ hizmetleri üzerine odaklanarak bilginizi daha da derinleştireceğiz. O zamana kadar, öğrendiklerinizi pratik ederek pekiştirmenizi tavsiye ederiz.
Sıkça Sorulan Sorular (SSS)
-
S: Güvenlik Grupları (SG) ve Ağ ACL'leri (NACL) arasındaki temel fark nedir?
C: Temel fark, uygulama seviyeleri ve durum bilgisidir. Güvenlik Grupları, örnek (instance) seviyesinde çalışan durum bilgisi olan (stateful) güvenlik duvarlarıdır ve yalnızca izin (allow) kuralları içerir. NACL'ler ise alt ağ (subnet) seviyesinde çalışan durum bilgisiz (stateless) güvenlik duvarlarıdır ve hem izin (allow) hem de reddetme (deny) kuralları tanımlanabilir. SG'ler dönen trafiğe otomatik izin verirken, NACL'lerde hem gelen hem de giden trafik için açıkça kural tanımlamanız gerekir. -
S: Özel alt ağdaki bir sunucunun internete erişmesi gerekiyorsa ne yapmalıyım?
C: Özel alt ağdaki bir sunucunun internete çıkış (outbound) erişimi için bir NAT Ağ Geçidi (NAT Gateway) veya NAT Örneği (NAT Instance) kullanmalısınız. NAT Ağ Geçidi, genellikle genel bir alt ağa konuşlandırılır ve özel alt ağın yönlendirme tablosu, internete yönelik tüm trafiği bu NAT Ağ Geçidi üzerinden yönlendirilecek şekilde yapılandırılır. Bu sayede sunucu internete çıkabilirken, internetten doğrudan gelen bağlantılardan korunur. -
S: Tek bir VPC içinde birden fazla proje veya departman için ağ segmentasyonu nasıl yapılır?
C: Tek bir VPC içinde birden fazla proje veya departman için ağ segmentasyonu yapmak amacıyla farklı alt ağlar oluşturabilir ve bu alt ağlara ayrı NACL'ler atayabilirsiniz. Ayrıca, her projenin veya departmanın kaynaklarına kendi Güvenlik Gruplarını atayarak daha granüler güvenlik kontrolleri sağlayabilirsiniz. İleri düzeyde, farklı VPC'leri birbirine bağlamak için VPC Peering veya Transit Gateway gibi hizmetler de kullanılabilir, ancak bu daha karmaşık senaryolar içindir. -
S: Bulut ağlarını izlemek için hangi araçlar kullanılabilir?
C: Bulut sağlayıcıları genellikle kendi izleme araçlarını sunar. Örneğin, AWS için CloudWatch ve VPC Flow Logs, Azure için Azure Monitor ve Network Watcher, Google Cloud için Cloud Monitoring ve VPC Flow Logs kullanılabilir. Bu araçlar, ağ trafiğini, bant genişliği kullanımını, gecikmeyi ve güvenlik olaylarını izlemek ve analiz etmek için hayati öneme sahiptir. -
S: Sanal Özel Bulut (VPC) neden önemlidir ve geleneksel bir ağdan farkı nedir?
C: VPC, bulut sağlayıcısının paylaşımlı altyapısı üzerinde oluşturulan sanal, izole bir ağdır. Önemi, diğer bulut kullanıcılarından tamamen mantıksal izolasyon sağlaması, güvenlik ve veri gizliliğini artırması ve kullanıcılara ağ topolojisi üzerinde tam kontrol sunmasıdır. Geleneksel bir ağdan farkı ise, fiziksel donanımlar yerine tamamen yazılım tanımlı (Software-Defined Networking - SDN) bileşenlerle çalışması, daha esnek, ölçeklenebilir ve otomatikleştirilebilir olmasıdır. Bu sayede altyapı yönetimi kolaylaşır ve maliyetler optimize edilebilir.