Amazon DOP-C02: Pipeline CI/CD e Strategie di Deployment — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Un solido sistema di CI/CD su AWS unisce controllo di versione, build, test, governance degli artefatti, orchestrazione del deployment e strategie di rilascio sicure su più account e Regioni. I servizi gestiti principali—CodeCommit, CodeArtifact, CodeBuild, CodePipeline e CodeDeploy—eliminano la manutenzione dei server, si integrano strettamente con IAM e KMS e forniscono supporto di prima classe per deployment blue/green, canary, rolling e in-place su EC2/Auto Scaling, ECS e Lambda. Pipeline efficaci si basano anche su trigger precisi (webhook, EventBridge, pianificazioni), una gestione disciplinata degli artefatti, caching delle build per la velocità e uno spostamento del traffico mirato (opinionated) con allarmi di integrità per il rollback automatico. Per le aziende, i pattern cross-account e cross-Region sono obbligatori e richiedono l’assunzione di ruoli (role assumption), archivi di artefatti regionali e policy di crittografia coerenti.

Orchestrazione con AWS Developer Tools

Utilizzare CodeCommit come servizio Git privato e ad alta disponibilità. Si integra con EventBridge per gli eventi dei repository e delle pull request, supporta template di regole di approvazione e utilizza IAM per autorizzazioni granulari. Per Git di terze parti (GitHub/Bitbucket), configurare le azioni di origine (source action) di CodePipeline con webhook per trigger quasi in tempo reale.

CodeArtifact centralizza la gestione dei pacchetti per più ecosistemi (npm, Maven, PyPI, NuGet). Supporta connessioni upstream a registri pubblici con caching, crittografia KMS per singolo repository e token di autenticazione con ambito limitato (scoped) che scadono automaticamente. Integrare in CodeBuild invocando aws codeartifact login durante la fase di pre_build per configurare i gestori di pacchetti senza incorporare segreti a lunga durata.

CodeBuild fornisce build effimere e containerizzate senza la necessità di gestire worker. Funzionalità chiave:

• Isolamento dell’ambiente e supporto VPC per le dipendenze private. Abilitare la modalità privilegiata per le build Docker e attivare il caching locale dei layer Docker per accelerare la creazione delle immagini.
• Variabili d’ambiente da tre fonti: testo in chiaro (plaintext), SSM Parameter Store e Secrets Manager (sicuro per impostazione predefinita, nessun segreto hardcoded). È anche possibile passare variabili da CodePipeline.
• Caching per ridurre i tempi di build:
  • Caching locale: cache del codice sorgente, cache dei layer Docker e directory personalizzate sull’host di build.
  • Caching S3: set di dipendenze riutilizzabili condivisi tra le build.
• Gestione degli artefatti: specificare primary e secondaryArtifacts per pubblicare output multipli (es. bundle dell’applicazione e template CloudFormation). Crittografare gli artefatti con chiavi KMS ed evitare ACL pubbliche.
• Reporting: inviare i log a CloudWatch Logs/S3. Utilizzare i report per i risultati dei test e i badge di CodeBuild per il feedback sulle PR.

CodePipeline è l’orchestratore. Definire stage (source, build, test, deploy, approval) con azioni che possono essere eseguite in parallelo o in sequenza. Best practice:

• Trigger:
  • Webhook per le fonti GitHub/Bitbucket.
  • Regole di EventBridge per le modifiche ai rami di CodeCommit; verificare l’esistenza della regola quando le pipeline non si avviano.
  • Pipeline pianificate tramite regole di pianificazione (schedule rules) di EventBridge che chiamano StartPipelineExecution.
• Archivi degli artefatti (artifact store): un bucket S3 per ogni Regione utilizzata dalla pipeline; usare una chiave KMS gestita dal cliente. Per azioni cross-Region, aggiungere archivi di artefatti regionali.
• Approvazioni manuali con SNS o EventBridge per integrare chat/webhook per notifiche quasi in tempo reale.
• IAM granulare: un ruolo di servizio (service role) per la pipeline con il minimo privilegio; i ruoli per singola azione vengono assunti per le operazioni cross-account.

