What aspects should I consider to divide the Magento processes as separate nodes on AWS? Currently there are two nodes running, one for backend and other for frontend. Is that enough or should I suggest the client to use a separate node for any process. BTW client is not worried about the charges, all he needs is, his site should run smoothly in peak hours.
The site is using Varnish, ERP and M2E's Ebay/Amazon modules. The site has two stores and around 25k products.

4 Answers 4


You could keep checkout on a separate node that might have better hardware, since rest of the front end part is more or less protected by Varnish and as such so you might just want to treat checkout differently in terms of the hardware you throw at it.

  • will consider your point
    – MTM
    Aug 25, 2014 at 4:52
  • you deserve an upvote :)
    – MTM
    Oct 13, 2014 at 8:29

The following setup on Amazon is optimal for what your requirements

1) Single instance on Ec2

2) Single RDS instance connected to Ec2 (Database)

As you scale I would highly recommend adding REDIS via ElasticCache

Varnish is a great win and I am assuming you are using a module.

You charges are going to be related to traffic, but your varnish should allow you to run a lower frontend server. You RDS instance could be .03-.07 cents an hour. (Depending on traffic!)


Identify the bottleneck and fix as necessary. No one here can guess your workload and any answer will be pure speculation.

The bottlenecks for Magento shift all over depending on the build, the type/nature of the product being sold, the marketing practice, the caching strategy, the traffic levels, the sales volume and the conversion rate. Whether you need multiple web heads, frontend or backend caches etc. will wholly vary based on your particular store.

More servers = more problems, especially for a VPS - where you cannot account for anything at all. You don't know how heavily loaded the hypervisor is on any machine, or how much network contention there might be between nodes, or available network bandwidth, or latency.

You'd be far better with a single large instance than two smaller ones. You'll have better load distribution and resource utilisation.

His site should run smoothly in peak hours

Then don't try to DIY. Your question makes it clear you don't have the experience setting up a server and when something is going wrong (and consequently costing your client hundreds/thousands/millions in lost revenue) - you'll have even less of an idea.

You don't want help setting up AWS, you want a proper, managed, Magento host. If you are determined to stick with "the Cloud", then consider someone like Tenzing or Engine Yard - they are both AWS resellers.

My $0.02, avoid AWS like the plague. The "Cloud" is fun for testing, but is unreliable, unsupported, invisible (in terms of diagnosis), expensive and slow.

  • On the contrary, it is entirely possible to run high traffic and volume Magento sites on AWS. And, there are lots of advantages to doing so.
    – Roscius
    Dec 11, 2014 at 18:15
  • 2
    I'm not sure I said it wouldn't be possible to run a large Magento store on AWS. I simply said that it wouldn't be my preference. And my post-answer summary has no bearing on the accuracy/correctness of the initial part of my answer. However, if you can provide evidence to the contrary of the latter part of my post (ie. how you can see hypervisor activity, interface capacity, routing flaps/failures), demonstrate the economy and performance - I'm all ears.
    – choco-loo
    Dec 11, 2014 at 19:36
  • 2
    I'll also add, there is a significant difference between large companies, with large stores on AWS; that have a significant budget, with in-house systems administration experience and large-scale clustering automation experience - to the Average Joe posting on SE. You may well run an enormous store on AWS and see the benefits, but that doesn't make it good advice for inexperienced developers, with no systems administration experience, limited budget and no foresight/ability to plan architecture appropriately without dozens of security and failure points.
    – choco-loo
    Dec 11, 2014 at 19:43
  • You're assuming a lot about the OP. S/he may have those resources and/or abilities. The question was how to best run Magento on AWS, not whether to run Magento on AWS and as such, we're both off topic :)
    – Roscius
    Dec 12, 2014 at 1:13
  • 1
    You might be off topic, but I'm certainly not - I've provided the best possible answer for the OP. You've merely read a single sentence of my response, not the entire response. The best answer is that circumstances vary, bottlenecks move and that any recommendation based on the severe [lack of] information provided would be erroneous. The OPs question and the place they asked it, say absolutely enough about the OPs abilities, experience and resources - there's no assumption at all.
    – choco-loo
    Dec 12, 2014 at 1:47

If cost is no object...

You're going to get more mileage by increasing the instance size in your existing setup than by sharding the frontend.

The backend (Magento admin area) doesn't eat a lot of resources, however having a separate instance is nice for security.

Moving the DB into RDS can help you squeeze more out of your frontend instances. Using a read replica for your DB is quite straight forward with Magento.

If a concern is uptime as well as performance (which it usually is for production sites), you'll need to be multi-zone for the DB and the frontend.

The caching and indexing improvements in Magento Enterprise are also critical in my opinion for very high volume/traffic sites, but expensive. However, if you're banging into the EC2 size limits, the cost most likely isn't a problem.

There's lots of optimization tweaks to be made that are more of an AWS specific question than a Magento specific question - ELB setup, multi-zone failovers, EBS vs S3 vs Cloud Front vs instance storage. Like anything else, start simple and go for the largest bang for the buck tweaks first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.