Amazon SAA-C03: Ağ Oluşturma ve Bağlanabilirlik — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

VPC Tasarımı ve CIDR Planlaması

Her VPC bir CIDR bloğu ile başlar ve oluşturma sırasında yapılan bu seçimin, peering, Transit Gateway bağlantıları ve hibrit bağlantı için ileride doğuracağı sonuçlar vardır. Birincil CIDR, /16 ile /28 arasında olmalı, RFC 1918 alanından seçilmeli ve peer bağlantısı kurmayı, bir Transit Gateway üzerinden yönlendirmeyi veya Direct Connect ya da VPN üzerinden erişmeyi planladığınız hiçbir ağ ile çakışmamalıdır. Çakışan CIDR’lar, bozuk hibrit tasarımların en yaygın nedenidir çünkü AWS, aynı adres alanını paylaşan iki ağ arasında yönlendirme yapamaz — Transit Gateway bağlantıyı kabul eder ancak yayılım (propagation) başarısız olur veya trafik sessizce kaybolur.

Bir VPC’nin adres alanı tükendiğinde, onu yeniden oluşturmanız gerekmez. En fazla dört ikincil IPv4 CIDR bloğu eklenebilir (ve daha geniş bir havuzdan ek aralıklarla birlikte varsayılan olarak toplam beş, bu sayı kota artışıyla genişletilebilir). İkincil bloklar, aynı RFC 1918 aralığından veya 10.0.0.0/8 tükendiğinde ya da operatör sınıfı NAT (carrier-grade NAT) alanına ihtiyaç duyulduğunda kullanışlı olan 100.64.0.0/10 paylaşılan adres alanından gelebilir. İkincil CIDR’lar, mevcut iş yüklerini yeniden numaralandırmadan genişleme için — EKS pod ağı, yeni bir katman (tier) gibi — yeni subnet’ler oluşturmanıza olanak tanır.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Sağlam bir tasarım, gelecekteki büyüme için bir /17 veya /18 ayırır, subnet sınırlarını Availability Zone’lar ile hizalar (AZ başına ve katman başına bir /20 yaygın bir modeldir) ve interface endpoint’ler, NAT gateway’ler ve load balancer’lar tarafından tüketilen ENI’ler için pay bırakır.

VPC, her biri tek bir AZ’ye bağlı subnet’lere bölünmüş bölgesel bir yapıdır. “Public” (genel) ve “private” (özel) arasındaki ayrım tamamen bir yönlendirme kararıdır: public bir subnet, bir Internet Gateway’i işaret eden 0.0.0.0/0 → igw-xxxx rotasına sahipken, private bir subnet’in ya varsayılan rotası yoktur ya da 0.0.0.0/0 rotası bir NAT cihazını işaret eder. Public bir subnet’teki instance’ların gelen trafiğe açık olabilmesi için ayrıca bir public veya Elastic IP’ye ihtiyacı vardır; IGW, private ve public IP arasında 1:1 NAT gerçekleştirir.

NAT Gateway’ler, NAT Instance’ları ve IPv6 Egress

Private subnet’lerden yalnızca giden (outbound-only) IPv4 internet erişimi için doğru temel bileşen NAT gateway’lerdir. Yönetilen bir NAT gateway, otomatik olarak 45–100 Gbps’ye kadar ölçeklenir, benzersiz hedef başına 55.000 eş zamanlı bağlantıyı destekler, AWS tarafından yamalanır ve kendi AZ’si içinde yüksek erişilebilirliğe sahiptir. NAT gateway’ler saatlik ve işlenen GB başına ücretlendirilir.

NAT instance’ları — kaynak/hedef kontrolü (source/destination check) devre dışı bırakılmış, kendi kendine yönetilen EC2’ler — artık eski bir yöntemdir (legacy). Tek bir instance’ın verimiyle (throughput) sınırlıdırlar, failover için script’lenmeleri gerekir ve sürekli yük altında bir darboğaz (bottleneck) haline gelirler. Yalnızca özel filtreleme gibi atipik ihtiyaçlar için uygundurlar ve bu durumda bile genellikle bir Gateway Load Balancer appliance’ı tercih edilir.

