<story><title>A Beginner&apos;s Guide to Scaling to 11M+ Users on Amazon&apos;s AWS</title><url>http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html</url></story><parent_chain></parent_chain><comment><author>napkindrawing</author><text>I work in the entertainment &amp;#x2F; ticketing industry and we&amp;#x27;ve been burned badly before by relying on AWS&amp;#x27; Elastic Load Balancer due to sudden &amp;amp; unexpected traffic spikes.&lt;p&gt;From the article: &amp;quot;Elastic Load Balancer (ELB): [...] It scales without your doing anything. If it sees additional traffic it scales behind the scenes both horizontally and vertically. You don’t have to manage it. As your applications scales so is the ELB.&amp;quot;&lt;p&gt;From Amazon&amp;#x27;s ELB documentation: &amp;quot;Pre-Warming the Load Balancer: [...] In certain scenarios, such as when flash traffic is expected [...] we recommend that you contact us to have your load balancer &amp;quot;pre-warmed&amp;quot;. We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request&amp;#x2F;response that you will be testing.&amp;quot;</text></comment>
<story><title>A Beginner&apos;s Guide to Scaling to 11M+ Users on Amazon&apos;s AWS</title><url>http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html</url></story><parent_chain></parent_chain><comment><author>falcolas</author><text>Hoo boy. Here we go. The problem with AWS reps is that they only see everything as working perfectly, with no possibility for downtime of their services.&lt;p&gt;RDS is great, but only to a certain level. You&amp;#x27;ll still need to pull it off RDS once you reach that service&amp;#x27;s capacity (much sooner than their 10m user mark). They also keep pushing Aurora, but without telling us what the tradeoffs are for the high availability. Based on the responses so far (MySQL backed by InnoDB), it appears to be based on a technology similar to Galara, which has a lot of caveats for its use, especially with multiple writers.&lt;p&gt;Don&amp;#x27;t depend on Elastic Scaling for high availability - when an AZ is having issues, the AWS API will either be down or swamped, so you want to have at least 50% extra capacity at all times, if you want high availability.&lt;p&gt;Using their scaling numbers, your costs start spiking at 10 users. Realistically, with intelligent caching (even something as simple as Nginx caching), you can easily support several thousand users just fine with a t2 style instance, either a small or micro. Splitting services onto different hosts not only increases your hosting costs, it increases the workload on your developers&amp;#x2F;admins and likeliness of failure.&lt;p&gt;DR: Don&amp;#x27;t wait until you have over a thousand users to have multiple instances in different AZs. The cost of duplicating a t2.small across an AZ is small compared to lost users or sales.&lt;p&gt;Automation: Be prepared for vendor lockin if you use Amazon&amp;#x27;s solutions. Also be prepared for their APIs being unavailable during times of high load or during AZ failures.&lt;p&gt;&amp;gt; Lambda [...] We’ve done away with EC2. It scales out for you and there’s no OS to manage.&lt;p&gt;The biggest problem with Lambda right now are the huge latency costs with cold lambda instances. You&amp;#x27;ll get a pretty good 95% percentile response times, but that other 5% will be off-the-chart bad.&lt;p&gt;In summary, AWS has a lot of great toys, and can absolutely be used for scaling up to silly levels. However, most who have done this degree of scaling do not do so using AWS tools.</text></comment>