Magento – Recommended AWS instance type for Magento

I was hosting Magento on AWS in 2011 until 2013. Many of the things you gain from using cloud infrastructure rather than traditional dedicated or shared hosting are more relevantly described under the topic of DevOps, which are not exclusive to AWS but are more easily enabled through its use.

• Complete and flexible control of your capacity planning -- scale up ahead of marketing events, enable dynamic provisioning via Elastic Beanstalk, scale down during low volume periods, spin up a site in a couple weeks, tear it down and throw it away.
• Easily setup dev/test/staging environments and replicate changes between them.
• Host your admin pages on a separate host.
• Use DynamoDB for session management and ElastiCache for cache w/o incurring additional operations overhead, beware ElastiCache doesn't currently function in VPC though.
• use ELBs for loadbalancing, but beware if requests take more than 60 seconds they'll be terminated ungracefully
• Use AmazonSES for sending emails (now even easier via regular SMTP), though gaps still exist in tooling for tracking bounces/complaints
• Use AmazonS3 for hosting media, and Cloudfront for CDN.
• Reduced operations cost for database activity via RDS, which features point in time restore, automated failover, automated backups, and automated upgrades.
• DNS management is super easy in Route53, but generally recommended for ease of mapping subdomains to load balancers.
• VPC to put all your machines on their own private network to have more granular control and expose access as you see fit via your own VPN tunnels.
• Easy performance metrics and alerting (aside from memory usage and disk usage) via CloudWatch & SNS

Minimal footprint will be 1 ELB, 2 EC2 webservers in seperate AZs, 1 multi-az RDS, Route53 hosted zone for the domain. Initially you can use sticky sessions on the ELB to keep session management simpler, but as your traffic increases you'll want to move media into a CDN (S3 & CloudFront) and sessions off of the individual machines.

Areas I haven't looked but still are promising: CloudFormation scripts for easier deployment of a Magento stack, offloading order creation via DynamoDB and worker queues for greater checkout throughput (someone has already started a project to do this via MongoDB at one of the hackathons recently), and setting up a multi-region presence via latency based routing with Route53.

I guess I'm kind of an evangelist for cloud. Specific to AWS, c3.large are a decent instance size for production webservers, but I'd start off with the smallest of each instance class and measure performance and scale up or optimize code as you see fit, which is why I refer everyone to xhgui constantly.

You've been advised poorly.

Remember that AWS doesn't do infinite scaling miracles, its just a virtual server provider

AWS is nothing more than a set of virtual servers, running in a contended, shared environment. Coupled with the fact it runs older generation hardware, that has its resources crippled by the AWS hypervisor - its performance is less than stellar if speed is important.

Its multi-tenant, so your performance isn't guaranteed

What you need to understand is that AWS is an entirely multi-tenant environment - from the physical hardware, to the internal networking, to the external networking. The performance you see will be heavily influenced by activity from other users of AWS. So you could have moments of "normal" performance, followed by catastrophically slow performance. You could opt for enhanced/clustered networking - but it is still effectively a public network performing a balancing act with QoS/CoS to try and improve latency/bandwidth to some users whilst limiting it for others.

Underlying hardware is a gamble of old technology

Also consider that you really have no idea what hardware your different instances are sat on. Some may benefit from newer generation CPU's, others significantly older - it is effectively pot luck as to what you get - and computationally how one instance may perform compared to another.

Scaling traffic isn't that easy, you'll hit a vertical ceiling almost instantly

In terms of handling high traffic, you are talking scalability, and AWS is constrained there too. You can only effectively scale horizontally. The capacity to scale vertically is limited to 32 cores - which is going to cripple any efforts to scale vertically.

But you can almost infinitely scale horizontally

So at this point, horizontal scaling is your only mechanism. Once you start scaling horizontally, you've got to add in considerations for

1. Load balancing
2. Shared/common storage
3. Availability

... and worrying about the fact that with each additional instance you run, the risk of failure is amplifying by as much. So high availability must then be built into your service.

When scaling horizontally, you are also back to the common bottleneck of contented networking. So whilst you can spin up infinite instances for load balancing, web servers, db servers and cache servers - your baseline performance will be dominated by the low communication speed between said instances.

AWS isn't that cheap

Once you dig into the costs of "the cloud", you'll suddenly realise that you're actually paying close to 2x or 3x as much you actually would for a dedicated server. Now this is for a reason, you can create/destroy instances on a whim - so you are paying a premium for the flexibility of reducing cost.

But your, and many others', main reason for looking to use cloud hosting is to have infrastructure that will support your growing business, this means that your business is growing (or plans to),

Ie. the plans are to outgrow the original VPS and you want infrastructure to support it

So now, the original premise of cost savings (but running only what you need) is effectively gone - and once your business has grown, and is using the extra resources that you wished for - you'll suddenly realise that you are actually paying about 3x as much as you would have been if you just opted for a dedicated box to begin with - not to mention, have significantly worse performance.

The burden of management, deployment and configuration is entirely on you

The very fact you are asking about setting up AWS is evidence enough that you shouldn't attempt this endeavour at all. At best on AWS, you'll get an average performance Magento store - at worst, you'll have a terrifically slow, unreliable store.

Don't expect any support from Amazon - not even email support. You are limited to community forums for help (which, if the worst is happening and you are losing sales (£££) by the minute, is costing your business significantly). You can opt for paid support, if you can afford the costs (read: not cheap) - but don't expect the person on the other end to be able to offer any application specific help for Magento.

My advice

There are plenty of capable Magento hosts out there that run specialised infrastructure designed to scale - and plenty of which who have experience with both high volume stores and large catalogue stores.

You would be mad to go it alone, especially if you think that your magic bullet resides in AWS's promise of infinite scalability.