Amazon SAA-C03: Konteynerler ve Orkestrasyon — Ç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.

ECS ile EKS ve EC2 ile Fargate Arasında Seçim Yapma

AWS üzerindeki herhangi bir container iş yükü için ilk mimari karar, orkestratör ve işlem modunu seçmektir. Amazon ECS, IAM, ALB/NLB, CloudWatch, Service Discovery ve VPC ağı ile sıkı entegrasyona sahip, AWS’e özgü bir orkestratördür. Kontrol düzlemi ücreti yoktur ve Kubernetes’e özgü araçlara ihtiyaç duymayan ekipler için üretime geçişin en hızlı yoludur. Görevler (task), bir yaşam döngüsünü paylaşan bir veya daha fazla container birimidir; servisler (service) ise bir zamanlayıcı tarafından yönetilen, uzun süre çalışan yönetimli görev kümeleridir. Amazon EKS, küme başına saatlik 0,10$ sabit ücretle upstream uyumlu Kubernetes çalıştırır ve iş yüklerinin taşınabilir kalması, Kubernetes API’sini kullanması veya CNCF ekosisteminden (Helm, CRD’ler, Operatörler) yararlanması gerektiğinde doğru seçimdir. Kontrol düzlemi — API sunucusu, etcd, denetleyici yöneticisi, zamanlayıcı — AWS tarafından yamalanır, yedeklenir ve üç AZ boyunca yüksek oranda erişilebilir hale getirilir.

Her iki orkestratör de iki işlem modunu kabul eder. AWS Fargate, her görevi veya pod’u izole Firecracker microVM’leri üzerinde çalıştırır; yamalanacak AMI, ayarlanacak Auto Scaling Group kapasite sağlayıcıları, bin-packing kararları veya SSH ile erişilebilen ana makineler yoktur. Görevin vCPU-saniyesi ve GB-saniyesi başına ödeme yaparsınız. EC2 başlatma türü / yönetilen düğüm grupları, esneklik ve operasyonel yüküyle birlikte bulut sunucularının sahibi olduğunuz anlamına gelir.

Bir senaryoda “sunucusuz”, “en az operasyonel yük” veya “yönetilecek altyapı yok” vurgusu yapıldığında, iş yükünün kısıtlamalarına uyması koşuluyla Fargate doğru varsayılan seçenektir: görev başına maksimum 16 vCPU / 120 GB bellek, GPU yok, ayrıcalıklı container’lar yok, DaemonSet’ler yok, HostPort/HostNetwork yok, Windows ana makine seviyesinde özelleştirme yok. GPU’lara, ana makine erişimi gerektiren DaemonSet’lere, özel AMI’lere, GMSA ile Windows Server container’larına, saniyenin altında bin-packing verimliliğine veya agresif Spot tabanlı maliyet optimizasyonuna ihtiyacınız olduğunda yönetilen düğüm gruplarını veya EC2 başlatma türünü seçin.

Klasik tuzak, daha ucuz “hissettirmeleri” nedeniyle EC2 düğümlerini seçmektir. Düzensiz veya düşük kullanımlı iş yükleri için, boşta kalan kapasite artı AMI yamalama, düğüm boşaltma ve küme otomatik ölçeklendirici yapılandırması için harcanan mühendislik zamanını (Fargate tüm bunları ortadan kaldırır) hesaba kattığınızda Fargate genellikle daha ucuza gelir.

Görev Tanımları, Yerleştirme ve Kapasite Sağlayıcıları

Standart bir ECS Fargate görev tanımı, temel unsurları içerir — CPU/bellek boyutlandırması, imajları çekmek ve logları yazmak için bir yürütme rolü, awsvpc ağ modu ve CloudWatch Logs bağlantıları:

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

EC2 ile ECS’de, görev yerleştirme stratejileri, görevlerin bulut sunucuları arasında nasıl dağıtılacağına karar verir. Sırayla birleştirilirler:

distinctInstance veya küme sorgu dilini kullanan memberOf gibi yerleştirme kısıtlamaları, adayları daha da daraltır.

Kapasite sağlayıcıları, servisleri ham Auto Scaling Group’larından ayırır. FARGATE ve FARGATE_SPOT yönetilen sağlayıcılardır; özel sağlayıcılar bir ASG’yi sarmalar ve yönetilen ölçeklendirmeyi etkinleştirir, böylece ECS, sağlanan görev sayısına göre ASG’nin istenen sayısını ayarlar. Bir kapasite sağlayıcı stratejisi, görevleri ağırlık ve taban değerine göre böler — örneğin, iki adet isteğe bağlı Fargate görevini garanti altına alıp geri kalanını kesintiye toleranslı iş yükleri için Fargate Spot ile 1:4 oranında bölmek gibi:

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Otomatik Ölçeklendirme: Pod’lar, Görevler ve Düğümler

Fargate düğüm yönetimini ortadan kaldırır, ancak görev veya pod sayısını otomatik olarak ölçeklendirmez. Bu ayrım, Fargate ile ilgili en sık düşülen yanılgıdır: sunucusuz kavramı ana makine katmanı için geçerlidir, servisinizin istenen sayısı için asla geçerli değildir. Servis seviyesindeki otomatik ölçeklendirme hala sizin sorumluluğunuzdadır.

ECS için Application Auto Scaling kullanın. Hedef takibi (target tracking), standart varsayılan yöntemdir çünkü genişleme ve daralma için CloudWatch alarmlarını otomatik olarak oluşturur ve bekleme sürelerine uyar. Mantıklı metrikler ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization ve ALBRequestCountPerTarget‘tır:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

Adım ölçeklendirme (step scaling) ve zamanlanmış ölçeklendirme (scheduled scaling), doğrusal olmayan yanıt eğrileri veya bilinen trafik pencereleri için kullanılabilir olmaya devam eder.

EC2 düğümleri üzerindeki EKS için pod boyutu Horizontal Pod Autoscaler (HPA) tarafından yönetilir; bu araç, CPU, bellek veya özel metriklere göre replika sayılarını ayarlar. HPA tek başına düğüm ekleyemez — replika sayısını memnuniyetle küme kapasitesinin üzerine çıkarır, bu noktada yeni pod’lar FailedScheduling olayları ile Pending durumuna girer. Bu nedenle EC2 üzerindeki HPA, her zaman Kubernetes Cluster Autoscaler veya Karpenter ile birlikte kullanılmalıdır. Bu eşleştirmeyi unutmak sık yapılan bir tasarım hatasıdır: HPA “20 replikaya ölçeklendi” raporu verirken, bunların yarısı beklemede takılı kalmıştır. Minimal bir Cluster Autoscaler yapılandırması, düğüm gruplarını ASG etiketleri aracılığıyla keşfeder:

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Fargate profillerinde bu sorun ortadan kalkar — her pod kendi microVM’i haline gelir, böylece düğüm ölçeklendirme boyutu tamamen ortadan kalkar. Ani ve öngörülemeyen pod sayılarına sahip iş yükleri için Fargate’in doğru seçim olmasının nedeni tam olarak budur.

Fargate Profilleri ve Özellik Sınırları

EKS’teki bir Fargate profili, EKS’e eşleşen pod’ları bir node yerine Fargate üzerinde zamanlamasını bildiren bir seçicidir — namespace ve isteğe bağlı pod etiketleri:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

Buradaki kritik uyarı, Fargate üzerindeki EKS’in tüm Kubernetes özellik yüzeyini desteklememesidir:

• DaemonSet’ler çalışmaz. Üzerinde daemon çalıştırılacak bir node olmadığından, fluentd gibi log gönderici DaemonSet’lerin yerini sidecar’lar veya yerleşik Fluent Bit log yönlendiricisi almalıdır.
• Ayrıcalıklı container’lar, HostPort ve HostNetwork kullanılamaz.
• Kalıcı depolama EFS ile sınırlıdır ve CSI sürücüsü aracılığıyla kullanılır. EBS desteklenmez, çünkü EBS birimleri belirli bir EC2 örneğine bağlanmayı gerektirir.
• GPU iş yükleri desteklenmez.
• NodePort servisleri ve ayrıcalıklı init container’larına dayanan service mesh’ler çalışmaz.

Özelliklerin aynı olduğunu varsaymak, EBS’e ihtiyaç duyan StatefulSet’lerin, hostPort kullanan ingress denetleyicilerinin veya GPU çıkarım iş yüklerinin başarısız geçişlerine yol açar.

Ingress: AWS Load Balancer Controller aracılığıyla ALB ve NLB Karşılaştırması

