Amazon SAA-C03: Container e Orchestrazione — Guida allo studio

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

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Scegliere tra ECS ed EKS, e tra EC2 e Fargate

La prima decisione architetturale per qualsiasi carico di lavoro containerizzato su AWS è la scelta dell’orchestratore e della modalità di calcolo. Amazon ECS è un orchestratore proprietario di AWS con una stretta integrazione con IAM, ALB/NLB, CloudWatch, Service Discovery e il networking VPC. Non ha costi per il control plane ed è il percorso più rapido verso la produzione per i team che non necessitano di strumenti specifici di Kubernetes. I task sono unità di uno o più container che condividono un ciclo di vita; i servizi sono insiemi di task gestiti a esecuzione prolungata, controllati da uno scheduler. Amazon EKS esegue una versione di Kubernetes conforme all’upstream a un costo fisso di 0,10 $ all’ora per cluster, ed è la scelta corretta quando i carichi di lavoro devono rimanere portabili, usare l’API di Kubernetes o sfruttare l’ecosistema CNCF (Helm, CRD, Operator). Il control plane — API server, etcd, controller manager, scheduler — viene aggiornato (patched), sottoposto a backup e reso altamente disponibile da AWS su tre AZ.

Entrambi gli orchestratori accettano due modalità di calcolo. AWS Fargate esegue ogni task o pod su microVM Firecracker isolate; non ci sono AMI da aggiornare, nessun capacity provider di Auto Scaling Group da ottimizzare, nessuna decisione di bin-packing, nessun host accessibile tramite SSH. Si paga al secondo per vCPU e al secondo per GB del task. Il launch type EC2 / managed node group significa che le istanze sono di tua proprietà, con la flessibilità e l’onere operativo che ciò comporta.

Fargate è la scelta predefinita corretta ogni volta che uno scenario enfatizza “serverless”, “minimo overhead operativo” o “nessuna infrastruttura da gestire”, a condizione che il carico di lavoro rispetti i suoi vincoli: massimo 16 vCPU / 120 GB di memoria per task, nessuna GPU, nessun container privilegiato, nessun DaemonSet, nessuna direttiva HostPort/HostNetwork, nessuna personalizzazione a livello di host Windows. Scegli i managed node group o il launch type EC2 quando hai bisogno di GPU, DaemonSet che richiedono accesso all’host, AMI personalizzate, container Windows Server con GMSA, efficienza di bin-packing sotto il secondo o un’ottimizzazione dei costi aggressiva basata su Spot.

La trappola classica è scegliere i nodi EC2 perché “sembrano” più economici. Per carichi di lavoro con picchi (spiky) o a basso utilizzo, Fargate è spesso più economico se si considerano la capacità inutilizzata e il tempo di ingegneria per l’aggiornamento delle AMI, il draining dei nodi e la configurazione del cluster autoscaler — tutte attività che Fargate elimina.

Definizioni dei Task, Posizionamento e Capacity Provider

Una definizione di task canonica per ECS Fargate cattura gli elementi essenziali: dimensionamento di CPU/memoria, un execution role per il pull delle immagini e la scrittura dei log, la modalità di rete awsvpc e il collegamento con 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

Su ECS con EC2, le strategie di posizionamento dei task (task placement strategies) decidono come i task vengono distribuiti tra le istanze. Si compongono in ordine:

I vincoli di posizionamento (placement constraints) come distinctInstance o memberOf, utilizzando il linguaggio di query del cluster, restringono ulteriormente i candidati.

I Capacity provider disaccoppiano i servizi dagli Auto Scaling Group sottostanti. FARGATE e FARGATE_SPOT sono provider gestiti; i provider personalizzati incapsulano (wrap) un ASG e abilitano il managed scaling in modo che ECS adegui il desired count dell’ASG in base al numero di task forniti. Una strategia di capacity provider suddivide i task per peso (weight) e base — ad esempio, garantendo due task Fargate on-demand e suddividendo il resto in un rapporto 1:4 con Fargate Spot per carichi di lavoro tolleranti alle interruzioni:

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

Autoscaling: Pod, Task e Nodi

Fargate elimina la gestione dei nodi, ma non scala automaticamente il numero di task o pod. Questa distinzione è l’equivoco più comune su Fargate: il serverless si applica al livello dell’host, mai al desired count del tuo servizio. L’autoscaling a livello di servizio rimane una tua responsabilità.

Per ECS, si usa Application Auto Scaling. Il target tracking è l’impostazione predefinita idiomatica perché crea automaticamente gli allarmi CloudWatch di scale-out e scale-in e rispetta i periodi di cooldown. Metriche sensate sono ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization e 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"}}'

Lo step scaling e lo scheduled scaling rimangono disponibili per curve di risposta non lineari o per finestre di traffico note.

Per EKS su nodi EC2, la dimensione dei pod è gestita dall’Horizontal Pod Autoscaler (HPA), che regola il numero di repliche in base a CPU, memoria o metriche personalizzate. L’HPA da solo non può aggiungere nodi — aumenterà tranquillamente le repliche oltre la capacità del cluster, a quel punto i nuovi pod entreranno nello stato Pending con eventi FailedScheduling. Ecco perché l’HPA su EC2 deve essere sempre abbinato al Kubernetes Cluster Autoscaler o a Karpenter. Dimenticare questo abbinamento è un errore di progettazione frequente: l’HPA riporta “scalato a 20 repliche” mentre metà di esse sono bloccate in stato pending. Una configurazione minima del Cluster Autoscaler rileva i node group tramite i tag degli ASG:

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

Con i profili Fargate questo problema scompare — ogni pod diventa la sua microVM, quindi la dimensione dello scaling dei nodi è completamente eliminata. Questo è esattamente il motivo per cui Fargate è la scelta corretta per carichi di lavoro con picchi (bursty) e con un numero di pod imprevedibile.

Profili Fargate e Limiti delle Loro Funzionalità

Un profilo Fargate in EKS è un selettore — namespace più etichette opzionali dei pod — che indica a EKS di schedulare i pod corrispondenti su Fargate anziché su un nodo:

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

L’avvertenza fondamentale è che EKS su Fargate non supporta l’intera gamma di funzionalità di Kubernetes:

• I DaemonSet non vengono eseguiti. Senza un nodo su cui eseguire il demone, i log shipper come i DaemonSet fluentd devono essere sostituiti con sidecar o con il log router integrato Fluent Bit.
• I container privilegiati, HostPort e HostNetwork non sono disponibili.
• Lo storage persistente è limitato a EFS tramite il driver CSI. EBS non è supportato perché i volumi EBS richiedono di essere collegati a un’istanza EC2 specifica.
• I carichi di lavoro GPU non sono supportati.
• I servizi NodePort e le service mesh che si basano su init container privilegiati non funzionano.

Presumere la parità di funzionalità porta a migrazioni fallite di StatefulSet che necessitano di EBS, di controller di ingress che usano hostPort o di carichi di lavoro di inferenza GPU.

Ingress: ALB vs NLB tramite l’AWS Load Balancer Controller

L’AWS Load Balancer Controller è un controller Kubernetes che traduce gli oggetti Ingress e Service in ALB e NLB reali. Per i microservizi HTTP/HTTPS con routing basato su percorso o host, creare un singolo Ingress di classe alb. Un singolo ALB che funge da frontend per molti servizi (tramite alb.ingress.kubernetes.io/group.name) è drasticamente più economico rispetto a un ALB per servizio e rappresenta il modello canonico per l’efficienza dei costi:

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

Utilizzare un NLB (Service di tipo LoadBalancer con service.beta.kubernetes.io/aws-load-balancer-type: external e target type nlb-ip) per TCP, UDP, pass-through TLS, requisiti di IP statici o throughput estremo a Layer 4. Mettere un proxy per database gRPC-su-HTTP/2 o plain-TCP dietro un ALB va bene solo per gRPC (l’ALB supporta HTTP/2 e gRPC); l’ALB non può terminare TCP arbitrario o alcun tipo di UDP. Tentare di servire traffico di gioco UDP attraverso un ALB è un disallineamento di protocollo che deve essere individuato in fase di progettazione.

IAM a Livello di Pod con IRSA

IAM Roles for Service Accounts (IRSA) è il meccanismo corretto per concedere permessi API AWS a singoli pod. Collegare il profilo dell’istanza del nodo per dare ai pod l’accesso a S3 è sbagliato, perché ogni pod sul nodo eredita tali permessi, violando il principio del privilegio minimo. IRSA funziona federando l’OIDC provider del cluster con IAM: creare l’OIDC provider una volta, poi creare un ruolo IAM la cui policy di trust si fidi di quel provider per un soggetto specifico namespace:serviceaccount.

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

Il service account viene annotato con eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, e i pod che lo montano ricevono credenziali STS a breve termine tramite un token proiettato. Saltare l’associazione dell’OIDC provider o omettere l’annotazione causa un fallback silenzioso al ruolo del nodo — una sottile regressione di sicurezza facile da non notare in fase di revisione.

Il plugin VPC CNI completa questo meccanismo assegnando a ogni pod un indirizzo ENI/IP instradabile nella sottorete del VPC. I pod possono quindi comunicare direttamente con RDS, ElastiCache o endpoint VPC utilizzando i security group, e CloudTrail vede l’IP effettivo del pod per scopi di auditing.

Storage Persistente ed Effimero

La scelta dello storage dipende dalla modalità di accesso, dalla durabilità e dal tipo di avvio.

EBS (tramite il driver EBS CSI su EKS, o EBS collegato al task su ECS) fornisce volumi a blocchi ReadWriteOnce per carichi di lavoro stateful a singolo pod, come un database primario Postgres. EFS fornisce storage NFS ReadWriteMany che è regionale, multi-AZ e montabile da molti pod simultaneamente — la scelta corretta ogni volta che il requisito menziona “altamente disponibile, tollerante ai guasti, condiviso tra più container” o artefatti di ML condivisi. FSx for Lustre gestisce HPC ad alto throughput; FSx for NetApp ONTAP e FSx for Windows File Server gestiscono NFS/SMB di livello enterprise.

I task Fargate ricevono 20 GB di storage effimero per impostazione predefinita, configurabili fino a 200 GB tramite ephemeralStorage.sizeInGiB sulla piattaforma 1.4.0+. Presumere che Fargate abbia sempre “abbondante spazio temporaneo” è una trappola: un container di terze parti che scrive 50 GB di file intermedi potrebbe rientrare nello storage effimero espanso, ma se il requisito è di 50 GB di storage condiviso o durevole tra i riavvii del task o tra più task, lo storage effimero è la scelta sbagliata perché viene distrutto all’arresto del task e non è mai condiviso. Fargate non supporta EBS. Se un carico di lavoro Fargate necessita di storage persistente o condiviso, EFS è essenzialmente l’unica opzione supportata.

Per ECS, montare EFS direttamente nella definizione del task; i punti di accesso applicano UID/GID POSIX e una directory radice per ogni task, fornendo un multi-tenancy sicuro su un singolo file system, e l’autorizzazione IAM limita l’ambito a 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"
  }]
}]

Per EKS, collegare EFS tramite una StorageClass:

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"

Una trappola ricorrente: selezionare Fargate per un carico di lavoro stateful dimenticando di installare il driver EFS CSI e la StorageClass — i pod si avviano ma le PersistentVolumeClaim rimangono in stato Pending per sempre. Al contrario, scegliere nodi EC2 solo per collegare EBS quando il requisito è uno storage condiviso multi-writer è altrettanto sbagliato; un volume EBS io2 collegato a un nodo non può essere condiviso tra più AZ.

Scansione delle Immagini e Ciclo di Vita in ECR

Amazon ECR offre due modalità di scansione. La scansione di base utilizza il database open-source Clair e viene eseguita al momento del push (o su richiesta) senza costi aggiuntivi. La scansione avanzata si integra con Amazon Inspector, monitora continuamente le CVE sia del sistema operativo che dei pacchetti dei linguaggi di programmazione e riporta i risultati in Security Hub. Per “scansionare le CVE, scansionare le nuove immagini alla creazione, con il minor numero di modifiche ai carichi di lavoro”, l’azione corretta è abilitare la scansione al push a livello di repository — non è richiesta alcuna modifica alla pipeline perché l’evento di push attiva la scansione:

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

La CI/CD chiama quindi describe-image-scan-findings e fa fallire le build in caso di conteggi CRITICAL o HIGH. Saltare la scansione significa eseguire in produzione CVE non patchate di Log4j, OpenSSL o glibc; il costo di mitigazione del non scansionare è enormemente superiore al costo quasi nullo della sua abilitazione.

Le policy del ciclo di vita limitano i costi di storage e impongono una corretta gestione dei tag:

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

Migrazione di carichi di lavoro Kubernetes + MongoDB

Quando si esegue una migrazione di tipo lift-and-shift di uno stack Kubernetes + MongoDB self-hosted su AWS con i vincoli di “non modificare il codice dell’applicazione” e “minimo sovraccarico operativo”, due decisioni si allineano. Primo, il livello di calcolo viene spostato su EKS perché la compatibilità con l’API di Kubernetes significa che i manifest e i chart di Helm possono essere trasferiti senza modifiche; utilizzare i profili Fargate per i servizi stateless per eliminare la gestione dei nodi.

Secondo, MongoDB stesso non dovrebbe essere ri-ospitato su istanze EC2 autogestite o StatefulSet: ciò reintrodurrebbe backup, sharding, failover e patching come oneri operativi. Utilizzare Amazon DocumentDB (con compatibilità MongoDB), che parla il protocollo wire di MongoDB 3.6/4.0/5.0, quindi i driver e le stringhe di connessione esistenti funzionano con modifiche minime.

L’avvertenza sulla compatibilità è importante. DocumentDB emula la superficie API di MongoDB ma non è MongoDB. Alcuni operatori di aggregazione, tipi di indici specifici, la semantica dei change stream e le funzionalità introdotte nelle versioni più recenti di MongoDB potrebbero non funzionare. Il passo corretto prima della migrazione è eseguire lo strumento di compatibilità di DocumentDB (compat.py) sull’applicazione per confermare che ogni operazione sia supportata. Scegliere DynamoDB al suo posto forzerebbe una riscrittura del modello dei dati; scegliere RDS romperebbe completamente il modello a documenti. Entrambi violano il vincolo di “nessuna modifica al codice”.

Opzioni Ibride: ECS Anywhere e EKS Anywhere

ECS Anywhere registra i server on-premise (o le VM di altri cloud) come istanze esterne in un cluster ECS. Il control plane rimane in AWS; l’SSM Agent e l’ECS Agent sull’istanza esterna si connettono in uscita (outbound). Un’unica pipeline di deployment, un’unica definizione di task e un unico set di ruoli IAM coprono sia i carichi di lavoro nel cloud che quelli on-premise.

EKS Anywhere installa una distribuzione Kubernetes conforme sul proprio hardware (tipicamente vSphere o bare metal), opzionalmente con visibilità nella console AWS tramite l’EKS Connector. Scegliere ECS Anywhere per un approccio ibrido leggero, basato su definizioni di task; scegliere EKS Anywhere quando vincoli normativi o di latenza richiedono Kubernetes in locale con gli stessi strumenti di EKS nel cloud. Entrambi mantengono l’orchestrazione coerente: il valore fondamentale è che i team evitano di mantenere due sistemi di CI/CD o due modelli mentali.

Visibilità Multi-Cluster con l’EKS Connector

Le organizzazioni gestiscono spesso un mix di cluster EKS, Kubernetes autogestiti su EC2 e cluster on-premise. L’Amazon EKS Connector registra qualsiasi cluster Kubernetes conforme nella console EKS, fornendo un pannello di controllo unificato (single pane of glass) per nodi, carichi di lavoro e metadati del cluster. È essenzialmente un agent leggero più un canale SSM: la risposta a basso sovraccarico per avere una “vista centralizzata di tutti i cluster”. Costruire una visibilità equivalente con Rancher, Anthos autogestiti o una federazione personalizzata di Prometheus/Grafana è fattibile ma molto più costoso dal punto di vista operativo e non si integra con IAM o con l’accesso basato sulla console.

L’EKS Connector è strettamente un livello di visibilità; non gestisce né aggiorna il cluster remoto, che è esattamente ciò che implica una “vista centralizzata con il minimo sovraccarico”.

Mettere Insieme i Pattern

Per un carico di lavoro di e-commerce con un front-end bilanciato, un middle tier containerizzato e uno store relazionale, dove il criterio è “il minor intervento manuale possibile”, lo stack canonico è ALB → ECS su Fargate → Aurora Serverless v2. Ogni livello elimina la gestione a livello di istanza: l’ALB è completamente gestito, Fargate rimuove gli host e Aurora Serverless v2 scala in ACU senza dimensionamento delle istanze.

Per una piattaforma di microservizi in cui il team “non può gestire infrastruttura aggiuntiva”, la combinazione corretta è ECS o EKS con Fargate, più un servizio dati completamente gestito. La selezione del tipo di avvio EC2 o di gruppi di nodi autogestiti contraddice il vincolo, anche se tecnicamente il carico di lavoro funzionerebbe.

Per una migrazione di tipo lift-and-shift di Kubernetes + MongoDB, la risposta converge su EKS + DocumentDB: l’API di Kubernetes preserva i metodi di deployment, DocumentDB preserva la compatibilità dei driver e i profili Fargate preservano un’operatività minima, a condizione che l’utilizzo delle funzionalità di Kubernetes e la superficie dei comandi MongoDB del carico di lavoro rientrino negli ambiti supportati descritti sopra.

← Calcolo · Tutti i domini · Architetture Serverless e Guidate dagli Eventi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →