My reading around has brought me to the conclusion that an Azure Web App itself, without use of any other azure device, can only ever be reached publicly on ports 80 and 443
It seems that advice like creating a config key of WEBSITES_PORT is not relevant to the public presentation of the service; it relates to the internal port my app might open inside the docker container that Azure runs the app; to whit, setting an WEBSITES_PORT of 1337, will not mean I can open a web browser, type http://mysite.azurewebsites.net:1337/index.html and see my app's home page. As I'm creating a C# .NET 7 REST API, the details of which port it opens internally aren't relevant to me, as the publish or startup process seems to decide on 8080 or 8081 etc and map it appropriately; the app still appears publicly to use 80 and/or 443
Am I correct in thinking that an Azure Application Gateway can open a custom public port, and be used to redirect traffic so that public users would hit the gateway, and the traffic would be silently redirected through to the web app (which perhaps could then exist solely on a private IP on a virtual network shared with the AAG)?
If I have an external service that expects to send me http traffic on port 1337, and only the host is configurable/the port is hardcoded into that service and cannot be changed, is the only way I can have an Azure Web App (not a VM, container, or any other kind of azure service) receive that HTTP data is to run an AAG to accept publicly on http://some_host.com:1337 and route it through to my Web App? Or does Azure offer some other way to make by webapp contactable on a non standard port?
The monthly cost for an AAG is incredibly high for this "TCP redirect" facility I need from it; while an AAGv1 cost is more realistic at around a tenth of the price, I cannot create an AAGv1 because it is deprecated and the deployment fails