AWS Load Balancer Controller, Ingress ve Service nesnelerini gerçek ALB’lere ve NLB’lere çeviren bir Kubernetes denetleyicisidir. Yol veya ana bilgisayar tabanlı yönlendirme yapan HTTP/HTTPS mikroservisleri için, sınıfı alb olan tek bir Ingress oluşturun. Birçok servisin önünde duran tek bir ALB (alb.ingress.kubernetes.io/group.name aracılığıyla), servis başına bir ALB kullanmaktan çok daha ucuzdur ve maliyet açısından en verimli kanonik modeldir:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

TCP, UDP, TLS pass-through, statik IP gereksinimleri veya aşırı Katman 4 (Layer 4) verimi için bir NLB (türü LoadBalancer olan, service.beta.kubernetes.io/aws-load-balancer-type: external ve hedef türü nlb-ip olan bir Service) kullanın. Bir ALB’nin arkasına gRPC-over-HTTP/2 veya düz bir TCP veritabanı proxy’si koymak yalnızca gRPC için uygundur (ALB, HTTP/2 ve gRPC’yi destekler); ALB rastgele TCP veya herhangi bir UDP’yi sonlandıramaz. Bir ALB üzerinden UDP oyun trafiği sunmaya çalışmak, tasarım aşamasında fark edilmesi gereken bir protokol uyuşmazlığıdır.

IRSA ile Pod Seviyesinde IAM

IAM Roles for Service Accounts (IRSA), tek tek pod’lara AWS API izinleri vermek için doğru mekanizmadır. Pod’lara S3 erişimi vermek için node’un instance profilini eklemek yanlıştır, çünkü node üzerindeki her pod bu izinleri devralır ve en az ayrıcalık ilkesini bozar. IRSA, kümenin OIDC sağlayıcısını IAM ile birleştirerek çalışır: OIDC sağlayıcısını bir kez oluşturun, ardından güven politikasında belirli bir namespace:serviceaccount öznesi için bu sağlayıcıya güvenen bir IAM rolü oluşturun.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

Service account, eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role ile etiketlenir ve bunu bağlayan pod’lar, yansıtılmış bir token aracılığıyla kısa ömürlü STS kimlik bilgileri alır. OIDC sağlayıcı ilişkisini atlamak veya bu etiketi eklememek, sessizce node rolüne geri dönülmesine neden olur — bu, gözden geçirme sırasında kolayca kaçırılabilecek ince bir güvenlik gerilemesidir.

VPC CNI eklentisi, her pod’a VPC alt ağında yönlendirilebilir bir ENI/IP adresi atayarak bunu tamamlar. Böylece pod’lar, güvenlik gruplarını kullanarak doğrudan RDS, ElastiCache veya VPC uç noktalarıyla konuşabilir ve CloudTrail denetim için pod’un gerçek IP’sini görür.

Kalıcı ve Geçici Depolama

Depolama seçimi erişim moduna, dayanıklılığa ve başlatma türüne bağlıdır.

EBS (EKS’te EBS CSI sürücüsü aracılığıyla veya ECS’te göreve eklenmiş EBS), Postgres birincil sunucusu gibi tek pod’lu durum bilgisi olan iş yükleri için ReadWriteOnce blok birimleri sağlar. EFS, bölgesel, çoklu AZ’li ve aynı anda birçok pod tarafından bağlanabilen ReadWriteMany NFS depolaması sağlar — gereksinim “yüksek oranda erişilebilir, hataya dayanıklı, birden çok container arasında paylaşılan” veya paylaşılan ML yapıtları gibi ifadeler içerdiğinde doğru seçimdir. FSx for Lustre yüksek verimli HPC’yi; FSx for NetApp ONTAP ve FSx for Windows File Server kurumsal NFS/SMB’yi yönetir.

Fargate görevleri varsayılan olarak 20 GB geçici depolama alanı alır ve bu, 1.4.0+ platformunda ephemeralStorage.sizeInGiB aracılığıyla 200 GB’a kadar yapılandırılabilir. Fargate’in her zaman “bol miktarda geçici alana” sahip olduğunu varsaymak bir tuzaktır: 50 GB ara dosya yazan bir satıcı container’ı genişletilmiş geçici depolamaya sığabilir, ancak gereksinim görev yeniden başlatmaları veya görevler arasında 50 GB paylaşılan veya dayanıklı depolama ise, geçici depolama yanlıştır çünkü görev durduğunda yok edilir ve asla paylaşılmaz. Fargate, EBS’i desteklemez. Bir Fargate iş yükünün kalıcı veya paylaşılan depolamaya ihtiyacı varsa, EFS esasen desteklenen tek seçenektir.

ECS için, EFS’i doğrudan görev tanımına bağlayın; erişim noktaları görev başına POSIX UID/GID ve kök dizini zorunlu kılarak tek bir dosya sisteminde güvenli çoklu kiracılık sağlar ve IAM yetkilendirmesi elasticfilesystem:ClientMount kapsamını belirler:

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

EKS için, EFS’i bir StorageClass aracılığıyla bağlayın:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Tekrarlanan bir tuzak: durum bilgisi olan bir iş yükü için Fargate’i seçip EFS CSI sürücüsünü ve StorageClass’ı kurmayı unutmak — pod’lar başlar ancak PersistentVolumeClaims sonsuza kadar Pending durumunda kalır. Tersine, gereksinim paylaşılan çoklu yazıcılı depolama olduğunda yalnızca EBS bağlamak için EC2 node’larını seçmek de yanlıştır; bir node’a bağlı EBS io2, AZ’ler arasında paylaşılamaz.

ECR İmaj Taraması ve Yaşam Döngüsü

Amazon ECR iki tarama modu sunar. Temel tarama, açık kaynaklı Clair veritabanını kullanır ve push işleminde (veya isteğe bağlı olarak) ücretsiz çalışır. Gelişmiş tarama, Amazon Inspector ile entegre olur, hem işletim sistemi hem de dil paketi CVE’lerini sürekli olarak izler ve bulguları Security Hub’a raporlar. “CVE’leri tara, yeni imajları oluşturulduklarında tara, iş yüklerinde en az değişiklik yap” gibi bir gereksinim için doğru eylem, depo seviyesinde push’ta taramayı etkinleştirmektir — pipeline’da değişiklik gerekmez çünkü push olayı taramayı tetikler:

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

CI/CD daha sonra describe-image-scan-findings komutunu çağırır ve CRITICAL veya HIGH sayımlarında derlemeleri başarısız kılar. Taramayı atlamak, yamalanmamış Log4j, OpenSSL veya glibc CVE’lerinin üretimde çalışması anlamına gelir; tarama yapmamanın azaltma maliyeti, etkinleştirmenin neredeyse sıfır olan maliyetinin yanında çok büyük kalır.

Yaşam döngüsü politikaları depolama maliyetini sınırlar ve etiket hijyenini zorunlu kılar:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Kubernetes + MongoDB İş Yüklerini Taşıma

Kendi barındırdığınız (self-hosted) bir Kubernetes + MongoDB yığınını “uygulama kodunu değiştirmeme” ve “minimum operasyonel yük” kısıtlamaları altında AWS’e taşırken (lift) iki karar öne çıkar. İlk olarak, işlem katmanı (compute layer) EKS’e taşınır çünkü Kubernetes API uyumluluğu, manifest’lerin ve Helm chart’larının değiştirilmeden taşınabileceği anlamına gelir; durumsuz (stateless) servisler için Fargate profilleri kullanarak node sahipliğini ortadan kaldırın.

İkinci olarak, MongoDB’nin kendisi, kendi yönettiğiniz EC2 veya StatefulSet’ler üzerine yeniden barındırılmamalıdır — bu, yedekleme, sharding, yük devretme (failover) ve yama yönetimi gibi operasyonel yükleri yeniden ortaya çıkarır. Bunun yerine, mevcut sürücülerin ve bağlantı dizelerinin (connection string) minimum değişiklikle çalışabilmesi için MongoDB 3.6/4.0/5.0 wire protokolünü konuşan Amazon DocumentDB (MongoDB uyumlu) kullanın.

Uyumlulukla ilgili bu önemli noktaya dikkat edilmelidir. DocumentDB, MongoDB API yüzeyini taklit eder ancak MongoDB değildir. Belirli aggregation operatörleri, özel indeks türleri, change stream semantikleri ve daha yeni MongoDB sürümlerinde sunulan özellikler çalışmayabilir. Doğru geçiş öncesi adım, her operasyonun desteklendiğini doğrulamak için DocumentDB uyumluluk aracını (compat.py) uygulamaya karşı çalıştırmaktır. Bunun yerine DynamoDB’yi seçmek, veri modelinin yeniden yazılmasını zorunlu kılar; RDS’i seçmek ise doküman modelini tamamen bozar. Her ikisi de “kod değişikliği yok” kısıtlamasını ihlal eder.

Hibrit Seçenekler: ECS Anywhere ve EKS Anywhere

ECS Anywhere, şirket içi (on-premises) sunucuları (veya diğer bulutların sanal makinelerini) bir ECS kümesine harici örnekler (external instances) olarak kaydeder. Kontrol düzlemi (control plane) AWS’te kalır; harici örnek üzerindeki SSM Agent ve ECS Agent dışarıya doğru bağlantı kurar. Tek bir dağıtım hattı (deployment pipeline), tek bir görev tanımı (task definition) ve tek bir IAM rol seti hem buluttaki hem de şirket içindeki iş yüklerini kapsar.

EKS Anywhere, donanımınız (genellikle vSphere veya bare metal) üzerine uyumlu (conformant) bir Kubernetes dağıtımı kurar ve isteğe bağlı olarak EKS Connector aracılığıyla AWS konsoluna görünürlük sağlar. Hafif, görev tanımı tabanlı hibrit çözümler için ECS Anywhere’i seçin; mevzuata veya gecikme süresine (latency) ilişkin kısıtlamalar, buluttaki EKS ile aynı araç setini kullanarak yerel olarak Kubernetes gerektirdiğinde EKS Anywhere’i seçin. Her ikisi de orkestrasyonu tutarlı tutar — temel değeri, ekiplerin iki ayrı CI/CD sistemini veya iki ayrı zihinsel modeli sürdürmekten kaçınmasıdır.

EKS Connector ile Çoklu Küme Görünürlüğü

Kuruluşlar genellikle EKS kümeleri, EC2 üzerinde kendi yönettikleri Kubernetes ve şirket içi kümelerin bir karışımını çalıştırır. Amazon EKS Connector, herhangi bir uyumlu Kubernetes kümesini EKS konsoluna kaydederek node’lar, iş yükleri ve küme meta verileri için tek bir merkezi görünüm (single pane of glass) sağlar. Esasen hafif bir ajan (agent) artı bir SSM kanalıdır — “tüm kümelerin merkezi görünümü” için düşük ek yüklü (low-overhead) bir yanıttır. Kendi barındırdığınız Rancher, Anthos veya özel bir Prometheus/Grafana federasyonu ile eşdeğer bir görünürlük oluşturmak mümkündür, ancak operasyonel olarak çok daha maliyetlidir ve IAM veya konsol tabanlı erişimle entegre olmaz.

EKS Connector kesinlikle bir görünürlük katmanıdır; uzak kümeyi yönetmez veya yükseltmez, bu da tam olarak “en az ek yükle merkezi görünüm” ifadesinin ima ettiği şeydir.

Modelleri Bir Araya Getirme

Yük dengelemeli (load-balanced) bir ön yüz (front end), konteynerize edilmiş bir orta katman (middle tier) ve ilişkisel bir veri deposu (relational store) olan bir e-ticaret iş yükü için “mümkün olan en az manuel müdahale” kriterinin geçerli olduğu durumlarda, kanonik yığın ALB → Fargate üzerinde ECS → Aurora Serverless v2’dir. Her katman, örnek (instance) seviyesinde sahipliği ortadan kaldırır: ALB tam olarak yönetilir (fully managed), Fargate sunucuları (host) ortadan kaldırır ve Aurora Serverless v2, örnek boyutlandırması olmadan ACU’lar ile ölçeklenir.

Ekibin “ek altyapıyı yönetemediği” bir mikroservis platformu için doğru kombinasyon, Fargate ile ECS veya EKS artı tam olarak yönetilen bir veri servisidir. EC2 başlatma türünü (launch type) veya kendi yönettiğiniz node gruplarını seçmek, iş yükü teknik olarak çalışacak olsa bile bu kısıtlamayla çelişir.

Kubernetes + MongoDB’nin lift-and-shift (olduğu gibi taşıma) senaryosunda, cevap EKS + DocumentDB’ye yakınsar: Kubernetes API dağıtım yöntemlerini korur, DocumentDB sürücü uyumluluğunu korur ve Fargate profilleri minimum operasyonel yükü korur — ancak bunun için iş yükünün Kubernetes özellik kullanımı ve MongoDB komut yüzeyinin yukarıda açıklanan desteklenen sınırlar içinde kalması gerekir.

← Bilişim · Tüm alanlar · Sunucusuz ve Olay Odaklı Mimariler →

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

Amazon'a göz atın →