Construcción y operación de un sistema de almacenamiento enorme llamado S3
(allthingsdistributed.com)- Amazon S3 comenzó en 2006 como un almacenamiento de objetos basado en una API HTTP REST y creció hasta convertirse en un servicio a gran escala operado por cientos de microservicios y múltiples equipos dedicados
- La escala de S3 no se explica solo con código: es un sistema en cambio constante donde discos duros, firmware, centros de datos, organización operativa y cargas de trabajo de los clientes interactúan continuamente
- Los HDD mejoraron mucho en capacidad y eficiencia de costos, pero su rendimiento de acceso aleatorio sigue limitado por restricciones mecánicas, por lo que S3 trata como problema central la gestión del calor de I/O y la colocación de datos en cientos de miles de discos
- La replicación y la codificación de borrado basada en Reed-Solomon no solo aumentan la durabilidad, sino que también ayudan a desviar solicitudes lejos de discos sobrecargados, contribuyendo al rendimiento y al control de la tail latency
- La operación de S3 está diseñada para mantener al mismo tiempo desarrollo rápido y altos estándares de durabilidad mediante revisiones de durabilidad, ShardStore basado en Rust, verificación formal ligera y ownership a nivel de equipo
Ver S3 como un único sistema de servicio enorme
- S3 es un servicio de almacenamiento de objetos compuesto por una API HTTP REST, una flota de frontend, un servicio de espacio de nombres, una flota de almacenamiento basada en discos duros y una flota de trabajos en segundo plano
- Cada gran componente tiene dentro de la organización de S3 un área separada, líderes y varios equipos; y los componentes internos también operan con sus propias flotas y equipos
- Actualmente S3 está compuesto por cientos de microservicios, y la interacción entre equipos se parece más a contratos a nivel de API
- Si la modularidad se diseña mal, la interacción entre equipos también puede volverse ineficiente e incómoda, y corregir eso también forma parte de diseñar conjuntamente el software y los equipos
El sistema no es solo software, sino el servicio completo
- Los clientes de S3 no compran software empaquetado, sino una experiencia de servicio, y esperan una calidad continua y predecible
- Los límites del sistema de S3 no se quedan solo en el código
- Código que se ejecuta cerca del disco
- Técnicos que instalan nuevos racks de almacenamiento en el centro de datos
- Aplicaciones de clientes que ajustan el rendimiento
- Organizaciones de hardware, finanzas e ingeniería
- S3 se parece más a un sistema vivo en el que software, hardware y personas siguen creciendo y cambiando juntos
- Un simple diagrama de arquitectura en pizarrón hace que el sistema real parezca menor de lo que es, porque oculta la escala y los servicios extendidos dentro de cada bloque
Cómo los límites físicos de los HDD afectan el diseño de S3
- S3 es un sistema enorme que usa cientos de miles de discos duros, y las características de los HDD son una de las restricciones centrales del diseño
- Los HDD han avanzado mucho desde la IBM 350 disk storage unit de 1956
- El HDD de mayor capacidad mencionado actualmente es el Western Digital Ultrastar DC HC670 de 26 TB
- Desde RAMAC, la capacidad mejoró 7.2 millones de veces
- El tamaño físico se redujo 5,000 veces
- El costo por byte ajustado por inflación se abarató 6 mil millones de veces
- Pero el seek time solo mejoró 150 veces, y el rendimiento de lectura y escritura aleatoria sigue alrededor de 120 operaciones por segundo
- Esa cifra de rendimiento ya era similar cuando S3 se lanzó en 2006, y tampoco era muy distinta diez años antes
- Como el HDD es un dispositivo mecánico, hay que esperar el movimiento del brazo y la rotación del plato, por lo que el rendimiento de acceso aleatorio no mejora al ritmo del aumento de capacidad
- La hoja de ruta de la industria apunta a HDD de 200 TB dentro de la próxima década, y en ese nivel, si se asume acceso aleatorio uniforme a todos los datos, solo se permitiría 1 I/O por segundo por cada 2 TB de datos en disco
- S3 todavía no usa discos de 200 TB, pero se espera que use esos y todos los tamaños intermedios
Gestión del calor: colocación de datos y rendimiento
- En S3, el heat se refiere a la cantidad de solicitudes que llegan a un disco específico en un momento dado
- Si la gestión del calor falla, las solicitudes se concentran en un disco específico y aparece un hotspot, lo que degrada el rendimiento general de las solicitudes que dependen de ese disco
- Un hotspot no necesariamente detiene el sistema de inmediato, pero sí crea colas de solicitudes y empeora la experiencia del cliente
- Se retrasan las solicitudes que esperan a un disco ocupado
- Esa latencia se amplifica en las capas superiores del stack de almacenamiento a través de I/O dependientes, como búsquedas de metadatos o codificación de borrado
- Aparecen solicitudes con latencia alta, es decir, stragglers
- Los hotspots en HDD individuales terminan convirtiéndose en tail latency y, si se dejan sin atender, afectan la latencia total de las solicitudes
- En S3, al momento de escribir los datos no se sabe cuándo ni cómo se accederá a ellos después, por lo que decidir su colocación en el momento de escritura es difícil
- A pequeña escala es muy difícil predecir y gestionar el calor de I/O, pero en la escala y multitenencia de S3 aparecen otras propiedades
- Las cargas de trabajo individuales suelen estar inactivas la mayor parte del tiempo y luego mostrar picos repentinos, pero al sumar millones de cargas de trabajo la demanda total se vuelve plana y predecible
- Una vez superada cierta escala, es muy difícil o imposible que una sola carga de trabajo afecte el pico total
Replicación y codificación de borrado abordan durabilidad y rendimiento al mismo tiempo
- El método de redundancia de un sistema de almacenamiento no solo protege los datos frente a fallas de hardware, sino que también ayuda a distribuir el calor
- La replicación permite tolerar fallas de disco al guardar copias en varios discos, y hace posible atender lecturas desde cualquiera de esas copias
- La replicación es costosa en términos de capacidad, pero eficiente en términos de I/O de lectura
- Para no pagar el sobrecosto de la replicación en todos los datos, S3 también usa codificación de borrado
- Un enfoque de ejemplo usa algoritmos como Reed-Solomon
- Divide un objeto en
kshards de identidad - Genera además
mshards de paridad - Mientras se pueda usar cualquier conjunto de
kshards de un total dek+m, el objeto puede leerse
- Divide un objeto en
- Este enfoque reduce el sobrecosto de capacidad mientras mantiene tolerancia al mismo número de fallas
Estrategias de colocación de datos y aislamiento de cargas de trabajo de clientes
- Los métodos de redundancia dividen los datos en más fragmentos de los necesarios para leerlos, lo que permite enviar solicitudes evitando discos sobrecargados
- S3 reduce aún más el calor distribuyendo los objetos nuevos ampliamente por toda la flota de discos
- Un objeto individual puede codificarse a través de decenas de discos, y objetos distintos se colocan sobre conjuntos distintos de discos
- Al distribuir los objetos dentro de cada bucket sobre muchos discos se obtienen dos ventajas
- La proporción de datos de un cliente en un solo disco se vuelve muy pequeña, así que una carga de trabajo individual difícilmente puede crear un hotspot en un disco específico
- Una carga de trabajo individual puede hacer burst hasta un nivel de escala de discos que sería difícil y costoso construir como sistema independiente
- Un burst de un cliente de análisis genómico que ejecuta análisis paralelos desde miles de funciones Lambda puede procesarse con más de un millón de discos individuales
- Hoy en S3 hay decenas de miles de clientes con buckets distribuidos a través de millones de discos
- Lo distintivo de S3 no es solo la escala del sistema de almacenamiento en sí, sino que la escala agregada de clientes y cargas de trabajo puede cambiar incluso la naturaleza del sistema
Revisiones de durabilidad y guardrails
- En Amazon se valora mucho que los ingenieros y los equipos puedan fallar rápido y de forma segura
- Para avanzar rápido sin dejar de ofrecer almacenamiento con alta durabilidad, S3 usa un proceso de durability review
- La durability review no forma parte del modelo estadístico de 11 nueves, pero se considera importante en la operación de S3
- Cuando un cambio de ingeniería puede afectar el estado de durabilidad, se realiza una durability review
- Este proceso toma prestada la idea del threat model de la investigación en seguridad
- Se redacta un resumen del cambio
- Se crea una lista exhaustiva de amenazas
- Se documenta cómo el cambio resiste esas amenazas
- La durability review cumple dos funciones
- Obliga a autores y revisores a pensar críticamente sobre los riesgos que deben protegerse
- Permite discutir por separado los riesgos y las contramedidas
- Al buscar contramedidas, se prefieren guardrails simples y contundentes que bloqueen familias amplias de riesgo, en vez de agregar mitigaciones individuales para cada riesgo específico
ShardStore, Rust y verificación formal ligera
- Hace algunos años, S3 inició un proyecto para reescribir desde cero la capa más baja de su stack de almacenamiento, es decir, la parte que administra los datos de cada disco individual
- El nombre de la nueva capa de almacenamiento es ShardStore
- Uno de los guardrails adoptados al reconstruir ShardStore fue la verificación formal ligera
- El equipo migró el lenguaje de implementación a Rust para encontrar bugs más temprano
- Aprovechó la seguridad de tipos
- Aprovechó el soporte estructurado del lenguaje
- Escribió librerías para extender la seguridad de tipos también a las estructuras en disco
- Desde el lado de la verificación, se escribió en Rust un modelo simplificado de la lógica de ShardStore y se colocó en el mismo repositorio que la implementación real de producción
- Ese modelo actúa como una especificación ejecutable que elimina la complejidad de la capa real de almacenamiento en disco y de los HDD
- El modelo tenía un tamaño equivalente a aproximadamente 1% del sistema real, pero hizo posible un nivel de pruebas poco realista frente a discos duros de 120 IOPS
- Este trabajo también se publicó en el paper de SOSP Using lightweight formal methods to validate a key-value storage node in Amazon S3
- Después se usaron herramientas y técnicas existentes como property-based testing para verificar si el comportamiento de la implementación coincidía con la especificación
- Lo clave fue industrializar técnicas de investigación en verificación formal en forma de código mantenible por ingenieros comunes y herramientas aplicadas en cada commit
- Los guardrails de verificación le dieron al equipo confianza para desarrollar más rápido, y siguieron funcionando incluso después de la incorporación de nuevos ingenieros
Abordar los problemas de escala de equipos e individuos mediante ownership
- En Amazon, ownership es el concepto de dejar claro qué persona o equipo único es responsable hasta el final de que una tarea o servicio tenga éxito
- En S3, para moverse rápido y al mismo tiempo mantener altos estándares de calidad, los equipos tienen que ser propietarios
- Son dueños de los contratos de API con otros sistemas
- Son responsables de la durabilidad, el rendimiento y la disponibilidad
- Si un bug inesperado afecta la disponibilidad, lo corrigen incluso a las 3 de la mañana
- Después de corregirlo, mejoran el sistema para que no vuelva a pasar
- El ownership requiere confianza además de una gran responsabilidad
- Para que una persona o un equipo sea dueño de un servicio, necesita margen para decidir directamente cómo entregarlo
- Incluso en la experiencia de proyectos de investigación de posgrado, cuando el estudiante siente que una idea le pertenece y puede desarrollarla por sí mismo, se involucra más a fondo
- En roles de ingeniería muy senior, suele ser más efectivo definir bien el problema y ayudar al equipo a ser dueño de la solución, en vez de presentar la solución como algo ya desplegado
- En problemas donde hay varias soluciones posibles, lograr que alguien elija una solución adecuada es una forma de darle a esa persona ownership de la solución
Conclusiones obtenidas de S3
- La escala técnica de S3 no es simplemente una versión más grande de un sistema pequeño: sus cargas de trabajo, estructura y modo de operación son fundamentalmente distintos
- El “sistema” incluye no solo el software, sino también la operación del servicio, la organización operativa y hasta el código del cliente que funciona junto con ese servicio
- Como la organización también es parte del sistema, tiene sus propios problemas de escala y oportunidades de innovación
- Para tener éxito en un rol individual, es más importante expresar con claridad los problemas que apoyar que equipos de ingeniería fuertes sean realmente dueños de las soluciones
2 comentarios
Opiniones de Hacker News
Una de las conversaciones que recuerdo de cuando estaba en AWS era que incluso un evento de una en mil millones ocurre todos los días a la escala de S3.
Cosas que normalmente uno descartaría por ser demasiado improbables como para preocuparse, necesariamente hay que considerarlas y manejarlas.
Me alegró ver enfoques como ShardStore, en especial la verificación formal y las pruebas basadas en propiedades. Los servicios de generaciones anteriores tenían tantos bugs que mostraban bien los riesgos del crecimiento orgánico, pero al menos estaban diseñados para fallar de forma “segura”, evitando la pérdida de datos, y los ingenieros de S3 estaban obsesionados con eso.
Y no es solo S3. Por ejemplo, en Prime Day 2022, DynamoDB llegó a más de 105 millones de solicitudes por segundo solo con cargas de trabajo de Amazon: https://aws.amazon.com/blogs/aws/amazon-prime-day-2022-aws-f...
En el artículo, Andy también habla de técnicas formales ligeras y de la adopción de Rust por parte del equipo; a una escala donde incluso los eventos de probabilidad extremadamente baja se vuelven comunes, hay que invertir en varias capas de herramientas y procesos para lograr corrección.
Le expliqué que al llegar al objetivo de 500k TPS, eso serían 30 veces por minuto, y le pregunté: “¿quieres estar on-call esa semana?”. En ese stack, “mantener los estándares más altos” significa algo totalmente distinto que en la mayoría de las organizaciones.
Por suerte, el algoritmo era bueno, y el hardware actual también es mucho más estable.
También tengo una vocecita un poco retorcida en la cabeza, lista con palomitas por si tengo la suerte de ver las repercusiones cuando ocurra la primera gran colisión de hashes criptográficos.
Trabajando en genómica, durante los últimos 10 años he manejado muchos almacenes de datos a escala de petabytes.
Después de usar AWS S3, GCP GCS y sistemas de almacenamiento para hardware en colocación (Ceph, Gluster y un sistema de HP cuyo nombre borré de mi memoria), llegué a respetar mucho el esfuerzo que implica operar sistemas como estos.
También es difícil subestimar la ventaja de compartir I/O de disco con muchísimos otros clientes. Es la primera vez que escucho el término “heat” que menciona el artículo, pero en un solo sistema es realmente difícil mitigarlo. En nuestro clúster de colocación, para gestionar bien el I/O entre trabajos grandes tuvimos que modificar el sistema de batch para tratar el I/O como un recurso asignable, igual que la RAM o la CPU. S3 y GCP son muy caros, pero a veces su rendimiento vale lo que cuestan.
Para mí, artículos como este son lo mejor de HN.
Desde la perspectiva del almacenamiento en la nube, el mejor cliente es el que guarda una enorme cantidad de datos pero casi nunca los lee. Es parecido a alquilar discos duros, pero si solo llenas una parte de cada disco con datos “fríos”, puedes seguir usando toda la capacidad de I/O de ese mismo disco para atender trabajos calientes.
Si equilibras con mucho cuidado qué datos poner en qué unidad, puedes mantener todas las unidades en uso aunque la mayor parte de los datos no se use. Por eso el almacenamiento es relativamente barato y la lectura relativamente cara.
Incluso cuando soportan S3, su rendimiento suele ser mucho más lento de lo que podría ser.
Es difícil, y lamento que la disponibilidad de lectura sea de apenas alrededor del 99.95%.
Si S3 hubiera especificado un protocolo simple basado en OAuth2 para delegar acceso de lectura/escritura, se podrían haber creado muchas cosas
El mundo necesita un protocolo basado en HTTP que permita que una app acceda a datos en nombre del usuario. Google Drive es lo más cercano a eso, pero tiene un solo proveedor y también otros problemas[0]. Es una lástima que remoteStorage no haya logrado consolidarse. Espero que a Solid le vaya bien, pero a mí me parece demasiado complejo. Mi enfoque para este problema es https://gemdrive.io/, aunque ahora está casi detenido porque estoy enfocado en otras partes de mi stack de self-hosting
[0]: https://gdrivemusic.com/help
Hacerlo bien hoy es extremadamente difícil. Creé una app CLI completa para resolver el problema de “emitir credenciales de AWS que solo puedan acceder a este bucket específico”, pero no quiero pedirles a los usuarios que instalen y ejecuten algo así: https://s3-credentials.readthedocs.io/en/stable/
En la práctica, sería bueno tener una biblioteca con mínimas dependencias del lado del cliente que monte un directorio local que en realidad sea el bucket de S3 del usuario
Porque un competidor podría entrar en cualquier momento mediante interoperabilidad adversarial
Es una verdadera lástima que todos los proyectos que intentaban crear, o están creando, soberanía de datos para el usuario hayan terminado yéndose hacia cosas raras de criptomonedas
https://docs.aws.amazon.com/cognito/latest/developerguide/co...
Edición: creo que leí mal el comentario. Entendí que la app quería delegar los datos del usuario al cliente, pero en realidad parece que el usuario quiere delegar sus datos a la app. Son casos de uso distintos
Las especificaciones de IBM RAMAC dicen capacidad de almacenamiento de 3.75 MB y unos 9,200 dólares por terabyte, pero eso no puede ser correcto
Si multiplicas el costo por la capacidad de almacenamiento, el precio del disco sería de 3 centavos
Este sitio[1] dice que “almacenaba alrededor de 2,000 bits por pulgada cuadrada y su precio de compra era de unos 10,000 dólares por megabyte”
Así que probablemente la especificación debería decir 9,200 dólares por megabyte. Eso pondría el precio del disco en 34,500 dólares, lo cual suena más plausible
[1]: https://www.historyofinformation.com/detail.php?entryid=952
Eran 30 millones de bits, usando solo 6 bits de datos después de excluir la paridad. Pero como se alquilaba por 3,000 dólares al mes, no había un costo fijo equivalente a comprar la unidad física de una sola vez. En ese sentido, también se parece bastante al modelo de S3
Lo que la mayoría no entiende es que la magia no está en manejar el sistema en sí, sino en hacer que la autorización parezca no tener costo
La autorización en sistemas distribuidos es tremendamente difícil. A escala de AWS, es prácticamente magia. AWS tiene un modelo de permisos muy rico, y los cambios de permisos se propagan por toda la infraestructura en tiempos submilisegundo, probablemente mientras procesa billones de solicitudes
Esta parte, junto con el logging y la conciliación para facturación, son los dos elementos mágicos de AWS sobre los que me gustaría leer
S3 maneja el control de acceso de forma distinta a otros servicios: los permisos están asociados al recurso. Supongo que es por velocidad
Una de las razones por las que el enfoque bucket/clave es especial es que, cuando apareció IAM, ese modelo ya estaba establecido
Si se mantuvo después, probablemente fue porque eliminar el modelo existente habría roto la configuración de muchos clientes y habría sido una tarea difícil
“Como ingeniero realmente sénior en la empresa, por supuesto tengo opiniones fuertes y también una agenda técnica. Pero cuando interactúas con ingenieros, si solo intentas repartir ideas, es difícil que todos tengan éxito. Es mucho más difícil involucrarse a fondo con una idea que uno no siente propia. Por eso, al trabajar con equipos, adopté la estrategia de hacer que mis mejores ideas no fueran ideas mías, sino ideas de otras personas. Conscientemente dedico mucho más tiempo a desarrollar el problema y expresarlo muy bien, en lugar de vender una solución. Suele haber muchas maneras de resolver un problema, y elegir la correcta consiste en lograr que alguien se apropie de la solución.”
“Aprendí que, para tener verdadero éxito en mi rol, tenía que enfocarme en articular con claridad el problema, no la solución, y encontrar maneras de apoyar a un equipo de ingeniería fuerte para que realmente se apropiara de esa solución.”
Esa parte me encantó. Hasta cierto punto me hizo pensar en el efecto Ikea. Si quieres que alguien se apasione por lo que hace, tienes que fomentar el sentido de pertenencia, y una buena forma es lograr que ese trabajo se convierta en “su idea”.
Al final, la gente suele discrepar desde qué es el “problema”.
Por suerte no todos los problemas son así. Pero, por ejemplo, si miras las discusiones sobre el “problema de empaquetado” de Python, en realidad la gente está describiendo de maneras muy distintas unos seis problemas diferentes, y este fenómeno se ve bastante mal ahí.
Andy Warfield, si estás leyendo esto —y probablemente lo estés—, tengo una pregunta. Al desarrollar un problema, ¿qué tan valioso es bosquejar posibles soluciones? Si expresas claramente el problema, naturalmente se te ocurrirán algunas soluciones posibles; ¿vale la pena compartirlas para activar el pensamiento de posibles dueños del tema? ¿O es mejor concentrarse solo en el problema y dejar el espacio de soluciones completamente abierto?
Además, ¿hay algún material recomendado para leer más sobre la forma de trabajo de este tipo de colaboradores individuales muy sénior?
A mí me suena como decir: “¡Tú, plebeyo! No tengo tiempo para ocuparme de tus problemas. Si me traes solo el problema, no puedo usar tu trabajo para ascender”.
Para poder resolver un problema, primero hay que entenderlo y reconocer que existe.
En situaciones donde no hay autoridad ni expertise reconocidos de antemano —es decir, el contexto en el que aparecen la mayoría de los problemas cotidianos—, si uno ocupa por su cuenta un canal de diálogo bidireccional con una descripción larga, detallada y cuidadosamente elaborada del problema, es fácil parecer alguien que solo habla y no quiere hacer el trabajo, o alguien que no quiere buscar soluciones junto con los demás.
Me alegra ver que empleados de Amazon ya puedan hablar públicamente sobre el funcionamiento interno de S3.
También me gustaría escuchar más sobre cómo funciona Glacier. Hasta donde sé, nunca han revelado cuál es el medio de almacenamiento subyacente, así que ha habido todo tipo de especulaciones: cinta, HDD offline, HDD personalizados, etc.
Pero hay gente que no está de acuerdo. Sigue siendo una incógnita.
Me encantaría que AWS contara todo sobre eso y sobre todo su recorrido. Es algo fascinante.
Bastaría con que un ingeniero se emborrachara y soltara la lengua. En ámbitos mucho más graves, un militar de Massachusetts filtró información de seguridad nacional en Discord para impresionar a sus amigos gamers y ahora enfrenta una larga condena de prisión. Pensé que los detalles de Glacier ya habrían salido a la luz para este momento.
“Imagina la cabeza de un disco duro como un 747 volando sobre un césped a 75 millas por hora. La separación de aire entre la parte inferior del avión y la punta del pasto es del grosor de dos hojas de papel. Si medimos los bits del disco como hojas de pasto, el ancho de una pista sería de 4.6 hojas de pasto, y la longitud de un bit sería una hoja de pasto. Mientras el avión vuela sobre el césped contando hojas de pasto, solo se pierde una hoja cada 25 mil vueltas alrededor de la Tierra.”
La parte sobre balanceo de carga me recordó la época de KeyMap de S3 y cuando intentábamos migrar a eso desde la implementación inicial.
Lo que aprendimos fue que, incluso después de identificar el objeto/partición/bucket más caliente, no podíamos simplemente moverlo y ya. Había que ordenar todo. La solución real fue ordenar y luego dividir la carga de particiones del host en cuartiles, y mover una partición del segundo cuartil al host con menor carga.
Si intentábamos mover el bucket más caliente, es decir, el primer cuartil, la carga recaía más sobre los miembros restantes y seguía fallando.
Otro efecto secundario fue que la tasa de errores pasó de un ~1% estable a varios días sin errores, y como resultado actualizamos los umbrales de alerta para que fueran mucho más estrictos. Esto fue más o menos alrededor de 2009.
Yo también venía del mundo académico de UM, pero en vez de hacer el doctorado me uní a S3. Hasta rima.
S3 es más que almacenamiento; es un estándar.
Me gusta que en varios lugares se pueda usar almacenamiento compatible con S3, normalmente con algunas salvedades. No sé qué tan abierto es el estándar ni si hay que pagarle a Amazon para poder decir “S3 compatible”, pero está bastante genial.
Algunos ejemplos son E2 de iDrive, Digital Ocean Object Storage, Cloudflare R2, Vultr Object Storage y Backblaze B2.
Edit: al buscarlo, parece que Azure de verdad no la tiene :-/
Opiniones de Hacker News
Trabajo en genómica y he manejado muchos almacenes de datos de varios petabytes durante la última década.
Las cosas que podríamos construir si S3 usara un protocolo basado en OAuth2 para delegar acceso de lectura/escritura.
Manejar la autenticación en sistemas distribuidos es muy difícil.
Es bueno ver a empleados de Amazon hablar públicamente sobre el funcionamiento interno de S3.
La parte que explica el cabezal del disco duro comparándolo con un avión 747.
Volviendo a la época de S3 KeyMap, aprendimos que incluso después de identificar los objetos/particiones/buckets más calientes, no bastaba con moverlos para resolver el problema.
S3 no es solo almacenamiento, es un estándar.