Unable to release service-managed Elastic IPs after switching ALB to dualstack-without-public-ipv4

Yes, these are service-managed Elastic IPs that AWS releases automatically - you cannot and should not attempt to release them manually.

Application Load Balancers use Public Elastic IPv4 addresses from EC2's public IPv4 address pool, which are visible in your AWS account when you view Elastic IPs in the console or use the describe-addresses CLI/API. Each ALB-associated IP address is marked with a service_managed attribute set to "ALB".

While these IPs appear in your account, they remain fully managed by the Application Load Balancer service. You cannot modify or release them yourself, which is why you're receiving the "OperationNotPermitted" error. The Application Load Balancer service will automatically release these IPs back into the public IPv4 address pool when they are no longer in use.

The timeline for automatic release can vary and may take longer than the connection draining period. Since you switched to dualstack-without-public-ipv4, the ALB service should eventually release these IPs as they're no longer needed for your load balancer's configuration. However, the exact timeline isn't specified and may extend beyond the 24+ hours you've already waited.

You should continue to monitor these IPs, but no action is required on your part. The service will handle the cleanup automatically. If the IPs persist for an unusually long time (several days), you may want to contact AWS Support for clarification on the specific timeline for your case.
Sources
Application Load Balancers - Elastic Load Balancing

These Elastic IPs are service-managed by the ALB service — you cannot release them manually, and the OperationNotPermitted error you're seeing is expected behavior. The ALB service owns and controls the lifecycle of these IP addresses.

Why they're still there after 24+ hours:

When you switch an ALB from dualstack to dualstack-without-public-ipv4, the public IPv4 addresses are not immediately removed. This is by design to allow existing IPv4 client connections to drain gracefully. According to the AWS blog post on this feature, the draining period is calculated as:

│ client_keep_alive.seconds + 1 hour

Since your client_keep_alive is set to 3600 seconds (1 hour), the expected draining window is approximately 2 hours. After this period, the public IPv4 addresses should be automatically removed from the load balancer network interfaces.

However, the recommended migration procedure (Option 2 in the blog) suggests you should:

1. Reduce client_keep_alive.seconds to 60 seconds before switching the IP address type — this shortens the draining window significantly.
2. Switch the IP address type to dualstack-without-public-ipv4.
3. Wait at least 1 hour + the client keepalive value after the switch.
4. Restore client_keep_alive.seconds to its original value.

Since you kept client_keep_alive at 3600 seconds during the switch, the draining period should have been ~2 hours, which has already passed.

What to do now:

1. Do not attempt to manually release these EIPs. They are service-managed and will return OperationNotPermitted regardless of your IAM permissions.
2. Verify the ALB no longer has public IPv4 addresses by checking the Network Mapping tab in the EC2 console, or by running: aws elbv2 describe-load-balancers --names 000-load-balancer --query 'LoadBalancers[].AvailabilityZones[].LoadBalancerAddresses'

Also verify with DNS: dig 000-load-balancer-<id>.<region>.elb.amazonaws.com A +short

If no A records are returned (only AAAA), the IPv4 transition is complete. 3. Check if the EIPs still show as associated in the EC2 > Elastic IPs console. If they appear as "associated" with an ENI that has a description like "ELB net/..." or "ELB app/...", they are still managed by the ALB service. The service will release them automatically once the internal de-provisioning completes. 4. If the EIPs persist beyond 48 hours after the switch and DNS confirms no A records are being returned, open an AWS Support case with the ELB service team. Include the load balancer ARN, the two EIP allocation IDs, and the timestamp of when you changed the IP address type. There may be an internal delay in the deprovisioning pipeline.

Summary: No manual release is required or possible — these are service-managed IPs. AWS will release them automatically. If they persist significantly beyond the expected draining window, contact AWS Support for investigation.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Sources:

• AWS Blog: Introducing dual-stack without public IPv4 ALB
• ALB Documentation: IP address type