AWS VPC Peering Bağlantısı Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

İki farklı AWS VPC’yi birbirine bağlamak gerektiğinde, çoğu ekip hemen Transit Gateway’e atlıyor. Ama duruma göre VPC Peering çok daha sade, ucuz ve yönetimi kolay bir çözüm olabiliyor. Özellikle iki ya da üç VPC arasında düşük gecikmeli, doğrudan bağlantı kurmanız gerekiyorsa, Peering tam olarak işinize yarıyor. Bu yazıda gerçek bir senaryo üzerinden VPC Peering bağlantısını baştan sona kuracağız, route table ayarlarını yapacağız, güvenlik gruplarını düzenleyeceğiz ve sık karşılaşılan sorunları çözeceğiz.

VPC Peering Nedir ve Ne Zaman Kullanılır

VPC Peering, iki VPC arasındaki trafiğin AWS omurga ağı üzerinden, internet üzerinden geçmeden iletilmesini sağlayan bir ağ bağlantısıdır. Bağlantı kurulduktan sonra iki VPC sanki aynı ağ içindeymiş gibi davranır; ancak bazı sınırlamalar vardır.

Kullanım Senaryoları:

  • Geliştirme ve Production ortamlarının belirli servisleri paylaşması (örneğin ortak bir logging VPC’si)
  • Farklı AWS hesapları arasında servis paylaşımı (Cross-Account Peering)
  • Farklı region’lardaki VPC’lerin birbirine bağlanması (Inter-Region Peering)
  • Küçük ve orta ölçekli mimarilerde maliyet optimizasyonu

Ne Zaman Kullanmamalısınız:

  • İkiden fazla VPC arasında tam bağlantı gerekiyorsa (Transit Gateway daha mantıklı, çünkü Peering’de geçişli yönlendirme yok)
  • Örtüşen CIDR bloklarınız varsa (bu durumda Peering hiç çalışmaz)
  • Merkezi bir hub-and-spoke mimarisi kuruyorsanız

Geçişli yönlendirme meselesini baştan anlamak önemli. VPC-A ile VPC-B arasında Peering varsa, VPC-B ile VPC-C arasında Peering varsa, VPC-A VPC-C’ye doğrudan ulaşamaz. Bunun için ayrı bir A-C Peering bağlantısı gerekir ya da Transit Gateway devreye alınır.

Senaryo: İki Farklı Ortamı Bağlamak

Bu yazıda şu senaryoyu ele alacağız: Şirketin Production VPC’si (10.0.0.0/16) ile ayrı bir hesapta çalışan Shared Services VPC’si (172.16.0.0/16) arasında bağlantı kuracağız. Shared Services VPC’sinde merkezi bir monitoring sunucusu ve dahili bir DNS servisi çalışıyor. Production instance’larının bu servislere erişmesi gerekiyor.

  • Production VPC: CIDR 10.0.0.0/16, Hesap ID: 111122223333, Region: eu-west-1
  • Shared Services VPC: CIDR 172.16.0.0/16, Hesap ID: 444455556666, Region: eu-west-1

Ön Koşulların Kontrolü

İlk adım olarak CIDR bloklarının çakışmadığını doğrulayalım. Bu basit bir kontrol gibi görünse de özellikle büyük organizasyonlarda bunu atlamak ciddi sorunlara yol açabiliyor.

# Production hesabında VPC bilgilerini çekelim
aws ec2 describe-vpcs 
  --filters "Name=tag:Name,Values=production-vpc" 
  --query 'Vpcs[*].{VpcId:VpcId,CidrBlock:CidrBlock,State:State}' 
  --output table 
  --profile production

# Shared Services hesabında VPC bilgilerini çekelim
aws ec2 describe-vpcs 
  --filters "Name=tag:Name,Values=shared-services-vpc" 
  --query 'Vpcs[*].{VpcId:VpcId,CidrBlock:CidrBlock,State:State}' 
  --output table 
  --profile shared-services

VPC ID’lerini not alın, ilerleyen adımlarda kullanacağız. Örneğimizde:

  • Production VPC ID: vpc-0abc123def456
  • Shared Services VPC ID: vpc-0xyz789ghi012

Peering Bağlantısı Oluşturma

Peering İsteği Gönderme (Requester Taraf)

Peering isteğini Production hesabından Shared Services hesabına göndereceğiz.

# Production hesabından Peering isteği oluştur
aws ec2 create-vpc-peering-connection 
  --vpc-id vpc-0abc123def456 
  --peer-vpc-id vpc-0xyz789ghi012 
  --peer-owner-id 444455556666 
  --peer-region eu-west-1 
  --tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=prod-to-shared-services},{Key=Environment,Value=production}]' 
  --profile production

Bu komut başarılı olursa bir Peering Connection ID döndürür. Örneğin: pcx-0a1b2c3d4e5f6. Bu ID’yi mutlaka bir yere not edin.

Peering isteğinin durumunu kontrol etmek için:

aws ec2 describe-vpc-peering-connections 
  --filters "Name=status-code,Values=pending-acceptance" 
  --query 'VpcPeeringConnections[*].{Id:VpcPeeringConnectionId,Status:Status.Code,Requester:RequesterVpcInfo.CidrBlock,Accepter:AccepterVpcInfo.CidrBlock}' 
  --output table 
  --profile shared-services

Peering İsteğini Kabul Etme (Accepter Taraf)

Shared Services hesabına geçip isteği kabul ediyoruz.

# Shared Services hesabından isteği kabul et
aws ec2 accept-vpc-peering-connection 
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f6 
  --profile shared-services

# Bağlantının aktif olduğunu doğrula
aws ec2 describe-vpc-peering-connections 
  --vpc-peering-connection-ids pcx-0a1b2c3d4e5f6 
  --query 'VpcPeeringConnections[*].Status' 
  --profile shared-services

Status “active” olarak dönmesi gerekiyor. “pending-acceptance” durumunda kalıyorsa Shared Services hesabında kabul işlemini yapmadınız demektir.

Route Table Yapılandırması

Peering bağlantısı aktif olsa bile trafik akmaz. Her iki tarafta da route table’lara uygun rotaları eklemeniz gerekiyor. Bu adımı atlayan pek çok mühendisle karşılaştım; “Peering kurdum ama ping atmıyor” diye geliyorlar.

Production Tarafında Route Ekleme

# Önce Production VPC'nin route table ID'sini bulalım
aws ec2 describe-route-tables 
  --filters "Name=vpc-id,Values=vpc-0abc123def456" 
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Subnet:Associations[0].SubnetId}' 
  --output table 
  --profile production

# Production route table'a Shared Services CIDR için rota ekle
aws ec2 create-route 
  --route-table-id rtb-0prod123456 
  --destination-cidr-block 172.16.0.0/16 
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f6 
  --profile production

Eğer birden fazla subnet’iniz varsa ve her birinin farklı bir route table’ı varsa, tüm ilgili route table’lara bu rotayı eklemeniz gerekiyor. Bu noktada şunu tavsiye ederim: Hangi subnet’lerin Peering üzerinden trafiğe ihtiyaç duyduğunu belirleyin ve sadece onlara rota ekleyin. Her şeyi açmak hem güvenlik hem de yönetim açısından sıkıntı yaratır.

Shared Services Tarafında Route Ekleme

# Shared Services route table'a Production CIDR için rota ekle
aws ec2 create-route 
  --route-table-id rtb-0shared789012 
  --destination-cidr-block 10.0.0.0/16 
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f6 
  --profile shared-services

Rotaların başarıyla eklendiğini doğrulayalım:

# Production route table'ı kontrol et
aws ec2 describe-route-tables 
  --route-table-ids rtb-0prod123456 
  --query 'RouteTables[*].Routes[?DestinationCidrBlock==`172.16.0.0/16`]' 
  --profile production

Güvenlik Grubu Yapılandırması

Route table ayarları tamamlandıktan sonra güvenlik gruplarını düzenlememiz gerekiyor. AWS güvenlik gruplarında kaynak olarak başka bir VPC’nin CIDR bloğunu kullanabilirsiniz; bu yöntem en yaygın kullanılan yaklaşımdır.

# Production monitoring sunucusunun güvenlik grubunu bul
aws ec2 describe-security-groups 
  --filters "Name=group-name,Values=monitoring-server-sg" 
  --query 'SecurityGroups[*].{GroupId:GroupId,GroupName:GroupName}' 
  --profile shared-services

# Production VPC'den gelen Prometheus scrape trafiğine izin ver (9090 portu)
aws ec2 authorize-security-group-ingress 
  --group-id sg-0shared456789 
  --protocol tcp 
  --port 9090 
  --cidr 10.0.0.0/16 
  --profile shared-services

# DNS servisi için UDP 53'e izin ver
aws ec2 authorize-security-group-ingress 
  --group-id sg-0shared456789 
  --protocol udp 
  --port 53 
  --cidr 10.0.0.0/16 
  --profile shared-services

Önemli Not: Güvenlik gruplarını konfigüre ederken en az ayrıcalık prensibini uygulayın. Tüm CIDR’ı açmak yerine mümkünse belirli subnet CIDR’larını kullanın. Örneğin monitoring erişimi sadece Production’ın application subnet’lerinden gelecekse 10.0.1.0/24 gibi daha dar bir CIDR kullanın.

DNS Çözümleme Ayarları

Cross-account Peering’de sık atlanan bir adım daha var: DNS çözümleme. Varsayılan olarak, Peering bağlantısı üzerinden özel DNS adlarını çözümleyemezsiniz. Bu özelliği etkinleştirmek için:

# Production tarafında DNS çözümlemeyi etkinleştir
aws ec2 modify-vpc-peering-connection-options 
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f6 
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true 
  --profile production

# Shared Services tarafında DNS çözümlemeyi etkinleştir
aws ec2 modify-vpc-peering-connection-options 
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f6 
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true 
  --profile shared-services

Bu adımı yapmadan production instance’larınız shared services’in özel DNS adlarını çözemez ve IP adresini hard-code etmek zorunda kalırsınız. Bu da bakımı zorlaştırır.

Bağlantıyı Test Etme

Her şeyi ayarladıktan sonra sıra bağlantıyı test etmeye geliyor. Bunun için production VPC’sindeki bir instance’a bağlanıp shared services tarafına ulaşmayı deniyoruz.

# Production instance'ına SSM Session Manager ile bağlan
aws ssm start-session 
  --target i-0production12345 
  --profile production

# Bağlandıktan sonra temel testleri yap
# Shared services monitoring sunucusuna ping
ping 172.16.10.5

# Prometheus endpoint'ini test et
curl -s http://172.16.10.5:9090/api/v1/status/config | head -20

# DNS çözümlemeyi test et
nslookup monitoring.internal.example.com

# traceroute ile yolu doğrula (AWS omurga ağı üzerinden gitmeli)
traceroute 172.16.10.5

Traceroute çıktısında tek hop görmeniz normal; AWS ağ altyapısı genellikle ara hop’ları gizler. Önemli olan hedef IP’ye erişebilmenizdir.

Terraform ile Peering Yönetimi

Büyük ortamlarda AWS CLI ile manuel yapılandırma yerine Infrastructure as Code kullanmak çok daha sağlıklı. İşte Terraform ile aynı yapıyı kurmak için temel bir örnek:

# Production hesabı için provider
provider "aws" {
  alias   = "production"
  region  = "eu-west-1"
  profile = "production"
}

# Shared Services hesabı için provider
provider "aws" {
  alias   = "shared_services"
  region  = "eu-west-1"
  profile = "shared-services"
}

# Peering isteği - Production tarafından
resource "aws_vpc_peering_connection" "prod_to_shared" {
  provider    = aws.production
  vpc_id      = "vpc-0abc123def456"
  peer_vpc_id = "vpc-0xyz789ghi012"
  peer_owner_id = "444455556666"
  peer_region = "eu-west-1"
  auto_accept = false

  tags = {
    Name        = "prod-to-shared-services"
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# Peering kabulü - Shared Services tarafından
resource "aws_vpc_peering_connection_accepter" "shared_accept" {
  provider                  = aws.shared_services
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
  auto_accept               = true

  tags = {
    Name = "prod-to-shared-services-accepter"
  }
}

# Production route table'a rota ekle
resource "aws_route" "prod_to_shared" {
  provider                  = aws.production
  route_table_id            = "rtb-0prod123456"
  destination_cidr_block    = "172.16.0.0/16"
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

# Shared Services route table'a rota ekle
resource "aws_route" "shared_to_prod" {
  provider                  = aws.shared_services
  route_table_id            = "rtb-0shared789012"
  destination_cidr_block    = "10.0.0.0/16"
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

Bu Terraform kodu ile hem peering oluşturuluyor hem kabul ediliyor hem de route’lar otomatik ekleniyor. terraform plan ile değişiklikleri önce gözden geçirmeyi unutmayın.

Sık Karşılaşılan Sorunlar ve Çözümleri

Peering Aktif Ama Trafik Geçmiyor

Bu durumun yüzde sekseninde route table’a rota eklenmemiştir. Hemen kontrol edin:

# Route table'daki rotaları listele
aws ec2 describe-route-tables 
  --route-table-ids rtb-0prod123456 
  --query 'RouteTables[0].Routes[*].{Dest:DestinationCidrBlock,Target:VpcPeeringConnectionId,State:State}' 
  --output table 
  --profile production

Rota varsa ama “blackhole” durumundaysa, Peering bağlantısı silinmiş veya hatalı durumda demektir.

CIDR Çakışması Sorunu

# Her iki VPC'nin CIDR bloklarını karşılaştır
PROD_CIDR=$(aws ec2 describe-vpcs --vpc-ids vpc-0abc123def456 
  --query 'Vpcs[0].CidrBlock' --output text --profile production)
SHARED_CIDR=$(aws ec2 describe-vpcs --vpc-ids vpc-0xyz789ghi012 
  --query 'Vpcs[0].CidrBlock' --output text --profile shared-services)

echo "Production CIDR: $PROD_CIDR"
echo "Shared Services CIDR: $SHARED_CIDR"

Eğer CIDR’lar çakışıyorsa VPC Peering kullanmanız mümkün değil. Bu durumda NAT ya da PrivateLink gibi alternatifleri değerlendirmeniz gerekiyor.

Security Group Kaynaklı Erişim Engeli

# VPC Flow Logs'u etkinleştirip RED trafiği izleyin
aws ec2 create-flow-logs 
  --resource-type VPC 
  --resource-ids vpc-0abc123def456 
  --traffic-type REJECT 
  --log-destination-type cloud-watch-logs 
  --log-group-name /aws/vpc/flowlogs/production 
  --deliver-logs-permission-arn arn:aws:iam::111122223333:role/VPCFlowLogsRole 
  --profile production

Flow Logs’ta REJECT gören trafik varsa, güvenlik grubu veya Network ACL engelliyor demektir. Hangi portun engellendiğini Flow Logs’tan görebilirsiniz.

Peering Bağlantısını İzleme

Üretim ortamında Peering bağlantısının sağlığını takip etmek önemli. CloudWatch ile basit bir alarm kurabilirsiniz:

# Peering bağlantısını CloudWatch'ta izle
aws cloudwatch put-metric-alarm 
  --alarm-name "VPC-Peering-Status-Check" 
  --alarm-description "VPC Peering connection status check" 
  --namespace "AWS/VPC" 
  --metric-name "StatusCheckFailed" 
  --dimensions Name=VpcPeeringConnectionId,Value=pcx-0a1b2c3d4e5f6 
  --statistic Average 
  --period 300 
  --threshold 1 
  --comparison-operator GreaterThanOrEqualToThreshold 
  --evaluation-periods 2 
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:ops-alerts 
  --profile production

Ayrıca AWS Config ile Peering bağlantılarının konfigürasyon değişikliklerini takip edebilirsiniz. Birisi yanlışlıkla route siliyor ya da güvenlik grubunu değiştiriyorsa Config timeline’ı size bunu gösterir.

Maliyet Değerlendirmesi

VPC Peering maliyetinin iki bileşeni var:

  • Aynı Region, Aynı AZ: İki instance aynı Availability Zone’daysa Peering üzerindeki trafik ücretsizdir.
  • Aynı Region, Farklı AZ: Veri transferi başına 0.01 USD/GB ödenir.
  • Farklı Region (Inter-Region Peering): Kaynak region’dan çıkış ve hedef region’a giriş ücretleri uygulanır, bu da toplam yaklaşık 0.02-0.09 USD/GB arasında değişir.

Transit Gateway ile karşılaştırıldığında küçük trafik hacimlerinde Peering genellikle daha ucuzdur. Transit Gateway saatlik işleme ücreti alır; Peering almaz. Ama on’larca VPC arasında bağlantı gerektiren büyük ortamlarda Transit Gateway’in yönetim kolaylığı maliyet farkını telafi eder.

İyi Uygulama Önerileri

  • Naming Convention: Peering bağlantılarını kaynak-hedef şeklinde adlandırın (prod-to-shared, dev-to-staging gibi). Birkaç ay sonra hangi bağlantının ne işe yaradığını bulmak zorlaşabilir.
  • Tagging: Tüm Peering bağlantılarına tutarlı tag’ler ekleyin. Owner, CostCenter, Environment tag’leri minimum olmalı.
  • Least Privilege Route Policy: Route table’lara mümkün olan en dar CIDR bloklarıyla rota ekleyin. Tüm VPC CIDR’ı yerine sadece erişmesi gereken subnet CIDR’ını kullanın.
  • Düzenli Denetim: Kullanılmayan Peering bağlantılarını temizleyin. “Bir gün lazım olur” diye tutulan bağlantılar hem güvenlik açığı yaratır hem de karışıklığa yol açar.
  • Flow Logs: Peering üzerinden geçen trafiği izlemek için VPC Flow Logs’u her zaman etkin tutun. Anomali tespiti ve troubleshooting için vazgeçilmez.
  • Değişiklik Yönetimi: Peering değişikliklerini her zaman IaC ile yapın ve change management sürecinizden geçirin. Manuel değişiklikler izlenmesi zor drift’e yol açar.

Sonuç

VPC Peering, doğru senaryoda kullanıldığında basit, güvenli ve maliyet etkin bir çözüm sunuyor. Geçişli yönlendirme çalışmadığı için birden fazla VPC’yi birbirine zincirleyen topolojilerde Transit Gateway daha uygun olsa da iki veya üç VPC arasındaki doğrudan bağlantı ihtiyaçlarında Peering hala ilk tercih olmalı.

Bu yazıda ele aldığımız adımlar; bağlantı oluşturma, kabul etme, route table yapılandırması, güvenlik grubu ayarları, DNS çözümleme ve izleme konularını kapsıyor. Gerçek dünyada bu adımları Terraform veya CloudFormation ile otomatize etmenizi kesinlikle tavsiye ederim. Manuel yapılan her değişiklik, ileride başka birinin anlaması gereken bir muamma haline gelir.

Troubleshooting yaparken VPC Flow Logs her zaman ilk başvuracağınız kaynak olsun. Trafik engelleniyorsa REJECT logları size hangi IP’nin, hangi portta, hangi güvenlik grubu tarafından engellendiğini söyler. Route sorunu varsa da “blackhole” state’i sizi doğrudan sorunun kaynağına yönlendirir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir