I am pretty new to AWS deployment (please send any helpful guides). And I read that it comes with an elastic load balancer but I've also heard that a lot of people put NGINX on an EC2 to use as a load balancer.
Do people commonly use either or? Having two seems redundant.
Nginx on an EC2 instance for load balancing would be a single point of failure, if the EC2 instance went down your app would be down. An AWS Load Balancer is actually multiple load balancer nodes distributed across multiple AWS availability zones to provide high availability. The EC2 instance would also be something for you to have to manage, where an AWS Load Balancer is managed for you by Amazon.
You mention Elastic Beanstalk in your question title. Elastic Beanstalk will use both. It uses a Load Balancer for distributing traffic across multiple instances, and it uses Nginx on each instance as a reverse proxy to your application.
Maybe I am not understanding what exactly Elastic Beanstalk should be used for, so my question is this:
How does Elastic Beanstalk have the ability to support multiple EC2 instances in the same Elastic Beanstalk Environment if the instances act as a backend web server?
For example, if I have a server that has the end point www.example.com/api/endpoint, does Elastic Beanstalk allow me to have more than 1 instance (for high availability) with that same endpoint? Is that possible? If not, how do you make use of the extra EC2 instances if they all have different domains?
How do I send requests to the Elastic Beanstalk environment (from a front end web app) that all instances can understand?
You're going to need to watch some video's.
ElasticBeanStalk is for lazy developers who don't want to learn Cloud Technology ;) I know because I was one once!
ElasticBeanStalk creates a VPC that has Subnets by default 1 per Availability Zone (AZ), and the number of AZs depends on the regions number of AZs. The VPC it creates will have a Internet Gateway attached via the Route Tables making it Public.
In the Subnet(s) ElasticBeanStalk will spin up a EC2/VM to host your website.
ElasticBeanStalk will make a Network Security Group (NSG) opening port 80 &/or 443 and because the VPC is public plus the NSG is open the EC2 will be accessible to the WWW.
If you've chosen an Auto Scale Group (ASG) the ASG will spin up/down EC2s depending typically on CPU but you can use CloudWatch metrics.
With an ASG the ElasticBeanStalk will spin up a Elastic Load Balancer (ELB) and that will coordinate the traffic coming into the Internet Gateway to the VMs. The ELB is registered with the ASG and that's how it knows the ASG spun up or down EC2 instances. This is how the ELB can deliver the traffic using either Level4 (a range of IP addresses) or Layer7 (a range of IP Addresses plus HTTP Request, Header & etc info) to the EC2s currently running in a "Target Group".
if I have a server that has the end point www.example.com/api/endpoint, does Elastic Beanstalk allow me to have more than 1 instance (for high availability
Yes! And its actually quite tricky to demonstrate because you hit the same URL and need to get the ID of the different instances in the ASG.
The best resource is Ryan Kroonenberg's A Cloud Guru "Solution Architect Associate" video on VPCs, Chapter 9. https://acloudguru.com/course/aws-certified-solutions-architect-associate-saa-c02-4KYV (you can find an yrs old torrent with it)
This diagram isn't 100% accurate, the ASGs stretch across AZs:
I have an on-premises load balancer that I wish to use to distribute traffic on EC2s in an Autoscaling group(ASG).
When AWS's Elastic Load Balancer(ELB) registers an ASG as a target, during a scale-out,new instances are automatically registered to ELB to route traffic to.
Can the same functionality be achieved in any way with an on-prem load balancer?
There is in-built integration between Amazon EC2 Auto-Scaling and Elastic Load Balancers. The Auto Scaling systems knows how to modify Target Groups to add/remove instances. However, it has no knowledge about your on-premises load balancer.
You could use Amazon EC2 Auto Scaling lifecycle hooks to trigger additional code (that you write) to add/remove the instances to your own load balancer, but that would require an AWS Lambda function to communicate with the on-premises load balancer to update the configuration.
If you wanted to get the IPs of your target group you can do that do with an API call, and put that into your LB, but I think you may as well proxy calls from your LB to an ELB sitting on AWS which does the actual LoadBalancing. IMO there is way too much work and a lot could go wrong if you were to try and re-implement ELB features using Lambda functions.
I am new to AWS. I would like to activate load balancing. I need to know that should I create multipl ec2 instance with the same files? Or only one instance is enough?. What will happen while heavy traffic?
AWS Elastic Load balancer (ELB) is for distributing traffic across multiple EC2 instances. You will be registering the instances with the ELB. Even when instances fail and new instances are added to ELB, the traffic is evenly distributed among the remaining active registered instances. Please see the documentation: AWS Elastic Load Balancing
If you have only one instance, ELB will send traffic only to that. But, what is the use of ELB then? It serves no purpose to have only 1.
If you need to scale out as the traffic increases, you need to use AWS Auto Scaling : AWS Auto Scaling
My question is simple. Does it make sense to have an Amazon Elastic Load Balancer (ELB) with just one EC2 instance?
If I understood right, ELB will switch traffic between EC2 instances. However, I have just one EC2 instance. So, does it make sense?
On the other hand, I´m using Route 53 to route my domain requests example.com, and www.example.com to my ELB, and I don´t see how to redirect directly to my EC2 instance. So, do I need an ELB for routing purposes?
Using an Elastic Load Balancer with a single instance can be useful. It can provide your instance with a front-end to cover for a disaster situation.
For example, if you use an auto-scaling group with min=max=1 instance, with an Elastic Load Balancer, then if your instance is terminated or otherwise fails:
auto-scaling will launch a new replacement instance
the new instance will appear behind the load balancer
your user's traffic will flow to the new instance
This will happen automatically: no need to change DNS, no need to manually re-assign an Elastic IP address.
Later on, if you need to add more horsepower to your application, you can simply increase your min/max values in your autoscaling group without needing to change your DNS structure.
It's much easier to configure your SSL on an ELB than an EC2, just a few clicks in the AWS console. You can even hand pick the SSL protocols and ciphers.
It's also useful that you can associate different security groups to the actual EC2 and the forefront ELB. You can leave the ELB in the DMZ and protect your EC2 from being accessible by public and potentially vulnerable to attacks.
There is no need to use a Load Balancer if you are only running an single Amazon EC2 instance.
To point your domain name to an EC2 instance:
In the EC2 Management Console, select Elastic IP
Allocate New Address
Associate the address with your EC2 instance
Copy the Elastic IP address and use it in your Route 53 sub-domain
The Elastic IP address can be re-associated with a different EC2 instance later if desired.
Later, if you wish to balance between multiple EC2 instances:
Create an Elastic Load Balancer
Add your instance(s) to the Load Balancer
Point your Route 53 sub-domain to the Load Balancer
With NO ELB :-
Less Secure (DOS Attacks possible as HTTP 80 will be open to all, instead of being open only to ELB)
You won't have the freedom of terminating an instance to save EC2 hrs without worrying about remapping your elastic IP(not a big deal tho)
If you don't use ELB and your ec2 instance becomes unhealthy/terminates/goesDown
Your site will remain down (It will remain up if you use ELB+Scaling Policies)
You will have to remap your elastic IP
You pay for the time your elastic IP is not pointing to an instance around $0.005/hr
You get 750 hours of Elastic Load Balancing plus 15 GB data processing with the free tier so why not use it along with a min=1,max=1 scaling policy
On top of the answer about making SSL support easier by putting a load balancer in front of your EC2 instance, another potential benefit is HTTP/2. An Application Load Balancer (ALB) will automatically handle HTTP/2 traffic and convert up to 128 parallel requests to individual HTTP/1.1 requests across all healthy targets.
For more information, see: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-configuration
It really depends on what are you running in the EC2 instance.
While with only one EC2 instance it's not necessary to use ELB (all your traffic will go to that instance anyways), if your EC2 service has to scale in the near future, is not a bad idea to invest some time now and get familiar with ELB.
This way, when you need to scale, it's just a matter of firing up additional instances, because you have the ELB part done.
If your EC2 service won't scale in the near future, don't worry too much!
About the second part, you definitely can route directly to your EC2 instance, you just need the EC2 instance IP. Take a look at the amazon route53 docs. Mind that if your IP is not static (you don't setup an Amazon Elastic IP), you'd need to change the IP mapping everytime the EC2 ip changes.
You can also use an ELB in front of EC2 if for example you want it to be publically reachable, without having to use up an Elastic IP address. As said previously they work well too with ASG's