Seguim a la Part VII amb el Capítol 30: Multi-compte i landing zones, que tracta sobre com organitzen AWS les empreses grans. Al subcapítol 23.1 vam veure AWS Organizations i les SCP, i vam mencionar que les empreses usen diversos comptes. Ara aprofundim: per què separar les coses en comptes diferents en comptes de posar-ho tot en una? Entendre això és clau per dissenyar la base de qualsevol organització seriosa a AWS. La idea central: el compte d’AWS és la millor unitat de separació que existeix.

Un compte d’AWS és un «contenidor» complet i aïllat de recursos, amb la seva pròpia facturació i els seus propis límits de seguretat. Fins ara hem treballat, implícitament, dins d’un compte. Les empreses grans, en canvi, usen molts comptes coordinats (amb AWS Organizations, subcapítol 23.1). La pregunta és per què.

Imagina una empresa amb diversos equips, diversos projectes i els entorns de desenvolupament, proves i producció, tot en un sol compte d’AWS. Sorgeixen problemes seriosos:

És com tenir tota una empresa treballant en una única habitació gegant sense parets: el soroll, el desordre i els riscos d’uns afecten a tots. Cal posar «parets». I a AWS, la millor «paret» és el compte.

La pràctica recomanada per a empreses és separar les diferents workloads (càrregues de treball) en comptes diferents. Cada equip, projecte o entorn important va en el seu propi compte. El compte és la unitat de separació més forta d’AWS, perquè ofereix aïllament en tres dimensions alhora:

Analogia: separar en comptes és com dividir un edifici en apartaments independents en comptes d’una nau diàfana. Cada apartament té la seva porta amb clau (un problema en un no entra als altres: seguretat), el seu comptador de la llum (cadascú paga el seu: costos), i les seves pròpies instal·lacions (un no esgota l’aigua de l’altre: límits). Viure en apartaments separats és molt més ordenat i segur que compartir una nau sense parets. Els comptes són aquests apartaments.

Si separes en comptes, un problema de seguretat en un compte (una bretxa, un error, un atac) queda contingut en aquell compte i no afecta els altres. És l’aplicació màxima del «radi d’explosió» limitat: si alguna cosa surt malament, el dany està acotat.

Això és especialment valuós per separar producció (el crític) de desenvolupament/proves (on s’experimenta i hi ha més risc). Un error d’un desenvolupador en el seu compte de proves mai hauria de poder tocar producció, i separar comptes ho garanteix.

Amb cada workload en el seu compte, la factura de cadascun està separada automàticament (recorda la facturació consolidada d’Organizations, subcapítol 23.1: veus el total, però també el desglossament per compte). Saber exactament quant costa cada projecte o equip és essencial per a la gestió de costos (recorda FinOps, subcapítol 25.5). En un sol compte, separar costos és molt més difícil (depens només d’etiquetes).

AWS imposa certs límits per compte (quants recursos d’un cert tipus pots crear, etc.). Si tot està en un compte, un projecte podria esgotar aquests límits i afectar els altres. Amb comptes separats, cada workload té els seus propis límits i no destorba els altres.

Com decideixen les empreses què va a cada compte? Patrons comuns:

Aquests comptes s’agrupen ordenadament en Unitats Organitzatives (OU) dins d’AWS Organizations (recorda el subcapítol 23.1), i se’ls apliquen regles comunes amb SCP.

Exemple del món real: una empresa amb tres equips de producte decideix la seva estructura multi-compte. Cada equip rep dos comptes: un de desenvolupament (on experimenten lliurement) i un de producció (amb controls estrictes). A més, creen un compte de seguretat central (per a l’equip de seguretat) i un compte de logs (on es centralitzen tots els registres). Resultat: quan un desenvolupador trenca alguna cosa en el seu compte de desenvolupament, producció ni se n’assabenta; cada equip veu exactament el que costa el seu producte; i un incident en un equip queda aïllat dels altres. L’empresa va passar d’un «tot barrejat» arriscat a una estructura ordenada, segura i amb costos clars. Aquesta separació és la base d’operar a escala.

• Posar tot en un sol compte d’AWS no escala: barreja entorns (un error en proves afecta producció), confon costos, embolica permisos, concentra el risc i comparteix límits. Com una empresa en una nau sense parets.
• La pràctica recomanada és separar els workloads en comptes diferents (per entorn, equip o projecte). El compte és la unitat d’aïllament més forta d’AWS. Com dividir un edifici en apartaments independents.
• Separar en comptes aïlla en tres dimensions: seguretat (un problema no salta entre comptes; la més important), costos (factura separada per compte) i límits (cada compte té els seus).
• El més valuós: separar producció de desenvolupament/proves, perquè un error o bretxa en proves mai pugui tocar producció.
• Els comptes s’agrupen en OU i es governen amb SCP (Organizations, subcap. 23.1). Patrons: per entorn, equip, projecte, més comptes especials (seguretat, logs).

Al següent subcapítol veurem com crear i gestionar tots aquests comptes de manera automatitzada i amb bones pràctiques des del principi, amb AWS Control Tower i les landing zones.