Kanonik yüksek erişilebilirlikli model, her AZ için bir NAT gateway kullanmak, her birini o AZ’nin public subnet’ine yerleştirmek ve her AZ için ayrı bir private route table oluşturarak varsayılan rotayı yerel NAT gateway’e yönlendirmektir:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

AZ’ler arasında paylaşılan tek bir NAT gateway dağıtmak iki nedenden dolayı bir tuzaktır. Birincisi, tek bir hata noktasıdır (single point of failure): bir AZ kesintisi, her private subnet’in giden (egress) trafiğini keser. İkincisi, diğer AZ’lerdeki instance’lardan gelen her paket bir AZ sınırını geçer ve NAT gateway işleme ücretinin üzerine ek olarak (şu anda her yön için $0.01/GB olan) AZ’ler arası veri transferi ücretlerine neden olur. Yüzlerce TB giden trafik (egress) yapan iş yüklerinde bu maliyet, fazladan NAT gateway’lerin maliyetini gölgede bırakır. Sık yapılan ikinci bir yanlış yapılandırma, NAT gateway’in kendisini private bir subnet’e yerleştirmektir — bu durumda IGW’ye giden bir yolu olmaz ve çalışmaz.

IPv6 için, her IPv6 adresi küresel olarak yönlendirilebilir (globally routable) olduğundan NAT ne gereklidir ne de mevcuttur. İstenmeyen gelen trafiği engellerken yalnızca giden IPv6 trafiğine izin vermek için, bir egress-only internet gateway ekleyin ve private subnet’lerden ::/0 rotasını bu gateway’e yönlendirin. Normal bir IGW çift yönlüdür ve instance’ları dış dünyaya açık hale getirir.

VPC Uç Noktaları: Ağ Geçidi ve Arayüz Karşılaştırması

VPC uç noktaları, VPC’niz ile AWS hizmetleri arasındaki trafiği AWS omurgası üzerinde tutarak interneti, NAT ağ geçitlerini ve internet ağ geçitlerini tamamen devre dışı bırakır. Temelde farklı iki uygulaması vardır ve bunları karıştırmak en yaygın mimari hatalardan biridir.

Ağ Geçidi uç noktaları yalnızca Amazon S3 ve DynamoDB için mevcuttur. Bunlar, uç noktanın kendisini hedefleyen bir rota tablosu girdisidir — bir ön ek listesidir (örneğin, us-east-1’deki S3 için pl-63a5400a). ENI, DNS değişikliği, saatlik maliyet ve güvenlik grubu yoktur (erişim, rota tablosu ve uç nokta politikası ile kontrol edilir). Rota tabanlı oldukları için yalnızca VPC içindeki kaynaklar için çalışırlar — Direct Connect üzerinden S3’e ulaşan şirket içi ağlar bunları kullanamaz.

Arayüz uç noktaları (AWS PrivateLink), alt ağlarınıza yerleştirilen özel IP’lere sahip ENI’lardır ve AZ başına saatlik artı GB başına faturalandırılır. Neredeyse diğer tüm hizmetler için — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS ve yüzlercesi daha — ve ayrıca uç nokta hizmetleri olarak yayınlanan üçüncü taraf hizmetler için çalışırlar. Arayüz uç noktaları, genel hizmet ana bilgisayar adını geçersiz kılarak uç noktanın özel IP’sine çözümleyen özel DNS‘i destekler, böylece SDK’lar ve CLI’lar kod değişikliği gerektirmez. ENI tabanlı oldukları için güvenlik grupları uygulanır.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

