La lección anterior terminó con una decisión pendiente. EFS resolvía el problema de que las cuatro instancias del viernes compartieran /var/www/fotos, pero al precio equivocado: unas trece veces más caro que la alternativa, con todo el tráfico de imágenes pasando por las instancias y sin aprovechar la escala global de AWS. Esa alternativa es Amazon S3 (Simple Storage Service), y esta lección es donde MercadoFresco toma la decisión definitiva sobre sus fotos de producto.

S3 es probablemente el servicio más importante de AWS. Fue el primero que se lanzó, en 2006, y hoy es el sitio donde acaban los datos de casi cualquier arquitectura: ficheros estáticos, copias de seguridad, registros, lagos de datos, artefactos de despliegue. Entenderlo bien —no solo "es donde se suben archivos"— cambia la forma de diseñar sistemas, porque S3 no es un disco: es un almacén de objetos con una API, y esa diferencia tiene consecuencias en todo.

1. Almacenamiento de objetos: bucket, objeto, clave y prefijo
2. Por qué S3 no es un sistema de archivos
3. Nombres de bucket, regiones y espacio de nombres global
4. Durabilidad y disponibilidad: los once nueves
5. Clases de almacenamiento y cómo elegir
6. Reglas de ciclo de vida para las fotos antiguas del catálogo
7. Versionado y protección frente a borrados accidentales
8. Migrar /var/www/fotos con aws s3 sync
9. aws s3 frente a aws s3api
10. Permisos: Block Public Access, políticas de bucket y ACL
11. URLs prefirmadas: los informes de Sara sin credenciales
12. Cifrado en reposo y en tránsito
13. Alojamiento de un sitio estático
14. Eventos de S3: el disparador de las miniaturas
15. Multipart upload y Transfer Acceleration
16. Costes de S3 y cómo no llevarse sorpresas

El modelo de S3 tiene solo tres piezas, y conviene nombrarlas con precisión porque toda la documentación las usa así.

Un objeto puede pesar desde 0 bytes hasta 5 TiB. Un bucket puede contener un número ilimitado de objetos y crecer sin que nadie provisione nada.

Esta es la idea que hay que interiorizar, porque de ella se derivan casi todas las sorpresas de los principiantes.

En S3 no existen las carpetas. La consola las dibuja, aws s3 ls las lista, pero no están ahí. Lo único que existe es una lista plana de claves, y la barra / es un carácter más dentro del nombre.

Las consecuencias prácticas de esto son concretas:

Y una consecuencia positiva enorme: al no haber estructura jerárquica real, no hay límite de escala. Un bucket con mil millones de objetos funciona igual de bien que uno con diez, y S3 admite al menos 3.500 escrituras y 5.500 lecturas por segundo y por prefijo, con paralelización prácticamente ilimitada usando varios prefijos.

Por eso el diseño de claves importa. Para MercadoFresco:

El nombre de un bucket es único en todo AWS, en todas las cuentas y todas las regiones del mundo. Si alguien en Australia tiene fotos, tú no puedes tenerlo. Es el único recurso de AWS con espacio de nombres verdaderamente global.

Reglas del nombre:

• Entre 3 y 63 caracteres.
• Solo minúsculas, números, guiones y puntos.
• Debe empezar y acabar con letra o número.
• No puede parecerse a una dirección IP.
• Evita los puntos: rompen la validación del certificado TLS con nombres de estilo virtual y causan errores difíciles de diagnosticar.

Convención de MercadoFresco, que aplicaremos siempre:

Aunque el nombre sea global, los datos residen en una región concreta y nunca salen de ella salvo que lo pidas explícitamente. Para MercadoFresco esto no es un detalle: las fotos y los informes se quedan en eu-west-1, dentro de la UE, lo que sostiene el argumento de RGPD que vimos en 01-03.

La trampa de LocationConstraint. En us-east-1 (y solo ahí) no debe pasarse ese parámetro: el comando falla si lo incluyes. En cualquier otra región es obligatorio. Es una herencia histórica de que S3 nació en Virginia.

S3 Standard promete 99,999999999 % de durabilidad anual: los famosos once nueves. La cifra suena a marketing, pero tiene un significado operativo preciso.

Si guardas 10 millones de objetos, la expectativa estadística es perder uno cada 10.000 años. Dicho de otro modo: es muchísimo más probable que pierdas los datos por un borrado accidental o una política mal escrita que por un fallo de S3.

Cómo se consigue: cada objeto se replica automáticamente en al menos tres zonas de disponibilidad de la región, con verificación continua de integridad y reparación automática. Tú no configuras nada.

No hay que confundir dos métricas distintas:

Un matiz que importa mucho para MercadoFresco: la durabilidad de S3 no te protege de ti mismo. Si Luis ejecuta un aws s3 rm --recursive sobre el bucket equivocado, S3 lo borrará con once nueves de fiabilidad. La protección contra eso es el versionado, que veremos más abajo.

No todos los datos se acceden igual. Las fotos de los tomates de temporada se piden mil veces al día en junio y ninguna en enero. S3 ofrece clases con distinto equilibrio entre coste de almacenamiento y coste/latencia de acceso.

Entre Standard y Deep Archive hay un factor de 23 veces en el coste de almacenamiento. Ese es el premio por clasificar bien los datos.

Tres criterios de decisión:

1. Si no sabes el patrón de acceso, usa Intelligent-Tiering. Mueve los objetos entre niveles automáticamente, sin coste de recuperación, cobrando una pequeña cuota de monitorización por objeto. Es la opción segura por defecto para datos heterogéneos.
2. Cuidado con el mínimo de permanencia. Si subes un objeto a Standard-IA y lo borras a los 10 días, se te cobran los 30. Para datos de vida corta, esta clase sale más cara que Standard.
3. One Zone-IA solo para datos reproducibles. Vive en una sola AZ: si esa AZ se pierde, el dato se pierde. Es perfecto para las miniaturas de MercadoFresco, porque siempre se pueden regenerar a partir del original.

Una regla de ciclo de vida aplica transiciones y caducidades automáticamente según la edad de los objetos. Es la forma de que el ahorro anterior ocurra sin que nadie intervenga.

El análisis de MercadoFresco: las fotos de producto se consultan intensamente los primeros meses tras publicarse, luego el interés cae, y las de productos descatalogados solo se necesitan por motivos contables. Traducido a política, en ciclo-vida-fotos.json:

Comentario regla por regla:

• fotos-productos-enfriamiento: escalera de tres saltos. A los 3 meses baja a IA, al año a Glacier Instant (que sigue devolviendo en milisegundos), a los 3 años a Deep Archive.
• miniaturas-una-sola-az: aprovecha que son regenerables. Ahorro sin riesgo real.
• informes-analitica-caducan-a-2-anos: además de mover, borra. Los informes de Sara no tienen valor pasados dos años y borrar es el ahorro definitivo.
• limpiar-cargas-multiparte-incompletas: la más olvidada y la que más dinero silencioso ahorra. Una subida grande interrumpida deja fragmentos que se facturan y no aparecen al listar el bucket. Esta regla debería estar en absolutamente todos tus buckets.
• versiones-antiguas-caducan-a-90-dias: sin esto, el versionado hace crecer el bucket para siempre.

Estimación del ahorro para 40.000 fotos de 500 KB (unos 20 GB) con una distribución de edades típica:

Con 20 GB la diferencia es calderilla. Con los 20 TB que MercadoFresco tendrá tras abrir en tres ciudades más (problema 3), son más de 250 USD al mes de diferencia. Las reglas se ponen ahora, cuando cuestan un minuto, no cuando duelen.

Con el versionado activado, S3 nunca sobrescribe ni borra de verdad:

• Al subir un objeto con una clave existente, se crea una versión nueva y la anterior se conserva.
• Al borrar, se coloca un marcador de borrado (delete marker): el objeto desaparece de los listados pero todas sus versiones siguen ahí.
• Para recuperarlo basta con borrar el marcador de borrado.

Recuperación de un borrado accidental, el escenario real:

Una vez activado, el versionado no se puede desactivar, solo suspender (las versiones ya creadas se conservan). Y ojo al coste: cada versión se factura por separado, de ahí la regla de ciclo de vida NoncurrentVersionExpiration del apartado anterior.

Dos protecciones adicionales, mencionadas brevemente porque son de casos concretos:

