AWS auto scaling for Magento
In case you already have a big e-store or you are expecting explosive growth AWS auto scaling allows be sure in stable works. Briefly, central income point named Load balancer, accept connections and pass to auto scaling group. This group has two or more instances which automatically launching if needs from specially preconfigured AMI. Instances from auto scaling can be not big but we would like to recommend use a middle size instance starting from the c4.large minimum. The Magento need strong CPU. So, when traffic will grow suddenly instances will load highly or start generated 502 or 504 error code, AWS CloudWatch will monitoring it and based on results of monitoring Auto Scaling group could receive the signal increase or decrease number of instances. The monitoring values needs fine-tune for each of Magento e-store installation. It is the first part of the setup.
Auto Scaling Group and NFS
Instances from Auto Scaling Group should have actual and updated file, images, styles and etc… It is easy to organize by NFS server or AWS Elastic File System. Let suppose that we use an additional Amazon instance as NFS server because EFS available only for EU (Ireland), US East (N. Virginia), US East (Ohio), US West (Oregon) regions on December 2016. This NFS server will have an EBS volume which uses by serves to store site’s files and uses for NFS server. Instances from Auto Scaling has access to our NFS server using the NFS client. In this manner, we have one place to save our files which will available for a number of instances from Auto Scaling Group.
Let us do not forget about MySQL. We recommend using a big instance or MySQL cluster with three instances minimum. MySQL Master/Slave scheme does not work well and does not have a significant performance than one big MySQL instance but could give a lot of headaches. For example. A client put goods to cart and goes to checkout but does not see these goods. What happens? MySQL master saved this information and did not synchronize it to MySQL Slave yet but client’s request was read information about his cart from Slave and see the empty cart because MySQL slave does not have actual information. It is no so often case but we had met it several times.
The cache solution.
We love Redis. It supported natively by Magento 2.x and by a plug-in for Magento 1.9.x. The Redis allows store full pages and user’s sessions. An instance for Redis should have memory depending on the cache you desired and strong CPU for a big cache. If your e-store is huge will be a good idea build Redis cluster.
Why does not we like a cache and database AWS solution? We have the easy reason. These service does not offer console access and all optimizations and fine-tune needs additional actions which waste our time. But we love AWS Elastic File System. EFS spreads across regions and offers you space as much as you need. You should do nothing to increase or decrease size space and you will pay only for taken disk space.
NFS server as well could be used as Magento administrative instance but it will better if these instances will be independent. An administrative instance allows to have a big time-outs value and if the instance will be overloaded it will not affect front-end of e-store. Also, this instance could create file backup weekly and save MySQL dump daily or often and synchronize these backups to AWS S3.
Avoid hitting into spam
To send emails you might use AWS SNS, Mailjet or service like this.
Preconfigured AMI always set to upgrade important server software automatically, but needs upgrade manually and actualize the AWS Auto Scaling template from time to time.