For an ALB (which has a security group containing more than one AZ for HA) to make sense, the EC2 instances in the ALB's target group ALSO have to be living on more than one AZ, is that correct?
Otherwise, if all instances are in the same AZ but the ALB supports multiple AZs, this doesn't make sense, am I getting this right?
ALB's target group ALSO have to be living on more than one AZ, is that correct?
It is incorrect. You don't have to place them in more than one 1 AZ. But they still have to be at least in one of the AZs enabled for the ALB - it can't be a different AZ.
And the reason why you don't have to do it, is because for ALB cross-zone load balancing is always enabled:
When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
With Application Load Balancers, cross-zone load balancing is always enabled.
this doesn't make sense, am I getting this right?
Sort of. You ALB requires two AZs for HA. Thus, placing all instances in one of them is not really recommended. But sometimes you have to do it. An example is that your instances in ASG share a pool of EBS volumes. EBS volumes have zonal scope, so you have to bound all your instances to a single AZ.
Related
I'm working my way through a practice exam for an AWS certification. One of the questions is as follows:
The web tier for an a pplication is running on 6 EC2 instances spread
across 2 AZs behind a classic ELB. The data tier is a MySQL database
running on an EC2 instance. What changes will increase the
availability of the application? (select TWO)
A: Turn on CloudTrail in the AWs account
B: Migrate the MySQL database to a Multi-AZ RDS MySQL database instance
C: Turn on cross-zone load balancing on the ELB
D: Launch the web tier EC2 instances in an Auto Scaling Group
E: Increase the instance size of the web tier EC2 instance
Correct answers are B and D. My question is, why is C NOT a correct answer? The instructor (an Amazon employee) glosses over C, explaining that "enabling cross-zone load balancing would have little to no effect on availability." But the way I'm looking at it, if the ELB can't send traffic to both AZ's, then we're effectively making our 6-instance system into a 3-instance system (assuming there are 3 in each AZ). And a single AZ system is never the considered a highly available architecture, since if that one AZ fails, your whole system is unavailable.
Enabling cross-zone load balancing does not impact availability because ELBs can send traffic to all configured AZs without the feature enabled. That's not what cross-zone balancing means.
An ELB configured in two availability zones always has at least two balancer nodes, one in each AZ. You can't see this, directly, but if you look under "Network Interfaces" in the EC2 console, you can find the Elastic Network Interfaces (ENIs) attached to the balancer nodes. Each node has one ENI. The service determines how many nodes a balancer has, based on load. This is managed automatically, and you are not billed based on node count.
Cross-zone load balancing controls what each node can do. "Enabled" means the balancer node in zone A can send traffic to instances in zone A or B, instead of just to instances in zone A, and the same for the balancer node in zone B.
This doesn't improve availability because if an availability zone is lost, then the balancer node in that zone is also lost, so the fact that it could have sent traffic to instances in the other zone is immaterial.
Cross-zone load balancing helps ensure that the workload is spread as evenly as possible across all instances behind the balancer, which helps if you have asymmetry -- such as 3 application instances in one AZ and 2 application instances in the other (in this case, the zone with 2 would see proportionally more traffic per instance than the zone with 3) -- or other cases where the instances are not seeing evenly-balanced workloads, which would be more likely when the number of instances behind the balancer is small or if there is wide variation in request processing time due to the complexity of certain requests compared to others.
What changes will increase the availability of the application?
Increased availability means that there are less time periods where the application is serving requests.
(B) Multi-AZ database will certainly help because if one AZ fails, it will automatically promote the secondary database server in the other AZ
(D) Auto Scaling will certainly help because failed instances will be replaced.
Cross-zone load balancing would help where there are no healthy instances available in an AZ but traffic is being handled by the ELB in that AZ. It is an unlikely scenario, especially with 3 instances in an AZ, but I could understand an argument for it. However, the other two answers are much stronger.
It's worth mentioning that official AWS Certification questions go through several levels of technical review and shouldn't leave such ambiguity in a question. Sample exam questions (be it in an AWS course or otherwise) probably haven't gone through such detailed scrutiny.
I am about to take my AWS Architect Associate Certification Exam and I have some things on ELB and ASG that I still don't get (or maybe I just did not study enough) and I liked to ask your help to clear things out.
Multi-AZ Autoscaling Group
what difference does it make when I say I have one ASG that will handle
autoscaling for 3 AZs rather than have one ASG for each AZ? If fault tolerance
is the answer then the latter should be the standard setup, why have one ASG
for three or two AZs?
Multi-AZ ELB
same kind of question as I had for #1.
3.
Multi-AZ ASG and one ELB for each AZ
Multi-Az ASG and one ELB that serves multiple AZs
One ASG and One ELB for each AZ
What are the use cases for each?
The answer becomes more obvious when you think about the implications and understand what may be some missing details.
If an ASG crosses multiple availability zones, then it can increase capacity in the healthy zones when the instances in a catastrophically failed AZ become unavailable. With one in each, there would be no coordination like this.
The same thing is true for ELB. In both Classic and Application load balancers, when you deploy a single ELB in multiple AZs, you actually get balancer hardware allocated from the beginning in each AZ -- yet the price is the same. If an AZ fails, it fails, and you still have working hardware in the remaining zones.
ELBs and ASGs in a single AZ would not be fault tolerant, and there's no reason to provision separate ones for each AZ, when you can provision just one, and have it handle the failure of an entire availability zone (unlikely, but not impossible) by scaling out (deploying more hardware) capacity in the healthy zones that remain.
AWS recently introduced NLB (Network load balancer) where EIP (Elastic IP) can be linked to a AZ (availability zone). It is recommended to have NLB over multiple AZs hence have multiple EIP linked to each.
But what happens when one of the AZ goes down, does the linked EIP gets linked to other AZ till the original AZ comes back again? This is important if you are using single EIP (i.e. using one AZ for NLB) where such failure can cause traffic failures even though your servers running on multi-AZs are up and running.
Answering my question for anyone struggling with similar question. This is what AWS support responded to my question
Availability zones (AZs) are distinct geographical locations that are engineered to be insulated from failures in other AZs. However, unfortunately when an AZ fails the service is disrupted on that AZ. There would be no IP shift to another AZ automatically[1].
Although AZ failures are rare and AWS takes great efforts to not have such failures, these type of failures can and do occur. For this reason we normally ask users to place resources(NLB) in multiple AZs. This way an application can be protected from failure at a single location. If one zone fails, the application in the other zone can continue to run[2].
[1]https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones
[2]https://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf
The EIP stops working if there are no healthy instances in the AZ, and NLB removes its entry from the load balancer' DNS records. It is added back in when the AZ becomes healthy again.
If one or more target groups does not have a healthy target in an enabled Availability Zone, we remove the IP address for the corresponding subnet from DNS so that requests cannot be routed to targets in that Availability Zone.
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html
For this reason, your callers should respect the DNS TTL.
When launching an Elastic Load Balancer in AWS, I happened to notice two ENI's get created that reference the ELB. The private IP's (assigned through the VPC subnet) for both of these ENI's appears in the httpd access log on my load balanced back-end instance during periodic health checks.
My questions are:
Do these ENI's belong to the ELB (or abstracted ELB instances)?
Are they solely for health check purposes?
Also, under what circumstance would more than two ENI's be created or do only two ENI's appear no matter the number of instances being monitored (I experimented with a single and dual instances and in both cases, only two ENI's were generated)?
Do these ENI's belong to the ELB (or abstracted ELB instances)?
ELB is a logical entity and the multiple ENI's belong to multiple concrete instances of the ELB.
Are they solely for health check purposes?
No
Also, under what circumstance would more than two ENI's be created or do only two ENI's appear no matter the number of instances being monitored (I experimented with a single and dual instances and in both cases, only two ENI's were generated)?
There can be multiple instances serving the ELB based on load. I think by default ELB's start off with 2 instances for redundancy. If the traffic to the ELB increases, more instances are added to handle the load. When the traffic decreases the instances are removed. This is the Elastic part of ELB! The actual IP address or ENIs of the ELB are not guaranteed at any time. So always use the DNS name of the ELB.
We were experimenting with ELB's a bit and it may be that the number of ENIs depends on how many zones are being used by the ELB
my aws auto-scaled instances are not picked up by load-balancer and the auto-scaled instances are recreated frequently,
also is there any problem in using auto-scaled instances and static instances at the same time in aws ELB ?
what are the precautions to take when doing so if it is possible
is there any disadvantages doing so ?
Need to make sure that your autoscaling group is registered with the load balancer appropriately, and that you have the appropriate policies. Really need more details to answer this though.
Don't do it. If you need an instance to be running all the time, configure your group to have a minimum of the number of "static" instances. If you need to run a "static" instance, and a scaling group - you're probably thinking about the problem the wrong way.
One reason could be: If you have configured your autoscaling group for multiple availability zones, but those zones are not added to the associated load balancer. In Management Console, go to Load Balancers -> Instances and verify Availability Zones.
I would go with #Peter H. Modify your design so you don't depend on any particular instance for persistent data. Store persistent data externally in a database or on S3.