CodeDeploy è il motore di deployment che supporta target EC2/on-prem, ECS e Lambda. Gestisce gli hook del ciclo di vita (lifecycle hook), lo spostamento del traffico, i controlli di integrità (health check) e il rollback automatico tramite allarmi CloudWatch. Assicurarsi che le istanze EC2 eseguano l’agente CodeDeploy, abbiano un profilo di istanza (instance profile) e connettività in uscita (outbound) verso gli endpoint di CodeDeploy (o in uscita tramite NAT). Eventi saltati (skipped event) e deployment nulli (no-op) indicano spesso problemi con l’agente, i permessi o la connettività.

Strategie di distribuzione e ciclo di vita di CodeDeploy

Scegliere la strategia in base a rischio, capacità e piattaforma:

• Sul posto (In-place) (EC2/on-prem): Aggiorna l’applicazione sulle istanze esistenti. Si combina con le configurazioni di distribuzione OneAtATime, HalfAtATime o AllAtOnce. Collega un ELB per drenare e registrare nuovamente le istanze.
• A rotazione (Rolling) (ECS): Sostituisce i task in batch sullo stesso servizio. Rolling nativo di ECS o gestito tramite CodeDeploy come blue/green con spostamento controllato.
• Blue/green:
  • EC2/Auto Scaling: Esegui il provisioning di un ASG “green”, convalida, quindi sposta il traffico dal “blue” al “green”. Opzionalmente, termina o mantieni l’ambiente “blue”.
  • ECS: Crea un set di task sostitutivo dietro un secondo gruppo di destinazione; convalida, quindi scambia i listener.
  • Lambda: Sposta il traffico dell’alias verso una nuova versione della funzione e monitora.
• Canary: Sposta prima una piccola percentuale (es. 10%), osserva per un intervallo di tempo, quindi completa.
• Lineare (Linear): Aumenta il traffico in passaggi uguali (es. 10% ogni 5 minuti).

Il file appspec.yml di CodeDeploy definisce cosa installare e quando eseguire gli script:

• Per EC2/On-Prem (YAML):
  • files: dove posizionare i file.
  • permissions: aggiornamenti di proprietà/modalità dei file senza script personalizzati.
  • hook (comuni): ApplicationStop, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService.
  • Hook di controllo del traffico (quando si usa un load balancer): BeforeBlockTraffic, AfterBlockTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • Usa variabili d’ambiente predefinite (es. DEPLOYMENT_GROUP_NAME, DEPLOYMENT_ID, LIFECYCLE_EVENT) per modificare dinamicamente il comportamento senza revisioni separate, come ad esempio attivare/disattivare i livelli di log di Apache per ogni gruppo di distribuzione.
• Per ECS:
  • resources: TargetService con TaskDefinition e LoadBalancerInfo.
  • hook: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic.
  • AfterAllowTestTraffic è ideale per test di fumo/integrazione sul set di task “green” con un listener di test.
• Per Lambda:
  • resources definisce la funzione, la versione e l’alias da spostare.
  • hook: BeforeAllowTraffic e AfterAllowTraffic.

Spostamento del traffico e rollback:

• Configura le configurazioni di distribuzione:
  • Lambda/ECS: Canary10Percent15Minutes, Canary10Percent5Minutes, Linear10PercentEvery1Minute, AllAtOnce o personalizzate.
  • EC2 Blue/Green: Reindirizzamento del traffico di tipo “tutto in una volta” (all-at-once), canary o lineare tramite i listener/gruppi di destinazione del load balancer.
• Aggiungi allarmi CloudWatch al gruppo di distribuzione per eseguire il rollback automatico in caso di errori, 5xx o metriche personalizzate. Per ECS, gli allarmi possono monitorare gli errori 5xx del gruppo di destinazione o le metriche del servizio; per Lambda, monitora le metriche Errors/Throttles della funzione con le dimensioni alias/versione.
• Usa gli hook del ciclo di vita (es. AfterAllowTestTraffic) per eseguire la convalida tramite Lambda o SSM; un codice di uscita diverso da zero causa il rollback.

Blue/Green e spostamento del traffico per EC2, ECS e Lambda

EC2/Auto Scaling:

• La strategia blue/green con CodeDeploy esegue il provisioning di un nuovo Auto Scaling group per l’ambiente “green”, lo associa a un gruppo di destinazione separato, quindi scambia i listener dell’ALB. Puoi scegliere di terminare automaticamente l’ambiente “blue” o di mantenerlo per un rollback rapido.
• Per le distribuzioni “sul posto” (in-place) su EC2, combina con un ELB per de-registrare/registrare le istanze in modo controllato (gracefully) e proteggere la disponibilità. La configurazione della distribuzione determina la dimensione dei batch e il ritmo.

