AWS Outpost doesn't support NLBs/CLBs indeed. Which makes it impossible to use the default OpenShift ingress which by default is exposed using NLB/CLB. The ALBO is suggested as a replacement in the OCP docs. That can be a workaround but in that case the end user needs to shift the focus to Ingress objects instead of Route.

Also, in the context of the GA readiness, we need to note that the ALBO is an addon operator, so it's not available on the OpenShift cluster out of the box - it has to be installed explicitly by the end user or the cluster admin.

There needs to be RnD work to validate the ALBO is working with AWS Outpost.

Worth exploring other possibilities if we haven't already:

• Could we run the router pods on control-plane nodes? (This option seems simplest, but maybe it defeats the purpose of using AWS Outpost, if the goal is to have remote worker nodes close to the client.)
• Could we run the router pods on worker nodes but use host networking and round-robin DNS pointing directly to those worker nodes? (Somewhat complicated, especially the DNS-management part, but probably easier than using ALBO.)
• For that matter, do the use-cases that involve AWS Outpost require having multiple router-pod replicas, or could we have just one router-pod replica on a dedicated worker node using host networking with a single DNS A record pointing to that node? (This would be fairly simple to do by pinning the router pod to a specific node and having the operator or installer configure a DNS A record for that node.)
• Could we use a NodePort service and put an HAProxy instance in front of the router pods, basically taking the place of an ELB?
• Could we treat these clusters as disconnected clusters, make the default IngressController private, configure a DNS A record pointing to the cluster service IP address, and tell customers that they gotta figure out ingress on their own (maybe using ALBO, maybe using some third-party solution)?