Soy bastante nuevo en las infraestructuras de plataformas en la nube. Para simplificar la discusión, digamos que las únicas dos plataformas que estoy analizando son AWS y Google Cloud.
Ahora digamos que tengo un servidor HTTP que maneja principalmente la respuesta HTTP a través de una API abierta para un juego en línea. Digamos que el tamaño promedio de respuesta es de 10 KB y se enviarán alrededor de un millón de respuestas por día.
Según tengo entendido, el precio mensual depende de la cantidad de datos transferidos en términos de GB. Ahora mi problema es que si alguien escribe un script que sigue recibiendo respuesta de mi servidor repetidamente, el precio aumentará hasta las nubes.
Estoy seguro de que cualquier buen servidor evita este problema, pero no estoy seguro de cómo se evita exactamente. Según mi observación, muchos servidores API de juegos en línea grandes de la vida real no optimizan el tamaño de su respuesta cuando son solo unos pocos KB. Debe haber algún tipo de "pago mensual fijo o pago basado en la cantidad de datos transferidos por segundo"Sucede algo que no depende de la cantidad de datos transferidos.
Sin embargo, simplemente no pude encontrar ninguna referencia en los sitios web de la plataforma sobre tales opciones.
Cualquier ayuda sería apreciada.
Respuesta1
Los servicios en la nube brindan increíbles beneficios para los proyectos, que están especialmente diseñados para usarlos. Si hablamos de alojamiento de aplicaciones/web, los modelos de precios en la nube se adaptan a las empresas, que obtienen sus principales ingresos de los usuarios que utilizan dicha aplicación/sitio web.
A menos que esa sea su principal fuente de ingresos (en cuyo caso debería convertir fácilmente entre tráfico web bruto y ganancias), es posible que el alojamiento en la nube no le convenga en absoluto.
Tenga en cuenta que si su aplicación no se creó para la infraestructura de la nube (como dicho servidor de juegos), no tendrá ningún beneficio sobre el VPS/alojamiento dedicado de instancia única, a menos que haya dedicado cierta cantidad de tiempo al trabajo de Devops. Se necesita el mismo trabajo de Devops para prevenir eficazmente el ataque a su ancho de banda que describió.
Dado que ese tipo de ataque ya tiene un nombre, puedes encontrar algunos consejos más o menos viables buscando "Denegación de billetera"
Respuesta2
Ninguno de los proveedores de la nube ofrece ancho de banda XX a un precio fijo. El precio se basa en el consumo.
Usted es responsable de controlar el acceso de los clientes a sus recursos.
Esto significa implementar autenticación o limitación u otras tecnologías, pero usted elige cómo y con qué productos.
Los servicios en la nube son muy parecidos a construir una casa. Home Depot no le ofrece clavos y madera ilimitados. Compras lo que necesitas para construir tu casa. Luego compra combustible para calentar su casa.
Llevo trabajando en la nube desde el día cero. Antes de eso, centros de datos privados. Su preocupación es posible, pero en el mundo real, no sucede lo suficiente como para impedir que la mayoría de nosotros implementemos en la nube. Para consumir su ancho de banda, necesito consumir el ancho de banda de mi red disponible. Si un hacker quiere acabar con usted, hay muchos métodos más dolorosos que puede implementar, que son mucho más baratos para ellos y que son más difíciles de rastrear quién y dónde se encuentran.
Respuesta3
Del lado del servidor, las formas de evitar esto son:
- Requerir autenticación para solicitudes. OIA, hazlo de tal manera que puedas rastrearOMSestá cometiendo tales ataques y convertirlos en un delito prohibible. Luego, bloquee adecuadamente la creación de su cuenta para que no sea fácil obtener nuevas credenciales después de ser baneado.
- Implementar limitación de velocidad. Por lo general, esto se hace en múltiples etapas, a menudo limitando la velocidad por cuenta autenticada (por lo que cualquier usuario tiene un límite de velocidad), por punto final API (por lo que no se puede abusar fácilmente de los puntos finales computacionalmente costosos que no reciben llamadas con mucha frecuencia para ataques DoS). ), y posiblemente en general por IP. Deberías hacer esto por otras razones (en particular, para protegerte contra ataques DoS inteligentes y la posibilidad de ataques basados en el tiempo en la lógica del juego).
- Utilice una buena compresión en el protocolo. Para el tamaño de respuesta indicado, probablemente valga la pena considerar Brotli (o posiblemente ágil o LZ4), debería ser lo suficientemente rápido para satisfacer sus necesidades de rendimiento, pero aún así reducir algunos kB del tamaño de respuesta y estar al punto de tratar con millones. de solicitudes por mes, esa es una cantidad nada trivial de datos guardados.
En cuanto a mitigarlo en otros lugares, no es tan fácil de hacer. Los proveedores de nube completa como el que usted menciona a menudo ofrecen un "nivel gratuito" mínimo para permitir a los desarrolladores experimentar fácilmente sin que les cueste un ojo de la cara. Creo que para AWS son 5 GB por mes salientes (no cobran nada por los datos entrantes), por ejemplo. Eso es lo más cerca que se puede llegar en una configuración de nube completa para bloquear el uso del que habla, porque la mayoría de los usuarios se beneficiarán al tenerexactoel uso se prorratea en lugar de comprar en "trozos".
Sin embargo, si realmente desea una gran parte, consulte AWS Lightsail. Allí, usted compra un paquete de un nodo virtual que incluye una cantidad fija de CPU, una cantidad fija de RAM y almacenamiento integrado, y un límite de uso de red específico. El uso de la red por debajo de ese límite en un ciclo de facturación no cuesta nada, mientras que el uso superior se prorratea como en una configuración de nube completa. No sé si GCP tiene un equivalente, pero la mayoría de los proveedores de VPS (como Vultr, Linode o Digital Ocean) funcionan de la misma manera para sus ofertas principales y, de hecho, sugeriría buscar allí si sigue esta ruta. Los límites de red en estos suelen estar en el rango de varios terabytes, y la norma es que solo se realiza un seguimiento para la contabilidad de la dirección que tiene un mayor uso.