Why does one of my ALBs have an Elastic IP associated with it, while others do not? Unable to delete due to permission error.

This is actually normal behavior for internet-facing Application Load Balancers. AWS automatically assigns service-managed public IPv4 addresses to internet-facing ALBs from EC2's public IPv4 address pool. These appear in your AWS account as Elastic IPs with a service_managed attribute set to "ALB".

The key points to understand:

1. These service-managed Elastic IPs are fully managed by the Application Load Balancer service and cannot be modified or released manually by you. This explains the permission error you're seeing when trying to delete it.

2. The reason you see this for one ALB but not others might be because:

• The ALB with the visible Elastic IP is internet-facing, while others might be internal
• AWS has been making these service-managed IPs more visible in customer accounts since early 2024 (particularly after they started charging for public IPv4 addresses)

3. This is not a misconfiguration. The ALB service automatically manages these IPs and will release them back into the public IPv4 address pool when they are no longer needed.

If you no longer need the ALB and want to release the associated Elastic IP, you would need to delete the ALB itself. The service will then automatically release the associated Elastic IP addresses.

If you require static IP addresses for your ALB (for allow-listing purposes), the recommended approach is to place a Network Load Balancer (NLB) in front of the ALB, as NLBs support static Elastic IPs that you can manage.
Sources
Elastic IP created automatically by ALB and I cannot disassociate or delete | AWS re:Post
Application Load Balancers - ELB

An Application Load Balancer (ALB) does not natively support Elastic IPs. So this is not normal ALB behavior.

If you see an Elastic IP (EIP) “associated” with an ALB in the console, it is usually because:

• The EIP is attached to a Network Interface (ENI) that was created by:
• an AWS-managed service, or
• a previous architecture (for example: NLB → ALB migration, PrivateLink, or an old workaround)
• The ENI looks related to the ALB, but the EIP is not directly owned by the ALB
• In some cases, the EIP is owned by an AWS service account, not your IAM user

So this is not a valid ALB configuration, but rather a leftover or indirect association.