How to save money in Amazon Web Services - choosing an efficient architecture
Hello!
Today we will talk about how to “save money” professionally when using Amazon Web Services cloud services when hosting web solutions adapted for Russia. We actively use the services of this cloud provider for the company's projects for almost 2 years and are constantly engaged in cost optimization. Oddly enough, the important topic of optimizing spending on Amazon Web Services, cleared from the marketing bullshit, is somehow not particularly represented on the web. I will try to share the experience and identify the obvious benefits and errors that should be considered when designing web systems.
')
In the US (Virginia, Oregon) the cost of hourly rental of virtual machines is much cheaper than, for example, in Europe and other AWS regions.
But these are flowers. Berries - if you take virtualki wholesale for a year ahead - then you will pay almost 50% less for virtuals in Europe and 60% less in the US (we use standard virtual machines: m1 *, m2 *, c *). If you take the car for 3 years ahead - saving even more.
In addition, Amazon launches new useful technologies in production, usually in the US first. For example, disks with a guaranteed IOPS number that was set during creation - I installed at least 1500 IOPS on 4 disks in raid 10 and forgot about MySQL performance :-) Also, cloud memcached and SMS notifications from the cloud first appeared in American Amazon data centers.
That is, if you want to be ahead of the rest of the planet and pay less for services, run in data centers in the United States.
However, there are downsides to placing in the US for Russian projects. One of them is latency at 150 ms - but if you transfer static resources to Amazon's CDN or a domestic CDN , then the delay is almost imperceptible, since The client receives statics from the servers closest to the browser with minimal latency (units, maximum tens of ms). Secondly, data centers in the US, especially the largest in Virginia, are falling, to put it mildly, more often than the nearest European one to us in Ireland. Apparently in the US thunderstorms happen more often :-)
In general, if you want new efficient technologies in the cloud, cheaper, you are ready to configure the CDN to return statics and the application is placed in at least 2 local data centers of the Amazon region for switching traffic from one DC to another imperceptible for a client when lightning strikes or another object - you can safely Choose the United States and post your web solution there (this is not sarcasm, this is the minimum so that the client almost did not notice anything :-)).
Here is the most interesting. It turns out that if you carefully read about cloud blocks offered by Amazon, such as autoscaled groups of machines and load balancers , having drunk strong coffee, you can see that you can run parts of your web application on unused capacities of the cloud provider, which cost MULTIPLE less than nominal hourly - i.e. almost for nothing :-)
Those. if a:
then you are completely calm, without technical risks, you can set up 2 groups of autoscaling - the main and the “penny”. The “cheap” group will assume the load, with the cost of the machines, say 8 cents per hour (I am describing a real example from the production) - and in the case of rare cases of Spot Instances price increase - the main group of machines will automatically take over. In any case, you will save on the hourly cost - several times.
Here is a specific example:
The cost of the virtual c1.xlarge retail in the us-east-1 region: $ 0.58.
The cost of the same virtual machine rented as Spot Instance on the exchange of unused resources rarely rises above $ 0.08
Those. if you have a cluster of 15 c1.xlarge - make 2 clusters, one with “cheap” cars of size 13, and one of the standard machines for $ 0.58 the size of 2 machines. In case of a possible increase in the price of Spot Instances above the nominal one every several months, you automatically scale the standard cluster.
However, I note that such large savings can be achieved, unfortunately, only in the American regions of the Amazon - in Europe, Spot Instances are not so cheap, but also significantly cheaper than the usual ones ($ 0.17 instead of $ 0.08 in this example).
And it is important to understand, of course, the limitation of Spot Instances - their price fluctuates and can rise even higher than the retail hourly (here, according to our observations, is extremely rare) - in this case, the Spot Instances cluster starts to put out the cars (of course, you can’t keep mysql on machines, you are welcome). Your web application should be able to handle this case and automatically expand the cluster of regular machines. We solved this task by connecting the CPU usage test in CloudWatch with auto-scaled groups - it works out of the box without a headache.
These are not all ways to “save professionally” in AmazonWebServices. In the following articles I will talk about other, equally effective ways - for example, copying the bake s3 into the bake s3 without burning traffic, etc.
In the article, I tried to objectively substantiate the pros and cons, the risks of using American regions of Amazon for Russian web projects, and showed by example that by laying a scalable cluster architecture of a web solution, you can save a lot on renting virtualos.
I wish you all good luck, more good ideas and effective architectural solutions, and I invite everyone on April 4 to the conference dedicated to the resiliency of web applications in conventional hosting and in the clouds!
Today we will talk about how to “save money” professionally when using Amazon Web Services cloud services when hosting web solutions adapted for Russia. We actively use the services of this cloud provider for the company's projects for almost 2 years and are constantly engaged in cost optimization. Oddly enough, the important topic of optimizing spending on Amazon Web Services, cleared from the marketing bullshit, is somehow not particularly represented on the web. I will try to share the experience and identify the obvious benefits and errors that should be considered when designing web systems.
Where to run the application?
')
In the US (Virginia, Oregon) the cost of hourly rental of virtual machines is much cheaper than, for example, in Europe and other AWS regions.
But these are flowers. Berries - if you take virtualki wholesale for a year ahead - then you will pay almost 50% less for virtuals in Europe and 60% less in the US (we use standard virtual machines: m1 *, m2 *, c *). If you take the car for 3 years ahead - saving even more.
In addition, Amazon launches new useful technologies in production, usually in the US first. For example, disks with a guaranteed IOPS number that was set during creation - I installed at least 1500 IOPS on 4 disks in raid 10 and forgot about MySQL performance :-) Also, cloud memcached and SMS notifications from the cloud first appeared in American Amazon data centers.
That is, if you want to be ahead of the rest of the planet and pay less for services, run in data centers in the United States.
However, there are downsides to placing in the US for Russian projects. One of them is latency at 150 ms - but if you transfer static resources to Amazon's CDN or a domestic CDN , then the delay is almost imperceptible, since The client receives statics from the servers closest to the browser with minimal latency (units, maximum tens of ms). Secondly, data centers in the US, especially the largest in Virginia, are falling, to put it mildly, more often than the nearest European one to us in Ireland. Apparently in the US thunderstorms happen more often :-)
In general, if you want new efficient technologies in the cloud, cheaper, you are ready to configure the CDN to return statics and the application is placed in at least 2 local data centers of the Amazon region for switching traffic from one DC to another imperceptible for a client when lightning strikes or another object - you can safely Choose the United States and post your web solution there (this is not sarcasm, this is the minimum so that the client almost did not notice anything :-)).
Savings due to the features of the web solution architecture
Here is the most interesting. It turns out that if you carefully read about cloud blocks offered by Amazon, such as autoscaled groups of machines and load balancers , having drunk strong coffee, you can see that you can run parts of your web application on unused capacities of the cloud provider, which cost MULTIPLE less than nominal hourly - i.e. almost for nothing :-)
Those. if a:
- Your application does not store files on the virtual disk, but keeps the data in the database and / or memory
- The virtual image is launched by the controller of an automatically scalable group - for example, depending on the load (we have exactly that)
- Clients go to the cluster of machines through the cloud balancer
then you are completely calm, without technical risks, you can set up 2 groups of autoscaling - the main and the “penny”. The “cheap” group will assume the load, with the cost of the machines, say 8 cents per hour (I am describing a real example from the production) - and in the case of rare cases of Spot Instances price increase - the main group of machines will automatically take over. In any case, you will save on the hourly cost - several times.
Here is a specific example:
The cost of the virtual c1.xlarge retail in the us-east-1 region: $ 0.58.
The cost of the same virtual machine rented as Spot Instance on the exchange of unused resources rarely rises above $ 0.08
Those. if you have a cluster of 15 c1.xlarge - make 2 clusters, one with “cheap” cars of size 13, and one of the standard machines for $ 0.58 the size of 2 machines. In case of a possible increase in the price of Spot Instances above the nominal one every several months, you automatically scale the standard cluster.
However, I note that such large savings can be achieved, unfortunately, only in the American regions of the Amazon - in Europe, Spot Instances are not so cheap, but also significantly cheaper than the usual ones ($ 0.17 instead of $ 0.08 in this example).
And it is important to understand, of course, the limitation of Spot Instances - their price fluctuates and can rise even higher than the retail hourly (here, according to our observations, is extremely rare) - in this case, the Spot Instances cluster starts to put out the cars (of course, you can’t keep mysql on machines, you are welcome). Your web application should be able to handle this case and automatically expand the cluster of regular machines. We solved this task by connecting the CPU usage test in CloudWatch with auto-scaled groups - it works out of the box without a headache.
Results
These are not all ways to “save professionally” in AmazonWebServices. In the following articles I will talk about other, equally effective ways - for example, copying the bake s3 into the bake s3 without burning traffic, etc.
In the article, I tried to objectively substantiate the pros and cons, the risks of using American regions of Amazon for Russian web projects, and showed by example that by laying a scalable cluster architecture of a web solution, you can save a lot on renting virtualos.
I wish you all good luck, more good ideas and effective architectural solutions, and I invite everyone on April 4 to the conference dedicated to the resiliency of web applications in conventional hosting and in the clouds!
Source: https://habr.com/ru/post/174181/
All Articles