AWS Elastic Load Balancing (ELB) logo

AWS Elastic Load Balancing (ELB)

Automatically distribute your incoming application traffic across multiple Amazon EC2 instances
3K
1.7K
+ 1
53

What is AWS Elastic Load Balancing (ELB)?

With Elastic Load Balancing, you can add and remove EC2 instances as your needs change without disrupting the overall flow of information. If one EC2 instance fails, Elastic Load Balancing automatically reroutes the traffic to the remaining running EC2 instances. If the failed EC2 instance is restored, Elastic Load Balancing restores the traffic to that instance. Elastic Load Balancing offers clients a single point of contact, and it can also serve as the first line of defense against attacks on your network. You can offload the work of encryption and decryption to Elastic Load Balancing, so your servers can focus on their main task.
AWS Elastic Load Balancing (ELB) is a tool in the Load Balancer / Reverse Proxy category of a tech stack.

Who uses AWS Elastic Load Balancing (ELB)?

Companies
979 companies reportedly use AWS Elastic Load Balancing (ELB) in their tech stacks, including 9GAG, Intuit, and Quora.

Developers
1983 developers on StackShare have stated that they use AWS Elastic Load Balancing (ELB).

AWS Elastic Load Balancing (ELB) Integrations

Amazon EC2, Datadog, Scalyr, Jungle, and Cloudcraft are some of the popular tools that integrate with AWS Elastic Load Balancing (ELB). Here's a list of all 15 tools that integrate with AWS Elastic Load Balancing (ELB).

Why developers like AWS Elastic Load Balancing (ELB)?

Here’s a list of reasons why companies and developers use AWS Elastic Load Balancing (ELB)
Top Reasons
AWS Elastic Load Balancing (ELB) Reviews

Here are some stack decisions, common use cases and reviews by companies and developers who chose AWS Elastic Load Balancing (ELB) in their tech stack.

Dmitry Mukhin
Dmitry Mukhin
at Uploadcare · | 20 upvotes · 65K views
atUploadcareUploadcare
Tornado
Tornado
Python
Python
Amazon EC2
Amazon EC2
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)

The 350M API requests we handle daily include many processing tasks such as image enhancements, resizing, filtering, face recognition, and GIF to video conversions.

Tornado is the one we currently use and aiohttp is the one we intend to implement in production in the near future. Both tools support handling huge amounts of requests but aiohttp is preferable as it uses asyncio which is Python-native. Since Python is in the heart of our service, we initially used PIL followed by Pillow. We kind of still do. When we figured resizing was the most taxing processing operation, Alex, our engineer, created the fork named Pillow-SIMD and implemented a good number of optimizations into it to make it 15 times faster than ImageMagick

Thanks to the optimizations, Uploadcare now needs six times fewer servers to process images. Here, by servers I also mean separate Amazon EC2 instances handling processing and the first layer of caching. The processing instances are also paired with AWS Elastic Load Balancing (ELB) which helps ingest files to the CDN.

See more
John-Daniel Trask
John-Daniel Trask
Co-founder & CEO at Raygun · | 19 upvotes · 79.5K views
atRaygunRaygun
Amazon S3
Amazon S3
Amazon RDS
Amazon RDS
nginx
nginx
Amazon EC2
Amazon EC2
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
#CloudHosting
#WebServers
#CloudStorage
#LoadBalancerReverseProxy

We chose AWS because, at the time, it was really the only cloud provider to choose from.

We tend to use their basic building blocks (EC2, ELB, Amazon S3, Amazon RDS) rather than vendor specific components like databases and queuing. We deliberately decided to do this to ensure we could provide multi-cloud support or potentially move to another cloud provider if the offering was better for our customers.

We’ve utilized c3.large nodes for both the Node.js deployment and then for the .NET Core deployment. Both sit as backends behind an nginx instance and are managed using scaling groups in Amazon EC2 sitting behind a standard AWS Elastic Load Balancing (ELB).

While we’re satisfied with AWS, we do review our decision each year and have looked at Azure and Google Cloud offerings.

#CloudHosting #WebServers #CloudStorage #LoadBalancerReverseProxy

See more
Joseph Kunzler
Joseph Kunzler
DevOps Engineer at Tillable · | 9 upvotes · 36.5K views
atTillableTillable
Amazon S3
Amazon S3
Amazon EC2
Amazon EC2
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
AWS CloudFormation
AWS CloudFormation
Terraform
Terraform

We use Terraform because we needed a way to automate the process of building and deploying feature branches. We wanted to hide the complexity such that when a dev creates a PR, it triggers a build and deployment without the dev having to worry about any of the 'plumbing' going on behind the scenes. Terraform allows us to automate the process of provisioning DNS records, Amazon S3 buckets, Amazon EC2 instances and AWS Elastic Load Balancing (ELB)'s. It also makes it easy to tear it all down when finished. We also like that it supports multiple clouds, which is why we chose to use it over AWS CloudFormation.

