C’è una fase nella vita di ogni startup chiamata “ClickOps”. Accedi alla console AWS. Stai cercando EC2. Fai clic su “Avvia istanza”. Lo chiami “legacy-server-do-not-touch”. Funziona. Sembra produttivo. Due anni dopo, quel server si blocca. L’ingegnere che l’ha costruito se n’è andato. Nessuno sa quale versione del sistema operativo fosse in esecuzione. Nessuno sa quali gruppi di sicurezza fossero aperti. Nessuno sa dove siano le chiavi SSH. L’attività è offline.

Noi di Maison Code Paris applichiamo una regola rigorosa: L’infrastruttura è il codice. Se non è in Terraform (o Pulumi/CDK), non esiste. Questa guida approfondisce la creazione di un’infrastruttura AWS di livello produttivo che sia resiliente, sicura e non mandi in bancarotta.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Perché Maison Code parla di infrastrutture

Gestiamo infrastrutture per marchi che non possono fallire. Quando un cliente avvia una collaborazione con una superstar globale, il traffico aumenta di 100 volte in 60 secondi. Se il sistema di bilanciamento del carico non viene riscaldato, se il database non è scalabile, il sito si blocca. Progettiamo per l’Elasticità. Utilizziamo AWS non come “Server Host” ma come “Utilità programmabile”. Aiutiamo i CTO a migrare dai fragili “server per animali domestici” alle resilienti “flotte di bestiame”.

1. La filosofia di base: Infrastruttura come codice (IaC)

Perché scriviamo l’infrastruttura in HCL (HashiCorp Configuration Language)?

Riproducibilità: puoi creare un ambiente di “Staging” che è un clone esatto di “Produzione” in 10 minuti.
Verificabilità: git colpa ti dice esattamente chi ha aperto la Porta 22 al pubblico e quando.
Disaster Recovery: se us-east-1 non funziona, si modifica una variabile region = "eu-west-1" e si ridistribuisce.

Lo stack Terraform

Non gestiamo lo stato a livello locale. Utilizziamo un backend remoto (S3 + DynamoDB per il blocco).

# principale.tf
terraformare {
  back-end "s3" {
    bucket = "maisoncode-terraform-state"
    chiave = "prod/infrastruttura.tfstate"
    regione = "noi-est-1"
    dynamodb_table = "serrature terraform"
    crittografare = vero
  }
}

fornitore "aws" {
  regione = "noi-est-1"
  tag_predefiniti {
    tag = {
      Ambiente = "Produzione"
      Progetto = "E-commerce"
      ManagedBy = "Terraforma"
    }
  }
}

2. Rete: la trappola VPC

L’errore più grande commesso dagli sviluppatori è utilizzare il “VPC predefinito”. Il VPC predefinito inserisce tutto nelle sottoreti pubbliche. Il tuo database ha un IP pubblico. Questo è sconsiderato. Progettiamo reti a 3 livelli.

“sirena”. grafico TD Utente —>|HTTPS| ALB[Bilanciatore del carico dell’applicazione] sottografo VPC sottografo Sottorete pubblica ALB NAT[Gateway NAT] fine sottografo Sottorete privata App[Server app/Lambda] fine sottografo Sottorete del database RDS[Postgres RDS] fine fine Applicazione —>|SQL| RDS App —>|In uscita| NAT


### Livello 1: sottorete pubblica
* **Contiene**: bilanciatori di carico (ALB), gateway NAT, host bastioni.
* **Routing**: dispone di un gateway Internet (IGW). 0.0.0.0/0 -> IGW.

### Livello 2: sottorete privata (livello app)
* **Contiene**: istanze EC2, contenitori Fargate, Lambda ENI.
* **Routing**: nessun gateway Internet. 0.0.0.0/0 -> Gateway NAT (per aggiornamenti in uscita).
* **Sicurezza**: non è raggiungibile direttamente da Internet.

### Livello 3: sottorete interna (livello dati)
* **Contiene**: RDS, ElastiCache, Redshift.
* **Routing**: Nessun accesso a Internet. Nessun NAT.
* **Sicurezza**: Isolamento totale.

## 3. La sorpresa del gateway NAT da $ 20.000

I prezzi della larghezza di banda AWS sono predatori.
Un **NAT Gateway** ti addebita un costo all'ora + per GB elaborati.
Se la tua applicazione scarica 10 TB di immagini da S3 e il traffico S3 standard passa attraverso il gateway NAT, pagherai ~ $ 450.
**Correzione**: endpoint gateway S3.
Si tratta di un "wormhole" virtuale dal tuo VPC a S3 che bypassa il NAT.
È **gratuito**.

```hcl
risorsa "aws_vpc_endpoint" "s3" {
  vpc_id = aws_vpc.main.id
  service_name = "com.amazonaws.us-east-1.s3"
}

Effettua sempre il provisioning degli endpoint gateway per S3 e DynamoDB.

4. Calcolo: EC2 vs Fargate vs Lambda

Quale motore di calcolo si adatta all’e-commerce di lusso?

EC2 (Macchine virtuali)

Caso d’uso: app legacy, servizi con stato (WebSocket), database (se ospitati autonomamente).
Verdetto del codice della Maison: Evitare. Troppa manutenzione (patch del sistema operativo).

ECS Fargate (contenitori serverless)

Caso d’uso: app Node.js/Docker di lunga durata.
Pro: Nessuna patch per il sistema operativo. Definisci “CPU: 2, RAM: 4 GB”. AWS lo esegue.
Verto del codice Maison: Scelta standard per i server Next.js che inviano HTML.

Lambda (Funzioni)

Caso d’uso: attività guidate da eventi (ridimensionamento delle immagini, elaborazione degli ordini).
Pro: scala a zero.
Vertenza Maison Code: Eccezionale per “Glue Code” e lavoratori in background.

5. Il database: RDS Aurora Serverless v2

RDS tradizionale richiede di scegliere una dimensione di istanza (db.m5.large). Se il traffico aumenta, ti schianti. Se il traffico diminuisce, paghi più del dovuto. Aurora Serverless v2 scala la capacità di elaborazione su e giù localmente in millisecondi. Si abbina perfettamente al modello di gocce di lusso “Flash Sale”.

risorsa "aws_rds_cluster" "predefinito" {
  cluster_identifier = "aurora-cluster-demo"
  motore = "aurora-postgresql"
  engine_mode = "provisioned"
  serverlessv2_scaling_configuration {
    capacità_min = 0,5 # € 40/mese
    capacità_massima = 64.0 # Carico pesante
  }
}

Al termine del calo, il valore torna a 0,5 ACU (unità di capacità Aurora). Paghi per quello che usi.

6. Distribuzione dei contenuti: CloudFront

Non è possibile fornire risorse da S3 direttamente agli utenti. S3 è lento (tempo al primo byte). CloudFront è obbligatorio. È un CDN globale. Configurazione critica: Criteri della cache. Non limitarti a memorizzare tutto nella cache.

Immagini: cache per 1 anno.
Risposte API: memorizza nella cache per 0 secondi (o 60 secondi se pubblica).
HTML: cache per 0 secondi (rendering lato server).

Sicurezza: utilizza OAC (Origin Access Control) per bloccare il tuo bucket S3 in modo che solo CloudFront possa leggerlo. Gli utenti non possono bypassare la CDN.

7. Il quadro ben architettato (6 pilastri)

AWS fornisce un elenco di controllo chiamato “Quadro ben architettato”. Controlliamo ogni cliente rispetto ad esso.

Eccellenza operativa: automatizza tutto. Nessuna modifica manuale.
Sicurezza: crittografa tutto. Privilegio minimo.
Affidabilità: implementazioni Multi-AZ. Sistemi di autoguarigione.
Efficienza prestazionale: utilizza Serverless/Spot per ridimensionare i contenuti.
Ottimizzazione dei costi: analizza le fatture quotidianamente. Tagga ogni risorsa.
Sostenibilità: utilizzare processori Graviton (ARM). Consumano il 60% di energia in meno.

8. Disaster Recovery: RTO vs RPO

Se AWS “us-east-1” si brucia, cosa succede? Definisci 2 metriche:

RTO (Recovery Time Objective): quanto tempo ci vuole per tornare online? (Obiettivo: < 1 ora).
RPO (Recovery Point Objective): quanti dati possiamo perdere? (Obiettivo: < 5 minuti). Strategia:
Database: repliche di lettura tra regioni (Stati Uniti -> UE). La promozione dura 5 minuti.
File: Replica tra regioni S3 (CRR).
Codice: Applicazione Terraform multiregione.

9. Sicurezza: il principio del privilegio minimo

IAM (Identity Access Management) è il firewall per gli esseri umani. Non utilizzare mai l’account root. Chiudetelo in una cassaforte. Mai fornire “AdministratorAccess” a uno sviluppatore.

Creare policy dettagliate strettamente legate alle risorse.

{
    "Effetto": "Consenti",
    "Azione": ["s3:PutObject"],
    "Risorsa": "arn:aws:s3:::maisoncode-uploads/images/*"
}

Questo utente può caricare immagini. Non possono eliminare il bucket. Non possono leggere i resoconti finanziari.

8. Ottimizzazione dei costi: istanze Spot

Per l’elaborazione dati in batch (ad esempio, processi di ottimizzazione delle immagini eseguiti di notte), non utilizzare istanze on demand. Utilizza Istanze Spot. Si tratta di capacità AWS di riserva vendute con uno sconto del 70-90%. Il problema: AWS può terminarli con un preavviso di 2 minuti. Se la tua app è senza stato (come un operatore in coda), questo non ha importanza. Gestisce la terminazione e si riavvia altrove. Ciò consente di risparmiare migliaia di dollari al mese su lavori in background.

9. Flusso di lavoro di sviluppo: ambienti effimeri

Come testare i cambiamenti infrastrutturali? Usiamo “Effimeri”. Quando un PR viene aperto in GitHub:

GitHub Actions attiva Terraform.
Crea un nuovo spazio di lavoro pr-123.
Distribuisce uno stack completo (VPC + Fargate + RDS).
Esegue test E2E.
Esegue “terraform destroy”.

Ciò dà la totale certezza che le modifiche al codice non interromperanno la produzione.

10. Conclusione

AWS è una motosega. È abbastanza potente da abbattere una foresta, ma abbastanza pericoloso da tagliarti una gamba. Facendo clic sulla console si gioca con i giocattoli. Scrivere Terraform è ingegneria. Per il 2026, ci stiamo muovendo verso “Infrastructure from Code” (utilizzando SST o Pulumi per dedurre infra dal codice), ma i fondamenti di VPC e IAM rimangono immutabili.

Il tuo cloud è in disordine?

Hai “Server sconosciuti” in esecuzione? La tua bolletta è un mistero?

Controlla la mia infrastruttura. Assumi i nostri architetti.