How to Save Money at Amazon Web Services - Choosing an Effective Architecture

    Hello!

    Today we’ll talk about how to “professionally save” money when using Amazon Web Services cloud hosting services when hosting web solutions adapted for Russia. We have been actively using the services of this cloud provider for company projects for almost 2 years and are constantly engaged in cost optimization. Strangely enough, the important topic of cost optimization on Amazon Web Services, cleared of marketing bullet, is somehow not particularly represented on the network. I will try to substantively share my experience and outline the obvious benefits and errors that should be taken into account when designing web systems.


    Where to run the application?



    In the USA (Virginia, Oregon), the cost of an hourly rental of virtual machines is significantly cheaper than, for example, in Europe and other AWS regions.
    But these are still flowers. Berries - if you take virtual machines in bulk a year in advance - then for virtual computers in Europe you will pay almost 50% less, and in the USA - 60% less (we use standard virtual machines: m1 *, m2 *, c *). If you take the car for 3 years in advance - saving even more.



    In addition, Amazon launches new useful technologies in production, usually first in the USA. For example, disks with a guaranteed and set IOPS number when creating - put a minimum of 1500 IOPS on 4 disks in raid 10 and forgot about MySQL performance :-) Also, cloud memcached andSMS notifications from the cloud first appeared in Amazon's US data centers.

    That is, if you want to be ahead of the rest and pay less for services, start up in data centers in the USA.

    However, there are also disadvantages of placing in the USA for Russian projects. One of them is a latency of 150 ms - but if static resources are transferred to Amazon’s CDN or domestic CDN , the delay is almost invisible, because the client receives statics from the servers closest to the browser with the minimum latency (units, maximum tens of ms). Secondly, data centers in the USA, especially the largest in Virginia, are falling, to put it mildly, more often than the European closest to us in Ireland. Apparently in the USA, thunderstorms occur more often :-)

    In general, if you want new effective technologies in the cloud, cheaper, you are ready to set up a CDN for static output and the application is located in at least 2 local data centers of the Amazon region to seamlessly switch traffic from one data center to another when a lightning bolt or another object hits - you can safely choose the USA and place your web solution there (this is not sarcasm, this is the minimum so that the client does not notice almost anything :-)).

    Savings through web architecture features



    Here is the fun part. It turns out that if you carefully read about the cloud bricks offered by Amazon, such as auto-scaling groups of machines and load balancers , drinking strong coffee, you can see that you can run parts of your web application at the unused capacity of the cloud provider, the cost of which is several times lower than the nominal hourly - i.e. almost for nothing :-)
    i.e. if:
    1. Your application does not store files on the virtual disk, but stores data in a database and / or memory
    2. The image of the virtual machine is launched by the controller of the automatically scalable group - for example, depending on the load (this is exactly what we have)
    3. Clients go to a cluster of cars through a cloud balancer


    then you can absolutely calmly, without technical risks, set up 2 auto-scaling groups - the main and the “cheap” ones. The load will be borne by a “cheap” group, with the cost of cars, let's say 8 cents per hour (I describe a real example from production) - and in rare cases of increasing the price of Spot Instances, the main group of machines will automatically take over the load. In any case, you will save on hourly cost - several times.

    Here is a specific example:




    The cost of c1.xlarge virtual retail in the us-east-1 region: $ 0.58.
    The cost of the same virtual machine rented as Spot Instance on the stock 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 in size of 2 cars. In the event of a possible monthly increase in prices for Spot Instances above the nominal one, you automatically scale the standard cluster.

    However, I note that such a big savings can be achieved, unfortunately, only in the American regions of Amazon - in Europe, Spot Instances are not so cheap, but also significantly cheaper than ordinary ones ($ 0.17 instead of $ 0.08 in this example).

    And it’s important to understand, of course, the restriction of Spot Instances - their price fluctuates and can rise even higher than the retail hourly (here, according to our observations, it is extremely rare) - in this case, the Spot Instances cluster begins to turn off the machines (of course, mysql cannot be kept on machines, and Apaches you are welcome). Your web application should be able to process this case and automatically expand the cluster of conventional machines. We solved this problem by connecting the CPU usage test in CloudWatch with autoscale groups - it works out of the box without a headache.

    Summary



    These are not all ways to “save money professionally” in AmazonWebServices. In the following articles I’ll talk about other equally effective methods - for example, copying the s3 bucket to the s3 bucket without burning traffic, etc.

    In the article I tried to objectively justify the pros and cons, the risks of using Amazon American regions for Russian web projects, and showed by example that laying a scalable cluster architecture of a web solution - you can save several times on the rental of virtualok capacities.
    I wish everyone good luck, more good ideas and effective architectural solutions and invite everyone to the conference on April 4 , dedicated to the fault tolerance of web applications in both shared hosting and clouds!

    Also popular now: