Common Mistakes I See Students Make
These are the load balancer mistakes I see after the lab: calling two A records a balancer, a health check left unhealthy, and trying to put another region inside one balancer. Read them once.
मित्रांनो, load balancer च्या या चुका मी lab नंतर बघतो: दोन A records ला balancer म्हणणे, health check unhealthy, आणि region एकाच balancer मध्ये घुसवणे. एकदा वाचून ठेवा.
दोस्तों, load balancer की ये गलतियाँ मैं lab के बाद देखता हूँ: दो A records को balancer कहना, health check unhealthy, और region एक ही balancer में घुसाना. एक बार पढ़कर रखो.
- Calling two A records a load balancer. IP1 still gets visitors after instance A is stopped. There is no health check.
- Installing Nginx on the load balancer. You cannot SSH to
lab-alband runsudo yum. Nginx stays on the EC2 instances. - Thinking one DNS name means one EC2. The lab count is 2. The minimum that answers is 1. Zero healthy targets is a 502.
- Creating the balancer in only one subnet. An Application Load Balancer asks for two Availability Zones.
- Forgetting to allow port 80 from
lb-sg. Your own IP can open the instance, and the target stays unhealthy because the balancer is a different source. - Judging the page while the target is still initial. Wait until the status says healthy.
- Putting instance B only in
site-b-tgand expecting round robin on/. Round robin runs inside one group./usessite-a-tg. - A path rule that does not match.
/apiwithout the star can miss/api/. The lab value is/api/*. Check the priority number. - Expecting a Network Load Balancer to read the Host header. Host and path rules are the Application Load Balancer.
- Expecting the Application Load Balancer's address to be the static IP a partner typed last year. That fixed address is the Network Load Balancer.
- Opening a Classic balancer for a new lab.
- Adding a Singapore instance to
lab-alb. One Application Load Balancer does not span regions. The second region needs its own balancer. Route 53 chooses which balancer. - Turning on latency and geolocation for the same name and not knowing which answer you will get.
- Stopping the only healthy instance while the new one is still initial.
- Deleting the instances and leaving
lab-albbehind. Delete the balancer when class ends. Delete the extra Route 53 records you added for the paper region if you created them. Deregister targets first if the console asks. - One target group for pages, API, and checkout. A browsing spike then shares the checkout instances. Separate groups, with different desired counts.
- A health check path of
/when the app returns 302 to login. Every target looks unhealthy. Use/healthand a 200 with no login. - Making
/healthwait on the database. A short database blip then removes healthy web instances. - Putting the app tier balancer on the internet. Anyone can skip the web tier. Scheme internal, private subnets, 8080 only from the web security group.
- Trying to edit an existing balancer from internet-facing to internal. Create a new one. The scheme is chosen at create time.
- Registering RDS in the web target group. No load balancer in front of the primary. Writes do not round-robin across two primaries.
- Looking for a cross-zone switch on an Application Load Balancer. It is already on. The switch you can set is on a Network Load Balancer.
- Expecting one Application Load Balancer in Mumbai to own EC2 instances in Ireland. One public name, two balancers, Route 53 in front. That is not cross-zone.
- Latency records with no evaluate-target-health. A dead Mumbai group can still be the answer for Pune. Failover needs the health check.