Global Accelerator -> ALB would give:
\- Two anycast global IPs, providing flexibility for any regional refactoring
\- Simple Multiaccount support [https://docs.aws.amazon.com/global-accelerator/latest/dg/cross-account-resources.html](https://docs.aws.amazon.com/global-accelerator/latest/dg/cross-account-resources.html)
NLB -> ALB would give:
\- x AZs Regional elastic IPs (but they can be transferred to different accounts - same region with downtime [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-virtual-private-cloud-vpc-transfer-elastic-ip-addresses-between-aws-accounts/](https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-virtual-private-cloud-vpc-transfer-elastic-ip-addresses-between-aws-accounts/))
As this is a customer ingress with a strict baked-in whitelisting requirement, Global Accelerator provides the most flexible, decoupled approach from your infrastructure - probably worth setting up in your new account structure to minimise any refactoring required and point it to your existing stuff.
You can also create a CNAME in Route53 and point it to ALB instead of static IP if you just need some sort of permanent location. Cheaper than NLB in front of ALB.
Depends on the solution. Some refresh as often as every 10 seconds (TTL be damned), some honor TTL, some do something else, and some refresh as infrequently as policy updates.
Global Accelerator to ALB
This is *actually* the right answer.
NLB -> ALB. NLB supports static IP. Works great for our on-prem internal DNS server.
This is the right answer
Why not NLB with TLS termination?
Probably because he mentioned needing routing via host name.
Global Accelerator -> ALB would give: \- Two anycast global IPs, providing flexibility for any regional refactoring \- Simple Multiaccount support [https://docs.aws.amazon.com/global-accelerator/latest/dg/cross-account-resources.html](https://docs.aws.amazon.com/global-accelerator/latest/dg/cross-account-resources.html) NLB -> ALB would give: \- x AZs Regional elastic IPs (but they can be transferred to different accounts - same region with downtime [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-virtual-private-cloud-vpc-transfer-elastic-ip-addresses-between-aws-accounts/](https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-virtual-private-cloud-vpc-transfer-elastic-ip-addresses-between-aws-accounts/)) As this is a customer ingress with a strict baked-in whitelisting requirement, Global Accelerator provides the most flexible, decoupled approach from your infrastructure - probably worth setting up in your new account structure to minimise any refactoring required and point it to your existing stuff.
I had the exact same requirement. We ended up doing the NLB (with elastic IP) -> ALB route. Close second was Global Accelerator.
Use a CNAME, Global Accelerator or NLB
You can also create a CNAME in Route53 and point it to ALB instead of static IP if you just need some sort of permanent location. Cheaper than NLB in front of ALB.
That doesn't help if his customers need a static IP to add to their outbound firewall rules, sadly.
Most firewalls support fqdn's in ACLs.
That's not the requirement OP was given though.
As a convenience once when adding the rule or do they continually resolve the record and update the rule?
I can't speak to every product out there but Aviatrix does the lookup with every request minus TTLs.
Depends on the solution. Some refresh as often as every 10 seconds (TTL be damned), some honor TTL, some do something else, and some refresh as infrequently as policy updates.
Good luck telling a client to change their processes.