See more
AWS Elastic Beanstalk
AWS Elastic Beanstalk
Heroku
Heroku
Ruby
Ruby
Rails
Rails
Amazon RDS for PostgreSQL
Amazon RDS for PostgreSQL
MariaDB
MariaDB
Microsoft SQL Server
Microsoft SQL Server
Amazon RDS
Amazon RDS
AWS Lambda
AWS Lambda
Python
Python
Redis
Redis
Memcached
Memcached
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
Amazon Elasticsearch Service
Amazon Elasticsearch Service
Amazon ElastiCache
Amazon ElastiCache

We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.

We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.

In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.

Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache

See more
Mixmax
Mixmax
Meteor
Meteor
Node.js
Node.js
Amazon EC2
Amazon EC2
Go
Go
nginx
nginx
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
AWS Elastic Beanstalk
AWS Elastic Beanstalk

As Mixmax began to scale super quickly, with more and more customers joining the platform, we started to see that the Meteor app was still having a lot of trouble scaling due to how it tried to provide its reactivity layer. To be honest, this led to a brutal summer of playing Galaxy container whack-a-mole as containers would saturate their CPU and become unresponsive. I’ll never forget hacking away at building a new microservice to relieve the load on the system so that we’d stop getting paged every 30-40 minutes. Luckily, we’ve never had to do that again! After stabilizing the system, we had to build out two more microservices to provide the necessary reactivity and authentication layers as we rebuilt our Meteor app from the ground up in Node.js. This also had the added benefit of being able to deploy the entire application in the same AWS VPCs. Thankfully, AWS had also released their ALB product so that we didn’t have to build and maintain our own websocket layer in Amazon EC2. All of our microservices, except for one special Go one, are now in Node with an nginx frontend on each instance, all behind AWS Elastic Load Balancing (ELB) or ALBs running in AWS Elastic Beanstalk.

See more
Amazon VPC
Amazon VPC
AWS Elastic Load Balancing (ELB)
AWS Elastic Load Balancing (ELB)
AWS Elastic Beanstalk
AWS Elastic Beanstalk
Amazon EC2
Amazon EC2
Amazon CloudWatch
Amazon CloudWatch

AWS Elastic Beanstalk is Amazon's excellent PaaS offering that saves me from a bunch of time and effort building and maintaining my own platform.

Rather than me having to DIY configuration for Amazon EC2 , Amazon CloudWatch , Amazon VPC , AWS Elastic Load Balancing (ELB) and more, AWS Elastic Beanstalk handles that for me, so I can focus on my app/service.

See more

AWS Elastic Load Balancing (ELB)'s Features

  • Distribution of requests to Amazon EC2 instances (servers) in multiple Availability Zones so that the risk of overloading one single instance is minimized. And if an entire Availability Zone goes offline, Elastic Load Balancing routes traffic to instances in other Availability Zones.
  • Continuous monitoring of the health of Amazon EC2 instances registered with the load balancer so that requests are sent only to the healthy instances. If an instance becomes unhealthy, Elastic Load Balancing stops sending traffic to that instance and spreads the load across the remaining healthy instances.
  • Support for end-to-end traffic encryption on those networks that use secure (HTTPS/SSL) connections.
  • The ability to take over the encryption and decryption work from the Amazon EC2 instances, and manage it centrally on the load balancer.
  • Support for the sticky session feature, which is the ability to "stick" user sessions to specific Amazon EC2 instances.
  • Association of the load balancer with your domain name. Because the load balancer is the only computer that is exposed to the Internet, you don’t have to create and manage public domain names for the instances that the load balancer manages. You can point the instance's domain records at the load balancer instead and scale as needed (either adding or removing capacity) without having to update the records with each scaling activity.
  • When used in an Amazon Virtual Private Cloud (Amazon VPC), support for creation and management of security groups associated with your load balancer to provide additional networking and security options.
  • Supports use of both the Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6).

AWS Elastic Load Balancing (ELB) Alternatives & Comparisons

What are some alternatives to AWS Elastic Load Balancing (ELB)?
HAProxy
HAProxy (High Availability Proxy) is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.
Traefik
A modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components and configures itself automatically and dynamically.
Envoy
Originally built at Lyft, Envoy is a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures.
DigitalOcean Load Balancer
Load Balancers are a highly available, fully-managed service that work right out of the box and can be deployed as fast as a Droplet. Load Balancers distribute incoming traffic across your infrastructure to increase your application's availability.
GLBC
It is a GCE L7 load balancer controller that manages external loadbalancers configured through the Kubernetes Ingress API.
See all alternatives

AWS Elastic Load Balancing (ELB)'s Followers
1746 developers follow AWS Elastic Load Balancing (ELB) to keep up with related blogs and decisions.
Żaneta Jażdżyk
Vedant  Dubey
vivek patwari
Sascha Perkowski
Gregory Golberg
Venkat Susarla
mohamed_jebali
Vasiliy Trofimov
Lalit Nayyar
Tristan Gilford