AWS Fargate Sorun Giderme: ENI Limitleri, Timeout, Debugging

Fargate, ENI limitleri, memory leak’ler ve subnet tükenmesi gibi kaynak kısıtlarını yeşil dashboard’ların arkasında gizler; ta ki bir trafik artışı bunları görmezden gelmenin imkânsız hâle getirdiği ana kadar. Bu arızaların ortak bir örüntüsü var: temel neden standart CloudWatch metrikleriyle görünmez, bu yüzden task’lar yanıltıcı hatalarla takılır ya da çöker. Vakaların çoğunu beş arıza biçimi açıklar ve her birinin dakikalar içinde sonuç veren bir kontrolü vardır.

Bu serinin önceki bölümleri (101, 102) temelleri ve gelişmiş pattern’leri ele aldı. Serideki bir sonraki bölüm olan 104 Infrastructure-as-Code deployment pattern’lerini kapsar.

ENI Tükenmesi#

Belirti: Task’lar PENDING durumundan çıkmıyor ve service event log’unda şu görünüyor:

ResourcesNotReady: The ENI allocation could not be completed

Deployment’lar tamamlanmıyor, auto-scaling kapasite ekleyemiyor. Servis ve task dashboard’ları normal görünüyor; çünkü tükenen kaynak hesabın network interface kotası ve bunu raporlayan bir ECS metriği yok.

ENI’lar Nereye Gidiyor#

awsvpc modundaki her Fargate task’ı kendi ENI’ını alır. Kota ne servisinize göre ölçeklenir ne de VPC’nize: Network interfaces per Region hesap düzeyinde 5.000’lik bir kotadır ve Availability Zone başına uygulanır. Birkaç yüz task tek başına sorun değildir; aynı hesap ve zone’daki diğer tüketiciler sayıldığında kotayı tüketirler:

• Varsayılan kota: Region başına 5.000 network interface, Availability Zone başına uygulanır
• Her Fargate task: 1 ENI
• Her RDS instance: 1 ENI
• VPC’deki her Lambda: ENI pool’u paylaşır
• Her ELB: Birden fazla ENI

Kullanımı kotayla karşılaştırma:

# Hesapta hâlihazırda ayrılmış interface sayısı
aws ec2 describe-network-interfaces \
  --query 'length(NetworkInterfaces)'

# Kotanın kendisi
aws service-quotas get-service-quota \
  --service-code vpc \
  --quota-code L-DF5E4CA3  # Network interfaces per Region

Yalnızca uygulamayı zorlayan load test’ler bunu asla göstermez. Önemli olan sayaç, hesaptaki tüm servislerin kümülatif interface kullanımıdır ve uygulama sağlıklı görünürken artmaya devam eder.

Çözüm Yaklaşımı#

Acil adımlar:

# Development'taki kritik olmayan servisleri küçült
aws ecs update-service \
  --cluster development \
  --service api \
  --desired-count 0

# AWS Support üzerinden kota artırımı talep et
aws support create-case \
  --subject "ENI quota increase needed - production capacity planning" \
  --service-code "service-quota-increase"

Uzun vadeli iyileştirmeler:

1. Ayrı hesaplar: Kota hesap ve Region başına olduğundan, asıl alan açan şey dev ve staging’i kendi hesaplarına taşımaktır
2. ENI monitoring: ENI kullanımını takip eden CloudWatch custom metric
3. Doğru boyutlandırma: Fazla provision edilmiş task’ları azalt
4. Lambda optimizasyonu: Mümkün olan Lambda’ları VPC dışına taşı

// ENI monitoring Lambda
import { EC2Client, paginateDescribeNetworkInterfaces } from '@aws-sdk/client-ec2';
import { CloudWatchClient, PutMetricDataCommand } from '@aws-sdk/client-cloudwatch';

const ec2 = new EC2Client({});
const cloudWatch = new CloudWatchClient({});

export const monitorENIs = async () => {
  // DescribeNetworkInterfaces sayfalanır; tek sayfa eksik sayar
  let inUse = 0;
  for await (const page of paginateDescribeNetworkInterfaces({ client: ec2 }, {})) {
    inUse += page.NetworkInterfaces?.length ?? 0;
  }

  await cloudWatch.send(new PutMetricDataCommand({
    Namespace: 'Custom/VPC',
    MetricData: [{
      MetricName: 'ENIsInUse',
      Value: inUse,
      Unit: 'Count'
    }]
  }));
};

Öğrenilen dersler:

• Load testing, uygulama throughput’u kadar altyapı kotalarını da kapsamalı
• Interface kotası hesap genelindedir ve Availability Zone başına uygulanır; yan taraftaki sessiz bir VPC bile onu tüketir
• Kota artırımları Service Quotas veya Support üzerinden ilerler ve anlık değildir; trafik yoğunluğundan önce alan talep edin

Subnet Route Arızası#

Kurulum: Üç private subnet’te Multi-AZ Fargate deployment’ı.

Belirti: Aralıklı bağlantı sorunları. Bazı HTTP istekleri başarılı oluyor, diğerleri 30 saniye sonra timeout’a düşüyor ve yalnızca tek bir subnet’teki task’lar etkileniyor.

Standart Kontroller#

Önce task’ın kendisini eleyen kontroller:

# Task sağlığını kontrol et
aws ecs list-tasks --cluster production --service-name api
aws ecs describe-tasks --cluster production --tasks task-abc123

# Network interface'leri kontrol et
aws ec2 describe-network-interfaces \
  --filters "Name=subnet-id,Values=subnet-12345" \
  --query 'NetworkInterfaces[*].[NetworkInterfaceId,Status,PrivateIpAddress]'

Task’lar sağlıklı raporluyor. Network interface’leri bağlı ve aktif. İkisi de subnet’ten çıkan yol hakkında hiçbir şey söylemiyor.

Bu soruyu flow log’lar yanıtlar:

# Problem subnet için VPC Flow Logs'u etkinleştir
aws ec2 create-flow-logs \
  --resource-type Subnet \
  --resource-ids subnet-12345 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs

Flow log’lar paketlerin subnet’ten çıktığını, buna karşılık gelen dönüş trafiğinin ise olmadığını gösterir. Egress yolunda bir yerde paketler düşüyordur.

Kök Sebep#

Bunun tipik nedeni, başka bir workload için yapılmış bir route table düzenlemesidir. Varsayılan route’u 0.0.0.0/0 → nat-gateway-123’ten 0.0.0.0/0 → nat-gateway-456’ya çevirmek tek satırlık bir değişikliktir ve kimse bunu çalışan bir Fargate servisiyle ilişkilendirmez; çünkü servis sağlıklı raporlamaya devam eder.

Yeni NAT gateway başka bir Availability Zone’daysa her paket AZ’ler arası bir sıçrama yapar ve dönüş trafiğinin hayatta kalıp kalmayacağına o subnet’in network ACL’i karar verir. NAT gateway’lerin kendine ait bir security group’u yoktur, dolayısıyla kontrol edilecek nokta subnet NACL’idir.

Çözüm:

# Subnet ile ilişkili route table'ı kontrol et
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-12345"

# Route'ları doğrula
aws ec2 describe-route-tables --route-table-ids rtb-abc123 \
  --query 'RouteTables[*].Routes[*].[DestinationCidrBlock,GatewayId,State]'

# Route'u düzelt (orijinal NAT gateway'e geri dön)
aws ec2 replace-route \
  --route-table-id rtb-abc123 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-gateway-123

Öğrenilen dersler:

• Route değişikliklerini her zaman production dışında test edin
• VPC Flow Logs, hiçbir ECS metriğinin yanıtlayamadığı soruyu yanıtlar: paket çıktı mı ve geri bir şey döndü mü
• Hangi route table’ların hangi servislere hizmet verdiğini dokümante edin
• Route table değişiklikleri için CloudTrail ve EventBridge üzerinden alarm kurun

