Il “multi-cloud” viene presentato come una strategia. Di solito non lo è: è una conseguenza. Un reparto dispone già di un tenant Azure nell’ambito del proprio ambiente M365, un partner di implementazione ha realizzato l’ultimo servizio su AWS e un team di data science vuole BigQuery. Nessuno l’aveva pianificato. Qualcuno deve comunque gestirlo.
Dopo un decennio trascorso a progettare piattaforme su AWS, Azure e Google Cloud per clienti del settore pubblico, ecco cosa conta davvero una volta superato il dibattito su “quale sia il cloud migliore” e una volta che ci si concentra sul garantire che i carichi di lavoro di produzione siano sicuri, conformi alle normative e economicamente sostenibili.
1. La sovranità e la classificazione vengono prima dell’architettura
Nei progetti commerciali, la scelta della regione è una decisione legata alle prestazioni. Nei progetti pubblici, invece, è innanzitutto una decisione di natura giuridica.
Prima ancora di scrivere un solo modulo Terraform, stabiliamo:
- A quale classificazione appartengono questi dati: UFFICIALE, UFFICIALE-SENSIBILE o superiore?
- Quali regioni soddisfano il requisito di residenza? Inoltre, il modello di responsabilità condivisa del fornitore lo soddisfa effettivamente o si limita a dichiararlo?
- Chi detiene le chiavi di crittografia: il fornitore, oppure il contratto prevede che le chiavi siano gestite dal cliente (CMK/BYOK)?
# Encryption key ownership is a decision, not a default
resource "aws_kms_key" "official_sensitive" {
description = "CMK for OFFICIAL-SENSITIVE workloads"
deletion_window_in_days = 30
policy = data.aws_iam_policy_document.key_admins.json
# Key never leaves customer control — no provider-managed fallback
}Se si commette un errore in questo ambito, nessuna soluzione tecnica, per quanto valida, potrà porvi rimedio in seguito. Abbiamo visto casi in cui le migrazioni sono rimaste in sospeso per mesi perché la residenza dei dati era stata data per scontata anziché verificata.
2. Scegliere il cloud più adatto a ciascun carico di lavoro, non un unico cloud per tutto
I team che incontrano difficoltà con l’approccio multi-cloud sono quelli che cercano di rendere ogni carico di lavoro trasferibile ovunque. I team che hanno successo scelgono un provider principale per ogni carico di lavoro in base alle sue effettive competenze e standardizzano le interfacce tra i vari provider.
| Carico di lavoro | Dove lo collochiamo solitamente | Perché |
|---|---|---|
| Servizi per i cittadini in stile GOV.UK | AWS GovCloud / regioni del Regno Unito | Ecosistema PaaS maturo, accreditamento consolidato nel settore pubblico |
| Gestione dei casi integrata con M365 | Azure | AD nativo, Graph API, tenant esistente |
| Piattaforme dati e analisi | GCP | Modello di costo di BigQuery, solidi strumenti per i dati |
| Carichi di lavoro in container | Qualunque regione richiesta dalla residenza | Portabilità intrinseca — vedi sotto |
L’errore non sta nell’utilizzare tre cloud, ma nell’utilizzarle senza aver preso una decisione. perché per ciascuno di essi.
3. Kubernetes è l’unica cosa che rende il multi-cloud sopportabile
Le API relative al computing, alla gestione delle identità e degli accessi (IAM) e alle reti presentano differenze tra AWS, Azure e GCP che non è mai possibile eliminare completamente. Kubernetes è ciò che più si avvicina a un substrato comune ed è l’unico investimento che ripaga indipendentemente dai provider che si finisca per utilizzare.
# Same manifest, three managed control planes
# EKS, AKS and GKE all accept this without modification
apiVersion: apps/v1
kind: Deployment
metadata:
name: claims-api
spec:
replicas: 3
template:
spec:
containers:
- name: claims-api
image: registry.internal/claims-api:1.4.2
resources:
requests: { cpu: "250m", memory: "256Mi" }
limits: { cpu: "500m", memory: "512Mi" }Continuiamo a utilizzare servizi nativi dei provider a livello di infrastruttura — RDS, Cosmos DB, Cloud SQL — perché reimplementare database gestiti su Kubernetes raramente conviene. Tuttavia, il livello applicativo rimane portabile, ed è proprio questa portabilità che consente a un dipartimento di spostare un carico di lavoro quando cambia il contratto relativo al framework.
4. Il FinOps è un’abitudine settimanale, non una revisione annuale
Nel settore pubblico, i costi eccessivi legati al cloud raramente derivano da una singola decisione sbagliata. Derivano piuttosto dal fatto che nessuno se ne occupa finché la fattura non arriva sulla scrivania di un dirigente.
# What an unmanaged multi-cloud bill actually looks like after 12 months
AWS: forecast £18k/mo → actual £31k/mo (orphaned EBS volumes, over-provisioned RDS)
Azure: forecast £9k/mo → actual £14k/mo (dev/test resources never torn down)
GCP: forecast £4k/mo → actual £4.2k/mo (tagged and budget-alerted from day one)La linea GCP si distingue dalle altre per un motivo ben preciso: sin dal lancio prevedeva avvisi di budget e l’assegnazione obbligatoria di tag, imposti da una politica aziendale. Le altre due non li prevedevano, finché non li abbiamo aggiunti noi.
# Tag enforcement at the policy layer, not the honour system
resource "aws_organizations_policy" "require_cost_tags" {
content = jsonencode({
tags = {
"cost-centre" = { tag_key = { "@@assign" = "cost-centre" }, enforced_for = { "@@assign" = ["ec2:instance", "rds:db"] } }
}
})
}Il rispetto dei tag, gli avvisi di superamento del budget e una revisione settimanale dei costi fanno la differenza tra una previsione e una fantasia.
5. L’infrastruttura come codice è l’unica fonte di verità — altrimenti non ha alcun valore
Un ambiente multi-cloud senza IaC comporta tre console, tre insiemi di conoscenze specifiche e una cronologia delle modifiche che, una volta che i responsabili se ne vanno, rimane solo nella memoria di qualcuno. Terraform (o OpenTofu), con moduli specifici per ogni provider gestiti tramite un’interfaccia condivisa, è ciò che rende gli audit gestibili.
module "network" {
source = "./modules/network/${var.cloud_provider}"
cidr = var.network_cidr
env = var.environment
}Ogni modifica viene sottoposta alla stessa revisione PR, allo stesso controllo “pianifica prima di applicare” e allo stesso percorso di audit, indipendentemente dal cloud a cui è destinata. Per un revisore ISO 27001 o Cyber Essentials Plus, questa coerenza è più importante della scelta del provider.
Punti chiave
- Classifica prima di progettare l’architettura — La sovranità e la titolarità delle chiavi sono questioni di natura giuridica, non infrastrutturale
- Scegli con attenzione in base al carico di lavoro — Il multi-cloud casuale è un punto debole; il multi-cloud pianificato è un punto di forza
- Kubernetes è il livello di portabilità — investire in questo ambito, anziché cercare di garantire ovunque una completa indipendenza dal cloud
- Il FinOps è un processo continuo — Il controllo dei tag e gli avvisi di budget sono sempre più efficaci di un foglio di calcolo trimestrale
- L’IaC è la tua traccia di audit — se non è nel codice e non è stato revisionato, non è successo
Il multi-cloud non è di per sé una strategia positiva o negativa. È un insieme di vincoli che qualcun altro ti ha già imposto. Il compito degli ingegneri è rendere questi vincoli “noiosi”: prevedibili, verificabili ed economici da gestire.
Comments
Loading comments…