I'm a little too confused on the terms and its usage. Can you please help me understand how are these used with Load Balancers?
I referred the aws-doc in vain for this :(
Target groups are just a group of Ec2 instances. Target groups are closely associated with ELB and not ASG.
ELB -> TG - > Group of Instances
We can just use ELB and Target groups to route requests to EC2 instances. With this setup, there is no autoscaling which means instances cannot be added or removed when your load increases/decreases.
ELB -> TG - > ASG -> Group of Instances
If you want autoscaling, you can attach a TG to ASG which in turn gets associated to ELB. Now with this setup, you get request routing and autoscaling together. Real world usecases follow this pattern. If you detach the target group from the Auto Scaling group, the instances are automatically deregistered from the target group
Hope this helps.
What is a target group?
A target group contains EC2 instances to which a load balancer distributes workload.
A load balancer paired with a target group does NOT yet have auto scaling capability.
What is an Auto Scaling Group (ASG)?
This is where auto scaling comes in. An auto scaling group (ASG) can be attached to a load balancer.
We can attach auto scaling rules to an ASG. Then, when thresholds are met (e.g. CPU utilization), the number of instances will be adjusted programatically.
How to attach an ASG to a load balancer?
For Classic load balancer, link ASG with the load balancer directly
For Application load balancer, link ASG with the target group (which itself is attached to the load balancer)
Auto Scaling Group is just a group of identical instances that AWS can scale out (add a new one) or in (remove) automatically based on some configurations you've specified. You use this to ensure at any point in time, there is the specific number of instances running your application, and when a threshold is reached (like CPU utilization), it scales up or down.
Target Group is a way of getting network traffic routed via specified protocols and ports to specified instances. It's basically load balancing on a port level. This is used mostly to allow accessing many applications running on different ports but the same instance.
Then there are the classical Load Balancers where network traffic is routed between instances.
The doc you referred to is about attaching load balancers (either classical or target group) to an auto-scaling group. This is done so scaling instances can be auto-managed (by the auto scaling group) while still having network traffic routed to these instances based on the load balancer.
Target groups
They listen to HTTP/S request from a Load Balancer
Are the Load Balancer's targets which will be available to handle an HTTP/S request from any kind of clients (Browser, Mobile, Lambda, Etc). A target has a specific purpose like Mobile API processing, Web App processing, Etc. Further, these target groups could contain instances with any kind of characteristics.
AWS Docs
Each target group is used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. You can create different target groups for different types of requests. For example, create one target group for general requests and other target groups for requests to the microservices for your application. Reference
So, a Target Group provides a set of instances to process specific HTTP/S requests.
AutoScaling groups
They are a set of instances who were started up to handle a specific workload, i.e: HTTP requests, SQS' message, Jobs to process any kind of tasks, Etc.
On this side, these groups are a set of instances who were started up by a metric which exceeded a specific threshold and triggered an alarm. The main difference is that Autoscaling groups' instances are temporary and they are available to process anything, from HTTP/S requests until SQS' messages. Further, the instances here are temporary and can be terminated at any time according to the configured metric. Likewise , the Autoscaling groups share the same characteristics because the follow something called Launch Configuration.
AWS Docs
An Auto Scaling group contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management. For example, if a single application operates across multiple instances, you might want to increase the number of instances in that group to improve the performance of the application or decrease the number of instances to reduce costs when demand is low. Reference
So, an Autoscaling group not only will be able to process HTTP/S requests but also can process backend stuff, like Jobs to send emails, jobs to process tasks, Etc.
As I understand it, Target Groups is a connection between ELB and EC2 instances. Some kind of a service discovery rules. This layer allows to Target Groups for ECS Services for instance when it's possible to have more than one container per instance.
Auto-Scaling Groups is an abstraction for aggregation of EC2 metrics and taking some actions based on that data.
Also, bear in mind, that the possibility of attaching of Auto-Scaling Groups to ELB comes from the previous generation of ELBs. You may compare the first generation and the second one in the CloudFormation docs.
Related
I am reading up on AWS Auto Scaling Groups and trying to understand (from a network-perspective) how the following resources all fit together:
Auto Scaling Group (ASG)
Application Load Balancer (ALB)
Individual EC2 instances sitting behind the ALB
ALB Listeners
ALB Target Groups
Security Group(s) enforcing which IPs/ports are allowed access to the EC2 instances
I understand what each of these does in theory, but in practice, I'm having trouble seeing the forest through the trees with how they all snap together. For example: do I configure the EC2 instances to be members of the Security Group? Or do I do that at the balancer-level? If I attach the ALB to the Auto Scaling Group, then why would I need to do any additional configuration with an ALB Target Group? When it comes to routing, do I route port 80 traffic to the ALB or the Auto Scale Group?
I know these are lots of small questions, so the main question here is: how do all of these snap together to provide a load balanced web server hosted on EC2 instances? Ultimately I need to configure all of this inside a CloudFormation template, but a diagram or explanation to help me configure everything manually is probably the best place for me to start. Thanks for any help!
do I configure the EC2 instances to be members of the Security Group?
Or do I do that at the balancer-level?
The EC2 instances should be a member of one security group. The Load Balancer should be a member of another security group. The Load Balancer's security group should allow incoming traffic from the Internet. The EC2 instances should allow incoming traffic from the load balancer.
If I attach the ALB to the Auto Scaling Group, then why would I need
to do any additional configuration with an ALB Target Group?
If you are using an auto-scaling group to create the instances, then you don't have to do any manual updates to the target group, the auto-scaling group will handle those updates for you.
When it comes to routing, do I route port 80 traffic to the ALB or the
Auto Scale Group?
An Auto-scaling group is not a resource that exists in your network. It is a construct within AWS that just creates/removes EC2 servers for you based on metrics. The traffic goes to the load balancer, and the load balancer sends it to the EC2 instances in the target group.
I know these are lots of small questions, so the main question here is: how do all of these snap together to provide a load balanced web server hosted on EC2 instances? Ultimately I need to configure all of this inside a CloudFormation template, but a diagram or explanation to help me configure everything manually is probably the best place for me to start.
It's a bit much to ask somebody on here to spend their free time creating a diagram for you. I suggest looking at the AWS reference WordPress implementations which they tend to use for providing reference implementations of auto-scaled web server environments.
See the "WordPress scalable and durable" CloudFormation template example here.
See the AWS WordPress Reference Architecture project here, which includes a diagram.
There is an ability to forward requests to multiple weighted target groups. Is there a way to set up priorities for target groups, not weights? What I'm trying to achieve is: I wanna have a rule which would have 2 tgs, one with scaled down ecs services (to 0) and another one with lambdas. If I need a performance boost (to avoid lambda warmups) I wanna be able to scale up the ecs cluster and it should overtake the request handling. That would be very nicely possible if I could set up two target groups as I described. When the number of healthy targets in ecs will be 0, it won't be able to handle any requests and the infra would route all the requests to the lambda target group. When the number of healthy targets in ecs will be 1 and more, based on the priority, all the requests will go to it. Is that possible? If not, what is the alternative approach to achieve what I have described?
You are basically asking for a failover mechanism. You want to route requests to the primary Target Group. Then if it goes unhealthy, route to the next Target Group based on the priority score. However, this article specifically mentions failover between target groups is not supported by default.
The Application Load Balancer distributes traffic to the target groups based on weights. However, if all targets in a particular target group fail health checks, then the Application Load Balancer doesn't automatically route the requests to another target group or failover to another target group. In this case, if a target group has only unhealthy registered targets, then the load balancer nodes route requests across its unhealthy targets. A weighted target group should not be used as a failover mechanism when all the targets are unhealthy in a specific target group.
However, if your problem is just the Lambda cold start, you can always schedule a ping to your Lambda every 5 minutes. I would think this is much easier than having to duplicate the same endpoint in ECS, especially from ops and maintenance perspective.
Finally, may be obvious, but if you really want it, you can always implement a script to do so.
EDIT
There is another way using Route 53, since it has a failover mechanism. Create 2 ALBs, one backed by ECS and another by Lambda. Use the failover routing.
Is it a good practice to setup 1 autoscaling with multiple target groups. All the target groups registered with same load balancer.
The scenario is Application load balancer LB1 listens on 80 and 443, has the target groups:
"open" Port is http/80
"secure". Port is https/443
If the auto scaling group has target tracking policy on average CPU utilisation, if "open" target group has higher CPU utilisation than "secure". Then there would be no auto scaling?
If alarm is breached how auto scaling group determine which target group should have the new instance?
Do I have to create separate auto scaling. group for each target group. I could not find any amazon docs for this scenario of multiple target group under 1 auto scaling group.
Please let me know
According to the AWS Documentation
If you attach multiple load balancer target groups or Classic Load Balancers to the group, all of them must report that the instance is healthy in order for it to consider the instance healthy. If any one of them reports an instance as unhealthy, the Auto Scaling group replaces the instance, even if other ones report it as healthy.
My test confirms that behavior with the one exception. Usually people start to configure auto-scaling group with the default settings, which means that the health-check is set to EC2 by default. For the proper work of multiply target groups attached to one auto-scaling group the health check should be set to ELB. If you change it after ASG started up, existing instances are not obey this new setting and retain in the groups.
It may cause the incorrect conclusion like this:
I have tried it, The instances retained even if its marked un healfthy from one target group #prassank
So the answer is:
It is not a good way to attach multiply target groups to a singe auto-scaling group unless you want more strict multiply health checking.
Is there a way like assigning a specific tag for the EC2 instances to automatically attached to the load balancer on AWS?
I believe I had done that in the past but unable to find that option now.
Since you say you've done it in the past, I believe you're thinking of a feature offered by EC2 auto-scaling groups (ASGs). ASG is a capability of the EC2 infrastructure that scales machine counts up and down based on workload or maintains a set number of healthy instances always running (destroying and replacing failed instances). When an ASG is attached to a load balancer, the instances controlled by the ASG are automatically registered and deregistered from the balancer.
Amazon EC2 Auto Scaling integrates with Elastic Load Balancing to enable you to attach one or more load balancers to an existing Auto Scaling group. After you attach the load balancer, it automatically registers the instances in the group and distributes incoming traffic across the instances.
https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html
Per AWS documentation you can attach multiple Load Balancers to a Single Auto Scaling Group. I would think there would be 1:1 relationship between ELB and ASG. If ASG scales which ELB does it update- All.
How does this work, what is the use case.
Although you can attach, multiple load balancers to a single Auto Scaling group, its rarely being used, specially after AWS introduced Application Load Balancer (ALB) with support for Routing Rules (Domain and Path based) and attaching multiple SSL Certificates for a single load balancer features.
For example few scenarios where it was required previously (Before above mentioned new features were available.)
If you have multiple applications running inside an EC2 (Although it's not recommended) and needed their own SSL certificates, it'd be required to point to multiple load balancers.
If you have an Application Proxy Auto Scaling Group which points to backend services with their own SSL.
For different path and port mappings for internal applications in EC2 (Similar to Point 1)
Looking at the AWS documentation you can attach multiple Load Balancers to an ASG. When the ASG scales up all the Load Balancers will know about the new EC2 instances.
Auto Scaling integrates with Elastic Load Balancing to enable you to attach one or more load balancers to an existing Auto Scaling group. After you attach the load balancer, it automatically registers the instances in the group and distributes incoming traffic across the instances
link to above quote can be found here
In terms of scaling down if one of load balancers is reporting an instance as unhealthy then the instance will be considered unhealthy and eventually terminated.
If you configure your Auto Scaling group to determine health status using both EC2 status checks and Elastic Load Balancing health checks, Auto Scaling considers the instance unhealthy if it fails either the status checks or the health check. Note that if you attach multiple load balancers to an Auto Scaling group, all of them must report that the instance is healthy in order for Auto Scaling to consider the instance healthy. If one load balancer reports an instance as unhealthy, Auto Scaling replaces the instance, even if other load balancers report it as healthy
Link to above quote can be found here
I hope this makes things a bit clearer.