Hey there! Let me walk you through exactly how to set up AWS Load Balancing to automatically shift traffic to your healthy EC2 instance when one goes down. I’ve configured this setup countless times for web services, so let’s break it down into clear, actionable steps.

Target groups are where you define your EC2 instances and the rules for checking if they’re healthy. Here’s how to set one up:

• Head to the EC2 Console, find the Target Groups section under "Load Balancing", and click "Create target group".
• Choose Instances as the target type, give it a meaningful name (like my-app-targets), and select the same VPC that your EC2 instances are running in.
• Configure health checks: Pick the protocol (HTTP/HTTPS) and port matching your app (e.g., 80 for HTTP), then set a health check path (I recommend a dedicated endpoint like /health that returns a 200 OK status when your app is running). This is critical—this is how the load balancer knows if an instance is alive.
• Register your two EC2 instances: Search for their instance IDs, select both, and add them to the target group. Finish creating the group.

For most web-based workloads, an ALB is the right choice (it’s layer 7, so it can handle HTTP/HTTPS and route based on paths if needed later). Here’s the setup:

• Go to the Load Balancers section in the EC2 Console, click "Create load balancer", and select "Application Load Balancer".
• Name your ALB (e.g., my-app-alb), choose "Internet-facing" if your app needs public access (or "Internal" for private services), and select the same VPC as your instances. Make sure to pick at least 2 Availability Zones for high availability (this prevents the load balancer itself from being a single point of failure).
• Configure security groups: Create or select a security group that allows incoming traffic on your app’s port (e.g., 80 for HTTP) from your desired sources. Also, ensure your EC2 instances’ security groups allow incoming traffic from the ALB’s security group on the app port.
• Set up a listener: Add a listener for your app’s protocol/port (e.g., HTTP:80), and set the default action to "Forward to" the target group you created earlier.
• Complete the setup and wait for the ALB to reach an "Active" status (this usually takes a few minutes).

Once everything is up, verify that the failover works as expected:

• Go back to your target group and check the Health status column—both instances should show as healthy.
• Test the failover: Manually stop one of your EC2 instances. After a few minutes (depending on your health check interval), the target group will mark that instance as unhealthy. The ALB will automatically stop sending traffic to it and route all requests to the healthy instance.
• Bring the stopped instance back up: Once it’s running and passes health checks, the target group will mark it as healthy again, and the ALB will resume distributing traffic across both instances.

The default health check settings might not be perfect for your app—adjust them to match your workload:

• In your target group’s Health checks tab, you can modify:
  • Interval: How often the load balancer checks instance health (default 30 seconds; I often use 10 seconds for faster failover).
  • Timeout: How long to wait for a response (default 5 seconds).
  • Unhealthy threshold: Number of failed checks before marking an instance as unhealthy (default 2).
  • Healthy threshold: Number of successful checks before marking it healthy again (default 2).
• Pro tip: Make sure your /health endpoint is lightweight—avoid running heavy database queries or complex logic here. It should quickly return 200 OK when the app is operational.

• Ensure both EC2 instances are in the same VPC and that their security groups allow traffic from the ALB’s security group.
• If you’re using HTTPS, get a free SSL certificate from AWS Certificate Manager (ACM) and attach it to your ALB’s HTTPS listener.
• The ALB itself is highly available as long as you selected multiple Availability Zones—you don’t need to worry about it going down.

内容的提问来源于stack exchange，提问作者Jhon