La lliçó anterior va acabar amb una decisió pendent. EFS resolia el problema que les quatre instàncies del divendres compartissin /var/www/fotos, però al preu equivocat: unes tretze vegades més car que l'alternativa, amb tot el trànsit d'imatges passant per les instàncies i sense aprofitar l'escala global d'AWS. Aquesta alternativa és Amazon S3 (Simple Storage Service), i en aquesta lliçó MercadoFresco pren la decisió definitiva sobre les seves fotos de producte.

S3 és probablement el servei més important d'AWS. Va ser el primer que es va llançar, el 2006, i avui és el lloc on acaben les dades de gairebé qualsevol arquitectura: fitxers estàtics, còpies de seguretat, registres, llacs de dades, artefactes de desplegament. Entendre'l bé —no només «és on es pugen fitxers»— canvia la manera de dissenyar sistemes, perquè S3 no és un disc: és un magatzem d'objectes amb una API, i aquesta diferència té conseqüències en tot.

1. Emmagatzematge d'objectes: bucket, objecte, clau i prefix
2. Per què S3 no és un sistema de fitxers
3. Noms de bucket, regions i espai de noms global
4. Durabilitat i disponibilitat: els onze nous
5. Classes d'emmagatzematge i com triar
6. Regles de cicle de vida per a les fotos antigues del catàleg
7. Versionatge i protecció davant d'esborraments accidentals
8. Migrar /var/www/fotos amb aws s3 sync
9. aws s3 davant d'aws s3api
10. Permisos: Block Public Access, polítiques de bucket i ACL
11. URL signades prèviament: els informes de la Sara sense credencials
12. Xifratge en repòs i en trànsit
13. Allotjament d'un lloc estàtic
14. Esdeveniments d'S3: el disparador de les miniatures
15. Multipart upload i Transfer Acceleration
16. Costos d'S3 i com no endur-se sorpreses

El model d'S3 té només tres peces, i convé anomenar-les amb precisió perquè tota la documentació les fa servir així.

Un objecte pot pesar des de 0 bytes fins a 5 TiB. Un bucket pot contenir un nombre il·limitat d'objectes i créixer sense que ningú provisioni res.

Aquesta és la idea que cal interioritzar, perquè d'ella se'n deriven gairebé totes les sorpreses dels principiants.

A S3 no existeixen les carpetes. La consola les dibuixa, aws s3 ls les llista, però no hi són. L'única cosa que existeix és una llista plana de claus, i la barra / és un caràcter més dins del nom.

Les conseqüències pràctiques d'això són concretes:

I una conseqüència positiva enorme: com que no hi ha estructura jeràrquica real, no hi ha límit d'escala. Un bucket amb mil milions d'objectes funciona igual de bé que un amb deu, i S3 admet com a mínim 3.500 escriptures i 5.500 lectures per segon i per prefix, amb paral·lelització pràcticament il·limitada fent servir diversos prefixos.

Per això el disseny de claus importa. Per a MercadoFresco:

El nom d'un bucket és únic a tot AWS, a tots els comptes i totes les regions del món. Si algú a Austràlia té fotos, tu no el pots tenir. És l'únic recurs d'AWS amb espai de noms veritablement global.

Regles del nom:

• Entre 3 i 63 caràcters.
• Només minúscules, xifres, guions i punts.
• Ha de començar i acabar amb lletra o xifra.
• No pot semblar-se a una adreça IP.
• Evita els punts: trenquen la validació del certificat TLS amb noms d'estil virtual i causen errors difícils de diagnosticar.

Convenció de MercadoFresco, que aplicarem sempre:

Encara que el nom sigui global, les dades resideixen en una regió concreta i no en surten mai llevat que ho demanis explícitament. Per a MercadoFresco això no és un detall: les fotos i els informes es queden a eu-west-1, dins de la UE, cosa que sosté l'argument de l'RGPD que vam veure a 01-03.

El parany de LocationConstraint. A us-east-1 (i només allà) no s'ha de passar aquest paràmetre: la comanda falla si l'hi inclous. A qualsevol altra regió és obligatori. És una herència històrica del fet que S3 va néixer a Virgínia.

S3 Standard promet 99,999999999 % de durabilitat anual: els famosos onze nous. La xifra sona a màrqueting, però té un significat operatiu precís.

Si hi deses 10 milions d'objectes, l'expectativa estadística és perdre'n un cada 10.000 anys. Dit d'una altra manera: és moltíssim més probable que perdis les dades per un esborrament accidental o una política mal escrita que per una fallada d'S3.

Com s'aconsegueix: cada objecte es replica automàticament en almenys tres zones de disponibilitat de la regió, amb verificació contínua d'integritat i reparació automàtica. Tu no configures res.

No s'han de confondre dues mètriques diferents:

Un matís que importa molt per a MercadoFresco: la durabilitat d'S3 no et protegeix de tu mateix. Si el Luis executa un aws s3 rm --recursive sobre el bucket equivocat, S3 l'esborrarà amb onze nous de fiabilitat. La protecció contra això és el versionatge, que veurem més avall.

No totes les dades s'hi accedeix igual. Les fotos dels tomàquets de temporada es demanen mil vegades al dia el juny i cap el gener. S3 ofereix classes amb un equilibri diferent entre cost d'emmagatzematge i cost/latència d'accés.

Entre Standard i Deep Archive hi ha un factor de 23 vegades en el cost d'emmagatzematge. Aquest és el premi per classificar bé les dades.

Tres criteris de decisió:

1. Si no saps el patró d'accés, fes servir Intelligent-Tiering. Mou els objectes entre nivells automàticament, sense cost de recuperació, cobrant una petita quota de monitoratge per objecte. És l'opció segura per defecte per a dades heterogènies.
2. Compte amb el mínim de permanència. Si puges un objecte a Standard-IA i l'esborres al cap de 10 dies, te'n cobren 30. Per a dades de vida curta, aquesta classe surt més cara que Standard.
3. One Zone-IA només per a dades reproduïbles. Viu en una sola AZ: si aquesta AZ es perd, la dada es perd. És perfecte per a les miniatures de MercadoFresco, perquè sempre es poden regenerar a partir de l'original.

Una regla de cicle de vida aplica transicions i caducitats automàticament segons l'edat dels objectes. És la manera que l'estalvi anterior passi sense que ningú hi intervingui.

L'anàlisi de MercadoFresco: les fotos de producte es consulten intensament els primers mesos després de publicar-se, després l'interès cau, i les de productes descatalogats només es necessiten per motius comptables. Traduït a política, a ciclo-vida-fotos.json:

Comentari regla per regla:

• fotos-productos-enfriamiento: escala de tres salts. Als 3 mesos baixa a IA, a l'any a Glacier Instant (que continua retornant en mil·lisegons), als 3 anys a Deep Archive.
• miniaturas-una-sola-az: aprofita que són regenerables. Estalvi sense risc real.
• informes-analitica-caducan-a-2-anos: a més de moure, esborra. Els informes de la Sara no tenen valor passats dos anys i esborrar és l'estalvi definitiu.
• limpiar-cargas-multiparte-incompletas: la més oblidada i la que més diners silenciosos estalvia. Una pujada gran interrompuda deixa fragments que es facturen i no apareixen en llistar el bucket. Aquesta regla hauria de ser en absolutament tots els teus buckets.
• versiones-antiguas-caducan-a-90-dias: sense això, el versionatge fa créixer el bucket per sempre.

Estimació de l'estalvi per a 40.000 fotos de 500 KB (uns 20 GB) amb una distribució d'edats típica:

Amb 20 GB la diferència és xavalla. Amb els 20 TB que MercadoFresco tindrà després d'obrir a tres ciutats més (problema 3), són més de 250 USD al mes de diferència. Les regles es posen ara, quan costen un minut, no quan fan mal.

Amb el versionatge activat, S3 no sobreescriu ni esborra mai de debò:

• En pujar un objecte amb una clau existent, es crea una versió nova i l'anterior es conserva.
• En esborrar, s'hi col·loca un marcador d'esborrament (delete marker): l'objecte desapareix dels llistats però totes les seves versions hi continuen sent.
• Per recuperar-lo n'hi ha prou d'esborrar el marcador d'esborrament.

Recuperació d'un esborrament accidental, l'escenari real:

Un cop activat, el versionatge no es pot desactivar, només suspendre (les versions ja creades es conserven). I compte amb el cost: cada versió es factura per separat, d'aquí la regla de cicle de vida NoncurrentVersionExpiration de l'apartat anterior.

Dues proteccions addicionals, esmentades breument perquè són de casos concrets:

• MFA Delete: exigeix un codi d'autenticació multifactor de l'usuari root per esborrar versions o canviar l'estat del versionatge. Molt fort, però només s'activa amb les credencials de root i no es pot gestionar des de la consola, cosa que el fa incòmode per al dia a dia.
• Object Lock (WORM: write once, read many): impedeix esborrar o modificar un objecte durant un període fixat, fins i tot a l'administrador del compte. Té dos modes, Governance (un rol amb permís especial se'l pot saltar) i Compliance (ningú no pot, ni el root). És per a retenció legal. Només es pot activar en crear el bucket. Per a les còpies de la base de dades de MercadoFresco tindria sentit; per a les fotos, no.

Arriba el moment. Les 40.000 fotos del servidor de l'oficina se'n van a S3.

Què fa cada opció:

• sync és incremental: compara mida i data de modificació, i només puja el que ha canviat. Es pot interrompre i rellançar sense duplicar feina, que és justament el que cal per migrar 40.000 fitxers per una connexió d'oficina.
• --dryrun: imprescindible abans de qualsevol sync amb destinació nova.
• --exclude "*" seguit de diversos --include: l'ordre importa. Primer s'exclou tot i després es readmeten les extensions desitjades. Així no s'hi colen .DS_Store, Thumbs.db ni còpies .bak.
• --cache-control: es desa com a metadada i el respectaran els navegadors i, més endavant, CloudFront (03-04). Un dia de memòria cau per a fotos que gairebé no canvien mai.

Verificació després de la migració:

Per a volums molt grans hi ha opcions específiques que convé conèixer encara que no les fem servir: AWS DataSync per a transferències massives i recurrents per xarxa, i la família AWS Snowball per quan moure les dades per internet trigaria més que enviar-les físicament en un dispositiu. Per als 20 GB de MercadoFresco, sync fa de sobres.

La CLI ofereix dues interfícies diferents per a S3, i confondre-les provoca molta frustració.

Regla pràctica: mou dades amb aws s3, configura amb aws s3api.

Les filtracions de dades per buckets S3 mal configurats han estat titular de premsa moltes vegades. AWS hi va respondre canviant els valors per defecte: avui tot bucket nou neix completament privat i amb Block Public Access activat a escala de compte i de bucket.

Els quatre interruptors, que molta gent activa o desactiva sense saber què fa cadascun:

La postura de MercadoFresco és deixar Block Public Access activat a tots els buckets, sense excepció. Les fotos es serviran públicament a través de CloudFront amb un control d'accés d'origen, no obrint el bucket. Això es munta a la lliçó 03-04.

Una política de bucket és un document JSON d'IAM adjunt al bucket que diu qui pot fer què. Exemple real de MercadoFresco: permetre que només el rol de les instàncies de la botiga llegeixi les fotos, i obligar que tot el trànsit faci servir HTTPS.

Dos detalls fonamentals:

• s3:ListBucket es concedeix sobre el bucket (arn:aws:s3:::bucket), mentre que s3:GetObject es concedeix sobre els objectes (arn:aws:s3:::bucket/*). Són ARN diferents i confondre'ls és l'error de política més freqüent.
• Un Deny explícit guanya sempre sobre qualsevol Allow, vingui d'on vingui. Per això la segona instrucció és una defensa sòlida: ningú, ni l'administrador, no pot accedir per HTTP sense xifrar. La lògica completa d'avaluació de permisos és la lliçó 04-01.

Les ACL (Access Control Lists) són el mecanisme original del 2006, anterior a IAM. Concedeixen permisos objecte a objecte a comptes o grups predefinits.

AWS recomana no fer-les servir. Des del 2023, els buckets nous neixen amb Object Ownership a «Bucket owner enforced», que les desactiva per complet. Només les has de conèixer per a dues coses: reconèixer-les en heretar un compte antic, i saber que si un tutorial et diu --acl public-read, aquest tutorial està desactualitzat. Fes servir polítiques de bucket.

La Sara, l'analista de negoci, necessita descarregar l'informe mensual de vendes. No té usuari d'AWS, no n'ha de tenir, i el bucket és privat. La solució és una URL signada prèviament: un enllaç temporal que incorpora una signatura criptogràfica i caduca.

L'essencial d'aquest mecanisme:

• Qui tingui l'enllaç el pot fer servir. No hi ha autenticació addicional: l'enllaç és la credencial. Per això els terminis han de ser curts.
• L'URL hereta els permisos de qui la signa. Si el perfil que signa no pot llegir l'objecte, l'URL tampoc no funcionarà.
• Caducitat màxima: 7 dies amb credencials d'usuari IAM; 1 hora si se signa des d'un rol amb credencials temporals, com seria el cas dins d'una Lambda.
• generate_presigned_post amb Conditions és la manera correcta d'acceptar pujades de tercers: limita tipus i mida abans que el fitxer arribi.

Tot objecte nou a S3 es xifra en repòs automàticament des del gener del 2023. No cal fer res per tenir xifratge; la decisió és només qui gestiona la clau.

Decisió de MercadoFresco: SSE-S3 per a les fotos (són dades públiques a la pràctica, no compensa el cost per petició de KMS) i SSE-KMS per als informes de vendes i les còpies de la base de dades, que contenen dades de negoci i on interessa el registre de qui desxifra.

BucketKeyEnabled: true redueix fins a un 99 % les crides a KMS i el seu cost associat; activa'l sempre que facis servir SSE-KMS. La gestió de claus es veu a fons a la lliçó 04-02.

En trànsit, tot el trànsit amb S3 va per HTTPS. Per garantir que ningú faci servir HTTP en clar hi ha la instrucció DenegarTodoLoQueNoSeaHTTPS de la política de bucket anterior.

S3 pot servir un lloc web estàtic directament: HTML, CSS, JavaScript i imatges, sense cap servidor.

El resultat és una URL del tipus http://mercadofresco-tienda-web-desarrollo.s3-website-eu-west-1.amazonaws.com.

Limitacions que cal conèixer abans d'emocionar-se:

• Només HTTP, sense HTTPS. El punt d'enllaç de lloc web estàtic no admet TLS.
• Sense domini propi amb certificat.
• Exigeix el bucket públic, cosa que xoca amb la política de Block Public Access.

Per això, en producció no es fa servir així. L'arquitectura correcta és bucket privat + CloudFront al davant amb Origin Access Control: dona HTTPS, domini propi, memòria cau en més de 400 ubicacions de vora i protecció. Això és exactament la lliçó 03-04. El mode lloc web d'S3 queda per a proves ràpides del Luis.

S3 pot notificar quan passa alguna cosa en un bucket. És la porta d'entrada a les arquitectures orientades a esdeveniments, i per a MercadoFresco resol un problema concret: les fotos originals pesen massa per al llistat de productes i calen miniatures.

Esdeveniments disponibles i destinacions possibles:

El flux que muntarem:

Configuració de la notificació (la funció s'escriu a 02-05):

El filtre per prefix i sufix és imprescindible. Sense ell, la Lambda es dispararia també en escriure les miniatures al mateix bucket, que al seu torn generarien un altre esdeveniment: un bucle recursiu infinit que és una de les maneres més ràpides i més cares d'equivocar-se a AWS.

Dos advertiments sobre la semàntica d'aquests esdeveniments: el lliurament és almenys una vegada (la funció pot rebre el mateix esdeveniment dues vegades, així que ha de ser idempotent) i no està garantit l'ordre. Aquí només deixem muntat el disparador; el codi l'escrivim a la lliçó 02-05.

Multipart upload trosseja un objecte gran i puja les parts en paral·lel. És obligatori per sobre de 5 GB i recomanable a partir de 100 MB.

Avantatges: més rendiment per paral·lelisme, reintent d'una sola part si falla la xarxa, i possibilitat de pausar i reprendre. aws s3 cp i aws s3 sync ho fan automàticament; només necessites s3api si programes el procés a mà.

El risc: si una pujada multipart s'interromp, les parts ja pujades es queden i es facturen, i no apareixen en un aws s3 ls normal. Per això incloem la regla AbortIncompleteMultipartUpload al cicle de vida. Per veure-les:

Transfer Acceleration encamina les pujades a través de la ubicació de vora de CloudFront més propera al client, i d'allà per la xarxa troncal d'AWS fins al bucket. Accelera de manera significativa quan qui puja és lluny de la regió. Té cost addicional (≈0,04 USD/GB) i per a MercadoFresco, que puja des d'Espanya a Irlanda, no compensa. Seria útil si un proveïdor de Sud-amèrica pugés catàlegs de fotos.

La factura d'S3 té quatre components, i gairebé tothom només mira el primer.

Càlcul realista per a MercadoFresco: 20 GB de fotos, 500.000 visites al mes amb 10 fotos vistes per visita (5.000.000 de peticions GET), foto mitjana de 200 KB:

El 97 % del cost és transferència de sortida. I aquesta dada justifica per si sola la lliçó 03-04: posant CloudFront al davant, la majoria de les peticions se serveixen des de la memòria cau de vora, la transferència d'S3 a CloudFront és gratuïta, i el preu per GB cap a internet és menor. La factura pot baixar a menys d'una tercera part, i a més el web anirà més ràpid.

Eines de control:

• S3 Storage Lens ofereix un tauler gratuït amb mètriques d'ús i recomanacions d'estalvi.
• S3 Inventory genera un informe periòdic en CSV o Parquet amb tots els objectes, la seva classe i la seva mida: la manera correcta d'auditar buckets amb milions d'objectes sense llistar-los un a un.
• El pressupost presupuesto-mensual-mercadofresco de la lliçó 01-02 continua sent la xarxa de seguretat.

Neteja de la lliçó. Si has creat buckets de prova, elimina'ls. Un bucket amb versionatge requereix esborrar també les versions i els marcadors:

aws s3 rm s3://mi-bucket-de-pruebas --recursive --profile mercadofresco-dev
aws s3api delete-objects --bucket mi-bucket-de-pruebas \\
  --delete "$(aws s3api list-object-versions --bucket mi-bucket-de-pruebas \\
    --query '{Objects: Versions[].{Key:Key,VersionId:VersionId}}' --output json)" \\
  --profile mercadofresco-dev
aws s3 rb s3://mi-bucket-de-pruebas --profile mercadofresco-dev

• Tractar S3 com un disc. Canviar el nom d'un prefix amb 40.000 objectes són 80.000 operacions i minuts d'espera. Dissenya bé les claus des del principi.
• Fer un bucket públic «perquè funcioni ràpid». És l'origen de la majoria de les filtracions publicades. Deixa Block Public Access activat i fes servir CloudFront amb OAC.
• Oblidar LocationConstraint fora d'us-east-1, o posar-lo dins d'us-east-1. Tots dos fallen, amb missatges poc clars.
• No configurar AbortIncompleteMultipartUpload. Cost invisible que creix per sempre.
• Activar el versionatge i no caducar les versions antigues. El bucket s'infla sense límit i ningú no entén per què la factura puja si «no es puja res de nou».
• Confondre l'ARN del bucket amb el dels objectes a les polítiques: ListBucket va sobre el bucket, GetObject sobre bucket/*.
• Posar una Lambda a escoltar esdeveniments del mateix bucket on escriu. Bucle infinit. Filtra sempre per prefix, o fes servir buckets diferents.
• Fer servir --acl public-read perquè ho diu un tutorial antic. Les ACL estan desactivades per defecte als buckets nous i AWS en desaconsella l'ús.
• Pujar a Standard-IA dades de vida curta. El mínim de 30 dies de facturació fa que surti més car que Standard.
• Mirar només el cost d'emmagatzematge. La transferència de sortida sol ser el 90 % de la factura d'S3.
• Consell: executa sync amb --dryrun sempre la primera vegada. Una destinació mal escrita pot copiar 40.000 fitxers al prefix equivocat, i desfer-ho és més feina que fer-ho.

MercadoFresco desarà a mercadofresco-copias-basedatos els abocaments diaris de la base de dades de comandes, sota el prefix copias/base-datos/. Cada abocament ocupa 2 GB. Els requisits són:

• Els últims 30 dies han de poder restaurar-se en minuts.
• Entre 30 dies i 1 any, la restauració pot trigar hores.
• Entre 1 i 7 anys (retenció legal fiscal) es conserven al cost mínim possible.
• Passats 7 anys s'esborren automàticament.

Escriu la regla de cicle de vida en JSON i calcula el cost mensual en règim estacionari, comparant-lo amb deixar-ho tot a Standard. Fes servir: Standard 0,023; Glacier Flexible 0,0036; Deep Archive 0,00099 USD/GB-mes.

La Sara ha de poder llegir els informes sota informes/, però no esborrar-los ni tocar altres prefixos. El rol rol-mercadofresco-analitica ha de poder escriure a informes/. Ningú no ha d'accedir sense HTTPS ni pujar objectes sense xifrar amb KMS.

Escriu la política de bucket completa i explica per què l'última condició necessita un Deny i no un Allow.

Per a cada dada de MercadoFresco, indica bucket, prefix, classe d'emmagatzematge inicial, si actives versionatge i quina regla de cicle de vida aplicaries:

• A) Les 40.000 fotos originals del catàleg, en alta resolució.
• B) Les miniatures 200×200 generades automàticament a partir de les anteriors.
• C) Els registres d'accés del servidor web, uns 3 GB al dia, consultats només si hi ha una incidència i obligatoris durant 90 dies.
• D) L'informe mensual de vendes que la Sara descarrega per URL signada prèviament.

Solució 1.

Volum en règim estacionari (2 GB/dia):

Notes de disseny: 2.555 dies són 7 anys. Deep Archive té 180 dies de permanència mínima, sense problema aquí perquè els objectes hi arriben amb 365 dies de vida i s'hi queden més de sis anys. I el requisit «restaurar en minuts els últims 30 dies» és el que impedeix baixar a Glacier abans: Glacier Flexible triga de minuts a 12 hores segons el mode de recuperació.

Solució 2.

Per què les dues últimes necessiten Deny i no Allow. Un Allow només concedeix: si simplement «permetessis HTTPS», qualsevol altra política —una política d'identitat d'IAM adjunta a l'usuari, per exemple— podria continuar concedint l'accés per HTTP, perquè els permisos se sumen. Un Deny explícit, en canvi, té precedència absoluta: cap política de cap capa no el pot anul·lar. Per a requisits de seguretat que s'han de complir sempre i sense excepció, la formulació correcta és prohibir la condició no desitjada, no permetre la desitjada.

Detall addicional: sense la condició s3:prefix a ListBucket, la Sara podria llistar tot el bucket i veure els noms d'objectes d'altres prefixos, encara que no els pogués descarregar. Noms que de vegades revelen més del que sembla.

Solució 3.

Observació transversal: el prefix de les miniatures ha d'estar fora del prefix que dispara l'esdeveniment (productos/), o el filtre de la notificació les ha d'excloure. És la protecció contra el bucle recursiu esmentat abans.

MercadoFresco ja té les seves fotos on han de ser. Has entès que S3 és un magatzem d'objectes i no un sistema de fitxers: no hi ha carpetes, només claus planes on la barra és un caràcter més; els objectes són immutables; canviar el nom d'un prefix significa copiar i esborrar. A canvi d'aquestes restriccions s'obté escala pràcticament il·limitada, onze nous de durabilitat per replicació automàtica en tres o més zones de disponibilitat, i un cost per GB unes tretze vegades menor que EFS.

Saps construir noms de bucket vàlids en un espai de noms global, amb el parany de LocationConstraint inclòs, i tens una convenció pròpia (mercadofresco-<component>- <propòsit>). Domines les set classes d'emmagatzematge i les seves compensacions —latència, cost de recuperació, permanència mínima, nombre d'AZ— i has escrit regles de cicle de vida que refreden les fotos del catàleg automàticament, mouen les miniatures a One Zone-IA per ser regenerables, caduquen els informes als dos anys, esborren les versions antigues i —la regla que tothom oblida— avorten les càrregues multipart incompletes que es facturen en silenci.

Has activat el versionatge i has practicat la recuperació real d'un esborrament accidental eliminant el marcador d'esborrament, i coneixes MFA Delete i Object Lock per als casos que exigeixen retenció inviolable. Has migrat /var/www/fotos amb aws s3 sync, amb el seu --dryrun obligatori i els seus filtres d'inclusió, i tens clara la divisió de feina entre aws s3 per moure dades i aws s3api per configurar.

En seguretat, has vist per què avui els buckets neixen tancats: Block Public Access amb els seus quatre interruptors, polítiques de bucket en JSON amb la distinció crítica entre l'ARN del bucket i el dels objectes, la precedència absoluta del Deny explícit, i les ACL com a llegat que no has de fer servir. Has generat URL signades prèviament amb boto3 perquè la Sara descarregui els seus informes sense tenir credencials d'AWS, i també per acceptar pujades de tercers amb límits de tipus i mida. Saps que tot es xifra en repòs per defecte i quan compensa passar de SSE-S3 a SSE-KMS amb BucketKeyEnabled.

Has vist l'allotjament estàtic i per què no es fa servir així en producció, has deixat configurada la notificació d'esdeveniments que dispararà la generació de miniatures —amb el filtre per prefix que evita el bucle infinit—, coneixes multipart upload i Transfer Acceleration, i has fet el càlcul que ordena tota la resta: a la factura d'S3 de MercadoFresco, el 97 % és transferència de sortida, no emmagatzematge.

Queden les fotos resoltes i falta el cor del negoci. Les comandes de MercadoFresco continuen a la base de dades del servidor de l'oficina, amb la seva còpia de seguretat poc fiable i la seva impossibilitat de créixer. A la lliçó 02-04, «Amazon RDS», migrarem aquesta base de dades a un servei gestionat: veurem què aporta davant d'instal·lar PostgreSQL en una EC2, muntarem Multi-AZ amb rèplica síncrona en espera, crearem rèpliques de lectura perquè els informes de la Sara no castiguin producció, i tancarem definitivament el problema 2 amb còpies automàtiques i restauració a un punt en el temps.