Maliyet mantığı önemlidir: özel bir alt ağdan genel bir AWS hizmetine giden herhangi bir trafik, varsayılan olarak yaklaşık 0,045$/GB maliyetle bir NAT ağ geçidinden geçer. S3’e günde 1 TB veri gönderen konteyner tabanlı bir iş yükü için, bir NAT ağ geçidi yolu ile bir ağ geçidi uç noktası arasındaki fark ayda binlerce dolar olabilir. Arayüz uç noktaları, büyük ölçekte NAT çıkışının yerini aldıklarında veya uyumluluk gereksinimleri internet yönlendirmesini yasakladığında kullanışlıdır.

Tuzaklar: bir ağ geçidi uç noktasına güvenlik grubu eklemek (ENI’ları yoktur); bir ağ geçidi uç noktasının şirket içinden erişilebilir olduğunu varsaymak (değildir — bir arayüz uç noktası veya EC2 → S3 ağ geçidi uç noktası → ayrı DX yolu hibrit modelini kullanın); bir arayüz uç noktasında özel DNS’i devre dışı bırakıp değiştirilmemiş SDK çağrılarının çalışmasını beklemek (bu çağrılar internet üzerinden genel uç noktaya ulaşır ve uç noktanın amacını tamamen ortadan kaldırır); bir ağ geçidi uç noktası oluşturup özel alt ağın rota tablosunu ilişkilendirmeyi unutmak (trafik sessizce genel yolu kullanmaya devam eder); ağ geçidi uç noktası olmayan bir hizmet için (örneğin KMS) ağ geçidi uç noktası kullanmaya çalışmak — yalnızca S3 ve DynamoDB bu özelliğe sahiptir.

VPC’ler Arası Bağlantı: Eşleme ve Transit Gateway Karşılaştırması

VPC eşlemesi, aynı veya farklı hesapta, aynı veya farklı Bölgede (Region) bulunan iki VPC arasında bire bir, geçişsiz (non-transitive) bir Katman 3 bağlantısıdır. Trafik AWS omurgası üzerinden geçer, bant genişliği darboğazı yoktur ve saatlik bir ücret alınmaz — yalnızca AZ’ler arası veya Bölgeler arası veri transferi için ödeme yaparsınız. Eşlemeyi sınırlayan iki özellik vardır: (1) geçişsizdir — eğer A, B ile ve B, C ile eşleşirse, A, B üzerinden C’ye ulaşamaz; ve (2) CIDR aralıkları çakışmamalıdır. N adet VPC’yi tam ağ (full-mesh) olarak bağlamak, her birinin her iki yönünde rota tablosu düzenlemeleriyle birlikte N(N-1)/2 eşleme gerektirir; 30 VPC için bu 435 eşleme demektir. Eşlemenin yüzlerce VPC’ye ölçeklenmesini beklemek bir tuzaktır.

Transit Gateway (TGW), bölgesel bir bulut yönlendiricisidir. Her bir VPC, VPN veya Direct Connect ağ geçidi bir eklentidir (attachment) ve TGW rota tabloları hangi eklentinin hangi ön eke ulaşabileceğini kontrol eder. Bu, O(n²) karmaşıklığındaki bir tam ağı (mesh), O(n) karmaşıklığındaki eklentilere dönüştürür ve bir güvenlik VPC’sinin tüm VPC’ler arası trafiği denetleyen güvenlik duvarlarına ev sahipliği yaptığı merkez-uç (hub-and-spoke) topolojilerini mümkün kılar. TGW, geçişli yönlendirmeyi destekler, VPN ve Direct Connect ağ geçidi ilişkilendirmelerini yerel olarak sonlandırır ve Resource Access Manager aracılığıyla AWS Organizations genelinde paylaşılabilir, böylece merkezi ağ ekipleri yönlendirmeyi kontrol ederken iş yükü hesapları VPC’lere sahip olur. TGW, eklenti başına saatlik bir ücret ve işlenen GB başına yaklaşık 0,02$ maliyet ekler.

Bölgeler arası bağlantı için, TGW eşlemesi, farklı Bölgelerdeki TGW’leri AWS küresel omurgası üzerinden şifreli trafikle birbirine bağlar — Bölge başına bir TGW, tam ağ (mesh) veya merkez (hub) tasarımında eşleştirilir. Bu, Bölgeler arası VPC eşlemesinin yeniden ortaya çıkardığı N-kare problemini ortadan kaldırır.

Rota tablosu hijyeni burada sessiz katildir. Bir eşleme bağlantısı veya bir TGW eklentisi oluşturmak, her iki VPC’nin alt ağ rota tablolarına pcx- veya tgw- hedefini gösteren açık CIDR rotaları eklenene ve güvenlik grupları trafiğe izin verene kadar hiçbir işe yaramaz. Sessiz bağlantı hataları neredeyse her zaman eksik bir rotadan veya yanlış kaynak CIDR’ını referans alan bir güvenlik grubundaki örtük bir reddetme kuralından kaynaklanır.

Hibrit Bağlantı: Site-to-Site VPN ve Direct Connect Karşılaştırması

Site-to-Site VPN ve Direct Connect arasındaki seçim, bir yanda dağıtım hızı ve yerleşik şifreleme, diğer yanda ise tutarlı düşük gecikme süresi, adanmış bant genişliği ve öngörülebilir verim arasında bir denge kurma meselesidir.

Site-to-Site VPN, bir müşteri ağ geçidi (şirket içi yönlendirici) ile bir Virtual Private Gateway veya bir Transit Gateway arasında iki IPsec tüneli kurar. Her tünelin kapasitesi yaklaşık 1.25 Gbps ile sınırlıdır. Trafik ağ katmanında şifrelenir ve TLS ile birleştirildiğinde ağ ve oturum katmanlarındaki şifreleme gereksinimlerini karşılar. Genel internet üzerinden geçtiği için gecikme ve titreşim (jitter) değişkendir, ancak dakikalar içinde kullanılabilir ve saat başına maliyeti sent düzeyindedir. Bağlantıya hemen ihtiyaç duyulduğunda, bant genişliği mütevazı olduğunda veya bir yedek yol olarak kullanılır.

Direct Connect (DX), şirket içi bir yönlendiriciden bir AWS Direct Connect konumuna adanmış bir fiber bağlantı (1, 10 veya 100 Gbps) sağlar. Genel interneti atlayarak tutarlı gecikme süresi ve daha yüksek verim sağlar. DX giden veri (egress) fiyatlandırması, internet giden veri fiyatlandırmasından önemli ölçüde daha düşüktür; bu durum günde yüzlerce gigabayt veri taşırken önem kazanır. Sağlama işlemi haftalar sürer — çapraz bağlantılar, LOA’lar, BGP yapılandırması.

Burada iki yaygın tuzak öne çıkıyor. Birincisi, Direct Connect tek başına trafiği şifrelemez. Özel bir devre, kriptografik olarak korunan bir kanal değildir. DX üzerinden bir şifreleme gereksinimini karşılamak için, üzerine bir Site-to-Site VPN katmanı ekleyin veya desteklenen adanmış portlarda Katman-2 şifrelemesi için MACsec kullanın. İkincisi, ham bir DX bağlantısı kendi başına birden fazla VPC’ye yönlendirme yapmaz. Bir özel VIF, tek bir VPC’ye bağlı tek bir Virtual Private Gateway’e bağlanır. Özellikle hesaplar ve Bölgeler (Region) arasında birçok VPC’ye ulaşmak için, bir transit VIF aracılığıyla bir Transit Gateway ile ilişkilendirilmiş bir Direct Connect Gateway kullanın ve her VPC’yi TGW’ye bağlayın:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Standart üretim modeli, iki DX konumunda ayrı müşteri yönlendiricilerinde sonlanan iki DX bağlantısı kullanır ve Site-to-Site VPN’i otomatik BGP yük devretme (failover) olarak konumlandırır — BGP AS-path prepending veya MED, çalışır durumdayken trafiği DX’e yönlendirir; eğer başarısız olursa, BGP DX rotalarını geri çeker ve VPN devreye girer.

