Fondamenta: AWS Organizations e la strategia multi-account

AWS Organizations raggruppa più account sotto un unico management account (ex “master”). La strategia multi-account non è un vezzo: separare workload, ambienti (dev/test/prod) e team in account distinti riduce il blast radius, crea confini di sicurezza netti e semplifica l’attribuzione dei costi. Gli account si organizzano in Organizational Unit (OU) — tipicamente per funzione (Security, Infrastructure, Workloads) o per ambiente — così da applicare policy a gruppi coerenti anziché account per account. Organizations abilita anche il consolidated billing, prerequisito per condividere volume discount, Reserved Instances e Savings Plans su tutta l’organizzazione.

Service Control Policy: i guardrail preventivi

Le SCP definiscono il perimetro massimo di permessi per gli account membri: non concedono nulla, limitano soltanto ciò che le identità IAM possono fare. Il permesso effettivo è l’intersezione tra SCP e policy IAM (identity/resource): se la SCP nega un’azione, nessuna policy IAM può riabilitarla. Vanno applicate a OU o a singoli account e si ereditano lungo la gerarchia. Due punti chiave: il management account non è mai soggetto alle SCP (per questo non va usato per i workload) e la SCP di default FullAWSAccess consente tutto finché non si adotta una strategia deny-based. Nel mondo DevOps le SCP servono a imporre guardrail come vietare la disabilitazione di AWS CloudTrail o AWS Config, bloccare region non approvate o negare la modifica di ruoli critici, indipendentemente da quanto siano permissive le policy IAM locali.

Least privilege e landing zone con Control Tower

Il least privilege resta il principio guida: concedere solo i permessi necessari, preferendo IAM role assunti temporaneamente a credenziali statiche e usando permission boundary per delimitare cosa un ruolo può delegare. Le SCP agiscono a livello di organizzazione; IAM policy e permission boundary a livello di account e identità: sono complementari, non alternativi. Costruire e mantenere a mano questa struttura è oneroso: AWS Control Tower automatizza una landing zone opinionata con OU predefinite, account dedicati per log e audit, guardrail preventivi (implementati come SCP) e guardrail detective (implementati come regole AWS Config). Account Factory provisiona nuovi account conformi in modo ripetibile. La scelta di design è tra Control Tower (rapido, best practice codificate, meno flessibile) e una landing zone custom (massimo controllo, più manutenzione).

Controllo e ottimizzazione dei costi multi-account

Con decine di account il costo va governato centralmente. Il consolidated billing aggrega la spesa e fa scattare automaticamente lo sharing di Savings Plans e Reserved Instances tra account. Per la visibilità si usano AWS Cost Explorer (analisi e trend), il Cost and Usage Report (dato granulare per pipeline di FinOps) e le cost allocation tag, da attivare nel management account per segmentare la spesa per progetto, team o ambiente. Il presidio proattivo si ottiene con AWS Budgets (soglie e alert) e AWS Cost Anomaly Detection (rilevamento anomalie). Le tag policy di Organizations aiutano a imporre una tassonomia di tag coerente, condizione necessaria per report di costo affidabili.

Trappole tipiche d’esame

  • SCP che “non concede” permessi → ricorda l’intersezione: una SCP non dà mai un permesso; se un’identità non può agire, controlla anche la IAM policy, perché serve il consenso di entrambe.
  • Bloccare un’azione in tutti gli account, root incluso → SCP, non IAM: le IAM policy si gestiscono account per account; solo una SCP applicata all’OU vincola ogni identità, root degli account membri compreso.
  • La regola non ha effetto dove ti aspetti → workload fuori dal management account: le SCP non si applicano al management account, quindi non ospitarci le risorse che vuoi vincolare.
  • Serve una landing zone conforme e veloce → Control Tower: se lo scenario chiede provisioning ripetibile con guardrail già pronti, è Control Tower + Account Factory, non script IAM manuali.
  • Alert automatico sullo sforamento di spesa → AWS Budgets: per notifiche su soglie usa Budgets; Cost Explorer serve ad analizzare i trend, non ad allertare in tempo reale.
  • Sconti di volume su più account → consolidated billing: RI e Savings Plans si condividono solo se gli account stanno nella stessa organization con consolidated billing attivo.