<p>There are two general strategies for dealing with traffic surges: increasing capacity and reducing cost.</p>

<p>Increasing capacity means auto-scaling, which everyone was very excited about when public clouds first became available. In its most basic sense, this will boot up more webservers for you based on load and add them to a load balancer, but since can be a pain to manage, there are more automagic solutions as well, like Elastic Beanstalk.</p>

<p>The trouble with automated capacity expansion is that its also automated bill expansion - 10x normal traffic means 10x servers means 10x money you have to pay. That's why, while it's a useful strategy to keep in mind, I think you should always start by seeing how much you can cheat.</p>

<p>By cheat, I mean cache, which rests on the idea that most of the time you can give users slightly out of date data and they won't notice, and that can save you tremendous amounts of time. Imagine that you have a page that you decide it's ok if it's five seconds out of date, and it gets 20 req/s. Without caching, you're running that calculation 1200 times a minute, whereas with caching it's only 12. You can see how this can make a tremendous difference.</p>

<p>There are of course many types of caching, and a successful website will use several of them. But for your use case, there are two pretty good and easy options.</p>

<p>The first is to make the site completely static. This assumes that you can do so, but if you can, then you just have Nginx serve up the html directly, and it can serve <em>tons</em> of requests with no sweat.</p>

<p>If you need some level of dynamicity, then doing some full-page caching is a good option. Nginx has some capability to do this, but I really like Varnish because of its flexibility.</p>

<p>Whatever option or options you go with, make sure you do load testing to validate that you've set it up properly; sometimes fixing one spot exposes a new bottleneck.</p>

CC BY-SA 3.0
2017-10-13T19:46:55.990Z
2017-10-13T19:46:55.990Z
Xiong Chiamiov
<p>I would recommend auto-scaling as mentioned above with the addition of some CloudWatch alarms to start the auto-scaling process when specific thresholds start to increase, not when it's already to far gone.</p>

<p>For example; configure CloudWatch to monitor your server, when the CPU is at 50% or higher for a period of 30 seconds or more start the auto-scaling process. </p>

<p>This may not be completely faultless but it's easy to do via some online guides and all configurable via the GUI.</p>

<p>Also, if your landing page is static why not host that on a free-tier t2.micro and use another t2.micro free-tier for your app?</p>

CC BY-SA 3.0
2017-10-16T14:47:33.043Z
Autoscaling is not the holistic answer during sudden traffic increases. The autoscaling detecting window is somewhere between 1-5 minutes, depending on your provisioning this can take some time as well. Generally the correct answer is to run instances hot, ie: above what your perceived traffic level would be and allow autoscaling to maintain that margin.
Matt O.
CC BY-SA 3.0
2017-09-29T10:35:33.607Z
2017-09-29T10:35:33.607Z
jto
<p>I’d love to help with this if you’re looking for some help. Depending on your page you may not need ec2 at all. For instance if your serving something static or JavaScript it can be served from s3 with a cloudfront distribution. Or we could possibly use an auto scaling group if absolutely necessary. </p>

CC BY-SA 3.0
2017-09-30T03:01:30.737Z
2017-09-30T03:01:30.737Z
user4564
<p>This depends a lot on the specific architecture, but for example:</p>

<ul>
<li>Front load your website with CloudFront to reduce load on the host</li>
<li>Use client side hosting service in something like S3 for scale</li>
<li>Elastic Load Balancer with an Autoscaling group</li>
</ul>

CC BY-SA 3.0
2017-10-16T06:42:33.303Z
2017-10-16T06:42:33.303Z
Henry
<p>I would like to share our experience with AWS. We deployed our application on EC2 and face the same problem and also high cost.
We deployed our application <strong>Amazon EC2 Container Service</strong> although our application was monolithic, but we achieved</p>

<ul>
<li>Availability</li>
<li>Cost Effective</li>
<li>Scalability</li>
</ul>

<p>Application load balancer will handle the traffic and will route traffic to the healthy instance and you can run multiple tasks of same services without worrying of scaling and balancing the load.</p>

<blockquote>
  <p>This architecture makes it easier to implement failure isolation.
  Techniques such as health-checking, caching, bulkheads, or circuit breakers
  allow you to reduce the blast radius of a failing component and to improve the
  Overall availability of a given application.</p>
</blockquote>

CC BY-SA 3.0
2017-10-16T23:10:53.263Z
There's [no separate pricing for ECS](https://aws.amazon.com/ecs/pricing/), just the underlying EC2 resources, so how was using ECS any more cost effective?  It should consume the same amount of resources whether you're managing the containers yourself or letting Amazon do it.
Xiong Chiamiov
CC BY-SA 3.0
2017-10-18T03:40:38.127Z
in container if you are using alpine which is 5mb and ec2 your are using ubuntu which is 2gb? which thing is best? in t2 micro you can run 5 php container with scale in and out on base of trafic.. can you run in ec2 with scale in and scale out?
Adiii
CC BY-SA 3.0
2017-10-18T21:47:37.980Z
You don't have to use Ubuntu for ec2 instances; you can upload an Alpine image and use that if you want.  If you've gotten everything working with ECS, that's great, and it's unlikely you'll want to move back, but my point is that merely moving to ECS does not make an app more scalable or cost effective; it's other changes you made to the app, infrastructure, and architecture at the same time that did that.
Xiong Chiamiov
CC BY-SA 3.0
2017-09-30T07:13:46.113Z
2017-09-30T07:13:46.113Z
Adiii
<p>If you want something quick to get this sorted without much more knowledge I'd recommend elastic beanstalk. It's another AWS application which will handle the load balancer configuration and instance scaling for you.</p>

<p>There's no extra cost on top of the load balancer and instances so you can keep using t2 type instances but let elastic beanstalk scale as much as you want to help.</p>

<p>Auto scaling isn't instant and in times of spiking traffic will take a short amount of time, minutes normally, to be able to handle a spike but it will be much better than manually scaling the instance size and is really easy to get to grips with.</p>

CC BY-SA 3.0
2017-09-28T08:28:09.830Z
2017-09-28T08:28:09.830Z
Briansbum
<p>I've a iOS app on the app store and recently I've received a huge surge of traffic to my landing page hosted on EC2 and resulted in the page not responding, luckily I managed to recover it by restarting and upgrading the instance to a t2.medium.<br/></p>

<p>Now I'm looking to hire someone to implement a technology to prevent the same death again. My experience only stretch that far allowing me to understand basic devops stuff but not enough for load balancer on AWS, I want to know what is a affordable implementation for my instance.<br /></p>

<p>My landing page and iOS app backend are hosted on the same instance.</p>

CC BY-SA 3.0
2017-09-28T11:03:32.813Z
Is your landing page static?
Michael - sqlbot
<amazon-web-services><amazon-ec2><load-balance>
How to prevent hug of death on EC2 Instance?
Missus
# How to prevent hug of death on EC2 Instance?

(Asked by: username_0 on 2017-09-28)

I've a iOS app on the app store and recently I've received a huge surge of traffic to my landing page hosted on EC2 and resulted in the page not responding, luckily I managed to recover it by restarting and upgrading the instance to a t2.medium.

Now I'm looking to hire someone to implement a technology to prevent the same death again. My experience only stretch that far allowing me to understand basic devops stuff but not enough for load balancer on AWS, I want to know what is a affordable implementation for my instance.

My landing page and iOS app backend are hosted on the same instance.

**Tags:** amazon-web-services, amazon-ec2, load-balance

> **Comments:**
> **username_1**: Is your landing page static?  

---

## 6 answers

### Answer by username_8 on 2017-09-28. Score: 8 | Accepted answer

If you want something quick to get this sorted without much more knowledge I'd recommend elastic beanstalk. It's another AWS application which will handle the load balancer configuration and instance scaling for you.

There's no extra cost on top of the load balancer and instances so you can keep using t2 type instances but let elastic beanstalk scale as much as you want to help.

Auto scaling isn't instant and in times of spiking traffic will take a short amount of time, minutes normally, to be able to handle a spike but it will be much better than manually scaling the instance size and is really easy to get to grips with.


---

### Answer by username_2 on 2017-10-13. Score: 1

There are two general strategies for dealing with traffic surges: increasing capacity and reducing cost.

Increasing capacity means auto-scaling, which everyone was very excited about when public clouds first became available. In its most basic sense, this will boot up more webservers for you based on load and add them to a load balancer, but since can be a pain to manage, there are more automagic solutions as well, like Elastic Beanstalk.

The trouble with automated capacity expansion is that its also automated bill expansion - 10x normal traffic means 10x servers means 10x money you have to pay. That's why, while it's a useful strategy to keep in mind, I think you should always start by seeing how much you can cheat.

By cheat, I mean cache, which rests on the idea that most of the time you can give users slightly out of date data and they won't notice, and that can save you tremendous amounts of time. Imagine that you have a page that you decide it's ok if it's five seconds out of date, and it gets 20 req/s. Without caching, you're running that calculation 1200 times a minute, whereas with caching it's only 12. You can see how this can make a tremendous difference.

There are of course many types of caching, and a successful website will use several of them. But for your use case, there are two pretty good and easy options.

The first is to make the site completely static. This assumes that you can do so, but if you can, then you just have Nginx serve up the html directly, and it can serve *tons* of requests with no sweat.

If you need some level of dynamicity, then doing some full-page caching is a good option. Nginx has some capability to do this, but I really like Varnish because of its flexibility.

Whatever option or options you go with, make sure you do load testing to validate that you've set it up properly; sometimes fixing one spot exposes a new bottleneck.


---

### Answer by username_3 on 2017-09-29. Score: 1

I would recommend auto-scaling as mentioned above with the addition of some CloudWatch alarms to start the auto-scaling process when specific thresholds start to increase, not when it's already to far gone.

For example; configure CloudWatch to monitor your server, when the CPU is at 50% or higher for a period of 30 seconds or more start the auto-scaling process.

This may not be completely faultless but it's easy to do via some online guides and all configurable via the GUI.

Also, if your landing page is static why not host that on a free-tier t2.micro and use another t2.micro free-tier for your app?

> **Comments:**
> **username_4**: Autoscaling is not the holistic answer during sudden traffic increases. The autoscaling detecting window is somewhere between 1-5 minutes, depending on your provisioning this can take some time as well. Generally the correct answer is to run instances hot, ie: above what your perceived traffic level would be and allow autoscaling to maintain that margin.  

---

### Answer by username_5 on 2017-09-30. Score: 1

I’d love to help with this if you’re looking for some help. Depending on your page you may not need ec2 at all. For instance if your serving something static or JavaScript it can be served from s3 with a cloudfront distribution. Or we could possibly use an auto scaling group if absolutely necessary.


---

### Answer by username_6 on 2017-10-16. Score: 0

This depends a lot on the specific architecture, but for example:

* Front load your website with CloudFront to reduce load on the host
* Use client side hosting service in something like S3 for scale
* Elastic Load Balancer with an Autoscaling group


---

### Answer by username_7 on 2017-09-30. Score: 0

I would like to share our experience with AWS. We deployed our application on EC2 and face the same problem and also high cost.
We deployed our application **Amazon EC2 Container Service** although our application was monolithic, but we achieved

* Availability
* Cost Effective
* Scalability

Application load balancer will handle the traffic and will route traffic to the healthy instance and you can run multiple tasks of same services without worrying of scaling and balancing the load.

> This architecture makes it easier to implement failure isolation.
> Techniques such as health-checking, caching, bulkheads, or circuit breakers
> allow you to reduce the blast radius of a failing component and to improve the
> Overall availability of a given application.

> **Comments:**
> **username_2**: There's [no separate pricing for ECS](https://aws.amazon.com/ecs/pricing/), just the underlying EC2 resources, so how was using ECS any more cost effective?  It should consume the same amount of resources whether you're managing the containers yourself or letting Amazon do it.  
> **username_7**: in container if you are using alpine which is 5mb and ec2 your are using ubuntu which is 2gb? which thing is best? in t2 micro you can run 5 php container with scale in and out on base of trafic.. can you run in ec2 with scale in and scale out?  
> **username_2**: You don't have to use Ubuntu for ec2 instances; you can upload an Alpine image and use that if you want.  If you've gotten everything working with ECS, that's great, and it's unlikely you'll want to move back, but my point is that merely moving to ECS does not make an app more scalable or cost effective; it's other changes you made to the app, infrastructure, and architecture at the same time that did that.  

---

