Hey there, let's work through your NLB issue step by step—great job getting the API Gateway + EC2 setup working already, that's solid progress for an AWS newbie! Let's break down the warning you're seeing and the request errors first.

First: Understand the NLB Subnet Warning #

The message There is an Internet Gateway attached to these subnets is AWS's way of flagging a potential misalignment between your NLB type and subnet configuration:

• If you created an Internal NLB: These are meant to live in private subnets (no IGW attached) since they're only accessible within your VPC. If your subnets have an IGW, AWS warns you because this breaks the "internal-only" intent and could expose resources unexpectedly.
• If you created an Internet-facing NLB: These need to be in public subnets (with an IGW attached) to accept traffic from the internet. In this case, the warning might be a harmless heads-up, but you should still confirm your subnet route tables have a 0.0.0.0/0 route pointing to the IGW.

First step: Double-check your NLB's scheme in the AWS Console (under NLB > Details > Scheme). Fix the subnet alignment based on that type.

Troubleshooting the Request Errors #

Let's walk through the most common issues that cause broken traffic when adding an NLB between API Gateway and EC2:

1. Verify API Gateway's Integration Target #

You used to proxy directly to your EC2 instance—now you need to update API Gateway's integration to point to your NLB's DNS name (e.g., my-nlb-1234567890.us-east-1.elb.amazonaws.com). Make sure:

• The endpoint matches the NLB's full DNS (not an IP, since NLBs use dynamic IPs)
• The port matches the listener port you configured on the NLB (e.g., 80 for HTTP, 443 for HTTPS)

2. Audit Security Group Rules #

Security groups are the #1 culprit for blocked traffic in AWS:

• NLB Security Group: Allow incoming traffic from API Gateway to your NLB's listener port. For simplicity (while testing), you can allow 0.0.0.0/0 to the port. Later, you can restrict it to AWS's API Gateway prefix lists for tighter security.
• EC2 Security Group: Instead of allowing all internet traffic, only allow incoming traffic from your NLB's security group to your application's port (e.g., 8080). This ensures only the NLB can reach your EC2 instances.

3. Check Target Group Health Status #

If your NLB isn't forwarding traffic, it's almost always because the target group thinks your EC2 instances are unhealthy:

• Go to the Target Groups console, select your group, and check the Targets tab. Look for healthy/unhealthy status.
• If unhealthy:
  • SSH into your EC2 instance and test the health check path directly (e.g., curl localhost:8080/health) to confirm your app is running and responding.
  • Ensure your health check configuration (path, port, timeout, success code) matches what your app expects. For example, if your app doesn't have a /health endpoint, the check will fail.
  • Confirm your EC2 security group allows incoming traffic from the NLB for health checks (covered in step 2).

4. Validate Subnet & Routing #

• For Internet-facing NLBs: Confirm your subnets are public (route table has 0.0.0.0/0 → IGW) and that the NLB's elastic network interfaces (ENIs) have public IPs assigned.
• For Internal NLBs: You can't use a regular HTTP proxy integration with API Gateway—you need to set up a VPC Link (Private Integration) to let API Gateway access the internal NLB. This is a common newbie pitfall!

5. Test the Traffic Path Step-by-Step #

Isolate where the failure is happening:

1. First, test directly accessing the NLB's DNS name (e.g., curl http://my-nlb-dns-name) from your local machine. If this fails, the problem is between NLB and EC2—focus on steps 2-4.
2. If the NLB test works, test your API Gateway endpoint. If this fails, double-check the API Gateway integration settings and ensure it's allowed to communicate with the NLB.

Prepping for Auto Scaling Groups (ASG) #

Once your NLB is working smoothly, integrating ASG is straightforward:

• When creating your ASG, link it to your NLB's target group in the "Advanced details" section. This way, new EC2 instances launched by the ASG will automatically register with the NLB, and terminated instances will be removed.
• Make sure your ASG's launch template includes:
  • The correct security group (that allows traffic from the NLB)
  • A user data script to automatically start your application server on boot (so new instances are ready to accept traffic)
  • The right AMI and instance type for your workload

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