ECS:

• CodeDeploy si integra con i servizi ECS utilizzando due gruppi di destinazione dietro un ALB. Viene creato un set di task sostitutivo (“green”) con la nuova definizione di task.
• Il traffico di test fluisce verso il gruppo di destinazione “green” tramite un listener di test dedicato; il traffico di produzione rimane sul “blue” fino alla promozione.
• Gli spostamenti di tipo canary o lineare trasferiscono progressivamente il traffico verso l’ambiente “green” monitorando gli allarmi di CloudWatch. Usa l’hook AfterAllowTestTraffic per eseguire la convalida (ad esempio, una funzione Lambda che esegue controlli sintetici) prima del passaggio alla produzione (cutover).

Lambda:

• CodeDeploy aggiorna un alias di funzione a una nuova versione con routing ponderato. I pattern canary e lineare spostano gradualmente la percentuale di traffico. Gli allarmi CloudWatch sull’alias guidano il rollback automatico.
• Con AWS SAM o CDK, imposta AutoPublishAlias e DeploymentPreference nei template per codificare la policy canary/lineare e gli allarmi per ogni funzione.

Routing ponderato oltre CodeDeploy:

• Per il bilanciamento multi-regione o multi-stack, i record ponderati di Route 53 con controlli di integrità (health check) forniscono la suddivisione del traffico a livello regionale (ad esempio, l'1% a una regione secondaria) e il failover. Questo integra ma non sostituisce lo spostamento del traffico per singolo servizio di CodeDeploy.

Distribuzione Multi-Account e Multi-Regione

Le pipeline enterprise risiedono tipicamente in un account centralizzato di “tooling”, effettuando il deployment su account dev/test/prod in più Regioni:

• Cross-account:
  • Nelle azioni di CodePipeline, specificare un RoleArn nell’account di destinazione che considera attendibile il principal del ruolo della pipeline. Utilizzare permessi con il minimo privilegio per ogni azione (CloudFormation, CodeDeploy, ECS, Lambda).
  • Per CodeBuild che deve accedere a risorse dell’account di destinazione, fare in modo che il build assuma un ruolo (STS) o utilizzi un ruolo di azione per-account, non un’ampia autorizzazione AdministratorAccess.
  • Per CodeDeploy su EC2, l’account di destinazione gestisce l’applicazione/gruppo di deployment e il ruolo di servizio; la pipeline assume un ruolo per chiamare CreateDeployment.
• Cross-Region:
  • Aggiungere un archivio di artefatti per Regione nella configurazione della pipeline (un bucket S3 con una chiave KMS regionale). Aggiornare le policy del bucket per consentire al ruolo della pipeline e ai ruoli per-azione di leggere/scrivere.
  • Creare artefatti specifici per la regione quando necessario (ad esempio, impacchettando il codice Lambda con

undefined

che punta a un bucket S3 locale della Regione).

• Le azioni di deploy di CloudFormation in una Regione remota devono fare riferimento all’archivio degli artefatti della Regione e possono specificare un ruolo di esecuzione dello stack nell’account di destinazione per il minimo privilegio.

Sicurezza, artefatti e governance:

• Mantenere privati i bucket degli artefatti; evitare ACL pubbliche come authenticated-read. Affidarsi a policy dei bucket limitate ai ruoli della pipeline e delle azioni, con crittografia KMS.
• Standardizzare i buildspec per pubblicare gli artefatti in modo prevedibile (es. bundle dell’applicazione per EC2/CodeDeploy, taskdef.json e appspec per ECS, template impacchettati per Lambda).
• Promuovere l’immutabilità con il pre-baking delle AMI per EC2 in modo che l’agente CodeDeploy e il runtime di base siano consistenti; questo riduce il drift e i tempi di deployment.
• Usare le regole di EventBridge per replicare gli eventi della pipeline in notifiche, operazioni di chat (chat ops) o sistemi di ticketing, e per orchestrare i gate manuali.

Scenario Pratico

Spotify ha bisogno di rilasci più sicuri per centinaia di microservizi con un substrato di calcolo misto (ECS su Fargate, servizi basati su EC2 e Lambda). Richiedono deployment di tipo canary e blue/green con test automatizzati prima del traffico di produzione, governance degli artefatti e promozione multi-regione, mantenendo l’ambiente di produzione in un account separato.

1. Creare repository e pacchetti

• Usare CodeCommit per i repository privati e l’automazione di PR/test guidata da EventBridge. CodeArtifact ospita le dipendenze npm, Maven e PyPI con upstream e crittografia KMS per standardizzare i controlli sulla supply-chain. Perché: Integrazione centrale con IAM/KMS e nessuna necessità di webhook esterni per i repository critici; CodeArtifact fornisce pacchetti curati e memorizzati nella cache.

2. Build e test

• Creare progetti CodeBuild per servizio con integrazione VPC, caching locale (livello Docker e sorgente) e variabili d’ambiente provenienti da Secrets Manager/Parameter Store. Creare le immagini e pubblicarle su ECR; generare artefatti secondari (taskdef.json/appspec.yaml o template CloudFormation impacchettati). Perché: Build effimeri e isolati, gestione sicura dei segreti, cicli più rapidi tramite caching e output multipli che supportano sia i container che il packaging serverless.

3. Orchestrare le pipeline

• Creare una CodePipeline centralizzata in un account di tooling con stage: Source, Build, Unit Tests, Deploy-to-Staging, Automated Tests, Manual Approval, Deploy-to-Prod. I trigger provengono da EventBridge in seguito ad aggiornamenti su CodeCommit; una regola EventBridge pianificata nottetempo avvia i test di integrazione. Perché: Flusso strutturato e auditabile con gate ed esecuzioni sia basate su eventi che pianificate.

4. Deployment blue/green e canary

• I servizi ECS utilizzano CodeDeploy blue/green con due target group e spostamento del traffico di tipo canary; la validazione viene eseguita in AfterAllowTestTraffic tramite una Lambda che esegue test di contratto e controlli sintetici. I servizi EC2 utilizzano CodeDeploy in-place con OneAtATime o scambi di ASG blue/green quando la capacità lo consente. Le funzioni Lambda vengono distribuite con CodeDeploy usando Canary10Percent15Minutes e allarmi CloudWatch su errori (Errors) e 5xx da API Gateway. Perché: Controlli del traffico di prima classe per ogni runtime e rollback automatico in caso di violazione degli allarmi minimizzano l’impatto sui clienti.

5. Promozione cross-account e cross-region

• La pipeline assume ruoli specifici per ambiente negli account dev/test/prod. Per us-east-1 e eu-west-1, configurare archivi di artefatti regionali e chiavi KMS regionali; CodeBuild produce template impacchettati specifici per regione e carica gli artefatti su bucket locali della regione. Le azioni di CloudFormation in ogni account/Regione usano ruoli di esecuzione dello stack; le azioni di CodeDeploy puntano ad applicazioni/gruppi di deployment specifici per l’ambiente. Perché: Forte isolamento di prod, minimo privilegio tramite l’assunzione di ruoli e crittografia conforme con un basso overhead operativo.

6. Governance e sicurezza degli artefatti

• Imporre l’uso di bucket S3 privati per gli artefatti con policy restrittive e rimuovere qualsiasi ACL pubblica. Firmare le immagini dei container e i template; archiviare gli SBOM come artefatti di build. Usare le condition key di IAM per limitare le azioni di produzione alle pipeline nell’account di tooling. Perché: Previene la fuga di dati, migliora la provenienza e si allinea con le best practice della supply-chain.

7. Osservabilità e notifiche

• Collegare allarmi CloudWatch a tutti i gruppi di deployment; le regole di EventBridge inoltrano gli eventi di esecuzione e approvazione di CodePipeline a un topic SNS e a una Lambda che pubblica su Slack. Perché: Feedback più rapido, rollback automatici e approvazioni con intervento umano (human-in-the-loop) dove necessario.

Questo design unifica runtime eterogenei sotto un’unica toolchain gestita, fornisce strategie di rollout sicure con verifica automatizzata, riduce la manutenzione eliminando l’infrastruttura CI/CD self-hosted e scala a livello globale con una chiara separazione dei compiti.

Tutti i domini · Infrastruttura come Codice e Gestione della Configurazione →

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

Sfoglia Amazon →