How does network pricing work exactly in cloud platforms? And how should I avoid dedicated pricing attacks?

I am pretty new to cloud platform infrastructures. For the sake of discussion simplicity, let's say the only two platforms I am discussing are AWS and Google Cloud.

Now say I have an HTTP server that mainly handle HTTP response through an open API for an online game. Let's say the average response size is 10KB and there will be around a million responses being sent per day.

Based on my understanding the monthly price depends on the amount of data transferred in terms of GB. Now my problem is that if someone writes a script that keeps getting response from my server repeatedly the price will just grow to sky high.

I am sure any good server avoids this problem but I am not sure how exactly is this problem avoided. Based on my observation, many real life large online-game API servers do not optimize their response size when its just a few KBs. There must be some kind of "fixed monthly payment or payment based on the amount of data transferred per second" thing happening that does not depend on the amount of data transferred.

However I simply just couldn't find any reference on the platform websites for such options.

Any help would be appreciated.

On the server side, the ways to avoid this are:

• Require authentication for requests. IOW, make it such that you can track down who is making such attacks, and make such attacks a bannable offense. Then properly lock down your account creation so that it’s not easy to get new credentials after you get banned.
• Implement rate limiting. Usually this is done in multiple stages, often rate-limiting per authenticated account (so any user has a rate limit), per API endpoint (so computationally expensive endpoints that don’t get called very often can’t be easily abused for DoS attacks), and possibly overall per IP. You should be doing this for other reasons (most notably protecting against smart DoS attacks and the possibility of timing-based attacks on the game logic).
• Utilize good compression in the protocol. For your stated response size, Brotli is probably worth looking into (or possibly snappy or LZ4), it should be fast enough to meet your performance needs but still shave a few kB off of the response size, and at the point of dealing with millions of requests per month, that’s a nontrivial amount of data saved.

As far as mitigating it elsewhere, that’s not as easy to do. Full cloud providers like what you are talking about often provide some minimal ‘free tier’ to let developers easily experiment without costing an arm and a leg. I think for AWS it’s 5GB per month outbound (they don’t charge for inbound data at all) for example. That’s as close as you can get in such a full cloud setup to block usage as you are talking about, because most users will benefit from having exact usage prorated as opposed to buying in ‘chunks’.

If you really want a big chunk though, look into AWS Lightsail. There, you buy a package deal of a virtual node that includes some fixed number of CPUs, fixed amount of RAM and integrated storage, and a specified network usage cap. Network usage below that cap in a billing cycle costs nothing, while above is prorated just like in a full cloud setup. I do not know if GCP has an equivalent, but most VPS providers (such as Vultr, Linode, or Digital Ocean) work the same way for their primary offerings and I would actually suggest looking there instead if you go this route. The network caps on these are usually in the multi-terabyte range, and the norm is that only the direction that has higher usage gets tracked for accounting.

Neither cloud vendor offers XX bandwidth at a fixed price. Pricing is consumption based.

You are responsible for controlling client access to your resources.

This means deploying authentication or throttling or other technologies but you choose how and with what products.

Cloud services are much like building a house. Home Depot does not give you unlimited nails and lumber. You purchase what you need to build your house. You then purchase fuel to heat your home.

I have been working in the cloud since day zero. Before that private data centers. Your concern is possible, but in the real world, it does not happen enough to stop most of us from deploying in the cloud. In order to consume your bandwidth, I need to consume my available network bandwidth. If a hacker wants to take you down, there are many more painful methods they can deploy that are a lot cheaper for them and that are more difficult to track who/where they are located.