Isolamento ambienti tramite condivisione infrastrutturale e separazione dati

Autore: Marco Orlandin, Architect
Data: 31 Marzo 2026
Status: Proposto
Settore: Research / Cloud infrastructure
Constraint principali: Budget staging minimo, progetto di ricerca ML in ambito accademico, team singolo, nessun requisito compliance, nessun PII

Nota: Progetto reale, anonimizzato per riservatezza (NDA). Metriche e dettagli semplificati, ma decisioni e lezioni apprese fedeli alla realtà.

Contesto e problema

Un progetto di ricerca ML in ambito accademico, in fase di migrazione verso AWS. Necessità di due ambienti separati (staging e produzione) senza duplicare l'infrastruttura.

Il problema classico: AWS offre decine di meccanismi di isolamento (account separati via Organizations, VPC dedicate, transit gateway, landing zone con Control Tower). Ogni layer aggiuntivo costa: in soldi, in complessità, in tempo di gestione. Per un progetto di ricerca con un team e zero requisiti di compliance, la maggior parte di questi meccanismi risolve problemi che non esistono.

La domanda: qual è il livello minimo di isolamento che garantisce separazione sicura dei dati senza costi infrastrutturali inutili?

Requisiti non funzionali

• Costo staging vicino a zero quando non in uso
• Separazione completa dei dati tra ambienti
• Nessuna duplicazione di infrastruttura condivisibile
• Setup gestibile da un singolo team
• Infrastruttura definita in IaC (Terraform)
• Possibilità di evolvere verso isolamento maggiore se il progetto scala

Opzioni valutate

Opzione 1: Account AWS separati per ambiente

• Pro: Isolamento totale. Blast radius zero tra ambienti. Best practice AWS per organizzazioni enterprise.
• Contro: Doppio billing, doppia configurazione IAM, doppio setup networking. Overhead di gestione sproporzionato per un team. Costo fisso di infrastruttura duplicata (ALB, NAT Gateway) anche su staging inattivo. ~$50-70/mese di costi fissi staging.

Opzione 2: VPC separate per ambiente (stesso account)

• Pro: Isolamento rete completo. Nessun rischio di comunicazione accidentale tra ambienti.
• Contro: ALB duplicato ($20/mese extra). NAT Gateway duplicato se si usano subnet private ($35/mese extra). Complessità networking (peering se servono risorse condivise). Overkill per il contesto.

Opzione 3: Account singolo con separazione logica via naming, tag e Security Group

• Pro: Costo staging marginale. Infrastruttura condivisa dove sicuro (VPC, ALB, ECR). Dati separati dove necessario (S3, Secrets Manager). Gestione semplificata per un team.
• Contro: Rischio errore umano su naming/tag. Nessun isolamento rete tra ambienti. Richiede disciplina su IaC. Non scalabile a multi-team senza evoluzione.

Decisione

Scelta l'Opzione 3: account singolo, infrastruttura condivisa, dati separati. Security Group come layer di isolamento gratuito al posto di subnet private + NAT Gateway.

Motivazioni principali:

• Il contesto (ricerca, team singolo, no compliance, no PII) non giustifica il costo dell'isolamento infrastrutturale.
• La separazione dei dati è l'unico isolamento che conta in questo scenario.
• I costi fissi delle opzioni 1 e 2 rappresentano budget sottratto al progetto senza beneficio reale.

Decisioni implementative

1. Due ambienti, dev locale

Staging e produzione su AWS. Sviluppo locale con docker-compose. Dev non ha bisogno di risorse cloud: il ciclo di feedback è locale, il deploy è CI/CD.

2. Account AWS singolo con separazione logica

Naming prefix (stg-, prod-) e tag Environment su tutte le risorse. Nessun account separato. IAM policies scoped per ambiente dove necessario, ma senza la complessità di cross-account access.

3. VPC condivisa con subnet pubbliche

Una VPC, due subnet pubbliche (una per AZ per high availability). Nessuna subnet privata: i task ECS ricevono IP pubblico e Security Group restrittivo. Il risparmio è il NAT Gateway (~$35/mese) che non serve se il task può uscire direttamente.

4. ALB condiviso con host-based routing

Un solo Application Load Balancer. Listener rules basate sull'host (stg.app.* vs app.*) instradano il traffico al target group corretto. Costo: un ALB invece di due. Le rules aggiuntive hanno costo trascurabile.

5. ECS Fargate in subnet pubbliche

Task Fargate con assign_public_ip = true. Nessun NAT Gateway necessario per traffico in uscita. Security Group per ambiente controlla il traffico in ingresso. Trade-off accettato: i task sono esposti a internet, ma solo sulle porte consentite dal SG.

6. Security Group come isolamento

Un Security Group per ambiente. Sostituisce il pattern "subnet privata + NAT Gateway" che costerebbe ~$35/mese senza aggiungere sicurezza significativa nel contesto. Il SG è gratuito e sufficiente per controllare chi accede a cosa.

7. ECR condiviso, S3 separato

Un repository ECR per le immagini container, differenziato per image tag (stg-v1.2, prod-v1.2). Le immagini sono artefatti immutabili, condividerle è sicuro. Due bucket S3 separati per i dati (stg-app-data, prod-app-data). I dati sono l'unica cosa che non deve mai mescolarsi.

8. Secrets Manager per ambiente

Un JSON secret per ambiente in AWS Secrets Manager. Ogni ambiente ha le proprie credenziali, connection string, configurazioni. Separazione logica, non fisica, ma sufficiente con naming convention rigoroso.

Conseguenze

Positive

• Costo staging quasi zero: senza ALB duplicato e senza NAT Gateway, staging costa solo il compute ECS quando è attivo (Fargate = pay per use) e pochi centesimi di S3.
• Gestione semplificata: un account, una VPC, un ALB. Un team gestisce tutto senza overhead organizzativo.
• IaC pulito: Terraform con variabili d'ambiente per switchare tra staging e produzione. Stesso codice, parametri diversi.

Negative

• Rischio naming: un errore di prefix e staging tocca risorse di produzione. Mitigazione: Terraform forza i pattern, tag obbligatori, CI/CD con validazione.
• Nessun isolamento rete: staging e produzione condividono la stessa VPC. Un misconfiguration su Security Group potrebbe esporre risorse. Mitigazione: SG restrittivi, review IaC su ogni PR.
• Non scalabile as-is: se il progetto cresce, aggiunge team, o gestisce dati sensibili, serve evolvere verso account separati o almeno VPC separate. Questo setup è esplicitamente per la fase attuale.

Quando non applicare questo approccio

• Compliance e regulated industries: GDPR con DPA stringenti, HIPAA, PCI-DSS richiedono isolamento fisico degli ambienti, audit trail separati, e spesso AWS Organizations con Service Control Policies.
• Organizzazioni multi-team: quando più team operano sullo stesso account, il rischio di errore su naming e tag diventa sistemico. Account separati proteggono i team l'uno dall'altro.
• PII su scala: dati personali in produzione non devono mai rischiare di finire in staging per un tag sbagliato. L'isolamento deve essere fisico, non logico.
• Produzione business-critical: se il downtime ha costo economico diretto, l'isolamento infrastrutturale è assicurazione, non lusso.

Stack

• Cloud: AWS (account singolo)
• Networking: 1 VPC, 2 subnet pubbliche, 1 ALB condiviso
• Compute: ECS Fargate
• Storage: S3 (bucket separati per ambiente)
• Registry: ECR (repo condiviso)
• Secrets: AWS Secrets Manager
• IaC: Terraform