Sou muito novo em infraestruturas de plataforma em nuvem. Para simplificar a discussão, digamos que as duas únicas plataformas que estou discutindo sejam AWS e Google Cloud.
Agora digamos que eu tenha um servidor HTTP que lida principalmente com respostas HTTP por meio de uma API aberta para um jogo online. Digamos que o tamanho médio da resposta seja 10 KB e que cerca de um milhão de respostas sejam enviadas por dia.
Pelo que entendi, o preço mensal depende da quantidade de dados transferidos em termos de GB. Agora, meu problema é que, se alguém escrever um script que continue recebendo respostas do meu servidor repetidamente, o preço aumentará muito.
Tenho certeza de que qualquer bom servidor evita esse problema, mas não tenho certeza de como exatamente esse problema é evitado. Com base na minha observação, muitos grandes servidores de API de jogos on-line da vida real não otimizam o tamanho da resposta quando são apenas alguns KBs. Deve haver algum tipo de "pagamento mensal fixo ou pagamento baseado na quantidade de dados transferidos por segundo"acontece algo que não depende da quantidade de dados transferidos.
No entanto, simplesmente não consegui encontrar nenhuma referência nos sites da plataforma para essas opções.
Qualquer ajuda seria apreciada.
Responder1
Os serviços em nuvem oferecem benefícios incríveis para projetos, que são especialmente desenvolvidos para usá-los. Se falamos de hospedagem de aplicativos/web, então os modelos de precificação em nuvem são adequados para empresas, que obtêm sua principal receita dos usuários que utilizam o referido aplicativo/site.
A menos que essa seja sua principal fonte de renda (nesse caso, você deve converter facilmente entre tráfego bruto da web e lucros), então a hospedagem na nuvem pode não ser adequada para você.
Tenha em mente que se o seu aplicativo não foi construído para infraestrutura em nuvem (como o referido servidor de jogos), você não terá nenhum benefício em relação à hospedagem VPS/dedicada de instância única, a menos que você gaste algum tempo fazendo trabalho de devops. O mesmo trabalho de devops é necessário para prevenir eficazmente ataques à sua largura de banda que você descreveu.
Como esse tipo de ataque já tem nome, você pode encontrar alguns conselhos mais ou menos viáveis pesquisando por "Negação de carteira"
Responder2
Nenhum fornecedor de nuvem oferece largura de banda XX a um preço fixo. O preço é baseado no consumo.
Você é responsável por controlar o acesso do cliente aos seus recursos.
Isso significa implantar autenticação, limitação ou outras tecnologias, mas você escolhe como e com quais produtos.
Os serviços em nuvem são como construir uma casa. A Home Depot não oferece pregos e madeira ilimitados. Você compra o que precisa para construir sua casa. Você então compra combustível para aquecer sua casa.
Trabalho na nuvem desde o dia zero. Antes disso, data centers privados. Sua preocupação é possível, mas no mundo real isso não acontece o suficiente para impedir a maioria de nós de implantar na nuvem. Para consumir sua largura de banda, preciso consumir minha largura de banda de rede disponível. Se um hacker quiser derrubá-lo, existem muitos métodos mais dolorosos que ele pode implantar, que são muito mais baratos para ele e que são mais difíceis de rastrear quem/onde estão localizados.
Responder3
Do lado do servidor, as formas de evitar isso são:
- Exigir autenticação para solicitações. IOW, faça com que você possa rastrearQuemestá fazendo tais ataques e torna tais ataques uma ofensa banível. Em seguida, bloqueie adequadamente a criação de sua conta para que não seja fácil obter novas credenciais após ser banido.
- Implementar limitação de taxa. Geralmente isso é feito em vários estágios, muitas vezes limitando a taxa por conta autenticada (para que qualquer usuário tenha um limite de taxa), por endpoint da API (para que endpoints computacionalmente caros que não são chamados com muita frequência não possam ser facilmente abusados por ataques DoS ) e possivelmente geral por IP. Você deveria fazer isso por outros motivos (principalmente proteção contra ataques DoS inteligentes e a possibilidade de ataques baseados em tempo na lógica do jogo).
- Utilize uma boa compactação no protocolo. Para o tamanho de resposta declarado, provavelmente vale a pena dar uma olhada em Brotli (ou possivelmente ágil ou LZ4), ele deve ser rápido o suficiente para atender às suas necessidades de desempenho, mas ainda assim reduzir alguns kB do tamanho da resposta e chegar ao ponto de lidar com milhões de solicitações por mês, essa é uma quantidade nada trivial de dados salvos.
No que diz respeito a mitigá-lo em outros lugares, isso não é tão fácil de fazer. Provedores de nuvem completos, como o que você está falando, geralmente fornecem algum 'nível gratuito' mínimo para permitir que os desenvolvedores experimentem facilmente sem custar um braço e uma perna. Acho que para a AWS são 5 GB de saída por mês (eles não cobram nada pelos dados de entrada), por exemplo. Isso é o mais próximo que você pode chegar em uma configuração de nuvem completa para bloquear o uso do qual você está falando, porque a maioria dos usuários se beneficiará de terexatouso rateado em vez de comprar em 'pedaços'.
Se você realmente quer uma grande fatia, dê uma olhada no AWS Lightsail. Lá, você compra um pacote de um nó virtual que inclui um número fixo de CPUs, uma quantidade fixa de RAM e armazenamento integrado e um limite de uso de rede especificado. O uso da rede abaixo desse limite em um ciclo de faturamento não custa nada, enquanto o acima é rateado como em uma configuração completa de nuvem. Não sei se o GCP tem um equivalente, mas a maioria dos provedores de VPS (como Vultr, Linode ou Digital Ocean) funcionam da mesma maneira para suas ofertas primárias e eu sugeriria procurar lá se você seguir esse caminho. Os limites de rede geralmente estão na faixa de vários terabytes, e a norma é que apenas a direção com maior uso seja rastreada para contabilização.