Amazon SAA-C03: Container & Orchestrierung — Lernleitfaden

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

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Die Wahl zwischen ECS und EKS sowie zwischen EC2 und Fargate

Die erste Architekturentscheidung für jeden Container-Workload auf AWS ist die Wahl des Orchestrators und des Rechenmodus. Amazon ECS ist ein proprietärer AWS-Orchestrator mit enger Integration in IAM, ALB/NLB, CloudWatch, Service Discovery und VPC-Networking. Es gibt keine Gebühr für die Steuerungsebene und es ist der schnellste Weg in die Produktion für Teams, die keine Kubernetes-spezifischen Werkzeuge benötigen. Tasks sind Einheiten aus einem oder mehreren Containern, die einen gemeinsamen Lebenszyklus haben; Services sind langlebige, verwaltete Task-Gruppen, die von einem Scheduler gesteuert werden. Amazon EKS führt Upstream-konformes Kubernetes zu einem Pauschalpreis von 0,10 $/Stunde pro Cluster aus und ist die richtige Wahl, wenn Workloads portabel bleiben, die Kubernetes-API verwenden oder das CNCF-Ökosystem (Helm, CRDs, Operators) nutzen müssen. Die Steuerungsebene – API-Server, etcd, Controller-Manager, Scheduler – wird von AWS gepatcht, gesichert und über drei AZs hochverfügbar gemacht.

Beide Orchestratoren akzeptieren zwei Rechenmodi. AWS Fargate führt jeden Task oder Pod auf isolierten Firecracker-MicroVMs aus; es gibt keine AMIs zu patchen, keine Auto Scaling Group Capacity Provider abzustimmen, keine Bin-Packing-Entscheidungen und keine per SSH zugänglichen Hosts. Sie zahlen pro vCPU-Sekunde und GB-Sekunde des Tasks. EC2-Starttyp / verwaltete Knotengruppen bedeutet, dass Sie die Instanzen besitzen, mit der damit verbundenen Flexibilität und dem Betriebsaufwand.

Fargate ist die richtige Standardwahl, wenn ein Szenario „serverless“, „minimalen Betriebsaufwand“ oder „keine zu verwaltende Infrastruktur“ betont, vorausgesetzt, der Workload passt zu seinen Einschränkungen: maximal 16 vCPU / 120 GB Arbeitsspeicher pro Task, keine GPU, keine privilegierten Container, keine DaemonSets, kein HostPort/HostNetwork, keine Anpassung auf Windows-Hostebene. Wählen Sie verwaltete Knotengruppen oder den EC2-Starttyp, wenn Sie GPUs, DaemonSets, die Host-Zugriff erfordern, benutzerdefinierte AMIs, Windows-Server-Container mit GMSA, Bin-Packing-Effizienz im Sub-Sekunden-Bereich oder aggressive, Spot-basierte Kostenoptimierung benötigen.

Die klassische Falle ist die Wahl von EC2-Knoten, weil sie sich „billiger anfühlen“. Für Workloads mit Lastspitzen oder geringer Auslastung ist Fargate oft günstiger, wenn man die ungenutzte Kapazität sowie den Engineering-Aufwand für das Patchen von AMIs, das Leeren von Knoten (Node Draining) und die Konfiguration des Cluster-Autoscalers mit einberechnet – all das entfällt bei Fargate.

Task-Definitionen, Platzierung und Capacity Provider

Eine kanonische ECS-Fargate-Task-Definition erfasst die wesentlichen Elemente – CPU-/Arbeitsspeicher-Dimensionierung, eine Ausführungsrolle (Execution Role) zum Abrufen von Images und Schreiben von Protokollen, den awsvpc-Netzwerkmodus und die Anbindung an CloudWatch Logs:

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

Bei ECS mit EC2 entscheiden Task-Platzierungsstrategien (Task Placement Strategies), wie Tasks auf Instanzen verteilt werden. Sie werden der Reihe nach angewendet:

Platzierungsbeschränkungen (Placement Constraints) wie distinctInstance oder memberOf unter Verwendung der Cluster-Abfragesprache schränken die Kandidaten weiter ein.

Capacity Provider entkoppeln Services von reinen Auto Scaling Groups. FARGATE und FARGATE_SPOT sind verwaltete Provider; benutzerdefinierte Provider umschließen eine ASG und ermöglichen Managed Scaling, sodass ECS die gewünschte Anzahl (Desired Count) der ASG basierend auf der Anzahl der bereitgestellten Tasks anpasst. Eine Capacity-Provider-Strategie teilt Tasks nach Gewichtung (Weight) und Basis (Base) auf – zum Beispiel, indem zwei On-Demand-Fargate-Tasks garantiert und der Rest im Verhältnis 1:4 auf Fargate Spot für unterbrechungstolerante Workloads aufgeteilt wird:

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

Autoscaling: Pods, Tasks und Knoten

Fargate eliminiert die Knotenverwaltung, aber es skaliert nicht automatisch die Anzahl der Tasks oder Pods. Diese Unterscheidung ist das am häufigsten missverstandene Konzept bei Fargate: Serverless bezieht sich auf die Host-Ebene, niemals auf die gewünschte Anzahl Ihres Services. Sie sind weiterhin für das Autoscaling auf Service-Ebene verantwortlich.

Für ECS verwenden Sie Application Auto Scaling. Target Tracking ist der idiomatische Standard, da es die CloudWatch-Alarme für Scale-Out und Scale-In automatisch erstellt und Cooldown-Perioden berücksichtigt. Sinnvolle Metriken sind ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization und ALBRequestCountPerTarget:

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"}}'

Step Scaling und Scheduled Scaling bleiben für nicht-lineare Antwortkurven oder bekannte Zeitfenster mit hohem Datenverkehr verfügbar.

Bei EKS auf EC2-Knoten wird die Pod-Dimension vom Horizontal Pod Autoscaler (HPA) gehandhabt, der die Anzahl der Replicas basierend auf CPU-, Arbeitsspeicher- oder benutzerdefinierten Metriken anpasst. Der HPA allein kann keine Knoten hinzufügen – er wird die Anzahl der Replicas problemlos über die Cluster-Kapazität hinaus erhöhen, woraufhin neue Pods mit FailedScheduling-Ereignissen in den Pending-Status wechseln. Deshalb muss der HPA auf EC2 immer entweder mit dem Kubernetes Cluster Autoscaler oder mit Karpenter gekoppelt werden. Diese Kopplung zu vergessen ist ein häufiger Designfehler: Der HPA meldet „auf 20 Replicas skaliert“, während die Hälfte davon im Pending-Status feststeckt. Eine minimale Konfiguration des Cluster Autoscalers erkennt Knotengruppen über ASG-Tags:

- --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

Bei Fargate-Profilen verschwindet dieses Problem – jeder Pod wird zu seiner eigenen MicroVM, sodass die Dimension der Knotenskalierung vollständig entfällt. Genau aus diesem Grund ist Fargate die richtige Wahl für stoßweise Workloads mit unvorhersehbarer Pod-Anzahl.

Fargate-Profile und ihre Feature-Einschränkungen

Ein Fargate-Profil in EKS ist ein Selektor – Namespace plus optionale Pod-Labels – der EKS anweist, passende Pods auf Fargate anstatt auf einem Node zu planen:

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

Der entscheidende Vorbehalt ist, dass EKS on Fargate nicht die volle Feature-Oberfläche von Kubernetes unterstützt:

• DaemonSets werden nicht ausgeführt. Da es keinen Node gibt, auf dem ein Daemon laufen könnte, müssen Log-Shipper wie fluentd-DaemonSets durch Sidecars oder den integrierten Fluent-Bit-Log-Router ersetzt werden.
• Privilegierte Container, HostPort und HostNetwork sind nicht verfügbar.
• Persistenter Speicher ist auf EFS über den CSI-Treiber beschränkt. EBS wird nicht unterstützt, da EBS-Volumes an eine bestimmte EC2-Instanz angehängt werden müssen.
• GPU-Workloads werden nicht unterstützt.
• NodePort-Services und Service Meshes, die auf privilegierten Init-Containern basieren, funktionieren nicht.

Die Annahme von Feature-Parität führt zu fehlgeschlagenen Migrationen von StatefulSets, die EBS benötigen, Ingress-Controllern, die hostPort verwenden, oder GPU-Inferenz-Workloads.

Ingress: ALB vs. NLB über den AWS Load Balancer Controller

Der AWS Load Balancer Controller ist ein Kubernetes-Controller, der Ingress- und Service-Objekte in echte ALBs und NLBs übersetzt. Für HTTP/HTTPS-Microservices mit pfad- oder hostbasiertem Routing erstellen Sie ein einzelnes Ingress der Klasse alb. Ein ALB, der viele Services bedient (über alb.ingress.kubernetes.io/group.name), ist erheblich günstiger als ein ALB pro Service und stellt das kanonische kosteneffiziente Muster dar:

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 }}}

Verwenden Sie einen NLB (Service vom Typ LoadBalancer mit service.beta.kubernetes.io/aws-load-balancer-type: external und Zieltyp nlb-ip) für TCP, UDP, TLS-Pass-Through, Anforderungen an statische IPs oder extremen Layer-4-Durchsatz. Einen gRPC-über-HTTP/2- oder einen reinen TCP-Datenbank-Proxy hinter einen ALB zu schalten, ist nur für gRPC in Ordnung (ALB unterstützt HTTP/2 und gRPC); ALB kann kein beliebiges TCP oder UDP terminieren. Der Versuch, UDP-Spiele-Traffic über einen ALB zu bedienen, ist ein Protokoll-Mismatch, der bereits in der Designphase erkannt werden muss.

IAM auf Pod-Ebene mit IRSA

IAM Roles for Service Accounts (IRSA) ist der korrekte Mechanismus, um einzelnen Pods AWS-API-Berechtigungen zu erteilen. Das Anhängen des Instanzprofils des Nodes, um Pods S3-Zugriff zu gewähren, ist falsch, da jeder Pod auf dem Node diese Berechtigungen erbt, was das Prinzip des geringsten Privilegs (Least Privilege) verletzt. IRSA funktioniert durch die Föderation des OIDC-Providers des Clusters mit IAM: Erstellen Sie den OIDC-Provider einmal und dann eine IAM-Rolle, deren Vertrauensrichtlinie diesem Provider für ein bestimmtes namespace:serviceaccount-Subjekt vertraut.

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

Das Service-Account wird mit eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role annotiert, und Pods, die es einbinden, erhalten kurzlebige STS-Anmeldeinformationen durch ein projiziertes Token. Das Überspringen der OIDC-Provider-Assoziation oder das Weglassen der Annotation führt zu einem stillen Fallback auf die Node-Rolle – eine subtile Sicherheitsregression, die bei einer Überprüfung leicht zu übersehen ist.

Das VPC CNI Plugin ergänzt dies, indem es jedem Pod eine routbare ENI/IP-Adresse im VPC-Subnetz zuweist. Pods können dann direkt mit RDS, ElastiCache oder VPC-Endpunkten über Sicherheitsgruppen kommunizieren, und CloudTrail sieht die tatsächliche IP des Pods für Auditing-Zwecke.

Persistenter und ephemerer Speicher

Die Wahl des Speichers hängt vom Zugriffsmodus, der Beständigkeit und dem Starttyp ab.

EBS (über den EBS-CSI-Treiber auf EKS oder als Task-angehängtes EBS auf ECS) bietet ReadWriteOnce-Block-Volumes für zustandsbehaftete Workloads mit einem einzigen Pod, wie z. B. eine Postgres-Primary-Instanz. EFS bietet ReadWriteMany-NFS-Speicher, der regional, Multi-AZ-fähig und von vielen Pods gleichzeitig einbindbar ist – die richtige Wahl, wenn die Anforderung „hochverfügbar, fehlertolerant, von mehreren Containern gemeinsam genutzt“ oder gemeinsam genutzte ML-Artefakte lautet. FSx for Lustre ist für High-Throughput-Computing (HPC) zuständig; FSx for NetApp ONTAP und FSx for Windows File Server bedienen Enterprise-NFS/SMB.

Fargate-Tasks erhalten standardmäßig 20 GB ephemeren Speicher, der über ephemeralStorage.sizeInGiB auf Plattform 1.4.0+ auf bis zu 200 GB konfiguriert werden kann. Anzunehmen, dass Fargate immer „genügend temporären Speicherplatz“ hat, ist eine Falle: Ein Anbieter-Container, der 50 GB an Zwischendateien schreibt, passt möglicherweise in den erweiterten ephemeren Speicher, aber wenn die Anforderung 50 GB gemeinsam genutzter oder dauerhafter Speicher über Task-Neustarts oder über mehrere Tasks hinweg ist, ist ephemerer Speicher falsch, da er beim Stoppen des Tasks zerstört und niemals geteilt wird. Fargate unterstützt kein EBS. Wenn ein Fargate-Workload persistenten oder gemeinsam genutzten Speicher benötigt, ist EFS im Wesentlichen die einzige unterstützte Option.

Für ECS binden Sie EFS direkt in der Task-Definition ein; Zugriffspunkte erzwingen POSIX UID/GID und ein Stammverzeichnis pro Task, was eine sichere Mandantenfähigkeit auf einem einzigen Dateisystem ermöglicht, und IAM-Autorisierung beschränkt den Geltungsbereich auf elasticfilesystem:ClientMount:

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

Für EKS binden Sie EFS über eine StorageClass ein:

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"

Eine wiederkehrende Falle: Fargate für einen zustandsbehafteten Workload auszuwählen und dabei zu vergessen, den EFS-CSI-Treiber und die StorageClass zu installieren – die Pods starten, aber die PersistentVolumeClaims bleiben für immer im Status Pending. Umgekehrt ist es ebenfalls falsch, EC2-Nodes nur deshalb zu wählen, um EBS anzuhängen, wenn die Anforderung ein gemeinsam genutzter Speicher mit mehreren Schreibzugriffen ist; ein an einen Node angehängtes EBS io2 kann nicht über AZs hinweg geteilt werden.

ECR Image-Scanning und Lebenszyklus

Amazon ECR bietet zwei Scan-Modi. Basis-Scanning verwendet die Open-Source-Datenbank Clair und wird bei einem Push (oder bei Bedarf) kostenlos ausgeführt. Erweitertes Scanning integriert Amazon Inspector, überwacht kontinuierlich auf CVEs sowohl im Betriebssystem als auch in Sprachpaketen und meldet die Ergebnisse an Security Hub. Für die Anforderung „nach CVEs scannen, neue Images bei Erstellung scannen, möglichst wenige Änderungen an Workloads“ ist die richtige Maßnahme, das Scannen bei Push auf Repository-Ebene zu aktivieren – es ist keine Änderung an der Pipeline erforderlich, da das Push-Ereignis den Scan auslöst:

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

CI/CD ruft dann describe-image-scan-findings auf und lässt Builds bei CRITICAL- oder HIGH-Zählern fehlschlagen. Das Überspringen des Scannens bedeutet, dass ungepatchte Log4j-, OpenSSL- oder glibc-CVEs in der Produktion ausgeführt werden; die Kosten für die Behebung der Folgen des Nicht-Scannens stellen die quasi nicht vorhandenen Kosten für die Aktivierung bei weitem in den Schatten.

Lebenszyklusrichtlinien begrenzen die Speicherkosten und erzwingen eine saubere Tag-Verwaltung:

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

Migration von Kubernetes- und MongoDB-Workloads

Bei der Migration eines selbst gehosteten Kubernetes- und MongoDB-Stacks zu AWS unter den Einschränkungen „keine Änderung am Anwendungscode“ und „minimaler Betriebsaufwand“ bieten sich zwei Entscheidungen an. Erstens wird die Compute-Ebene auf EKS verlagert, da die Kompatibilität der Kubernetes-API bedeutet, dass Manifeste und Helm-Charts unverändert übernommen werden können; verwenden Sie Fargate-Profile für die zustandslosen Dienste, um die Verwaltung von Nodes zu eliminieren.

Zweitens sollte MongoDB selbst nicht auf selbstverwalteten EC2-Instanzen oder StatefulSets neu gehostet werden – da dies Backups, Sharding, Failover und Patching als betriebliche Belastungen wieder einführen würde. Verwenden Sie Amazon DocumentDB (mit MongoDB-Kompatibilität), das das MongoDB 3.6/4.0/5.0 Wire-Protokoll spricht, sodass bestehende Treiber und Verbindungszeichenfolgen mit minimalen Änderungen funktionieren.

Der Kompatibilitätshinweis ist wichtig. DocumentDB emuliert die API-Oberfläche von MongoDB, ist aber nicht MongoDB. Bestimmte Aggregationsoperatoren, spezifische Indextypen, die Semantik von Change Streams und Funktionen, die in neueren MongoDB-Versionen eingeführt wurden, können fehlschlagen. Der korrekte Schritt vor der Migration ist die Ausführung des DocumentDB-Kompatibilitätstools (compat.py) gegen die Anwendung, um zu bestätigen, dass jeder Vorgang unterstützt wird. Die Wahl von DynamoDB würde stattdessen eine Neugestaltung des Datenmodells erzwingen; die Wahl von RDS würde das Dokumentenmodell vollständig zerstören. Beide verstoßen gegen die Einschränkung „keine Code-Änderung“.

