CODEWITHSUNDEEP
amazon-web-servicesamazon-elastic-beanstalkautoscaling
Random5000
Random5000

Reputation: 1670

Best Practices for AWS Elastic Beanstalk Auto Scaling Trigger Settings for Web Application?

By default when you create an elastic beanstalk application, the scaling is set to scale based on "Average network out", and add instance when > 6000000, and remove instance when < 2000000.

What's the best practice for setting trigger settings for these? These default settings are obviously terrible, as we just had a bunch of ELB errors because our servers couldn't handle the traffic, the CPU wasn't high either, this was on t2.micro servers.

Previously, I've always used the CPU trigger, but I understand a server can stop accepting request, even before the CPU is maxed out.

What are some of the general best practices you use when setting the auto scaling trigger?

I can't seem to find any really, it just leaves you to try and come up with them by yourself. This is just for a standard web application, and server size may change over time. So what's one setting I can just generally use for everything?

Upvotes: 8

Views: 1602

Answers (1)

Kasun Piyasena
Kasun Piyasena

Reputation: 114

For this one, we cannot say precisely what is the exact Auto Scaling Trigger configuration. This one actually depends on the application deployed.

In this case, you need to use the correct sizing for your application. As far as I can understand on this one this application is using more memory than a t2.micro instance. So you need to use correct sizing for your application. You can use this link to check what instance is suitable for your application deployment.

You can check the application memory usage by IDE. So that you can use the correct sizing for your application.

On Elastic Beanstalk there is no Auto Scaling Trigger configuration related to Memory Utilisation. So you cannot scale the application using Memory usage. So you can use a proper metric from available Metrics.

  • CPUUtilization: Useful for CPU-intensive workloads.
  • NetworkIn/NetworkOut: Ideal for applications with heavy data transfer.
  • RequestCountPerTarget: Suitable for applications with variable request traffic.
  • Latency: Focus on user experience by scaling based on response times.

So you can select accordingly. Then you need to set the thresholds with historical data. If there is no historical data you can start as follows.

  • CPUUtilization: Start with 60%-70% as an upper threshold.
  • Latency: Ensure it aligns with your Service Level Agreement (SLA).

Upvotes: 0

Related Questions