Google Cloud vs AWS: confronto su sicurezza e conformità

Su sicurezza e conformità Google Cloud e AWS partono dalla stessa base: responsabilità condivisa, certificazioni ISO/IEC 27001, 27017 e 27018, CSA STAR Level 2, almeno una regione in Italia, servizi qualificati ACN e designazione come fornitori critici DORA. Le differenze che contano per un'azienda italiana stanno nei dettagli: quante regioni italiane, come si controllano chiavi e accessi del provider, come arrivano i log al SOC.

Qui trovi sei criteri per confrontarli, con la domanda da fare a ciascuno. I criteri generali sono nella guida su come scegliere un cloud provider. Per trasparenza: AmagisTech è partner Google Cloud, quindi ogni fatto viene dalla documentazione pubblica dei provider o da fonti istituzionali.

Cosa hanno in comune

• Responsabilità condivisa. AWS distingue la sicurezza of the cloud, cioè l'infrastruttura su cui girano i servizi, che è sua, dalla sicurezza in the cloud, che resta al cliente e varia secondo i servizi scelti. Google Cloud usa lo stesso modello e lo affianca a quello che chiama shared fate: guide e configurazioni di base per partire con ambienti già impostati in modo sicuro.
• Certificazioni. AWS dichiara la certificazione ISO/IEC 27001:2022, 27017:2015 e 27018:2019 e la CSA STAR Level 2 Certification. Google Cloud dichiara la ISO/IEC 27001 accreditata dopo audit indipendente, insieme a 27017 e 27018, e la CSA STAR Level 2 Attestation per Google Cloud e Google Workspace. Entrambi mettono a disposizione i report SOC 2: AWS in AWS Artifact, Google tramite Compliance Reports Manager.
• DORA. Nell'elenco dei 19 fornitori terzi critici designati dalle Autorità europee di vigilanza il 18 novembre 2025 ci sono sia Amazon Web Services EMEA SARL sia Google Cloud EMEA Limited.
• ACN. Entrambi hanno servizi nel catalogo dei servizi cloud qualificati, al livello 2.

La conseguenza pratica è che la domanda chi è più sicuro porta poco lontano. Sulla parte gestita dal provider le garanzie verificabili sono equivalenti; sulla parte che resta a te, identità, permessi, reti e configurazioni, il risultato dipende da come l'ambiente è costruito e mantenuto. Gli errori tipici di quella parte sono raccolti negli errori di configurazione del cloud.

Sei criteri per confrontarli

1. Dove stanno i dati, disaster recovery compreso

Google Cloud ha due regioni in Italia: Milano (europe-west8) e Torino (europe-west12), ciascuna con tre zone. AWS ha una regione in Italia, Europe (Milan), eu-south-1, con tre zone di disponibilità. È una delle regioni introdotte dopo il 20 marzo 2019, che AWS lascia disattivate di default: va abilitata sull'account prima di creare risorse.

La differenza si sente sul disaster recovery. Le zone di una stessa regione coprono il guasto di una zona; una seconda regione copre l'indisponibilità dell'intera area. Se la tua politica chiede che anche la copia in un'altra regione resti in Italia, su Google Cloud la coppia Milano e Torino lo consente; su AWS la seconda regione si trova in un altro paese. Una seconda regione europea può andare bene, ma è una scelta da fare per iscritto, non da scoprire in audit.

Domanda da fare: per ogni servizio che userò, in quale regione finiscono dati, backup, log e copie di disaster recovery?

2. Certificazioni: il perimetro, servizio per servizio

Che il provider sia certificato non basta: conta se lo è il servizio che userai. AWS pubblica l'elenco dei servizi coperti per ogni programma di conformità, e precisa che, salvo esclusioni indicate, sono coperte tutte le funzionalità dei servizi elencati. Google Cloud pubblica per ogni certificazione i prodotti in perimetro. I report completi si scaricano dalle rispettive aree riservate, AWS Artifact e Compliance Reports Manager.

Su CSA STAR i due livelli 2 hanno forme diverse, una certificazione basata su ISO/IEC 27001 per AWS e un'attestazione basata su SOC 2 per Google: la differenza è spiegata nella guida a CSA STAR.

Domanda da fare: il servizio specifico che userò è nel perimetro di ISO/IEC 27001, 27017, 27018 e del report SOC 2 più recente?

3. Qualificazione ACN: cerca il servizio, non contare le schede

Nei dati aperti ACN sui servizi cloud qualificati, consultati l'8 ottobre 2026, Google Cloud Italy S.r.l. compare con 63 schede e Amazon Web Services EMEA SARL con 23, tutte al livello 2. È il livello QC2 del Regolamento ACN 21007/24, quello da cui in su la PA può collocare anche i dati critici.

I due numeri però non si confrontano. AWS ha qualificato i servizi per famiglie, con schede come Amazon Compute Services o Amazon Database Services. Google Cloud li ha qualificati uno per uno: tra gli altri Compute Engine, BigQuery, Cloud SQL, Cloud Key Management Service, Cloud External Key Manager, Access Transparency, Security Command Center, Google SecOps e Vertex AI Platform. Il controllo utile è cercare nel catalogo il servizio che userai.

Per un'azienda privata la qualificazione non è un obbligo, ma diventa un requisito se vendi servizi cloud alla Pubblica Amministrazione.

4. Chiavi di cifratura e accessi del provider

Sui dati più delicati le domande sono due: chi tiene le chiavi, e quanto vedi degli accessi del personale del provider.

Per le chiavi entrambi permettono di tenerle fuori dal cloud. Su Google Cloud c'è Cloud External Key Manager: le chiavi restano presso un gestore esterno supportato e non vengono mai memorizzate in Google Cloud. Su AWS c'è l'External Key Store di AWS KMS: le chiavi restano in un gestore di tua proprietà fuori da AWS, che AWS KMS non può creare, vedere né gestire. In entrambi i casi la disponibilità della chiave diventa tua: se la perdi, i dati non si recuperano. La documentazione AWS scrive che per la maggior parte dei carichi il peso operativo e i rischi su disponibilità e prestazioni superano i benefici percepiti: le chiavi esterne si usano sui dati che le richiedono davvero.

Per gli accessi del provider Google Cloud documenta tre strumenti:

• Key Access Justifications: ogni richiesta alla chiave esterna porta un codice che ne indica il motivo, e il gestore esterno può consentirla o negarla in base a quel codice.
• Access Transparency: registra le azioni del personale Google quando accede ai dati del cliente, con motivo, luogo e ruolo di chi accede. Va abilitato.
• Access Approval: consente di autorizzare quegli accessi prima che avvengano.

Domanda da fare a entrambi: per i servizi che userò, posso tenere le chiavi fuori dal cloud, e posso vedere e approvare gli accessi del vostro personale ai miei dati?

5. Log e monitoraggio: cosa arriva al SOC

• Google Cloud scrive i Cloud Audit Logs. Quelli di attività amministrativa sono sempre attivi e non si possono disattivare. Quelli di accesso ai dati sono disattivati di default, tranne che per BigQuery, perché generano grandi volumi: vanno abilitati sui servizi che contano.
• AWS registra le azioni di utenti, ruoli e servizi in CloudTrail. L'Event history conserva 90 giorni di eventi di gestione per regione; per conservarli più a lungo e mandarli a un sistema di monitoraggio si crea un trail, che li consegna in un bucket S3.

Per la postura entrambi hanno strumenti nativi: Security Command Center su Google Cloud, AWS Security Hub CSPM e Amazon GuardDuty su AWS.

Nel passaggio al SOC la piattaforma pesa. Google SecOps riceve i log di Google Cloud per ingestione diretta: Cloud Audit Logs e finding di Security Command Center Premium arrivano in tempo reale tramite un filtro di Cloud Logging. I log di AWS CloudTrail arrivano invece tramite un feed che li legge da S3. Quindi un SOC su Google SecOps sorveglia entrambi i cloud, con un percorso più corto per Google Cloud.

Domanda da fare: quali log sono attivi di default, per quanto tempo restano, e come arrivano al sistema che li analizza?

6. DORA e NIS2: il provider non cambia gli obblighi

La designazione come fornitore critico porta il provider sotto la sorveglianza delle autorità europee, ma non sposta la responsabilità: l'entità finanziaria resta sempre pienamente responsabile degli obblighi DORA (art. 28, par. 1, lett. a, Regolamento UE 2022/2554). Lo stesso vale per i soggetti NIS2, che tra le misure di sicurezza devono gestire quella della catena di approvvigionamento (art. 24 del D.Lgs. 138/2024). Su questo punto Google Cloud e AWS sono nella stessa posizione: contano contratto, registro delle informazioni, rischio di concentrazione e piano di uscita, che trattiamo in DORA e cloud.

I fattori che determinano il costo

Il costo dipende dall'architettura più che dal listino. I fattori da mettere sul tavolo:

• Carichi: tipo, dimensione e orari di macchine virtuali, database, analisi dei dati e AI.
• Traffico: quanti dati escono dal cloud verso utenti, sedi o altri provider.
• Impegni di utilizzo: entrambi offrono sconti in cambio di un impegno, i committed use discounts su Google Cloud e i Savings Plans su AWS, che vanno dimensionati su un uso stabile.
• Log: i log di accesso ai dati su Google Cloud e la conservazione lunga su AWS hanno un costo di volume e di archiviazione.
• Chiavi esterne: il gestore esterno, l'hardware e la rete per collegarlo sono a carico tuo.

Quando Google Cloud ha un vantaggio concreto

Restando sui fatti documentati, Google Cloud risponde meglio a un requisito preciso quando:

• vuoi primario e disaster recovery in due regioni distinte, entrambe in Italia;
• servono controlli sugli accessi del provider, come Access Transparency e Access Approval, su servizi qualificati ACN;
• il progetto passa da analisi dei dati e AI, con BigQuery e Vertex AI Platform nel catalogo ACN;
• usi già Google Workspace o vuoi un SOC su Google SecOps, che riceve i log di Google Cloud per ingestione diretta.

Se invece carichi e competenze del team sono già su AWS, il costo del cambiamento pesa più di qualsiasi confronto di funzionalità, e la domanda giusta diventa come sorvegliare bene ciò che c'è.

Se li usi entrambi

Se hai carichi su più cloud, il problema pratico è la visibilità: due console, due modelli di permessi, due formati di log. Wiz, entrato in Google Cloud l'11 marzo 2026, resta disponibile anche su AWS, Microsoft Azure e Oracle Cloud e dà una vista unica della postura, come spieghiamo in cos'è Wiz. Se non sai in che stato sono i tuoi ambienti, il primo passo è una fotografia della sicurezza del cloud fatta sui dati reali.

In sintesi: sulla parte gestita dal provider Google Cloud e AWS offrono garanzie equivalenti e verificabili. Le differenze utili sono quattro: due regioni italiane contro una, il modo in cui ACN ha qualificato i servizi, i controlli sugli accessi del personale del provider e il percorso dei log verso il SOC. Il resto dipende da come l'ambiente è costruito e gestito.

Come partner Google Cloud progettiamo, migriamo e gestiamo ambienti con questi criteri, partendo da un assessment di architettura, carichi, costi e rischi: trovi come lavoriamo nella pagina cloud e infrastruttura gestita.