Home Law in IT Banhammer on Amazon. Explanation of blocking entire subnets in plain and simple language (for dummies™)

Banhammer on Amazon. Explanation of blocking entire subnets in plain and simple language (for dummies™)

by admin

This tutorial provides extremely simple and straightforward answers to the following questions :

  1. Why doesn’t Amazon cooperate with Roskomnadzor?
  2. How much does it cost to permanently migrate Telegram servers to other IP addresses inside the cloud?
  3. Why is it impossible to ban Amazon-hosted services with specific IPs rather than subnets at once?

And we’ll probably start with a picture like this :
Banhammer on Amazon. Explanation of blocking entire subnets in plain and simple language (for dummies™)
When you run your service on Amazon, it usually goes like this :
(a) You set up some kind of virtual machine,
b) you install your service on it,
c) check that everything works, and then
d) turn it into AMI – a complete mold, an image of your service together with the operating system and everything else you have there.
It is saved in the cloud, and then if necessary very easily and simply (and most importantly, automatically) replicated at any reasonable scale with the same automatic fine-tuning. In the screenshot you can see the interface where you set up some extra settings to run multiple instances of the pre-configured footprint.
The option "Automatically assign external IP addresses for each instance" is marked with an arrow.
So there you go. When you run your service on a large scale, you can tell Amazon to spin up another instance of your service at a certain load on the virtual machine’s CPU. Or, for example, a hundred of them at once. Or not with the load on the processor, but, say, with a couple hundred simultaneously active network connections. Such metrics for automatic scaling a lot, and the rules for autoscaling can be configured quite flexibly too.
Now let’s look at a graph like this :
Banhammer on Amazon. Explanation of blocking entire subnets in plain and simple language (for dummies™)
This is the approximated number of simultaneously active users of worldwide Internet services during working hours. Almost no one lives in the Pacific Ocean, China has its own Internet, and the largest number of users is in Europe, and – especially – the western United States. This is true of almost any service with worldwide reach, be it Steam, Netflix, Wikipedia, or Telegram.
As we can see, the difference between the highs and lows is one and a half times. Literally, this means that if you’re working for the whole world, you need about half the day while it’s daytime in the Western Hemisphere, you need almost twice as much capacity as the other half of the day when it’s daytime in Asia. So you set up the appropriate auto-scaling rules to avoid wasting CPU time (and your money – in the clouds, like nowhere else, time=money) for nothing when you don’t need it.
And half of your service instances are simply killed by the cloud itself on schedule when America goes to bed. And the next day, when the load grows, it will helpfully bring them up again.
Now to answer question 3). The arrow in the screenshot is drawn for a reason. The option "Automatically assign external IP addresses for each instance" takes addresses from the available address pool – Amazon owns several million addresses, and rents some more from other owners. Public IPv4-addresses are scarce these days, so it’s a luxury and expensive to have one for each virtual instance (moreover, in any Amazon data center they only give you 5 permanent addresses, and increase that limit with a great deal of fiddling).
And as soon as an instance is killed, the address immediately goes back into the shared pool. And so on. Who will get it next time? Whoever. Maybe to you, maybe to another customer who also automatically scales his service, or maybe to an ephemeral instance of Amazon’s own service. Thus, the answer to question 3) is trivial: because it’s your IP today, and somebody else’s in a couple of hours. If your service is unwanted by somebody else, but automatically scales up, then you can ban it by IP, but only if you ban the whole pool.
And the answer to question 2) is also trivial: not at all. The cloud itself will assign to the next instance some other address from the pool available to it, whether you want it to or not.
Now about the first question.
The answer is not so obvious, but let’s try to make what is called an educated guess (I don’t know how to say it in Russian, "a guess based on experience, " perhaps?).
Amazon is the oldest of the big clouds. The software wrapper that handles all this automatic scaling was written about ten years ago, and it’s been running like clockwork ever since. Amazon’s giant service itself runs in exactly the same cloud. This wrapper is not broken, it doesn’t need to be fixed, and any changes that people write run the risk of introducing bugs. So the customer address pool isolation feature, if you start developing it now, is going to take a hell of a lot of time, and if it suddenly leads to big changes, the cost of the possible consequences will be in the billions of dollars. In the truest sense.
And the answer to 1) sounds like this : It’s simply not profitable for Amazon to redesign its infrastructure to meet the requirements of a crazy government oversight body, all customers from which don’t bring in enough money to compensate for the possible risk to itself and customers from other countries. Sounds tough, but that’s unfortunately business.
By the way, it’s exactly the same with the other clouds. YouTube was banned because Google’s own services are not separated from those of Google’s clients, and work in the same cloud space with a single pool of addresses. And it’s the same with Microsoft services.
Roskomnadzor, by blocking cloud services, is at war with the technology on which clouds are built. With scripts. With algorithms. It’s like fighting against the laws of physics, or trying to kick the elements : extremely stupid and pointless. You can’t beat the clouds and wind, you can only go underground never to see them…

You may also like