Tres lliçons han resolt la meitat del cinquè problema: la infraestructura de MercadoFresco és reproduïble, viu en un repositori, passa per revisió i es desplega des d'un pipeline que s'actualitza a si mateix. Però hi ha una frase que ha aparegut a les tres i que cap no ha resolt: els tres entorns comparteixen el compte 111122223333.

Mentre això continuï sent cert, un cdk destroy mal dirigit arriba a producció, un desplegament de desenvolupament pot esgotar una quota que necessita producció, cap política d'IAM no aïlla del tot qui ja té permisos amplis, i la factura no separa de debò el que costa cada entorn. AWS Organizations és la resposta: separar els entorns en comptes diferents i governar el conjunt des de dalt.

Avís de cost. Organizations és gratuït: no cobra per comptes, ni per unitats organitzatives, ni per polítiques de control de serveis. Control Tower tampoc no cobra per si mateix, però activa serveis que sí que costen: CloudTrail, Config i les notificacions de la línia base ronden els 10-25 USD al mes per compte, i el gravador de Config és la part més cara. Els comptes nous comencen amb la seva pròpia capa gratuïta. Comptes i dades fictícies.

1. Per què un sol compte es queda curt
2. Conceptes: organització, compte de gestió, OU i comptes membre
3. L'estructura de MercadoFresco
4. Crear i convidar comptes: correu, contactes i arrel
5. Polítiques de control de serveis: què són i què no
6. Quatre SCP reals per a MercadoFresco
7. Polítiques d'etiquetes, de còpies de seguretat i d'IA
8. Facturació consolidada
9. Control Tower, zona d'aterratge i Account Factory
10. IAM Identity Center: tres persones, cinc comptes
11. Rols entre comptes i sts:AssumeRole
12. Serveis a escala d'organització
13. El pla de migració de MercadoFresco
14. Cost i neteja
15. Errors habituals i consells
16. Exercicis
17. Conclusió: tancament del mòdul

El compte d'AWS no és només una unitat de facturació: és la frontera d'aïllament més forta que existeix a la plataforma. Tota la resta —IAM, VPC, etiquetes— és una frontera dins de la mateixa casa.

Convé veure on encaixa el compte entre les fronteres que el curs ja ha fet servir:

El cas que més espanta la Marta és el primer, i no és teòric: a 09-02 va aparèixer tres vegades. cdk destroy MercadoFrescoRedProduccion és a un autocompletat de distància de MercadoFrescoRedDesarrollo, i ni la protecció de terminació ni la disciplina de no fer servir --all són garanties: són pedaços. Amb comptes separats, l'ordre simplement no té permisos per arribar a producció, perquè les credencials amb què s'executa pertanyen a un altre compte.

El segon tampoc no és teòric. Les quotes d'EC2 —vCPU per família, IP elàstiques, interfícies de xarxa— són per compte i regió. Una prova de càrrega en desenvolupament que aixeca vint instàncies consumeix vCPU del mateix contingent que l'autoescalat de la botiga, i el divendres a les 19:00, amb 900 comandes/hora, l'ASG es pot quedar sense poder créixer per culpa d'una prova llançada el dijous.

• Organització: el conjunt de comptes gestionats de manera centralitzada. Té una arrel (root), que és el node superior de l'arbre.
• Compte de gestió (management account): el compte que crea l'organització. És el que paga, el que convida comptes i l'únic des del qual s'apliquen polítiques.
• Unitat organitzativa (OU): un contenidor de comptes i d'altres OU. És on s'apliquen les polítiques, i el motiu pel qual existeix: agrupar comptes que han de ser governats igual.
• Compte membre: qualsevol compte de l'organització que no sigui el de gestió. Aquí hi viu tota la feina.

Hi ha una regla que convé gravar abans de continuar: al compte de gestió no s'hi treballa. No s'hi despleguen càrregues, no s'hi creen usuaris de treball, no s'hi executen pipelines. Tres raons:

1. Les SCP no s'apliquen al compte de gestió. Ni tan sols si el poses dins d'una OU. Qualsevol recurs que hi visqui queda fora de totes les barreres que dissenyis.
2. És el compte amb més poder de l'organització: pot crear comptes, canviar polítiques i, en darrer terme, treure comptes de l'organització. Comprometre'l és comprometre-ho tot.
3. Facturació i govern són responsabilitats diferents de les càrregues. Barrejar-les fa impossible auditar qui ha fet què.

Un límit útil: la profunditat màxima de l'arbre d'OU és de cinc nivells per sota de l'arrel, i un compte pertany exactament a una OU.

Sis comptes, cinc dels quals de treball. Les decisions que hi ha al darrere mereixen justificar-se una a una:

• Seguridad aïlla el que ha de sobreviure a un incident als comptes de càrrega: la destinació del trail de l'organització, l'agregador de Config, Security Hub i GuardDuty. Si algú compromet producció, no pot esborrar les proves, perquè són en un altre compte al qual no té accés.
• Infraestructura allotja allò compartit entre entorns: el pipeline, mercadofresco-artefactos i els registres d'imatges. Separar-ho evita la paradoxa que el pipeline que desplega producció visqui a producció.
• Cargas agrupa els tres entorns, amb una OU per entorn per poder aplicar-los polítiques diferents. Producció tolera menys que desenvolupament, i desenvolupament necessita restriccions de cost que producció no.
• Aislamiento és buida i aquest és el seu propòsit: és la destinació d'un compte compromès. Porta una SCP que ho denega tot, de manera que moure-hi un compte el congela en un sol pas, sense tocar-ne les credencials ni els recursos, i deixa l'evidència intacta per a la investigació.

I una decisió pragmàtica que estalvia setmanes: el compte actual 111122223333 es converteix en producció. Migrar producció és el més car i el més arriscat; reutilitzar-lo i crear comptes nous per a tota la resta redueix la migració a allò que sí que es pot recrear amb les plantilles de 09-01 i el CDK de 09-02.

Hi ha dues maneres que un compte entri a l'organització: crear-lo des de dins o convidar-ne un d'existent.

--feature-set ALL és important: l'alternativa, CONSOLIDATED_BILLING, només agrupa la facturació i no permet polítiques de control de serveis, que és la meitat del valor d'Organizations.

Quatre detalls operatius que causen problemes si es descuiden:

• Cada compte necessita un correu únic, i aquest correu controla la recuperació de l'usuari arrel. La pràctica correcta és una llista de distribució —[email protected]— que arribi a la Marta i a una segona persona, mai el correu personal d'algú que pot marxar de l'empresa. Els àlies amb + funcionen a la majoria de proveïdors i fan que això sigui trivial.
• L'usuari arrel de cada compte membre es blinda i s'oblida: contrasenya llarga al gestor de secrets de l'equip, MFA activat, i sense claus d'accés. Tota la feina diària passa per Identity Center.
• OrganizationAccountAccessRole es crea automàticament als comptes creats des de l'organització, i permet al compte de gestió assumir-hi un rol d'administrador. Als comptes convidats no existeix i cal crear-lo a mà abans de convidar-los, o quedaran inaccessibles des de la gestió.
• Els contactes alternatius —facturació, operacions i seguretat— s'emplenen per compte i es poden fixar des de l'organització. És on AWS avisa d'un abús o d'un problema de seguretat, i un compte sense ells rep els avisos únicament al correu de l'usuari arrel.

Una política de control de serveis (SCP) defineix el màxim de permisos que es poden exercir en un compte. I aquí hi ha la frase que cal memoritzar: una SCP mai no concedeix permisos, només els limita.

El permís efectiu és la intersecció: el que permet la SCP i el que permet IAM. Conseqüències pràctiques:

• Una SCP que permet s3:* no dona accés a S3 a ningú: només deixa que IAM el pugui donar.
• Una SCP que denega s3:DeleteBucket impedeix esborrar buckets fins i tot a l'administrador del compte, fins i tot amb AdministratorAccess. És el seu valor principal: limita qui ja ho pot tot.
• Les SCP no s'apliquen al compte de gestió ni als rols vinculats a serveis (AWSServiceRoleFor*).

Hi ha dues estratègies, i l'elecció té conseqüències enormes:

MercadoFresco tria llista de denegats, que és el recomanable per al 90 % de les organitzacions: un equip de tres persones no pot mantenir una llista de permesos sense convertir-la en un coll d'ampolla. La llista de permesos té sentit en entorns molt regulats o en OU amb un propòsit únic.

El repartiment habitual de polítiques per nivell, que és el que MercadoFresco adopta:

L'herència és acumulativa cap avall: un compte està subjecte a les SCP de la seva OU, de les OU superiors i de l'arrel, totes alhora. I com que els Deny sempre guanyen, n'hi ha prou que una sola política del camí denegui una acció perquè quedi prohibida. Aquesta és la raó de l'advertiment clàssic que ve a continuació.

1. Limitar les regions. S'aplica a l'arrel. Impedeix crear recursos fora d'eu-west-1, amb l'excepció obligada d'us-east-1, on viuen CloudFront, WAF per a CloudFront i els certificats d'ACM associats.

NotAction és imprescindible: els serveis globals es resolen contra us-east-1 a l'API, i denegar-los per regió trencaria IAM, Route 53 i la mateixa consola de facturació. És l'error número u en escriure aquesta política.

2. Protegir l'auditoria. S'aplica a l'arrel. Impedeix que ningú —ni un administrador de producció— esborri el rastre.

Això tanca un forat real de 05-03: fins ara, qui tenia AdministratorAccess al compte podia apagar CloudTrail abans de fer res. Ja no.

3. Exigir xifratge a S3. S'aplica a l'OU Cargas. Denega pujar objectes sense xifrar i crear buckets sense bloqueig d'accés públic.

La segona declaració fa servir el patró d'excepció per principal: ningú no pot desactivar el bloqueig d'accés públic tret d'un rol concret de seguretat. És la manera correcta de deixar una vàlvula d'escapament sense obrir la porta.

4. Acotar el cost en desenvolupament. S'aplica només a l'OU Desarrollo.

La segona declaració evita un tipus d'error que no es desfà: comprar un compromís d'un any des del compte de desenvolupament. Els Savings Plans i les instàncies reservades es compren des del compte de gestió, i es reparteixen sols per tota l'organització (11-05).

Una condició que apareix a gairebé totes les organitzacions i que convé conèixer és aws:PrincipalOrgID, que identifica l'organització sencera. Permet escriure polítiques de recurs del tipus «aquest bucket és accessible des de qualsevol compte de la meva organització, i només des d'aquests», sense enumerar identificadors de compte que canvien amb el temps:

És la manera correcta de compartir el bucket d'artefactes entre el compte d'eines i els tres de càrrega: un sol document que no cal tocar quan entri un compte nou. La seva germana aws:PrincipalOrgPaths permet acotar a més per OU, per exemple perquè només els comptes de Cargas puguin llegir.

Mai no provis una SCP nova aplicant-la primer a l'arrel. És l'error que converteix una tarda de millores en un incident, i passa per dues raons combinades: les SCP afecten tots els comptes de cop, i els seus efectes no sempre són evidents —un Deny sobre ec2:* trenca també serveis que creen interfícies de xarxa, com Lambda a VPC o RDS—.

El procediment correcte té quatre passos:

1. Escriure la política i revisar-la en PR, com qualsevol altre codi: les SCP viuen a mercadofresco-infra.
2. Aplicar-la a un sol compte de desenvolupament i executar-hi el pipeline complet, un desplegament i les proves de fum.
3. Pujar-la a l'OU Desarrollo, esperar uns dies i revisar els AccessDenied a CloudTrail.
4. Promocionar-la a Cargas o a l'arrel.

I una salvaguarda que evita el pitjor escenari: el compte de gestió no està subjecte a les SCP, així que sempre queda un camí per desfer una política que hagi bloquejat l'organització. És una de les raons per les quals el seu accés ha d'estar protegit amb MFA i fer-se servir el mínim possible.

Organizations té altres tres tipus de política, menys coneguts i molt útils.

Les polítiques d'etiquetes defineixen etiquetes obligatòries, els seus valors vàlids i sobre quins recursos s'exigeixen. Resolen el problema que MercadoFresco arrossega des del mòdul 1: que l'etiquetatge obligatori depèn que la gent se'n recordi.

Amb enforced_for, una operació que creï un recurs d'aquests tipus amb un valor d'Entorno diferent dels tres permesos falla. Sense enforced_for, la política només informa: apareix un informe d'incompliment i res més. Aquesta diferència és exactament la de 08-02 entre avisar i bloquejar.

Les polítiques de còpies de seguretat apliquen plans d'AWS Backup a tota l'organització: quins recursos es copien, amb quina freqüència i amb quina retenció, sense dependre que cada compte ho configuri. Per a MercadoFresco és la garantia que un compte nou neix amb còpies, en comptes de descobrir-ho el dia que fan falta.

Les polítiques d'IA (AI services opt-out) permeten excloure tota l'organització de l'ús de les seves dades per millorar els serveis d'IA d'AWS. És una decisió que a Europa sol prendre l'àrea legal, i n'hi ha prou d'activar-la un cop a l'arrel.

La facturació consolidada és la part que menys entusiasma tècnicament i la que es nota més de pressa:

• Una sola factura per a tota l'organització, amb desglossament per compte.
• Descomptes per volum agregats: els preus escalonats d'S3 o de transferència de dades es calculen sobre l'ús sumat de tots els comptes, així que separar en comptes no encareix res. Al contrari: cinc comptes petits arriben abans a un esglaó de descompte que cinc projectes aïllats en comptes independents.
• Repartiment automàtic de Savings Plans i instàncies reservades: un compromís comprat des del compte de gestió s'aplica a qualsevol compte de l'organització que tingui ús elegible. Si producció no consumeix tot el compromís una nit, l'aprofita preproducció. Es detalla a 11-05.
• Capa gratuïta: es comparteix a escala d'organització, no es multiplica per compte.

I el més important per al problema que ha obert aquesta lliçó: la separació per compte fa que la pregunta «quant costa preproducció?» tingui una resposta exacta i sense feina. Abans depenia que tots els recursos estiguessin ben etiquetats, i a 09-01 es va veure que no ho estaven. Ara és una dimensió nativa de Cost Explorer (11-03).

Dos ajustos que convé fer el primer dia: activar l'ús compartit de descomptes (està actiu per omissió, però es pot desactivar per compte si un equip ha de veure el seu cost sense subvencions creuades) i habilitar les etiquetes d'assignació de costos al compte de gestió, ja que només des d'allà s'activen per a tota l'organització (11-02).

Tot l'anterior es pot muntar a mà amb la CLI. AWS Control Tower ho fa per tu i hi afegeix govern continu.

Una zona d'aterratge (landing zone) és un entorn multicompte preconfigurat i conforme a bones pràctiques. Control Tower la crea en unes dues hores: l'organització, les OU de seguretat i càrregues, un compte d'arxiu de registres, un compte d'auditoria, un CloudTrail d'organització, un agregador de Config, IAM Identity Center configurat i un conjunt de controls actius.

Els controls (guardrails) són de tres tipus, i la distinció importa:

L'Account Factory és l'aprovisionament de comptes: s'omple un formulari —nom, correu, OU— i en surt un compte amb la línia base aplicada, la xarxa creada i l'accés configurat. Amb Account Factory for Terraform o amb StackSets, tot això es pot disparar des d'un pipeline.

Quan convé fer servir Control Tower? El criteri és senzill:

Per a MercadoFresco, amb sis comptes i un equip que ja domina el CDK, la decisió de la Marta és començar amb Organizations a mà —les polítiques són poques i les vol entendre— i deixar Control Tower anotat per quan l'organització passi de deu comptes. És una decisió defensable; la contrària també ho seria.

Amb sis comptes, la pregunta operativa és immediata: la Marta necessita sis usuaris? La resposta és que necessita zero usuaris d'IAM.

IAM Identity Center (abans AWS SSO) proporciona un directori d'identitats —propi, o federat amb Entra ID, Okta o Google Workspace— i assigna conjunts de permisos a combinacions d'usuari o grup i compte. En iniciar sessió, cada persona veu un portal amb els comptes i rols als quals té accés, i en entrar rep credencials temporals: no hi ha claus d'accés de llarga durada a cap portàtil.

Un conjunt de permisos és una plantilla de rol que Identity Center materialitza a cada compte assignat. El disseny de MercadoFresco:

Quatre decisions de disseny que mereixen explicació:

• El Luis no té administració a producció. Té lectura i permís per llançar el pipeline, que és el que de debò necessita: des de 08-04, desplegar és aprovar una transició, no executar ordres. Aquest és el punt on el pipeline deixa de ser una comoditat i passa a ser un control de seguretat.
• Les sessions administratives duren una hora. Una sessió llarga amb permisos alts és una credencial oblidada en un terminal.
• RespuestaIncidentes és un accés d'emergència deliberadament incòmode: requereix aprovació i el seu ús dispara una notificació a alertas-mercadofresco. Existeix per a les tres de la matinada, no per al dimarts a la tarda.
• La Sara només entra a producció, i només a dades. No necessita desenvolupament ni preproducció, i donar-li accés «per si de cas» és exactament el que 04-01 desaconsella.

I l'ús diari des de la CLI, que substitueix el perfil mercadofresco-dev amb claus estàtiques del mòdul 1:

Identity Center resol l'accés de les persones. L'accés entre serveis de comptes diferents es resol amb rols i sts:AssumeRole, exactament el mecanisme de 04-01 creuant la frontera de compte.

El cas concret de MercadoFresco: el pipeline viu a herramientas-mercadofresco (555566667777) i ha de desplegar als tres comptes de càrrega.

Aquest document és la política de confiança del rol rol-despliegue-mercadofresco al compte de producció: diu qui el pot assumir. La política de permisos del rol, a part, diu què pot fer un cop assumit. Són dues coses diferents i totes dues han de ser restrictives: una política de confiança que accepti "AWS": "111122223333" sense res més permet a qualsevol principal d'aquest compte assumir el rol.

Al CDK, el bootstrap ja ho preveu: cdk bootstrap --trust 555566667777 crea els rols de desplegament del compte destinació confiant en el compte d'eines, i a partir d'aquí cdk deploy funciona entre comptes sense més configuració. És el motiu pel qual a 09-02 s'insistia a declarar env amb compte explícit: amb diversos comptes, el compte destinació deixa de ser un detall i passa a ser part de la definició de la pila.

Molts serveis de seguretat i govern es poden activar per a tota l'organització des d'un compte d'administrador delegat —típicament seguridad-mercadofresco—, de manera que els comptes nous queden coberts automàticament.

La peça que tanca el cercle del mòdul és l'última fila. El StackSet ss-mercadofresco-linea-base de 09-01, amb --permission-model SERVICE_MANAGED i --auto-deployment Enabled=true, fa que qualsevol compte que entri en una OU rebi la línia base sense que ningú faci res: alarma de facturació, rols d'accés, configuració de contactes, bloqueig d'accés públic d'S3 i subscripció a l'agregador de Config.

Aquesta ordre és la resposta a «com garantim que el compte que creem d'aquí a sis mesos tingui tot el que ha de tenir». La resposta és: no ho garanteix una persona, ho garanteix una OU.

La migració d'un compte a cinc de treball —més el de gestió— es fa en sis fases, sense tallar el servei. La regla que ordena tot el pla és: primer allò que es recrea, després allò que es mou, i les dades al final, amb permís.

Fase 1: crear l'organització i els comptes (dia 1). Es crea un compte de gestió nou i buit —999988887777—, es crea l'organització amb --feature-set ALL i es convida el compte actual 111122223333, que es converteix en producció i es col·loca a la seva OU. Es creen els altres quatre comptes. Res no canvia per al servei: el compte de producció continua funcionant exactament igual.

Fase 2: accés i línia base (dies 2-5). IAM Identity Center amb els conjunts de permisos, i el StackSet de línia base sobre totes les OU. Els usuaris d'IAM del mòdul 1 es desactiven però no s'esborren fins a comprovar que res automatitzat no els feia servir. CloudTrail d'organització i agregador de Config, amb destinació al compte de seguretat.

Fase 3: entorns nous des de codi (setmanes 2-3). Aquí es cobra la feina de les tres lliçons anteriors. Desenvolupament i preproducció es recreen des de zero als seus comptes amb el CDK de 09-02: cdk bootstrap a cada compte i cdk deploy amb env apuntant al compte corresponent. No es migra res: es desplega. Si alguna cosa no es pot recrear, és que faltava al codi, i aquest descobriment ja és valuós per si mateix.

Fase 4: pipeline i eines (setmana 4). El pipeline es mou a herramientas-mercadofresco i se li donen rols entre comptes cap als tres de càrrega. Es desplega a desenvolupament i preproducció des del compte nou i es verifica d'extrem a extrem abans de tocar producció.

Fase 5: SCP progressives (setmanes 4-6). Les polítiques s'apliquen en l'ordre de l'advertiment: primer un compte de desenvolupament, després l'OU Desarrollo, després Cargas, i només al final les dues de l'arrel. Entre esglaó i esglaó, revisió dels AccessDenied a CloudTrail.

Fase 6: els entorns vells (setmana 7). S'apaguen els recursos de desenvolupament i preproducció que quedaven al compte de producció. Això allibera quota, redueix el soroll i és on apareix l'estalvi: uns 340 USD al mes de recursos duplicats que ningú no sabia que continuaven encesos.

Les dades són la part delicada i mereixen el seu propi apartat, amb tres regles.

Producció no es mou. En reutilitzar 111122223333 com a compte de producció, Aurora, DynamoDB, Redshift i els cinc buckets es queden on són. És la decisió que elimina el 90 % del risc del projecte.

Les dades de desenvolupament i preproducció no es copien: es generen. És una oportunitat per fer allò que ja hauria d'estar fet: preproducció es pobla amb dades sintètiques o anonimitzades, no amb una còpia de producció. A més de ser més segur, elimina una font de deriva.

I aquí hi ha un avís que no és tècnic. Si en algun moment es planteja copiar dades de producció a un altre compte per fer proves, això és un tractament de dades personals de clients i cau sota el RGPD: noms, adreces de repartiment, telèfons i historial de compra. Una còpia a un altre compte —encara que sigui de la mateixa organització i de la mateixa regió— és una transferència que ha d'estar justificada, documentada i limitada en el temps, i l'anonimització ha de ser real, no un canvi de nom. Aquesta decisió no la pren l'equip tècnic tot sol: la revisa qui porta compliment. La Marta ho deixa escrit al pla com a requisit blocant, no com a recomanació.

Organizations, les OU i les SCP són gratuïtes. El que costa és allò que s'activa amb elles:

Per a MercadoFresco, el govern complet surt per uns 90 USD al mes, enfront dels 340 USD que s'estalvien en apagar els entorns duplicats. La migració es paga sola.

Sobre la neteja, dos avisos seriosos. Tancar un compte d'AWS no és immediat: queda en estat suspès 90 dies abans de tancar-se definitivament, i durant aquest temps no se'n poden recuperar els recursos ni reutilitzar-ne el correu. I un compte que surt de l'organització necessita el seu propi mètode de pagament i els seus contactes complets, o quedarà bloquejat. Mai no treguis un compte de l'organització sense haver-lo preparat abans.

Error: treballar al compte de gestió. És l'error estructural més car, perquè les SCP no el protegeixen i tot el que hi despleguis queda fora de les barreres. Consell: compte de gestió buit, accés amb MFA i ús excepcional.

Error: provar una SCP a l'arrel. Un Deny mal calibrat pot deixar l'organització sense poder desplegar. Consell: l'ordre de l'advertiment —un compte, una OU, l'arrel—, sempre amb revisió dels AccessDenied a CloudTrail entre passos.

Error: denegar per regió sense NotAction. Trenca IAM, Route 53, CloudFront i la consola de facturació, perquè els serveis globals es resolen contra us-east-1. Consell: la llista d'exclusions de la primera SCP d'aquesta lliçó.

Error: correus personals com a arrel dels comptes. El dia que aquesta persona marxa, el compte queda orfe. Consell: llistes de distribució amb almenys dos destinataris, i contactes alternatius emplenats.

Error: convidar un compte sense crear abans OrganizationAccountAccessRole. Als comptes convidats no existeix, i sense ell el compte de gestió no hi pot entrar. Consell: crear-lo abans de convidar.

Error: creure que una SCP concedeix permisos. Un Allow en una SCP no dona accés a ningú: només aixeca el sostre. Consell: interioritzar que el permís efectiu és la intersecció d'SCP i IAM.

Consell: guarda les SCP i l'estructura d'OU a mercadofresco-infra. Tot el d'aquest mòdul s'aplica també aquí: les polítiques són codi, es revisen en PR i es despleguen des del pipeline.

Consell: activa l'administrador delegat dels serveis de seguretat. Manté el compte de gestió buit i dona a seguretat el seu propi àmbit.

Consell: fes servir aws:PrincipalOrgID a les polítiques de recurs compartides. Evita llistes de comptes que cal mantenir i s'ajusta sola quan entra un compte nou.

Consell: crea l'OU d'aïllament abans de necessitar-la. Buida i amb el seu Deny posat, és un moviment de trenta segons el dia d'un incident; improvisar-la aquell dia no ho és.

Consell: posa un pressupost per compte el primer dia. Amb la separació per compte, AWS Budgets (11-04) es torna precís: una alerta per compte detecta abans una fuita que un pressupost global.

La Marta aplica a l'OU Cargas una SCP que denega totes les accions d'iam:* tret de lectura, amb l'argument que només el CDK ha de crear rols. L'endemà, el pipeline falla a tots els entorns amb AccessDenied en desplegar la pila d'aplicació, i a més una funció Lambda nova no aconsegueix arrencar. Explica (a) per què falla exactament el pipeline; (b) per què falla la Lambda, que és una fallada diferent; (c) com es diagnostica amb les eines del mòdul 5; (d) com es corregeix la política mantenint la intenció original; i (e) quin pas del procediment correcte es va saltar la Marta.

MercadoFresco contracta l'Elena, desenvolupadora, que s'incorpora a l'equip del Luis. Ha de poder desenvolupar amb llibertat, veure què passa a producció quan hi ha un incident, llançar desplegaments a preproducció però no a producció, i no ha de poder llegir dades personals de clients. Dissenya els seus accessos: quins grups, quins conjunts de permisos, en quins comptes, amb quina durada de sessió i quin mecanisme faries servir per al tema de les dades personals. Indica també què no li donaries encara que ho demanés, i com gestionaries el dia que necessiti accés d'emergència a producció.

Un company proposa accelerar el pla: crear els cinc comptes el dilluns, moure producció a un compte nou i net el dimarts a la nit —«així tot queda ordenat des del principi»—, i aplicar totes les SCP el dimecres. Argumenta que fer-ho de cop evita mesos d'estat intermedi. Respon: (a) tres riscos concrets de moure producció a un compte nou; (b) què li passa a Aurora, als buckets i a la zona de Route 53 en aquest moviment; (c) per què aplicar totes les SCP el dimecres encara és pitjor idea; (d) quina part de la seva proposta sí que és raonable; i (e) com l'hi explicaries en una frase.

Solució 1

(a) El pipeline falla perquè CloudFormation necessita iam:CreateRole i iam:PassRole. La pila d'aplicació crea el perfil d'instància de l'ASG i el rol d'execució de les Lambdes; tots dos requereixen crear rols i passar-los al servei que els farà servir. iam:PassRole és especialment fàcil d'oblidar perquè no crea res: autoritza a lliurar un rol existent a un servei, i sense ell el desplegament falla encara que el rol ja existeixi.

(b) La Lambda falla per un motiu diferent i més subtil: els rols vinculats a serveis. Quan una Lambda s'associa a una VPC, AWS crea AWSServiceRoleForLambdaReplicator o similars mitjançant iam:CreateServiceLinkedRole. Encara que les SCP no s'apliquen als principals de servei, sí que s'apliquen a la crida que fa el teu rol en demanar la creació d'aquest rol vinculat. És la categoria de fallada que fa que les SCP siguin perilloses: trenquen coses que ningú no relaciona amb IAM.

(c) El diagnòstic. CloudTrail (05-03) és l'eina: els esdeveniments denegats apareixen amb errorCode: AccessDenied i, quan la causa és una SCP, amb un missatge que esmenta explícitament una política de control de serveis. Una consulta a Athena sobre el trail de l'organització filtrant per errorCode a les últimes 24 hores retorna la llista completa d'accions bloquejades, que és exactament la informació que calia per calibrar la política. És també el mecanisme del pas 3 del procediment correcte.

(d) La correcció. La intenció —que ningú no creï rols a mà— és bona; la implementació és massa gruixuda. Es manté el Deny sobre les accions d'escriptura d'IAM però se n'excepten els principals legítims i les accions necessàries:

Amb això, només els rols de desplegament del CDK i del pipeline poden crear rols, i PassRole i CreateServiceLinkedRole queden fora del bloqueig. Una alternativa complementària és exigir un límit de permisos (iam:PermissionsBoundary) en tot rol creat, que acota el que aquests rols podran fer encara que algú els creï.

(e) El pas que es va saltar. El segon i el tercer: no va provar la política en un sol compte de desenvolupament executant-hi el pipeline complet, ni la va deixar reposar a l'OU Desarrollo revisant els AccessDenied. Aplicar-la directament a Cargas significa aplicar-la a producció, i la mateixa lliçó ho adverteix. El detall agreujant és que una fallada així apareix en el desplegament següent, que pot ser hores després i sense relació aparent amb el canvi.

Solució 2

Grups i conjunts de permisos. L'Elena entra al grup desarrolladores del directori d'Identity Center, que ja té assignacions; no se li crea res específic, perquè els permisos individuals són deute de govern.

El conjunt nou, LecturaOperacion, és la part interessant: ReadOnlyAccess és massa ampli perquè inclou llegir objectes d'S3 i consultar DynamoDB, és a dir, dades de clients. El correcte és un conjunt a mida amb CloudWatch, X-Ray, la consola d'ECS/EC2 i els estats de CloudFormation, i Deny explícit sobre s3:GetObject als buckets amb dades personals, dynamodb:GetItem, dynamodb:Query i rds-data:*.

El mecanisme per a les dades personals té dues capes, i cap de les dues no basta tota sola. La primera és la política del conjunt de permisos, amb els Deny anteriors. La segona és una SCP a l'OU Produccion que denegui l'accés als buckets i taules amb dades de clients tret d'una llista curta de rols d'aplicació; així, encara que algú ampliï el conjunt de permisos per error, la barrera continua dempeus. És la diferència entre una política que es pot canviar al compte i un sostre que no.

El que no li donaria encara que ho demani: administració a producció; permís per crear usuaris o claus d'accés d'IAM —des d'Identity Center no calen i són la principal font de credencials filtrades—; i accés permanent d'escriptura a preproducció per fora del pipeline, perquè tornaria a obrir el camí de «desplegar a mà» que el mòdul 8 va tancar.

L'accés d'emergència es resol amb RespuestaIncidentes: assignable a l'Elena, amb sessió d'una hora, aprovació de la Marta i notificació automàtica a alertas-mercadofresco en fer-lo servir. La regla que ho fa funcionar és que fer-lo servir no és un problema; fer-lo servir sense incident sí que ho és, i la notificació existeix perquè la revisió sigui possible.

Solució 3

(a) Tres riscos de moure producció a un compte nou. Primer, les dades: Aurora, DynamoDB i els buckets s'han de replicar o restaurar al compte destinació, cosa que implica una finestra de tall o una replicació amb doble escriptura, més una verificació d'integritat de la qual ningú no ha parlat. Segon, les identitats i referències: els ARN canvien de compte, així que rols, polítiques de bucket, claus de KMS, punts d'enllaç i tot el que els esmenti s'ha de revisar; una política de KMS que referencia el compte vell deixa de funcionar i produeix fallades de desxifratge difícils de diagnosticar. I tercer, allò que no és al codi: certificats d'ACM, la zona de Route 53, els ajustos de CloudFront, WAF i les quotes ampliades per suport, que no es migren automàticament i se solen descobrir a mitja finestra.

(b) Què li passa a cada cosa. Aurora no es mou: es comparteix una instantània amb el compte destinació —cosa que exigeix compartir també la clau de KMS— i es restaura, amb la qual cosa s'obté un clúster nou amb punt d'enllaç diferent, i tot el que s'hi connecti ha de canviar. Els buckets no es mouen: els noms són globals, així que cal crear buckets nous amb un altre nom i copiar-hi els objectes, revisant a més les polítiques i les URL públiques de les fotos de producte que puguin estar a la memòria cau de CloudFront. La zona de Route 53 sí que es pot moure mantenint els mateixos servidors de noms, que és l'única bona notícia de l'apartat, però exigeix coordinar el canvi amb els registres que apunten a recursos els ARN dels quals estan canviant alhora.

(c) Per què aplicar totes les SCP el dimecres encara és pitjor. Perquè acumula tres errors alhora: aplicar-les sense provar, aplicar-les totes juntes i aplicar-les just després d'una migració. Si alguna cosa falla el dijous —i alguna cosa fallarà—, serà impossible saber si la causa és una SCP, la migració o els ARN que van canviar. El diagnòstic depèn de poder aïllar la variable, i aquesta proposta les barreja totes. És el mateix principi de 08-05 amb els desplegaments petits: l'abast d'un canvi ha de permetre atribuir la fallada.

(d) El que sí que és raonable. Crear els cinc comptes el dilluns és correcte i no té risc: crear comptes no mou res. També ho és la intenció de fons —no deixar un estat intermedi etern—, que és un problema real: les migracions a mitges tendeixen a durar anys. La resposta a això no és accelerar, és posar data límit a cada fase i tractar el pla com un projecte amb fites, no com una intenció.

(e) La frase. «Reutilitzar el compte actual com a producció ens estalvia l'única part veritablement perillosa d'aquesta migració —moure les dades— i no ens costa res, perquè un compte no té memòria del que va ser: el que importa és l'OU on el posem i les polítiques que li apliquem.»

El cinquè problema queda resolt. MercadoFresco pot recrear el seu entorn complet des de zero amb una ordre, i ja no ho fa tot al mateix compte.

Aquesta lliçó ha convertit el compte únic en una organització de sis comptes amb quatre unitats organitzatives. Seguridad guarda allò que ha de sobreviure a un incident als comptes de càrrega; Infraestructura allotja el pipeline i els artefactes, i resol la paradoxa que allò que desplega producció visqués a producció; Cargas agrupa els tres entorns amb una OU cadascun, perquè producció tolera menys que desenvolupament; i Aislamiento és buida a propòsit, per congelar un compte compromès en un sol moviment sense destruir l'evidència. Amb la decisió pragmàtica que sosté tot el pla: el compte 111122223333 es converteix en producció, perquè migrar dades és l'única part veritablement perillosa i es pot evitar sencera.

Tens les polítiques de control de serveis amb la frase que cal memoritzar —mai no concedeixen permisos, només els limiten— i amb allò que això permet per primera vegada: limitar qui ja ho pot tot, de manera que ni un administrador de producció pugui apagar trail-mercadofresco ni desactivar Config. Quatre polítiques reals: regions acotades amb NotAction per no trencar els serveis globals, auditoria protegida, xifratge obligatori a S3 amb excepció per principal, i tipus d'instància i compres de compromís bloquejats en desenvolupament. Més l'advertiment que evita convertir una tarda de millores en un incident: un compte, després una OU, després l'arrel, revisant els AccessDenied a CloudTrail entre esglaons, amb el compte de gestió com a salvavides perquè les SCP no se li apliquen —i per això mateix, al compte de gestió no s'hi treballa—.

Tens la facturació consolidada, que respon «quant costa preproducció?» sense dependre que les etiquetes estiguin ben posades, conserva els descomptes per volum agregats i reparteix Savings Plans i instàncies reservades entre comptes (11-05). L'accés correcte amb IAM Identity Center: zero usuaris d'IAM, credencials temporals, i conjunts de permisos que reflecteixen responsabilitats reals —el Luis amb lectura i permís per llançar el pipeline a producció, que és el punt en què el pipeline deixa de ser una comoditat i es converteix en un control de seguretat; la Sara només amb dades i només a producció; i un accés d'emergència deliberadament incòmode, amb aprovació i notificació—. I els rols entre comptes amb sts:AssumeRole, amb la política de confiança i la de permisos com a dues coses diferents i totes dues restrictives.

Els serveis d'organització tanquen el cercle: CloudTrail d'organització i agregador de Config al compte de seguretat, Security Hub, GuardDuty, Access Analyzer i, sobretot, el StackSet ss-mercadofresco-linea-base de 09-01 amb desplegament automàtic, que respon a «com garantim que el compte que creem d'aquí a sis mesos tingui tot el que ha de tenir»: no ho garanteix una persona, ho garanteix una OU. El pla de migració va en sis fases amb una regla que les ordena —primer allò que es recrea, després allò que es mou, les dades al final i amb permís—, amb desenvolupament i preproducció desplegats des del CDK en lloc de migrats, que és on es cobra la feina de les dues lliçons anteriors. I amb un requisit blocant que no és tècnic: copiar dades de clients entre comptes és tractament de dades personals sota el RGPD, i ho revisa compliment abans que ningú executi res.

Amb això, els cinc problemes del curs estan resolts. Les caigudes dels divendres, amb autoescalat, memòria cau i cues. Les còpies poc fiables, amb instantànies, replicació i retenció. El creixement a més ciutats, amb una arquitectura desacoblada. Els desplegaments arriscats, amb un pipeline que reverteix sol en quatre minuts. I ara la infraestructura no governada, amb plantilles, constructes, proves, comptes separats i barreres que s'apliquen soles.

Queda una cosa que cap de les quatre lliçons no ha tocat, i que es veu així que mires les instàncies. La botiga continua executant-se sobre EC2 que cal apedaçar, amb AMI que cal reconstruir cada vegada que canvia una dependència, i amb una arrencada de dos minuts que és exactament el temps que sobra el divendres a les 19:00: quan l'ASG detecta el pic i llança una instància, els clients ja han esperat. El CDK descriu aquestes instàncies molt bé; Beanstalk les gestionava molt bé; però cap dels dos no fa que deixin d'existir.

Al mòdul 10, «Contenidors a AWS», ataquem precisament això. 10-01, «ECS i ECR», introdueix l'orquestració de contenidors i el registre d'imatges que substitueix les AMI. 10-02, «Fargate», elimina les instàncies del tot: sense servidors que apedaçar i amb arrencades de segons en lloc de minuts. I 10-03, «EKS», mostra l'alternativa amb Kubernetes i quan compensa la seva complexitat. La botiga de MercadoFresco deixarà de viure en màquines.