Hybride Optionen: ECS Anywhere und EKS Anywhere

ECS Anywhere registriert lokale Server (oder VMs anderer Clouds) als externe Instanzen in einem ECS-Cluster. Die Control Plane verbleibt in AWS; der SSM Agent und der ECS Agent auf der externen Instanz stellen eine ausgehende Verbindung her. Eine Deployment-Pipeline, eine Task-Definition und ein Satz von IAM-Rollen decken sowohl Cloud- als auch On-Premises-Workloads ab.

EKS Anywhere installiert eine konforme Kubernetes-Distribution auf Ihrer Hardware (typischerweise vSphere oder Bare Metal), optional mit Sichtbarkeit durch den EKS Connector in der AWS-Konsole. Wählen Sie ECS Anywhere für einen leichtgewichtigen, auf Task-Definitionen basierenden hybriden Ansatz; wählen Sie EKS Anywhere, wenn regulatorische oder Latenzanforderungen Kubernetes lokal mit denselben Tools wie EKS in der Cloud erfordern. Beide sorgen für eine konsistente Orchestrierung – der grundlegende Wert besteht darin, dass Teams die Wartung von zwei CI/CD-Systemen oder zwei mentalen Modellen vermeiden.

Multi-Cluster-Sichtbarkeit mit dem EKS Connector

Unternehmen betreiben häufig eine Mischung aus EKS-Clustern, selbstverwaltetem Kubernetes auf EC2 und On-Premises-Clustern. Der Amazon EKS Connector registriert jeden konformen Kubernetes-Cluster in der EKS-Konsole und bietet so eine zentrale Übersicht (Single Pane of Glass) für Nodes, Workloads und Cluster-Metadaten. Es handelt sich im Wesentlichen um einen leichtgewichtigen Agenten plus einen SSM-Kanal – die Antwort mit geringem Overhead für eine „zentrale Ansicht aller Cluster“. Der Aufbau einer gleichwertigen Sichtbarkeit mit selbst gehostetem Rancher, Anthos oder einer benutzerdefinierten Prometheus/Grafana-Föderation ist machbar, aber betrieblich weitaus aufwändiger und lässt sich nicht mit IAM oder dem konsolenbasierten Zugriff integrieren.

Der EKS Connector ist ausschließlich eine Sichtbarkeitsschicht; er verwaltet oder aktualisiert den Remote-Cluster nicht, was genau dem Prinzip „zentrale Ansicht mit geringstem Aufwand“ entspricht.

Das Zusammenspiel der Muster

Für einen E-Commerce-Workload mit einem Load-Balancer-Frontend, einer containerisierten mittleren Schicht und einem relationalen Speicher, bei dem „so wenig manuelle Eingriffe wie möglich“ das Kriterium ist, ist der kanonische Stack ALB → ECS on Fargate → Aurora Serverless v2. Jede Schicht eliminiert die Verwaltung auf Instanzebene: Der ALB ist vollständig verwaltet, Fargate beseitigt die Notwendigkeit von Hosts und Aurora Serverless v2 skaliert in ACUs ohne manuelle Instanzgrößenanpassung.

Für eine Microservices-Plattform, bei der das Team „keine zusätzliche Infrastruktur verwalten kann“, ist die richtige Kombination ECS oder EKS mit Fargate sowie ein vollständig verwalteter Datendienst. Die Auswahl des EC2-Starttyps oder selbstverwalteter Node-Gruppen widerspricht dieser Einschränkung, auch wenn der Workload technisch gesehen laufen würde.

Für eine Lift-and-Shift-Migration von Kubernetes + MongoDB läuft die Antwort auf EKS + DocumentDB hinaus: Die Kubernetes-API bewahrt die Deployment-Methoden, DocumentDB bewahrt die Treiberkompatibilität und Fargate-Profile bewahren den minimalen Betriebsaufwand – vorausgesetzt, die Nutzung von Kubernetes-Funktionen und die Befehlsoberfläche von MongoDB des Workloads fallen in den oben beschriebenen unterstützten Rahmen.

← Compute · Alle Domänen · Serverless →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →