Shift-right su AWS: canary per revisione e per tenant

Questa è la parte “a valle” di una tesi che ho messo nel primo articolo — Il costo non sparisce, migra: lo sviluppo nell’era degli agenti — dove sostengo che con gli agenti il costo dello sviluppo si sposta a monte (specificare) e a valle (verificare). Qui sto a valle.

La tesi in una frase: i criteri della DoD diventano gli allarmi che governano il rilascio. Il canary per revisione intercetta i problemi tecnici, il rollout per tenant quelli funzionali. La combinazione che propongo: canary ECS per la nuova revisione + rollout per tenant via feature flag.

Canary nativo su ECS Fargate

Dal 2025 ECS gestisce blue/green, linear e canary in modo nativo, senza CodeDeploy, con lifecycle hook, bake time e rollback nella configurazione del servizio.

1. ALB con due target group pesati sulla listener rule di produzione.
2. Strategia CANARY: per esempio 10% del traffico alla nuova revisione, con bake time, poi 100%.
3. Lifecycle hook (tipicamente una Lambda) che esegue test e2e o synthetic sul traffico di test prima di spostare quello reale.
4. Allarmi CloudWatch su error rate e latenza p95 della nuova revisione, collegati al rollback automatico.

Collegamento con la spec: se la DoD dice “latenza p95 sotto 300 ms” o “nessun aumento di errori 5xx”, quei criteri diventano gli allarmi del canary.

Il limite: il canary ECS assegna una percentuale di richieste a caso, non sceglie chi vede la novità.

Rollout per tenant con feature flag

In un sistema multitenant il canary si sposta dal deploy al rilascio: il codice va in produzione spento e si accende per gruppi di tenant.

• AppConfig, flag multi-variante: il tenant_id passato dall’applicazione come contesto viene valutato contro regole definite da te.
• Rollout graduale per entità (AppConfig Agent): un tenant che riceve una versione la mantiene per tutto il deploy, qualunque task serva la richiesta.
• Rollback automatico se scattano gli allarmi CloudWatch durante il deploy della configurazione.

Flusso automatizzabile in pipeline:

1. Tenant interno o di test
2. Coorte a basso rischio e con traffico sufficiente
3. 25% dei tenant
4. Tutti

Ogni step ha un bake time e il rollback sugli allarmi.

Alternative: LaunchDarkly, Unleash, Flagsmith. Con vincoli di data residency EU, Unleash self-hosted o AppConfig in una regione EU sono le opzioni più semplici.

Prerequisiti e limiti

Il rollback automatico funziona solo se le metriche sanno distinguere chi è nel canary: è questo il prerequisito vero, non il flag.

Tema	Problema	Cosa fare
Metriche per tenant	Gli allarmi non distinguono la coorte canary dagli altri	Etichettare metriche e log con il tenant
Volume di traffico	Con poco traffico il 10% o un tenant piccolo non dà segnale in pochi minuti	Dimensionare bake time e coorti sui volumi reali
Migrazioni DB	Due versioni convivono sullo stesso schema; il flag non isola il DB	Migrazioni expand/contract, imposte nella spec
Risorse condivise	Code e job batch colpiscono tutti i tenant	Valutarle a parte nel piano di rilascio
Debito dei flag	Ogni flag è un ramo di codice in più	Regola nella DoD: flag rimosso entro N giorni dal 100%
Comportamento funzionale	Lo shift-right intercetta bene i problemi tecnici, meno quelli funzionali con impatto contrattuale o di compliance	Validazione funzionale prima, non sugli utenti

Lo shift-right non sostituisce lo shift-left: usato come scusa per testare meno prima, diventa testare sugli utenti.

---

Riferimenti

• re:Invent 2025 deep dive: ECS Managed Instances e deploy nativi
• AWS samples: ECS deployment strategies
• AWS samples: ECS service and deployment
• AWS AppConfig: creating feature flags
• AWS AppConfig: deploying feature flags