Yük Dengeleyiciler: ALB, NLB ve GWLB

ALB, Katman 7’de çalışır ve HTTP semantiğini anlar — ana bilgisayar ve yol tabanlı yönlendirme, WebSocket’ler, yönlendirmeler, çerez tabanlı yapışkan oturumlar. HTTP olmayan her şey için yanlış bir araçtır: MQTT, ham TCP, UDP üzerinden syslog, SMTP. ALB, zamanla değişen IP’lerle DNS tabanlı adresleme kullanır; ona Elastik IP’ler atanamaz. İstemciler hedef IP’leri beyaz listeye aldığında, tek başına bir ALB uygun değildir — EIP’li NLB kullanın veya ALB’nin önüne Global Accelerator’ın iki statik anycast IP’sini koyun. “ALB DNS’ini bir kez çözüp IP’leri güvenlik duvarı kurallarına sabitlemek” bir tuzaktır: AWS bunları haber vermeksizin değiştirir.

NLB, Katman 4’te çalışır ve saniyede milyonlarca akışa ölçeklenir. Varsayılan olarak gerçek istemci kaynak IP’sini korur (hedefler gerçek istemciyi görür), AZ başına statik bir Elastik IP atamayı destekler ve yüksek verimli TCP/UDP iş yüklerini yönetir. Tarihsel olarak NLB, yük dengeleyicinin kendisinde güvenlik gruplarını desteklemiyordu — istemci CIDR’larının doğrudan hedefin SG’sinde izinlendirilmesi gerekiyordu. AWS, 2023’te isteğe bağlı NLB güvenlik grupları ekledi, ancak birçok tasarım hala klasik davranışı varsayar.

Standart halka açık model şöyledir:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Arka uçta kaynak olarak bir CIDR yerine ALB’nin güvenlik grubuna referans vermek, en az ayrıcalık ilkesine uygun modeldir ve ALB’nin ENI’lerinden kaynaklanan sağlık kontrolü trafiğini otomatik olarak kapsar. ALB’nin kendisi en az iki AZ’de genel alt ağlarda bulunur (IGW’ye giden rotalar); hedefler ise özel alt ağlarda bulunur. İnternete yönelik bir ALB’yi özel bir alt ağa yerleştirmek klasik bir yanlış yapılandırmadır — hedef kaydı başarılı olur ancak istemciler ona ulaşamaz.

Gateway Load Balancer (GWLB), üçüncü taraf sanal cihazların (güvenlik duvarları, IDS/IPS, DPI) şeffaf bir şekilde araya eklenmesi için özel olarak tasarlanmıştır. Katman 3’te çalışır ve GENEVE kapsüllemesini kullanarak UDP 6081 üzerinde tüm IP protokollerini iletir. Trafik, GWLB’ye bir GWLB uç noktası (GWLBe) aracılığıyla ulaşır — bu, bir alt ağda bulunan ve rota tablolarında hedef olarak görünen bir arayüz uç noktasıdır:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Uç nokta, paketleri PrivateLink üzerinden GWLB’ye iletir. GWLB, bir akışın her iki yönünün de aynı cihaza isabet etmesi için akış yapışkanlığı kullanarak cihaz filosu arasında yük dengelemesi yapar. Hub-and-spoke (merkez-uç) denetim tasarımında, uç (spoke) VPC’ler, rota tabloları doğu-batı trafiğini hedef VPC’lere ulaşmadan önce denetim VPC’si (GWLB ve cihazları içeren) üzerinden geçmeye zorlayan bir TGW’ye bağlanır. Gelen trafik denetimi (Ingress inspection), IGW’den web katmanına giden trafiği önce GWLBe üzerinden yönlendiren uç (edge) rota tablolarını kullanır:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Bu, merkezi, hesaplar arası denetim için doğru yanıttır — EC2 ile kendi çözümünüzü geliştirmek, özel rota tablosu hileleri ve yük devretme betikleri kullanmak, GWLB’nin yerel olarak sağladığı şeyi yeniden icat etmektir.

Tüketiciden Sağlayıcıya Hizmetler için PrivateLink

PrivateLink, AWS hizmetleri için arayüz uç noktalarını (interface endpoint) desteklemenin ötesinde, üçüncü taraflar veya diğer AWS hesapları tarafından yayınlanan hizmetlere özel bağlantı sağlar. Sağlayıcı, hizmetini bir NLB’nin arkasına yerleştirir ve bir VPC uç nokta hizmeti (VPC endpoint service) oluşturur. Tüketiciler, kendi VPC’lerinde bu hizmeti hedefleyen arayüz uç noktaları (interface endpoint) oluşturur.

Kritik yönlülük kuralı: bağlantı her zaman tüketiciden sağlayıcıya doğru başlatılır. Sağlayıcı, tüketicinin VPC’sine doğru bağlantı başlatamaz. Trafik asla internete çıkmaz, yalnızca belirli hedef hizmete ulaşılabilir (peering’de olduğu gibi sağlayıcının tüm VPC’sine değil) ve her iki tarafta yalnızca uç nokta IP’leri göründüğü için CIDR çakışması sorunları ortaya çıkmaz. Bu, tüketici VPC’sinde IGW, VPN veya Direct Connect bulunmayan bir SaaS veya satıcı veritabanı erişim senaryosu için standart yanıttır. VPC peering, CIDR aralıklarının tamamını ifşa eder ve çakışmayan IP’ler gerektirir; bir TGW bağlantısı (attachment) geniş kapsamlı yönlendirme yapar; internet üzerinden sunulan bir genel API özel değildir.

Global Accelerator ve Route 53

AWS Global Accelerator, dünya çapındaki AWS edge konumlarından (edge location) anons edilen iki adet statik anycast IPv4 adresi atar. İstemci trafiği en yakın edge konumuna girer ve en yakın sağlıklı bölgesel uç noktaya (ALB, NLB, EIP veya EC2) ulaşmak için AWS omurgasını (backbone) kullanır. Bu, aynı anda iki sorunu çözer: ALB’lerin önünde statik IP’ler (beyaz listeye ekleme (whitelisting) açığını kapatır) ve genel interneti baypas ederek küresel olarak dağıtılmış kullanıcılar için gecikme (latency) ve sapmayı (jitter) azaltır. CloudFront’un (içeriği önbelleğe alan) uygulanamadığı durumlarda, önbelleğe alınamayan TCP/UDP trafiğini kaynaklara (origin) doğru hızlandırır.

Route 53 farklı bir sorunu çözer — DNS seviyesinde trafik yönlendirme. Global Accelerator veri düzlemini (data plane) doğrudan etkiler; Route 53 ise yalnızca DNS çözümlemesini etkiler, bu işlemden sonra TCP bağlantısı çözümlenen IP’nin bulunduğu yere gider. Bu ikisi sıklıkla birlikte kullanılır: bir Route 53 alias kaydı, bölgesel ALB’lerin önünde duran bir Global Accelerator’ı işaret eder.

Route 53 yönlendirme politikaları:

Gecikme (latency) ve coğrafi konum (geolocation) sıklıkla karıştırılır: gecikme, kullanıcı tarafından algılanan RTT’yi en aza indirir; coğrafi konum ise gecikmeden bağımsız olarak veri yerleşikliğini (data residency) zorunlu kılar. Çok Bölgeli yük devretme, birincil kaynak üzerinde sağlık kontrolleri gerektirir. Alias kayıtları AWS’e özgüdür, sorgu ücreti olmadan doğrudan ALB, NLB, CloudFront, S3 web sitesi ve API Gateway uç noktalarına çözümlenir ve — CNAME’lerin aksine — zone apex’te (alan adının kökünde) çalışır.

