Azure Container Apps - How to close Port 80 on the managed public IP?

Shreeraksha.G 45 Reputation points
2026-06-26T15:38:39.6266667+00:00

We have identified that the public IP is associated with an Azure Container Apps managed environment. The corresponding Azure-managed Load Balancer contains both HTTP (Port 80) and HTTPS (Port 443) load balancing rules (http and https).

The customer's requirement is to completely close Port 80 and expose only Port 443 externally.

Could you please confirm :

  1. Are the http and https load balancing rules automatically created and managed by the Azure platform?
  2. Can these load balancing rules be modified or removed by customers?
  3. Is there any supported method to completely disable Port 80 on the Azure Container Apps managed ingress, or is HTTP-to-HTTPS redirection (allowInsecure = false) the only supported behavior?
  4. If exposing only Port 443 is required, what is the Microsoft-recommended approach?
Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.


2 answers

Sort by: Most helpful
  1. Divyesh Govaerdhanan 11,725 Reputation points MVP Volunteer Moderator
    2026-06-26T18:24:24.59+00:00

    Hi Shreeraksha.G,

    Welcome to Microsoft Q&A,

    1. Are the http/https LB rules platform-managed?

    Yes. Both ports 80 and 443 are exposed by design on the Container Apps managed environment, this is documented as fixed platform behavior, not something configured per app.

    2. Can customers modify or remove these LB rules?

    No. The managed Load Balancer and its public IP live in the platform-managed resource group, not your subscription's resource group or subnet. You don't have access to edit or delete these rules directly.

    3. Is allowInsecure = false the only supported behavior for HTTP?

    Yes, on the app level. With allowInsecure set to false (the default), HTTP requests on port 80 get automatically redirected to HTTPS on 443. The port 80 listener itself still exists at the platform LB to handle that redirect, there's no app-level setting to make port 80 stop listening entirely.

    4. Microsoft-recommended approach to fully expose only 443

    External environment (public managed IP): Closing port 80 at the network layer isn't supported. The official guidance is explicit that NSG or firewall rules can't lock down inbound traffic on an external workload profile environment, since that traffic doesn't route through your subnet at all. The supported path here is to put Azure Front Door or Application Gateway in front of your Container App and block port 80 at that layer instead, then point your public DNS/clients at the Front Door or App Gateway endpoint rather than the Container App's own FQDN.

    Internal environment (VNet-injected): Here inbound traffic does route through your subnet, so this is the one case where blocking port 80 is genuinely possible. Apply an NSG rule on your container app's subnet that denies inbound TCP on ports 80 and 31080 while still allowing 443 and 31443. This works because the internal environment's edge proxy listens on those exact ports behind the internal load balancer.

    Please Upvote and accept the answer if it helps!!

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. Rakesh Mishra 11,340 Reputation points Microsoft External Staff Moderator
    2026-07-07T13:16:20.0533333+00:00

    Hello Shreeraksha.G,

    Thank you for bringing this scenario to the Microsoft Q&A community.

    To achieve your customer's goal of completely disabling Port 80, it is crucial to understand that Azure Container Apps (ACA) handles ingress differently depending on whether the environment is deployed as External or Internal.

    By design, the platform automatically provisions a managed Standard Load Balancer that exposes both HTTP (Port 80) and HTTPS (Port 443). Because these resources reside in a Microsoft-managed node resource group, they cannot be directly modified or deleted. While setting allowInsecure = false handles HTTP-to-HTTPS redirection, the official documentation clarifies its limits: "Set allowInsecure to false (the default) to enforce HTTPS redirects." It does not drop the port 80 listener at the load balancer level.

    To truly block Port 80, you must implement network-level controls based on the environment type:

    1. External Environments (Public Managed IP)
    For external deployments, the platform load balancer sits completely outside of your virtual network. Therefore, you cannot apply an NSG to filter its inbound traffic.

    • The Recommendation: You must implement a Layer 7 service such as Azure Front Door or Azure Application Gateway configured to listen strictly on Port 443.
    • Securing the App: Once the front-end service is in place, you use ACA's built-in IP Restrictions. According to the Azure documentation on IP restrictions: "You can define rules to allow or deny traffic from specific IP addresses or ranges." By configuring a rule that only allows the specific outbound IPs of your Front Door/App Gateway and denying all other traffic (0.0.0.0/0), the Container App becomes unreachable directly via Port 80 from the public internet.

    2. Internal Environments (VNet-Injected)
    If the Container Apps environment is injected into a custom Virtual Network (Internal), the ingress IP is assigned directly from your delegated subnet. This makes it possible to block Port 80 natively using a Network Security Group (NSG).

    • The Recommendation: As outlined in the ACA VNet security guidelines, the internal edge proxy listens to HTTP on port 31080 and HTTPS on port 31443. You must apply an NSG to the delegated subnet that explicitly denies inbound TCP traffic on ports 80 and 31080, while allowing ports 443 and 31443.

    If you found this information helpful, please click "Accept Answer" and "Upvote" to help others in the community find this solution.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.