SSH Erişimi Olmadan Memory Leak Takibi#

Kurulum: Fargate’te çalışan Node.js API, task başına 2 GB memory limiti.

Belirti: Memory birkaç saat boyunca istikrarlı biçimde artıyor, sonra task OOM kill edilip yenisiyle değiştiriliyor. Grafik testere dişi şeklinde ve SSH yapılacak bir shell yok.

Shell Olmadan Debug#

Neredeyse her vakayı üç araç kapsar:

1. ECS Exec (birincil araç):

# Önce service'te etkinleştir
aws ecs update-service \
  --cluster production \
  --service api \
  --enable-execute-command

# Sonra çalışan task'a bağlan
aws ecs execute-command \
  --cluster production \
  --task task-abc123 \
  --container api \
  --interactive \
  --command "/bin/bash"

# Container içinde memory kullanımını kontrol et
> ps aux --sort=-%mem | head -20
> cat /proc/meminfo
> pmap -x 1  # PID 1'in memory map'i

2. Application-level monitoring:

// Node.js uygulamanıza ekleyin
const express = require('express');
const app = express();

// Memory monitoring endpoint
app.get('/debug/memory', (req, res) => {
  const used = process.memoryUsage();
  const stats = {
    rss: Math.round(used.rss / 1024 / 1024 * 100) / 100,  // MB
    heapTotal: Math.round(used.heapTotal / 1024 / 1024 * 100) / 100,
    heapUsed: Math.round(used.heapUsed / 1024 / 1024 * 100) / 100,
    external: Math.round(used.external / 1024 / 1024 * 100) / 100,
    arrayBuffers: Math.round(used.arrayBuffers / 1024 / 1024 * 100) / 100
  };
  
  res.json(stats);
});

// Heap snapshot endpoint, yerleşik v8 modülüyle
const v8 = require('v8');

app.get('/debug/heapdump', (req, res) => {
  const filename = v8.writeHeapSnapshot(`/tmp/heapdump-${Date.now()}.heapsnapshot`);
  res.download(filename);
});

Snapshot yazmak event loop’u durdurur ve kabaca heap boyutu kadar bellek ayırır; bu yüzden endpoint’i internal bir yolun arkasında tutun ve asla tüm task’larda aynı anda çağırmayın.

3. Leak’i bulmak:

ECS Exec, çalışan bir task’ın içine araç yüklemenizi sağlar. Belirgin bir allocation noktası olmayan yavaş bir artışta heap yerine soketlerden başlayın:

# Container içinde
> npm install -g clinic
> clinic doctor --on-port 8080 -- node index.js &
> curl http://localhost:8080/debug/memory

# Açık file descriptor'ları kontrol et
> ls -la /proc/1/fd | wc -l
> lsof -p 1 | grep TCP

CLOSE_WAIT durumunda takılı yüksek sayıda TCP bağlantısı HTTP client’ın imzasıdır. Uygulama heap’i sağlamdır.

Kök Sebep#

Buna yol açan kod zararsız görünür:

// Problemli kod
const axios = require('axios');

async function callExternalAPI() {
  const response = await axios.get('https://api.example.com/data');
  return response.data;
}

Yapılandırılmış bir agent yoksa her çağrı yeni bir soket açabilir ve karşı tarafın yarı kapattığı soketleri kapatan hiçbir şey olmaz. Node descriptor’ı tutmaya devam eder, resident memory de descriptor sayısını takip eder.

Çözüm:

// Düzgün yapılandırmalı düzeltilmiş versiyon
const axios = require('axios');
const https = require('https');
const http = require('http');

// Connection pooling'i yapılandır
const httpAgent = new http.Agent({
  keepAlive: true,
  maxSockets: 50,
  timeout: 5000,
});

const httpsAgent = new https.Agent({
  keepAlive: true,
  maxSockets: 50,
  timeout: 5000,
});

const axiosInstance = axios.create({
  httpAgent,
  httpsAgent,
  timeout: 10000, // 10 saniye
});

// Graceful shutdown
process.on('SIGTERM', () => {
  httpAgent.destroy();
  httpsAgent.destroy();
});

async function callExternalAPI() {
  const response = await axiosInstance.get('https://api.example.com/data');
  return response.data;
}

Öğrenilen dersler:

• ECS Exec containerized debugging için paha biçilmez
• HTTP client’ları production’da her zaman düzgün yapılandırın
• File descriptor sayısı öncü göstergedir, memory ise gecikmeli gösterge
• “Basit” HTTP client’lar için bile connection pool’lar önemli

30 Saniyelik Connection Timeout#

Kurulum: İki Fargate servisi arasında, load balancer üzerinden yönlendirilen internal servis-servis çağrıları.

Belirti: İsteklerin küçük bir bölümü tam 30 saniye askıda kalıyor, ardından connection timeout ile başarısız oluyor. Yük, günün saati veya deployment geçmişiyle korelasyon yok.

Katman Katman#

Network katman araştırması:

# VPC Flow Logs analizi
aws logs filter-log-events \
  --log-group-name /aws/vpc/flowlogs \
  --start-time 1645564800000 \
  --filter-pattern "REJECT"

# Security group kuralları denetimi
aws ec2 describe-security-groups \
  --group-ids sg-12345 \
  --query 'SecurityGroups[*].{GroupId:GroupId,IpPermissions:IpPermissions}'

Security group’lar da flow log’lar da normal görünüyor; bu, engellenmiş bir yolu eler ve işaret ettiği yer bağlantı kurulum aşamasıdır.

Application katman araştırması:

// Detaylı bağlantı takibi eklendi
const net = require('net');
const original_connect = net.Socket.prototype.connect;

net.Socket.prototype.connect = function(...args) {
  const startTime = Date.now();
  console.log(`[${new Date().toISOString()}] Starting connection to ${args[0]?.host || args[0]?.path}`);
  
  const result = original_connect.apply(this, args);
  
  this.on('connect', () => {
    const duration = Date.now() - startTime;
    console.log(`[${new Date().toISOString()}] Connected after ${duration}ms`);
  });
  
  this.on('error', (err) => {
    const duration = Date.now() - startTime;
    console.log(`[${new Date().toISOString()}] Connection error after ${duration}ms:`, err.message);
  });
  
  return result;
};

Log’ların Gösterdiği#

Başarılı bağlantılar tek haneli milisaniyelerde tamamlanır. Askıda kalanlar tam olarak client timeout değerinde durur; bu imza bağlantının hiç kurulamadığını gösterir, çünkü reddedilmiş bir bağlantı anında hata döndürürdü.

Durumu tekrar üreten koşul şu: çağıran taraf, çağırdığı load balancer’ın kayıtlı hedeflerinden biridir.

Sebep, hairpinning olarak da bilinen NAT loopback’tir. AWS bunu Network Load Balancer için dokümante eder: target group’ta client IP preservation açıkken, kendi load balancer’ını çağıran bir hedef yalnızca istek başka bir hedefe yönlendirildiğinde başarılı olur. İstek çağırana geri dönerse kaynak ve hedef adresi aynı olur ve bağlantı timeout’a düşer. Aynı durum host paylaşan container’lar için de geçerlidir.

Çözüm: AWS’nin önerisi, client IP preservation’ı kapatmak ve client adresini Proxy Protocol v2 üzerinden okumaktır. Load balancer’ın internal bir çağrıya hiçbir katkısı yoksa iki seçenek bu adımı tamamen ortadan kaldırır:

1. Doğrudan servis-servis çağrıları:

// AZ awareness ile service discovery
const { ECSClient, ListTasksCommand, DescribeTasksCommand } = require('@aws-sdk/client-ecs');
const ecs = new ECSClient({});