Route 53 Resolver, bir VPC içindeki DNS sorgularını .2 adresi (VPC CIDR tabanı + 2) aracılığıyla yanıtlar. Hibrit DNS için, gelen uç noktalar (inbound endpoint) şirket içi (on-premises) çözümleyicilerin AWS’teki özel barındırılan alanları (private hosted zone) sorgulamasına olanak tanır; yönlendirme kurallarına sahip giden uç noktalar (outbound endpoint) ise VPC kaynaklarının şirket içi adları çözümlemesini sağlar. Bunlar olmadan, EC2 örnekleri corp.internal adresini çözümleyemez ve şirket içi sunucular db.prod.internal adresini çözümleyemez — bu, yalnızca uygulamalar ortamlar arası sorgulamalara başladığında ortaya çıkan gizli bir sorundur. Arayüz uç noktaları, SDK çağrılarının uç nokta ENI’sine ulaşması için Özel DNS’i Etkinleştir (Enable Private DNS) seçeneğini gerektirir; bu olmadan, çağrılar yine de internet üzerinden genel uç noktaya ulaşır ve bu da asıl amacı boşa çıkarır.

Güvenlik Grupları, NACL’ler ve En Az Ayrıcalık İlkesi

Güvenlik grupları (Security group) durum bilgili (stateful) olup — geri dönüş trafiğine otomatik olarak izin verilir — ve ENI seviyesinde hareket eder. NACL’ler durum bilgisizdir (stateless) ve alt ağ (subnet) sınırında hareket eder. Bir NACL’deki herhangi bir TCP kuralı, açıkça bir gelen ve bir giden kuralı gerektirir; istemciler geçici (ephemeral) aralıktan bir kaynak bağlantı noktası seçtiği için, geri dönüş yönü kuralı 1024–65535 numaralı bağlantı noktalarına izin vermelidir (Linux varsayılan olarak 32768–60999 kullanır; daha geniş aralık Windows ve diğer yığınları kapsar). Bu geçici geri dönüş kuralını unutmak, SYN işlemini tamamlayan ancak yanıtta takılı kalan bağlantıların klasik bir nedenidir.

Katmanlar arasında en az ayrıcalık (least privilege) ilkesi için, güvenlik grubu kuralları CIDR’lar yerine diğer güvenlik grubu kimliklerini (ID) referans almalıdır. Bu, Auto Scaling ile birlikte ölçeklenir ve kırılgan IP beyaz listelerinden kaçınmayı sağlar:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACL’ler, güvenlik gruplarının yerine geçmez; daha çok kaba bir etki alanı (blast radius) kontrol mekanizmasıdır. Güvenlik grubu değişiklikleri yapılmadan ‘derinlemesine savunma (defense in depth)’ amacıyla NACL’leri sıkılaştırmak, durum bilgisi olmayan geri dönüş trafiği sessizce düşürüldüğü için bir NAT ağ geçidi üzerinden yapılan yum/apt güncellemeleri gibi giden yönde başlatılan akışları yaygın olarak bozar. Ulaşılabilirliği nihai olarak rota tabloları (route table) belirler: izin veren bir güvenlik grubu bile, rota tablosunda hedef için bir giriş yoksa trafiği iletemez ve tersine, bir ağ geçidi uç noktası (gateway endpoint) yalnızca, S3 ön ek listesi (prefix list) rotası iş yükünü barındıran alt ağların rota tablolarına gerçekten yüklendiğinde etkilidir.

Karar Referansı

← Veri Aktarımı ve Migrasyon · Tüm alanlar · İçerik Dağıtımı →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →