AWS Fargate 101: Serverless Container Nedir, Nasıl Çalışır?
AWS Fargate'e pratik bir rehber: task definition, awsvpc network modu, maliyet dengesi ve serverless container'ların ne zaman mantıklı olduğu.
EC2 üzerinde container çalıştırmak; OS yamalarını, cluster kapasitesini ve host düzeyindeki hataları yönetmek demektir. Bu iş, uygulama karmaşıklığıyla değil, host sayısıyla birlikte büyür. AWS Fargate bu katmanı ortadan kaldırır: AWS’ye bir container image’ı ile CPU/bellek çiftini verirsiniz, task’ı hiç giriş yapmayacağınız bir altyapıda çalıştırır.
Yeni container workload’ları için makul varsayılan Fargate’tir. Hesaplama birimi başına daha fazla ödersiniz, karşılığında host bakımını tamamen bırakırsınız. Bu takasın ters döndüğü durumlar bellidir: GPU iş yükleri, privileged container’lar ve Reserved Instance ya da Spot’un zaten ucuzlattığı sürekli yüksek kullanım. Kararın büyük kısmı, workload’un bu çizginin hangi tarafında durduğunu görmekten ibaret.
Fargate’e Genel Bakış#
Fargate’i “Sadece container’larımı çalıştırmak istiyorum” butonu olarak düşünün. AWS’ye Docker image’ınızı veriyorsunuz, ne kadar CPU ve bellek istediğinizi söylüyorsunuz, gerisini o hallediyor. Patch yapılacak EC2 instance’ı yok, yönetilecek cluster kapasitesi yok, host’un disk alanı bittiği için gece yarısı çağrısı yok. Ölçekleme tamamen AWS tarafında; siz sadece task sayısını ve kaynak ayarlarını tanımlarsınız.
İşe yarayan bir mental model şu: EC2 araba sahibi olmak gibiyse (yağ değişimi, lastik rotasyonu, çıkardığı o garip ses), Fargate araç çağırma servisi kullanmak gibidir. Nereye gitmek istediğinizi söylersiniz (bu container’ı çalıştır), aracın bakımıyla başkası ilgilenir.
Mimari#
Bu modelin can alıcı noktası izolasyon. Her Fargate task’ı kendi ortamında; kendi kernel’i, CPU kaynakları, belleği ve network interface’i ile çalışır. Her container için ayrı bir micro-VM’iniz varmış gibi, ama VM yönetmenin operasyonel yükü olmadan. Multi-tenant senaryolarda bu izolasyon güvenlik ve stabilite tarafında işe yarar.
İlk Deployment’ınız#
İşte ECS üzerinde pratik bir Fargate deployment’ı. İlk deployment için ECS’in hareketli parçası EKS’ten az; özel bir Kubernetes gereksiniminiz yoksa daha basit bir başlangıç noktası.
İlk olarak, bir task definition oluşturalım. Bu temelde AWS’ye “container’ımın çalışması için ihtiyacı olanlar bunlar” demek:
{
"family": "my-app",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "my-app",
"image": "nginx:latest",
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/my-app",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
}
}
]
}
Execution role’ü atlamak kolaydır. Bu rol olmadan task image’ı çekemez, CloudWatch Logs’a yazamaz ve kodunuz çalışmadan hata verir.
İnsanların takıldığı ikinci nokta CPU ve bellek değerleri. Bunlar rastgele değil; Fargate’in desteklediği kombinasyonlar belli:
| CPU (vCPU) | Bellek Değerleri (GB) |
|---|---|
| 0.25 | 0.5, 1, 2 |
| 0.5 | 1, 2, 3, 4 |
| 1 | 2, 3, 4, 5, 6, 7, 8 |
| 2 | 4-16 (1GB artışlarla) |
| 4 | 8-30 (1GB artışlarla) |
| 8 | 16-60 (4GB artışlarla) |
| 16 | 32-120 (8GB artışlarla) |
Geçersiz bir kombinasyon seçerseniz AWS task’ı reddeder ve değeri düzeltmenizi ister. Bu genellikle EC2 için yazılmış bir task definition kopyalandığında ve task’lar başlamadığında ortaya çıkar.
Network Yapılandırması#
Fargate yalnızca awsvpc network modunu destekler. Her task kendi elastic network interface’ini (ENI) ve özel IP’sini alır. Güvenlik izolasyonu açısından iyi; ama subnet boyutlandırması ve ENI kotaları kapasite planlamanızın parçası haline gelir.
İşte Terraform ile çalışan bir örnek (ilk denemelerin ötesine geçen her şey için console’da tıklamaktan daha yönetilebilir):
resource "aws_ecs_service" "my_app" {
name = "my-app-service"
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.my_app.arn
desired_count = 2
launch_type = "FARGATE"
network_configuration {
subnets = aws_subnet.private[*].id
security_groups = [aws_security_group.ecs_tasks.id]
assign_public_ip = false
}
load_balancer {
target_group_arn = aws_lb_target_group.my_app.arn
container_name = "my-app"
container_port = 80
}
}
# Önemli: Fargate 'ip' target type istiyor, 'instance' değil
resource "aws_lb_target_group" "my_app" {
name = "my-app-tg"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.main.id
target_type = "ip" # <-- Bu Fargate için kritik
health_check {
enabled = true
healthy_threshold = 2
unhealthy_threshold = 2
timeout = 5
interval = 30
path = "/health"
matcher = "200"
}
}
Fargate vs EC2: Karar Kriterleri#
Kararı çerçevelemenin pratik bir yolu şöyle:
Fargate’in Uygun Olduğu Durumlar#
- Tahmin edilemeyen veya ani yükselen trafik
- Zamanını host bakımı yerine uygulama koduna ayırmak isteyen bir ekip
- Çok sayıda küçük ve izole servis
- Güçlü workload izolasyonu isteyen uyumluluk gereksinimleri
- Halihazırda oturmuş bir container iş akışı
EC2’nin Uygun Olduğu Durumlar#
- GPU iş yükleri (Fargate GPU desteklemiyor)
- Host tarafında özel gereksinimleri olan Windows container’ları
- Reserved Instance veya Spot’un faturayı düşürdüğü tahmin edilebilir, yüksek kullanım
- Privileged container’lar veya özel kernel modülleri
- Host düzeyinde erişim isteyen her şey, örneğin node seviyesinde izleme agent’ları
Maliyet Dengesi#
Fargate, hesaplama birimi başına EC2’den pahalıdır. us-east-1’de 7/24 çalışan, 2 vCPU ve 4 GB’lık bir servis için liste fiyatları kabaca şöyle:
| Seçenek (2 vCPU, 4 GB) | Aylık, 7/24 çalışma |
|---|---|
| EC2 t3.medium, On-Demand | ~$30 |
| EC2 t3.medium, 1 yıllık Reserved | ~$19 |
| Fargate, On-Demand | ~$72 |
| Fargate Spot | ~$22 |
Compute Savings Plans Fargate’i de kapsar; indirim oranı taahhüt süresine ve ödeme seçeneğine göre değişir.
Not: AWS fiyatlandırması bölgeye göre değişir ve zaman içinde güncellenir. Bunlar örnek amaçlı yaklaşık liste fiyatları; güncel fiyatları bölgenizden kontrol edin.
Fargate Spot burada özel bir bahsi hak ediyor. Kullanılmayan kapasitede task’ları çalıştırarak %70’e varan maliyet tasarrufu sunuyor, ancak task’lar 2 dakika önceden haber verilerek kesintiye uğrayabilir. Hataya dayanıklı workload’lar için Fargate’i şaşırtıcı derecede maliyet açısından rekabetçi hale getirebilir.
Ama bu sayıların göstermediği şey:
- OS güncellemelerine harcanan zaman yok
- Cluster kapasite planlaması yok
- Auto-scaling grup konfigürasyonu yok
- Instance sağlık izlemesi yok
- Kapasite tükenmesi kaynaklı acil durumlar yok
Bunların hiçbiri faturada görünmez; bu yüzden saatlik karşılaştırma tek başına aradaki farkı olduğundan büyük gösterir.
Sık Karşılaşılan Sürprizler#
-
Başlangıç anlık değil: image çekme, ENI bağlama ve ilk health check’ler task trafiğe girmeden önce gerçekleşir. Bir task’ın planlandığı anda ayakta olduğunu varsaymak yerine deployment ve ölçek büyütme pencerelerinde bu boşluğu hesaba katın.
-
ENI limitleri: her Fargate task’ı bir ENI ve bir subnet IP’si tüketir. Network interface kotasına takılmak ya da küçük bir subnet’te adreslerin bitmesi, task’ların başlamasını engeller. Bu özellikle yoğun bir deployment gününde ortaya çıkar.
-
SSH Erişimi Yok: Fargate container’larına SSH yapamazsınız. Debug için ECS Exec kullanın:
aws ecs execute-command \ --cluster my-cluster \ --task abc123 \ --container my-app \ --interactive \ --command "/bin/sh"Bu yalnızca servis
enableExecuteCommandile oluşturulduysa ve task role SSM ile konuşabiliyorsa çalışır. -
Geçici depolama: task’lar varsayılan olarak 20 GB geçici depolama alır ve bu değer 200 GB’a kadar yapılandırılabilir. Ötesi için EFS bağlayın; yerel diskten daha yavaş I/O bekleyin.
-
Platform Versiyonları: Fargate her task’ı bir platform versiyonuna sabitler ve Linux’ta
LATEST1.4.0’a karşılık gelir. AWS bunları sizin yerinize ileri taşır; genelde sorun olmaz, arada davranış değişir. Önce staging’de test edin.
Referans Mimari#
Fargate üzerinde bir web servisinin production’da sık görülen şekli:
Bu düzende önemli olan noktalar:
- Load balancing için ALB kullanın - Fargate’in IP tabanlı target’larıyla sorunsuz entegre olur
- Fargate task’larını private subnet’lere koyun - Outbound internet için NAT gateway’ler kullanın
- Parameter Store veya Secrets Manager kullanın - Secret’ları image’lara gömeyin
- Düzgün logging kurun - CloudWatch Logs başlamak için iyi, ama production için Datadog veya benzeri düşünün
- ENI tahsisini izleyin - İlk tükeneceğiniz kaynak bu
Sonuç#
Yeni container workload’ları için Fargate ile başlayın ve belirli bir kısıt sizi dışarı itene kadar orada kalın: GPU erişimi, privileged container’lar, özel kernel modülleri ya da Reserved Instance veya EC2 Spot’un fiyatta net kazandığı sürekli yük. Fargate maliyeti planlamada tartıştığınız konu haline geldiyse bu genelde iyi bir problemdir; workload, cluster yönetiminin götürdüğü mühendislik zamanını gerekçelendirecek kadar öngörülebilir demektir.
Makul bir sonraki adım: kritik olmayan bir servisi 0.5 vCPU / 1 GB ile boyutlandırın, ip target’lı bir ALB arkasında çalıştırın ve faturayı yerine geçtiği EC2 host’unun maliyeti artı o host’un bakım yüküyle karşılaştırın.
Kaynaklar#
- Architect for AWS Fargate for Amazon ECS (yeni sekmede açılır) - AWS Fargate mimarisini, lansman türlerini ve Fargate ile EC2 arasında seçim kriterlerini açıklayan resmi ECS Geliştirici Kılavuzu.
- Amazon ECS task definition parameters for Fargate (yeni sekmede açılır) - Fargate görevleri için CPU, bellek, ağ modu ve depolama dahil tüm görev tanımı parametrelerinin referansı.
- Fargate platform versions for Amazon ECS (yeni sekmede açılır) - Fargate platform sürümleri, çekirdek ve çalışma zamanı kombinasyonları ile yükseltme dikkat noktaları.
- Amazon ECS task networking options for Fargate (yeni sekmede açılır) - Fargate’te awsvpc ağ modunun çalışma şekli, ENI tahsisi ve görev başına güvenlik grubu ataması.
- AWS Fargate Pricing (yeni sekmede açılır) - ECS ve EKS üzerinde Fargate için vCPU ve GB bellek başına resmi fiyatlandırma; Fargate Spot indirimleri dahil.
- Automatically scale your Amazon ECS service (yeni sekmede açılır) - Fargate iş yükleri için hedef izleme, adım ölçekleme ve zamanlanmış ölçekleme seçeneklerini içeren ECS Hizmet Otomatik Ölçekleme kılavuzu.
AWS Fargate Derinlemesine Serisi
AWS Fargate'e temellerden production'a tam rehber. Gerçek dünya deneyimleri ile serverless container'ları, maliyet optimizasyonu, debugging tekniklerini ve Infrastructure-as-Code deployment pattern'lerini öğrenin.
Bu serideki tüm yazılar
İlgili yazılar
Production workload'ları çalıştırırken öğrenilen gelişmiş Fargate pattern'leri. Maliyet optimizasyonundan stateful container'lara, dokümantasyonun size söylemeyecekleri.
aws · fargate · ecs +4
Global uygulamalar için AWS edge computing çözümlerini seçme ve uygulama üzerine pratik örnekler ve maliyet optimizasyonu stratejileri içeren kapsamlı teknik rehber.
aws · cloudfront · lambda +6
Secrets Manager ve Parameter Store'u karşılaştıran teknik rehber: hangi servisi ne zaman seçmeli ve production implementation pattern'leri.
aws · secrets-management · security +7
Dev, staging ve production ortamlarında Lambda Layer versiyonlarını AWS CDK ile yönetmek için pratik yaklaşımlar: otomatik pipeline ve rollback dahil.
aws · lambda · aws-cdk +4
AWS CDK, Lambda ve GitHub Actions kullanarak otomatik preview ortamları oluşturmayı öğrenin - sorunsuz PR test ve inceleme süreçleri için
aws-cdk · serverless · ci-cd +5