• MFA Delete: exige un código de autenticación multifactor del usuario root para borrar versiones o cambiar el estado del versionado. Muy fuerte, pero solo se activa con las credenciales de root y no se puede gestionar desde la consola, lo que lo hace incómodo para el día a día.
• Object Lock (WORM: write once, read many): impide borrar o modificar un objeto durante un periodo fijado, incluso al administrador de la cuenta. Tiene dos modos, Governance (un rol con permiso especial puede saltárselo) y Compliance (nadie puede, ni el root). Es para retención legal. Solo se puede activar al crear el bucket. Para las copias de la base de datos de MercadoFresco tendría sentido; para las fotos, no.

Llega el momento. Las 40.000 fotos del servidor de la oficina se van a S3.

Qué hace cada opción:

• sync es incremental: compara tamaño y fecha de modificación, y solo sube lo que ha cambiado. Se puede interrumpir y relanzar sin duplicar trabajo, que es justo lo que se necesita para migrar 40.000 ficheros por una conexión de oficina.
• --dryrun: imprescindible antes de cualquier sync con destino nuevo.
• --exclude "*" seguido de varios --include: el orden importa. Primero se excluye todo y después se readmiten las extensiones deseadas. Así no se cuelan .DS_Store, Thumbs.db ni copias .bak.
• --cache-control: se guarda como metadato y lo respetarán los navegadores y, más adelante, CloudFront (03-04). Un día de caché para fotos que casi nunca cambian.

Verificación tras la migración:

Para volúmenes muy grandes hay opciones específicas que conviene conocer aunque no las usemos: AWS DataSync para transferencias masivas y recurrentes por red, y la familia AWS Snowball para cuando mover los datos por internet tardaría más que enviarlos físicamente en un dispositivo. Para los 20 GB de MercadoFresco, sync sobra.

La CLI ofrece dos interfaces distintas para S3, y confundirlas provoca mucha frustración.

Regla práctica: mueve datos con aws s3, configura con aws s3api.

Las filtraciones de datos por buckets S3 mal configurados han sido titular de prensa muchas veces. AWS respondió cambiando los valores por defecto: hoy todo bucket nuevo nace completamente privado y con Block Public Access activado a nivel de cuenta y de bucket.

Los cuatro interruptores, que mucha gente activa o desactiva sin saber qué hace cada uno:

La postura de MercadoFresco es dejar Block Public Access activado en todos los buckets, sin excepción. Las fotos se servirán públicamente a través de CloudFront con un control de acceso de origen, no abriendo el bucket. Eso se monta en la lección 03-04.

Una política de bucket es un documento JSON de IAM adjunto al bucket que dice quién puede hacer qué. Ejemplo real de MercadoFresco: permitir que solo el rol de las instancias de la tienda lea las fotos, y obligar a que todo el tráfico use HTTPS.

Dos detalles fundamentales:

• s3:ListBucket se concede sobre el bucket (arn:aws:s3:::bucket), mientras que s3:GetObject se concede sobre los objetos (arn:aws:s3:::bucket/*). Son ARN distintos y confundirlos es el error de política más frecuente.
• Un Deny explícito gana siempre sobre cualquier Allow, venga de donde venga. Por eso la segunda instrucción es una defensa sólida: nadie, ni el administrador, puede acceder por HTTP sin cifrar. La lógica completa de evaluación de permisos es la lección 04-01.

Las ACL (Access Control Lists) son el mecanismo original de 2006, anterior a IAM. Conceden permisos objeto a objeto a cuentas o grupos predefinidos.

AWS recomienda no usarlas. Desde 2023, los buckets nuevos nacen con Object Ownership en "Bucket owner enforced", que las desactiva por completo. Solo debes conocerlas para dos cosas: reconocerlas al heredar una cuenta antigua, y saber que si un tutorial te dice --acl public-read, ese tutorial está desactualizado. Usa políticas de bucket.

Sara, la analista de negocio, necesita descargar el informe mensual de ventas. No tiene usuario de AWS, no debe tenerlo, y el bucket es privado. La solución es una URL prefirmada: un enlace temporal que incorpora una firma criptográfica y caduca.

Lo esencial de este mecanismo:

• Quien tenga el enlace puede usarlo. No hay autenticación adicional: el enlace es la credencial. Por eso los plazos deben ser cortos.
• La URL hereda los permisos de quien la firma. Si el perfil que firma no puede leer el objeto, la URL tampoco funcionará.
• Caducidad máxima: 7 días con credenciales de usuario IAM; 1 hora si se firma desde un rol con credenciales temporales, como sería el caso dentro de una Lambda.
• generate_presigned_post con Conditions es la forma correcta de aceptar subidas de terceros: limita tipo y tamaño antes de que el fichero llegue.

Todo objeto nuevo en S3 se cifra en reposo automáticamente desde enero de 2023. No hay que hacer nada para tener cifrado; la decisión es solo quién gestiona la clave.

Decisión de MercadoFresco: SSE-S3 para las fotos (son datos públicos en la práctica, no compensa el coste por petición de KMS) y SSE-KMS para los informes de ventas y las copias de la base de datos, que contienen datos de negocio y donde interesa el registro de quién descifra.

BucketKeyEnabled: true reduce hasta un 99 % las llamadas a KMS y su coste asociado; actívalo siempre que uses SSE-KMS. La gestión de claves se ve a fondo en la lección 04-02.

En tránsito, todo el tráfico con S3 va por HTTPS. Para garantizar que nadie use HTTP en claro está la instrucción DenegarTodoLoQueNoSeaHTTPS de la política de bucket anterior.

S3 puede servir un sitio web estático directamente: HTML, CSS, JavaScript e imágenes, sin ningún servidor.

El resultado es una URL del tipo http://mercadofresco-tienda-web-desarrollo.s3-website-eu-west-1.amazonaws.com.

Limitaciones que hay que conocer antes de emocionarse:

• Solo HTTP, sin HTTPS. El punto de enlace de sitio web estático no admite TLS.
• Sin dominio propio con certificado.
• Exige el bucket público, lo que choca con la política de Block Public Access.

Por eso, en producción no se usa así. La arquitectura correcta es bucket privado + CloudFront delante con Origin Access Control: da HTTPS, dominio propio, caché en más de 400 ubicaciones de borde y protección. Eso es exactamente la lección 03-04. El modo sitio web de S3 queda para pruebas rápidas de Luis.

S3 puede notificar cuando pasa algo en un bucket. Es la puerta de entrada a las arquitecturas orientadas a eventos, y para MercadoFresco resuelve un problema concreto: las fotos originales pesan demasiado para el listado de productos y hacen falta miniaturas.

Eventos disponibles y destinos posibles:

El flujo que montaremos:

Configuración de la notificación (la función se escribe en 02-05):

El filtro por prefijo y sufijo es imprescindible. Sin él, la Lambda se dispararía también al escribir las miniaturas en el mismo bucket, que a su vez generarían otro evento: un bucle recursivo infinito que es una de las formas más rápidas y más caras de equivocarse en AWS.

Dos advertencias sobre la semántica de estos eventos: la entrega es al menos una vez (la función puede recibir el mismo evento dos veces, así que debe ser idempotente) y no está garantizado el orden. Aquí solo dejamos montado el disparador; el código lo escribimos en la lección 02-05.

Multipart upload trocea un objeto grande y sube las partes en paralelo. Es obligatorio por encima de 5 GB y recomendable a partir de 100 MB.

Ventajas: mayor rendimiento por paralelismo, reintento de una sola parte si falla la red, y posibilidad de pausar y reanudar. aws s3 cp y aws s3 sync lo hacen automáticamente; solo necesitas s3api si programas el proceso a mano.

El riesgo: si una subida multiparte se interrumpe, las partes ya subidas se quedan y se facturan, y no aparecen en un aws s3 ls normal. Por eso incluimos la regla AbortIncompleteMultipartUpload en el ciclo de vida. Para verlas:

Transfer Acceleration enruta las subidas a través de la ubicación de borde de CloudFront más cercana al cliente, y de ahí por la red troncal de AWS hasta el bucket. Acelera de forma significativa cuando quien sube está lejos de la región. Tiene coste adicional (≈0,04 USD/GB) y para MercadoFresco, que sube desde España a Irlanda, no compensa. Sería útil si un proveedor de Sudamérica subiera catálogos de fotos.

La factura de S3 tiene cuatro componentes, y casi todo el mundo solo mira el primero.

Cálculo realista para MercadoFresco: 20 GB de fotos, 500.000 visitas al mes con 10 fotos vistas por visita (5.000.000 de peticiones GET), foto media de 200 KB:

El 97 % del coste es transferencia de salida. Y ese dato justifica por sí solo la lección 03-04: poniendo CloudFront delante, la mayoría de las peticiones se sirven desde la caché de borde, la transferencia de S3 a CloudFront es gratuita, y el precio por GB hacia internet es menor. La factura puede bajar a menos de una tercera parte, y además la web irá más rápida.

Herramientas de control:

• S3 Storage Lens ofrece un panel gratuito con métricas de uso y recomendaciones de ahorro.
• S3 Inventory genera un informe periódico en CSV o Parquet con todos los objetos, su clase y su tamaño: la forma correcta de auditar buckets con millones de objetos sin listarlos uno a uno.
• El presupuesto presupuesto-mensual-mercadofresco de la lección 01-02 sigue siendo la red de seguridad.

Limpieza de la lección. Si has creado buckets de prueba, elimínalos. Un bucket con versionado requiere borrar también las versiones y los marcadores:

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

• Tratar S3 como un disco. Renombrar un prefijo con 40.000 objetos son 80.000 operaciones y minutos de espera. Diseña las claves bien desde el principio.
• Hacer un bucket público "para que funcione rápido". Es el origen de la mayoría de las filtraciones publicadas. Deja Block Public Access activado y usa CloudFront con OAC.
• Olvidar LocationConstraint fuera de us-east-1, o ponerlo dentro de us-east-1. Ambos fallan, con mensajes poco claros.
• No configurar AbortIncompleteMultipartUpload. Coste invisible que crece para siempre.
• Activar el versionado y no caducar las versiones antiguas. El bucket engorda sin límite y nadie entiende por qué la factura sube si "no se sube nada nuevo".
• Confundir el ARN del bucket con el de los objetos en las políticas: ListBucket va sobre el bucket, GetObject sobre bucket/*.
• Poner una Lambda a escuchar eventos del mismo bucket donde escribe. Bucle infinito. Filtra siempre por prefijo, o usa buckets distintos.
• Usar --acl public-read porque lo dice un tutorial antiguo. Las ACL están desactivadas por defecto en buckets nuevos y AWS desaconseja su uso.
• Subir a Standard-IA datos de vida corta. El mínimo de 30 días de facturación hace que salga más caro que Standard.
• Mirar solo el coste de almacenamiento. La transferencia de salida suele ser el 90 % de la factura de S3.
• Consejo: ejecuta sync con --dryrun siempre la primera vez. Un destino mal escrito puede copiar 40.000 ficheros al prefijo equivocado, y deshacerlo es más trabajo que hacerlo.

MercadoFresco guardará en mercadofresco-copias-basedatos los volcados diarios de la base de datos de pedidos, bajo el prefijo copias/base-datos/. Cada volcado ocupa 2 GB. Los requisitos son:

• Los últimos 30 días deben poder restaurarse en minutos.
• Entre 30 días y 1 año, la restauración puede tardar horas.
• Entre 1 y 7 años (retención legal fiscal) se conservan al coste mínimo posible.
• Pasados 7 años se borran automáticamente.

Escribe la regla de ciclo de vida en JSON y calcula el coste mensual en régimen estacionario, comparándolo con dejarlo todo en Standard. Usa: Standard 0,023; Glacier Flexible 0,0036; Deep Archive 0,00099 USD/GB-mes.

Sara debe poder leer los informes bajo informes/, pero no borrarlos ni tocar otros prefijos. El rol rol-mercadofresco-analitica debe poder escribir en informes/. Nadie debe acceder sin HTTPS ni subir objetos sin cifrar con KMS.

Escribe la política de bucket completa y explica por qué la última condición necesita un Deny y no un Allow.

Para cada dato de MercadoFresco, indica bucket, prefijo, clase de almacenamiento inicial, si activas versionado y qué regla de ciclo de vida aplicarías:

• A) Las 40.000 fotos originales del catálogo, en alta resolución.
• B) Las miniaturas 200×200 generadas automáticamente a partir de las anteriores.
• C) Los registros de acceso del servidor web, unos 3 GB al día, consultados solo si hay una incidencia y obligatorios durante 90 días.
• D) El informe mensual de ventas que Sara descarga por URL prefirmada.

Solución 1.

Volumen en régimen estacionario (2 GB/día):

Notas de diseño: 2.555 días son 7 años. Deep Archive tiene 180 días de permanencia mínima, sin problema aquí porque los objetos llegan con 365 días de vida y se quedan más de seis años. Y el requisito "restaurar en minutos los últimos 30 días" es lo que impide bajar a Glacier antes: Glacier Flexible tarda de minutos a 12 horas según el modo de recuperación.

Solución 2.

Por qué las dos últimas necesitan Deny y no Allow. Un Allow solo concede: si simplemente "permitieras HTTPS", cualquier otra política —una política de identidad de IAM adjunta al usuario, por ejemplo— podría seguir concediendo el acceso por HTTP, porque los permisos se suman. Un Deny explícito, en cambio, tiene precedencia absoluta: ninguna política de ninguna capa puede anularlo. Para requisitos de seguridad que deben cumplirse siempre y sin excepción, la formulación correcta es prohibir la condición indeseada, no permitir la deseada.

Detalle adicional: sin la condición s3:prefix en ListBucket, Sara podría listar todo el bucket y ver los nombres de objetos de otros prefijos, aunque no pudiera descargarlos. Nombres que a veces revelan más de lo que parece.

Solución 3.

Observación transversal: el prefijo de las miniaturas debe estar fuera del prefijo que dispara el evento (productos/), o el filtro de la notificación debe excluirlas. Es la protección contra el bucle recursivo mencionado antes.

MercadoFresco ya tiene sus fotos donde deben estar. Has entendido que S3 es un almacén de objetos y no un sistema de archivos: no hay carpetas, solo claves planas donde la barra es un carácter más; los objetos son inmutables; renombrar un prefijo significa copiar y borrar. A cambio de esas restricciones se obtiene escala prácticamente ilimitada, once nueves de durabilidad por replicación automática en tres o más zonas de disponibilidad, y un coste por GB unas trece veces menor que EFS.

Sabes construir nombres de bucket válidos en un espacio de nombres global, con la trampa de LocationConstraint incluida, y tienes una convención propia (mercadofresco-<componente>- <propósito>). Dominas las siete clases de almacenamiento y sus compensaciones —latencia, coste de recuperación, permanencia mínima, número de AZ— y has escrito reglas de ciclo de vida que enfrían las fotos del catálogo automáticamente, mueven las miniaturas a One Zone-IA por ser regenerables, caducan los informes a los dos años, borran las versiones antiguas y —la regla que todo el mundo olvida— abortan las cargas multiparte incompletas que se facturan en silencio.

Has activado el versionado y practicado la recuperación real de un borrado accidental eliminando el marcador de borrado, y conoces MFA Delete y Object Lock para los casos que exigen retención inviolable. Has migrado /var/www/fotos con aws s3 sync, con su --dryrun obligatorio y sus filtros de inclusión, y tienes clara la división de trabajo entre aws s3 para mover datos y aws s3api para configurar.

En seguridad, has visto por qué hoy los buckets nacen cerrados: Block Public Access con sus cuatro interruptores, políticas de bucket en JSON con la distinción crítica entre el ARN del bucket y el de los objetos, la precedencia absoluta del Deny explícito, y las ACL como legado que no debes usar. Has generado URLs prefirmadas con boto3 para que Sara descargue sus informes sin tener credenciales de AWS, y también para aceptar subidas de terceros con límites de tipo y tamaño. Sabes que todo se cifra en reposo por defecto y cuándo compensa pasar de SSE-S3 a SSE-KMS con BucketKeyEnabled.

Has visto el alojamiento estático y por qué no se usa así en producción, has dejado configurada la notificación de eventos que disparará la generación de miniaturas —con el filtro por prefijo que evita el bucle infinito—, conoces multipart upload y Transfer Acceleration, y has hecho el cálculo que ordena todo lo demás: en la factura de S3 de MercadoFresco, el 97 % es transferencia de salida, no almacenamiento.

Quedan las fotos resueltas y falta el corazón del negocio. Los pedidos de MercadoFresco siguen en la base de datos del servidor de la oficina, con su copia de seguridad poco fiable y su imposibilidad de crecer. En la lección 02-04, «Amazon RDS», migraremos esa base de datos a un servicio gestionado: veremos qué aporta frente a instalar PostgreSQL en una EC2, montaremos Multi-AZ con réplica síncrona en espera, crearemos réplicas de lectura para que los informes de Sara no castiguen a producción, y cerraremos definitivamente el problema 2 con copias automáticas y restauración a un punto en el tiempo.