Amazon SAP-C02: Complessità organizzativa e strategia multi-account — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fa parte della AWS Solutions Architect Professional SAP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Strategia multi-account e vending di account

Una strategia multi-account inizia con una chiara separazione delle responsabilità: sicurezza e audit, networking condiviso, carichi di lavoro di produzione e account di sandbox o per sviluppatori. L’utilizzo di AWS Organizations con AWS Control Tower o una landing zone personalizzata impone questa separazione fin dal primo giorno. L’Account Factory di Control Tower fornisce un pattern di vending di account che automatizza la creazione di account, i ruoli IAM di base, i template VPC e i guardrail, mentre una landing zone personalizzata costruita con CloudFormation/CDK e Service Catalog offre maggiore flessibilità per reti e governance su misura. Il compromesso principale è tra l’overhead operativo e la riduzione del blast radius: un numero maggiore di account aumenta la superficie di gestione (automazione, ruoli cross-account, visibilità della fatturazione) ma limita l’esposizione alla compromissione del dominio e semplifica la conformità per singolo account. Le scelte di networking — condivisione di VPC con AWS Resource Access Manager, architettura hub-and-spoke con Transit Gateway o VPC isolati con VPC peering — determinano compromessi in termini di costi e latenza. I servizi condivisi (DNS, NAT, Active Directory) risiedono spesso in un account di networking o di servizi condivisi; il vending di account dovrebbe collegare automaticamente i nuovi account a queste risorse condivise o fornire VPC delegati. Pianificare le quote e l’automazione: centralizzare le pipeline per gli artefatti di base in modo che la scalabilità degli account non moltiplichi il lavoro manuale ripetitivo.

Governance: SCP, guardrail di Control Tower e policy organizzative

La governance in un ambiente AWS multi-account si basa sull’applicazione di policy a livello di organization e su controlli di runtime delegati. Le Service Control Policies (SCP) stabiliscono il limite massimo per le azioni consentite tra gli account; sono potenti ma inflessibili — le regole di deny a livello della OU radice impediscono persino agli amministratori di creare ruoli collegati ai servizi (service-linked roles) o di utilizzare servizi a meno che non siano esplicitamente permessi. Control Tower offre guardrail predefiniti (obbligatori, fortemente raccomandati, facoltativi) che implementano SCP e regole di Config comuni, ma può risultare restrittivo per pattern di servizio avanzati. La decisione progettuale si concentra sulla scelta tra governance centralizzata e delegata: una deny-list restrittiva a livello radice massimizza la conformità ma aumenta l’attrito per i team di prodotto e l’automazione, mentre baseline permissive con permission boundary e controlli sui ruoli IAM consentono una maggiore velocità di sviluppo. Le policy di logging e auditing (CloudTrail a livello di organization, aggregatore di AWS Config, amministratori delegati per Security Hub e GuardDuty) devono essere applicate dall’account di gestione per garantire percorsi di audit immutabili. Un approccio pragmatico è la governance a più livelli: SCP a livello di organization per le restrizioni ad alto impatto, permission boundary per definire l’ambito degli sviluppatori e guardrail automatizzati applicati dalla CI/CD della landing zone per mantenere la coerenza senza blocchi manuali.

Confini di sicurezza: ruoli cross-account, KMS e policy delle risorse

L’accesso cross-account è un pattern fondamentale e deve essere implementato secondo il principio del privilegio minimo (least privilege) e con solidi controlli di trust. Il pattern comune delega l’accesso tramite ruoli IAM in ogni account, che i principal fidati assumono con STS: i ruoli per il deployment CI/CD, il monitoraggio (CloudWatch/SSM) e le integrazioni di terze parti dovrebbero richiedere l’MFA dove appropriato e utilizzare ID esterni (external ID) per l’accesso dei partner. Le policy basate sulle risorse (resource-based policies) su bucket S3, code SQS e chiavi KMS consentono l’accesso cross-account diretto, ma KMS aggiunge complessità: una policy di una chiave KMS deve consentire esplicitamente i principal e i servizi dell’account che si fida (trusting account), e potrebbero essere necessari dei grant o grant con vincoli per l’accesso temporaneo. L’uso di una chiave KMS centralizzata nell’account di logging o di sicurezza semplifica la crittografia centralizzata, ma crea un accoppiamento operativo e potenziali considerazioni sulla disponibilità; le chiavi per singolo account riducono il blast radius ma moltiplicano la gestione della rotazione delle chiavi e dei grant. Le trappole comuni includono SCP che negano inavvertitamente la creazione di risorse KMS o di ruoli collegati ai servizi, policy dei bucket in conflitto con le SCP e dimenticare di aggiungere il ruolo di delega a Config/CloudTrail nell’account collettore. Le decisioni progettuali dovrebbero soppesare la semplicità amministrativa, il principio del privilegio minimo e la latenza cross-account.

