Internal ALB is placed in a public subnet.

The warning you received is somewhat misleading, and I can clarify the situation for you.

An internal Application Load Balancer (ALB), even when placed in a public subnet, cannot directly receive internet traffic. Here's why:

1. Internal ALBs, regardless of the subnet they're placed in, only have private IP addresses. They do not have public IP addresses associated with them.

2. The DNS name of an internal ALB resolves only to private IP addresses. This means that it cannot be accessed directly from the internet, as internet clients cannot route to private IP addresses.

3. The key distinction between internal and internet-facing load balancers is not the subnet they're in, but rather how their DNS names resolve and the type of IP addresses they use.

The warning you're seeing is likely meant to highlight a best practice rather than indicate an actual security risk. It's generally recommended to place internal ALBs in private subnets because:

1. It aligns with the intended use of internal load balancers, which is to route traffic within your VPC.
2. It helps maintain a clear separation between public-facing and internal resources.
3. It reduces the chance of misconfiguration that could potentially expose the load balancer to unwanted traffic.

However, the internal ALB is not exposed to the internet just because it's in a public subnet. The "can receive internet traffic" part of the warning is misleading.

In practice, your internal ALB will still only be accessible from within your VPC or from connected networks (like through a VPN or Direct Connect), regardless of whether it's in a public or private subnet. The subnet placement doesn't change its fundamental behavior as an internal load balancer.
Sources
Internal Classic Load Balancers - Elastic Load Balancing
How Elastic Load Balancing works - Elastic Load Balancing
Internet-facing Classic Load Balancers - Elastic Load Balancing