// Fargate, Availability Zone'u environment variable olarak sağlamaz.
// Desteklenen kaynak task metadata endpoint'idir.
async function currentAvailabilityZone() {
  const res = await fetch(`${process.env.ECS_CONTAINER_METADATA_URI_V4}/task`);
  const meta = await res.json();
  return meta.AvailabilityZone;
}

async function getServiceEndpoints() {
  const { taskArns = [] } = await ecs.send(new ListTasksCommand({
    cluster: 'production',
    serviceName: 'target-service'
  }));
  if (taskArns.length === 0) return [];

  const { tasks = [] } = await ecs.send(new DescribeTasksCommand({
    cluster: 'production',
    tasks: taskArns
  }));

  return tasks.map(task => ({
    ip: task.attachments[0].details.find(d => d.name === 'privateIPv4Address').value,
    az: task.availabilityZone,
    port: 8080
  }));
}

// Akıllı routing
async function callService(endpoint, data) {
  const currentAZ = await currentAvailabilityZone();
  const endpoints = await getServiceEndpoints();
  
  // Önce aynı AZ direkt bağlantıyı dene
  const sameAZEndpoint = endpoints.find(e => e.az === currentAZ);
  if (sameAZEndpoint) {
    try {
      return await axios.post(`http://${sameAZEndpoint.ip}:${sameAZEndpoint.port}${endpoint}`, data);
    } catch (error) {
      // Load balancer'a geri dön
      return await axios.post(`https://internal-service.example.com${endpoint}`, data);
    }
  }
  
  // Cross-AZ için load balancer kullan
  return await axios.post(`https://internal-service.example.com${endpoint}`, data);
}

Bu endpoint listesini cache’leyin. ListTasks ve DescribeTasks throttle edilen API’lerdir; her istekte çağırmak, load balancer’ın düşeceğinden çok önce limite takılır. ECS Service Connect veya Cloud Map aynı işi bu API trafiği olmadan yapar.

2. Connection timeout ayarlaması:

const axiosInstance = axios.create({
  timeout: 5000,  // 30s beklemek yerine çabuk başarısız ol
  httpsAgent: new https.Agent({
    timeout: 2000,  // Connection timeout
    keepAlive: true,
  })
});

Öğrenilen dersler:

• Kendi load balancer’ını çağıran bir hedef, client timeout dolana kadar askıda kalabilir; önce client IP preservation’a bakın
• Service discovery direkt iletişim pattern’lerini mümkün kılar
• Her zaman SLA’nızdan daha kısa connection timeout’lar uygulayın
• Internal trafiğin bir load balancer üzerinden çıkması zorunlu değildir

Takılan Deployment’lar#

Kurulum: CodeDeploy kullanarak standart blue-green deployment.

Belirti: Deployment ortasında takılıyor. Task’ların bir kısmı yeni revizyonu, geri kalanı eskisini çalıştırıyor; CodeDeploy konsolu hata olmadan InProgress gösteriyor.

Auto-rollback hiç tetiklenmiyor, çünkü hiçbir şey başarısızlık raporlamadı.

Araştırma#

CodeDeploy size bir şey söylemez:

aws deploy get-deployment --deployment-id d-XXXXXXXXX
# Status: InProgress, hata bilgisi yok

aws logs filter-log-events \
  --log-group-name /aws/codedeploy-agent \
  --start-time $(date -d '1 hour ago' +%s)000

ECS service event’leri söyler:

aws ecs describe-services \
  --cluster production \
  --services api \
  --query 'services[0].events[0:10]'

Event’ler şunu gösteriyordu:

"(service api) failed to launch a task with (error ECS was unable to assume role...)"

Kök Sebep#

Task execution role’ünün trust policy’si artık ECS’yi işaret etmiyordur. Alakasız bir servis için yapılan bir düzenleme bunun için yeterlidir: trust relationship tek bir principal’dır ve onu değiştirmek, günler sonra gelebilecek bir sonraki task launch’a kadar hiçbir şeyi bozmaz.

Bu haldeki bir trust policy her launch’ı başarısız kılar:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"  // YANLIŞ!
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Şöyle olmalıydı:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"  // DOĞRU
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Çözüm:

# Role trust policy'sini kontrol et
aws iam get-role --role-name fargate-task-execution-role \
  --query 'Role.AssumeRolePolicyDocument'

# Güncelle
aws iam update-assume-role-policy \
  --role-name fargate-task-execution-role \
  --policy-document file://trust-policy.json

Önleme stratejisi:

// Otomatik role validasyonu
import { IAMClient, GetRoleCommand } from '@aws-sdk/client-iam';

const iam = new IAMClient({});

export const validateTaskRoles = async () => {
  const { Role } = await iam.send(new GetRoleCommand({
    RoleName: 'fargate-task-execution-role'
  }));

  // AssumeRolePolicyDocument URL-encoded döner
  const trustPolicy = JSON.parse(decodeURIComponent(Role.AssumeRolePolicyDocument));

  // Principal.Service ya bir string ya da string dizisidir
  const trustsECS = trustPolicy.Statement.some(statement =>
    [statement.Principal?.Service ?? []].flat().includes('ecs-tasks.amazonaws.com')
  );

  if (!trustsECS) {
    await sendAlert('Task execution role missing ECS trust relationship');
    return false;
  }

  return true;
};

Öğrenilen dersler:

• ECS service event’leri CodeDeploy log’larından daha detaylı
• Role trust policy’leri kırılgan ve monitoring gerektirir
• Blue-green deployment’lar limbo’da takılabilir
• İşler gizemli şekilde çalışmayı durdurduğunda her zaman IAM’ı kontrol edin

Debug Araç Kutusu#

Yukarıdaki bölümlerin ihtiyaç duyduğu şeylerin çoğunu üç parça karşılar:

1. Debug Yapılabilir Container İmajı#

FROM node:18-alpine
RUN apk add --no-cache \
    curl \
    wget \
    netcat-openbsd \
    bind-tools \
    tcpdump \
    strace \
    htop \
    iotop \
    lsof \
    procps \
    net-tools

# Uygulamanızı ekleyin
COPY . /app
WORKDIR /app

# Debug endpoint'leri
RUN npm install express clinic

strace ayrıca task definition’da linuxParameters.capabilities.add altında SYS_PTRACE ister. Fargate’in eklemenize izin verdiği tek capability budur ve platform version 1.4.0 veya üzerini gerektirir.

2. Monitoring Stack#

// Detaylı teşhislerle health check endpoint
app.get('/health/detailed', async (req, res) => {
  const health = {
    timestamp: new Date().toISOString(),
    uptime: process.uptime(),
    memory: process.memoryUsage(),
    cpu: process.cpuUsage(),
    connections: {
      active: await getActiveConnections(),
      waiting: await getWaitingConnections()
    },
    environment: {
      nodeVersion: process.version,
      availabilityZone: await currentAvailabilityZone(),  // task metadata endpoint
      region: process.env.AWS_REGION || 'unknown'
    }
  };
  
  res.json(health);
});

async function getActiveConnections() {
  return new Promise((resolve) => {
    require('child_process').exec('netstat -an | grep ESTABLISHED | wc -l', 
      (error, stdout) => {
        resolve(parseInt(stdout.trim()) || 0);
      }
    );
  });
}

3. Otomatik Olay Müdahalesi#

# Sessizce başarısız olan iki limit için alarm'lar
ENIUtilizationAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmName: High-ENI-Utilization
    MetricName: ENIsInUse
    Namespace: Custom/VPC
    Statistic: Maximum
    Period: 300
    EvaluationPeriods: 2
    Threshold: 4500  # Varsayılan 5.000 kotasının %90'ı
    ComparisonOperator: GreaterThanThreshold
    AlarmActions:
      - !Ref SNSTopic

MemoryUtilizationAlarm:
  Type: AWS::CloudWatch::Alarm  
  Properties:
    AlarmName: Fargate-Memory-High
    MetricName: MemoryUtilized
    Namespace: ECS/ContainerInsights
    Statistic: Average
    Period: 300
    EvaluationPeriods: 3
    Threshold: 80  # %80 memory kullanımı
    ComparisonOperator: GreaterThanThreshold

Belirtiye Göre Triyaj Sırası#

Bir şey bozulduğunda sebebe en hızlı ulaştıran sıra şudur:

1. Task’lar başlamadığında: Kotaları, security group’ları ve IAM trust policy’lerini kontrol et (bu sırayla)

2. Task’lar yavaş olduğunda: Önce network’e bak (route table’lar, NAT gateway’ler, DNS)

3. Memory sürekli arttığında: Uygulama heap’inden önce connection pooling ve event listener’lara bak

4. Deployment’lar asılı kaldığında: Deployment log’lar değil, service event’leri kontrol et

5. İsteklerin küçük bir bölümü başarısız olduğunda: Load balancer loopback’i veya cross-AZ yolları ara

6. Hiçbir şey mantıklı olmadığında: VPC Flow Logs ve ECS Exec’i etkinleştir

Fargate, aksi hâlde işletmeniz gereken altyapının çoğunu ortadan kaldırır ve bu soyutlama kotalar, routing ve bağlantı yaşam döngüsü dışında her yerde tutar. Bu üçü sizde kalır; o yüzden onlara ait teşhis araçlarını ihtiyaç duymadan önce hazır edin: serviste açık ECS Exec, subnet’lerde erişilebilir VPC Flow Logs ve interface kullanımına bir alarm. Bunlardan herhangi birini olay sırasında sonradan kurmak, çözümün kendisinden daha fazla zaman götürür.

Kaynaklar#

• Architect for AWS Fargate for Amazon ECS (yeni sekmede açılır) - Görev yaşam döngüsü, ağ iletişimi ve tam yönetimli altyapı modelini kapsayan temel Fargate mimari referansı.
• Amazon ECS task networking options for Fargate (yeni sekmede açılır) - Fargate’in görev başına ENI yönetimi ve awsvpc ağ modunun getirdiği kısıtlamalar.
• Amazon VPC quotas (yeni sekmede açılır) - Network interface kotası (Region başına 5.000, Availability Zone başına uygulanır) ile route table, NACL ve security group limitleri.
• Troubleshoot your Network Load Balancer (yeni sekmede açılır) - Client IP preservation açıkken kendi load balancer’ını çağıran hedefi vuran loopback timeout’u ve desteklenen iki çözüm.
• Using Amazon ECS Exec to access your containers (yeni sekmede açılır) - Çalışan bir Fargate task’ında shell açmak için ön koşullar, IAM izinleri ve platform version gereksinimleri.
• Task metadata endpoint version 4 for Fargate (yeni sekmede açılır) - Availability Zone, task ARN ve container istatistiklerini task içinden okumanın desteklenen yolu.
• Fargate security best practices in Amazon ECS (yeni sekmede açılır) - Salt okunur kök dosya sistemleri, kaynak limitleri ve ağ politikaları dahil Fargate güvenlik sertleştirme rehberi.
• Amazon ECS service quotas and API throttling limits (yeni sekmede açılır) - Büyük ölçekte üretim sürprizlerine yol açan ENI ve görev kotaları ile limit artırma talepleri.
• Updating an Amazon ECS service (yeni sekmede açılır) - Kademeli güncellemeler ve dağıtım devre kesici yapılandırması dahil hizmet güncelleme stratejileri.
• Cost Optimization Checklist for Amazon ECS and AWS Fargate (yeni sekmede açılır) - Üretim maliyetlerini azaltmak için Fargate Spot, Tasarruf Planları ve doğru boyutlandırma konularını ele alan AWS Containers blog kontrol listesi.