Pattern di logging, fatturazione e automazione centralizzati

Il logging e la fatturazione centralizzati sono la spina dorsale della visibilità aziendale. Un CloudTrail a livello di organizzazione con trail inviati a un bucket S3 in un account centralizzato di sicurezza o audit garantisce l’acquisizione di eventi a prova di manomissione; integrare con i filtri di sottoscrizione di CloudWatch Logs verso Kinesis Data Firehose per l’analisi e aggregare i dati di Config con un aggregatore nello stesso account. La visibilità dei costi richiede la fatturazione consolidata in Organizations, Cost Explorer, Budgets e i Cost and Usage Reports inviati centralmente; la governance dei tag e l’applicazione automatizzata dei tag tramite le regole di Config migliorano l’accuratezza del chargeback. I pattern di automazione che scalano tra più account utilizzano comunemente una pipeline CI/CD condivisa o un account di deployment che assume ruoli di deployment cross-account, oppure CloudFormation StackSets con un amministratore delegato per il provisioning di massa. Utilizzare Systems Manager Automation e State Manager per il patching e la configurazione cross-account, ma ricordare che ogni account deve concedere i ruoli e le autorizzazioni SSM necessari. I compromessi bilanciano centralizzazione e latenza: l’aggregazione centrale riduce la duplicazione dello storage e semplifica l’analisi, ma crea dipendenze di rete e di disponibilità; il logging distribuito duplica i dati ma isola i guasti. Pianificare la retention, le regole di lifecycle, la replica cross-region per il DR e la gestione delle chiavi di crittografia in modo coerente con i requisiti di conformità.

Scenario d’uso pratico

Scenario: Contoso Media gestisce un ambiente AWS aziendale con Organizations e Control Tower attivi. Hanno un account di gestione, un account di rete per i servizi condivisi e 20 account membri che eseguono carichi di lavoro di produzione, staging e sviluppo in due Regioni.

Sfida: Contoso deve eseguire rapidamente l’onboarding di 15 nuovi account di progetto, garantendo al contempo il logging centralizzato, guardrail SCP appropriati, connettività di rete automatizzata all’account dei servizi condivisi tramite Transit Gateway e pipeline di deployment che non richiedano una configurazione IAM manuale per ogni account.

Approccio consigliato:

1. Utilizzare Control Tower Account Factory o un flusso di lavoro automatizzato con l’API di AWS Organizations per distribuire gli account con un template di base CloudFormation/CDK che registra l’account in AWS Config, abilita un CloudTrail di organizzazione che punta al bucket S3 dell’account di audit e applica i tag richiesti.
2. Collegare gli SCP a livello di OU che impongono deny ad alto impatto (ad esempio, negare la cancellazione di chiavi cross-region e le region non consentite) mantenendo le OU con permessi di sviluppo meno restrittive; validare gli SCP in una sandbox prima di un’applicazione su larga scala.
3. Configurare il Transit Gateway nell’account di rete dei servizi condivisi e creare attachment per l’attachment VPC del Transit Gateway di ogni nuovo account, utilizzando Infrastructure-as-Code e un amministratore delegato o un ruolo cross-account che il processo di distribuzione assume per automatizzare la creazione degli attachment e la propagazione delle route.
4. Effettuare il provisioning di una pipeline di deployment CI/CD centralizzata in un account per gli strumenti (tooling) che utilizza ruoli IAM cross-account (assume-role) creati dal processo di distribuzione degli account; utilizzare CloudFormation StackSets (con amministratore delegato) o azioni CodePipeline cross-account per il provisioning di base iniziale e gli aggiornamenti continui.

Motivazione: L’automazione della distribuzione degli account con artefatti di base impone la governance riducendo al minimo i passaggi manuali; la delega delle attività di rete e di deployment tramite ruoli cross-account e Transit Gateway centralizza i servizi condivisi, riduce il raggio d’impatto (blast radius) e permette di scalare l’onboarding senza sacrificare la sicurezza o l’auditabilità.

Tutti i domini · Networking e connettività ibrida →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →