Yo sé que muchos de ustedes utilizan Amazon, Amazon S3, porque Amazon S3 es seguramente uno de los servicios más utilizados en el mundo entero para almacenar archivos estáticos.
Seguramente es uno de, yo diría que el más utilizado del mundo, si no el que más.
Porque dice Amazon S3, un servicio ofrecido por Amazon Web Services que proporciona almacenamiento de objetos a través de una interfaz de servicio web.
Normalmente archivos estáticos, ¿vale?
Bueno, pues resulta que tienen que tener mucho cuidado porque, ojo con esto, ojo con lo que le ha pasado a Laura Wendel.
Aparentemente, si alguien sabe o adivina el nombre de tu bucket en S3, ¿vale?
Como tu cajón de S3, incluso si es privado, o sea, aunque sea privado, te pueden arruinar enviando infinitas solicitudes PUT y no hay nada que puedas hacer al respecto.
Las solicitudes son rechazadas. O sea, que encima no es que digas, no, es que claro, me están atacando y me están todo el rato recuperando un archivo.
No, no, no. Aunque la solicitud sea rechazada, lo que pasa es que AWS lo cuenta como una operación de escritura.
Esto es una locura, amigos, porque las operaciones de escritura suelen ser más caras.
Si fuese de lectura, pues bueno, no sería tan caro, que también sería un problema, pero es que la cuenta como si fuese de escritura.
Y el problema es que tienes que pagar 0,005 por cada 1000 requests, que esto puede parecer poco, pero si te hacen 10.000 millones de peticiones, pues ya veréis que empieza a picar.
Esto me parece una locura, especialmente porque muchos servicios dependen de URLs prefirmadas para cargas o descargas que ponen el nombre de su depósito al cliente.
De nuevo, es el nombre del depósito, no es el token, no es algo especial, es el nombre del depósito.
Hay veces que el nombre del depósito, de hecho se suele hacer, lo puedes ocultar utilizando otros servicios, puedes tener un CloudFront y tal,
pero hay veces que por lo que sea, pues lo tienes público porque es que no debería pasar absolutamente nada si tienes bien los permisos, ¿sabes?
Total, que dice, en este caso el autor consiguió que se rechazara su factura, pero el soporte dejó claro que es una excepción, no la regla.
O sea, que como le pasa a otra persona, y fijaos aquí lo que le pasó, fijaos, 55 millones de peticiones, 40 millones de peticiones, 100 millones de peticiones en total,
una factura de 1.300 dólares, todo en un día, en un día, simplemente en un día, por peticiones en un bucket, o sea, que no tenían permisos para utilizar.
Aquí tenéis el artículo, que está bastante interesante, lo tenéis por aquí, claro, si tenéis CloudFront, CloudFront al final es como un CDN,
un CDN que se pone por delante de S3, claro, si utilizáis CloudFront, pues no, la gente no va a saber el origen,
y por lo tanto no va a tener acceso al bucket, pero aún así es que da igual, o sea, si tenéis CloudFront no vais a tener problema,
pero igualmente es bastante, bastante grave esto, es bastante grave porque nada te dice que tengas que estar obligado a utilizar CloudFront por delante, ¿no?
¿De dónde venía el request? Por defecto, AWS no hace un log de las peticiones que van a los buckets de S3, claro, porque no tenía mucho sentido.
Sin embargo, puede ser activado si te está dando CloudFront y tal, no sé qué.
Y aquí te dice, pero ¿por qué algunos third parties te pueden bombardear S3 buckets haciendo peticiones no autorizadas?
Claro, puede ser un ataque, o lo que sea, ¿no?
Pero claro, a veces puede ser lo que dice aquí, dice que si hay una herramienta open source popular que tiene una configuración por defecto,
que resulta que intenta conectarse a un S3 random y resulta que es el tuyo, ¿te imaginas?
Es que te destroza la vida, te destroza la vida, ¿eh?
Bueno, y te dice, S3 te cobra por las request 400.
Es que esto es muy grave, tío, esto es muy grave, imagínate.
O sea, alguien puede ponerse ahí a intentar constantemente a tener acceso que no lo va a tener.
Tú haces esto, imagínate que tienes aquí el nombre del bucket sin necesidad de sabértelo aquí, ¿vale?
Tú haces esto, te sabes el nombre del bucket, el que sea, de hecho lo puedes intentar ahora, porque tampoco hay tantos.
Los nombres de los buckets son únicos.
Entonces, imagínate que alguien se llama JavaScript.
Pues esto, tú te pones a hacer esto constantemente ahí hasta el infinito y ya le vas a estar cobrando a alguien, le vas a estar haciendo dinero a otra gente.
Es que no sé, no sé qué está pasando últimamente con tema cloud, pero telita, ¿eh?
Lección 1, no puedes proteger, el problema además, dice, no puedes proteger tu bucket con servicios como CloudFront o WAF cuando es accedido directamente con la API de S3.
Claro, esto tiene sentido.
CloudFront lo puedes poner para cuando la gente lo consume, pero si estás utilizando la API de S3 y alguien ve el nombre de tu bucket, pues ya está jodido.
Ya está jodido porque lo van a poder ver.
Luego pensad también que lo pueden adivinar, o sea, alguien se puede poner a intentar hacer esto, adivinarlo y ya está, ¿sabes?
Ahora, lo que dice es, pues, que puedes ponerte a añadir sufijos random al final del nombre del bucket para evitar esto.
Pero bueno, esto al final te la pueden liar también.
No sé, qué curioso, pero bueno, solo para que tengáis en cuenta, para que tengáis cuidado de que no hagáis público tampoco el nombre de vuestro bucket de S3,
porque ya veis que es algo bastante peligroso, o sea, es una cosa bastante rara, ¿eh?
Y límites de consumo-gasto con corte automático.
Claro, esto, lo que dice Romano, sí que podéis hacer esto, podéis poner un límite de consumo y gasto, pero hay un problema con esto.
El problema es que, vale, conseguís que no os cobren la factura, ¿vale?
Pero paráis el servicio, lo cual no es una solución, porque sí, haces que de repente te corte esto,
pero imagínate que haces esto y tienes un e-commerce y empiezas a perder pedidos porque has hecho esto.
Es que, claro, sí, es una solución para que no haya una sangría de dinero,
pero el problema es que también es un problema de que te cortas el servicio y punto, ¿no?
Mi empresa tiene buckets públicos para temas de plantilla de correos e imágenes.
¿Qué solución podemos aplicar para que no nos pase algo así?
Pues eso, si son los buckets, son públicos, utilizar un servicio por delante como CloudFront para que al menos lo podáis consumir a partir de ahí.
Y ya está, ¿no?
Pon Rate Limiter.
El bucket no puede tener Rate Limit.
Lo puedes poner en CloudFront, lo puedes poner en cosas así, pero no el acceso a través de la API.
Claro, si restringes el acceso a la API, sí, ¿no?
Aquí tenéis cómo lo explican.
Requester Page.
Si falla la autentificación, si la petición es anónima, aquí paga.
Es que no tiene mucho sentido, ¿eh?
La verdad no tiene mucho sentido.
Tiene unas cosas a veces el tema de la nube, ¿no?
Pero es algo que AWS debería mejorar, ¿no?
Totalmente.
Yo creo que sí.
Yo creo que en este caso debería mejorar.
Debería mejorarlo AWS.
No tiene sentido.
En algunas apps es esencial que el bucket sea público.
Por ejemplo, Reddit, todos sus recursos como vídeos, imágenes, tienen URLs con su bucket.
Ya, pero es que las URLs con su bucket, o sea, la URL con su bucket, es que eso no tiene mucho sentido.
Porque tienes razón lo que dices, Wizzatec, ¿no?
Que no es que sea esencial.
Porque tú al final podrías subir el archivo a través de backend y el backend devolverte directamente la URL de CloudFront.
Lo que pasa, y la razón por la que no se hace, Wizzatec, es porque CloudFront cuesta dinero.
CloudFront también cuesta dinero y a lo mejor pues no te compensa tampoco tener un CDN de esas características y más con lo que te puede costar esto, ¿no?
Yo me imagino que van por aquí un poco las cosas por las que no utilizan CloudFront.
Pero sí que lo podrías hacer, ¿no?
¿Qué miedo los servicios?
Puede llegar a costar más el collar que el perro.
Sí, sí, no.
Hay veces que estas cosas, uno se va al cloud y dice, venga, locura.
Te viene la factura ahí de 1.500 dólares de repente y madre mía.
Creo que aquí es donde se demuestra si puedes fiarte un poco de ese cloud o no.
Porque este tipo de detalles, con CloudFront no pasa eso, pero pueden pasar otras cosas.
CloudFront tiene este artículo que dice, ¿por qué utilizar CloudFront R2 o Amazon S3, no?
Y sí, hacían una comparativa aquí que está bastante bien.
Y bueno, cada uno tiene sus cosas.
Cada uno tiene sus cosas.
Pero es verdad que cuando hablamos de transferencia de datos, lo mejor es que R2 es ilimitada y S3 son 100 GB.
Esto es un rollo.
Pero luego sí que tiene algunas cositas.
A ver, no sé, ¿había alguna cosa?
No sé, ¿habían alguna que a la larga te podía salir a cuenta S3?
O sea, dependía un poco del caso de uso que había que te podía salir a cuenta S3.
No sé si en CloudFront.
Yo creo que en CloudFront no pasa este problema de que con errores te lo cobran también.
Dice, además que son con puts, no con gets.
Ahí el CDN y CloudFront no tienen mucho sentido.
Claro, claro, es que es el put a la hora de intentar hacer una escritura.
¿Qué es ese problema?
Es que lo tenéis aquí, es este.
Mira, veis aquí que pone class A operations.
Class A operations significa subir el archivo.
Class B significa leer el archivo.
Claro, leer el archivo es más barato.
Por eso subir el archivo suele ser más caro.
¿Cuál es el problema?
El problema es que tú sueles subir pocos archivos o subes muchos, pero no los haces constantemente.
Este es el problema porque aquí, aquí es donde está el problema.
Es que por cada mil pagas 0,005 de post.
Y claro, esto te destruye.
Esto te destruye muy fuerte.
Si al final el post es cualquier cosa.
No sé cómo pasará en CloudFront.
Me gustaría entenderlo.
Me gustaría saber si lo hacen o no lo hacen.
Aquí es que dice que estas son las operaciones, list buckets y tal, pero no deja claro si también los errores los cuenta.
No lo deja claro.
Tengo dudas.
Me gustaría saber.
Quiero pensar que no, porque no tendría mucho sentido.
Lo que sí que pone es que no te cobran nada de ancho de banda.
Que esto la verdad es que es un ahorro bastante importante.
¿Me do def y Cloudinary?
Cloudinary es diferente porque Cloudinary está interesante, pero Cloudinary es para imágenes.
Entonces, Cloudinary, si vas a transformar las imágenes, te puedes salir a cuenta.
Si no vas a transformar las imágenes, lo que te vas a ir más a cuenta es R2, porque es mucho, mucho, mucho más barato.
Mucho más barato.
O sea, no hay ningún tipo de duda que es mucho más barato.