iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🌐

Azure Container Apps Ingress Configuration Pattern Example 2 (Microservices)

に公開
Azure
Network
Azure Container Apps
tech

Introduction

This article is a record of my experience building and testing Ingress configuration patterns in Azure Container Apps.

https://zenn.dev/georgeosddev/articles/azure-container-apps-ingress-architecture-patterns

In this article, we will cover Pattern ②.

Configuration

The environment I created is as follows. In this case, the (Optional) components included in the mermaid diagram above are omitted.
In the environment created in Pattern ①, I will limit the Ingress of aca-without-vnet to within the environment.

https://zenn.dev/georgeosddev/articles/azure-container-apps-ingress-pattern-1

Container Apps

aca-without-vnet

By configuring Ingress to limit traffic within the environment, .internal. will be displayed in the FQDN.

  • As I tested in Pattern ①, the .internal. FQDN can be used even if traffic is not limited to within the environment.

app-ingress-limited

$ az containerapp show -g zenn-aca-without-vnet -n aca-without-vnet \
  --query "properties.{environmentId: environmentId,
                       configuration: {ingress: configuration.ingress},
                       latestRevisionFqdn: latestRevisionFqdn,
                       outboundIpAddresses: outboundIpAddresses}" \
  -o json

{
  "configuration": {
    "ingress": {
      "additionalPortMappings": null,
      "allowInsecure": false,
      "clientCertificateMode": "Ignore",
      "corsPolicy": null,
      "customDomains": null,
      "exposedPort": 0,
      "external": false, // ★★★ external is false
      "fqdn": "aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io", // ★★★ .internal. is added to the FQDN
      "ipSecurityRestrictions": null,
      "stickySessions": {
        "affinity": "none"
      },
      "targetPort": 80,
      "targetPortHttpScheme": null,
      "traffic": [
        {
          "latestRevision": true,
          "weight": 100
        }
      ],
      "transport": "Auto"
    }
  },
  "environmentId": "/subscriptions/<Subscription ID>/resourceGroups/zenn-aca-without-vnet/providers/Microsoft.App/managedEnvironments/aca-env-without-vnet",
  "latestRevisionFqdn": "aca-without-vnet--internal.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io", // ★★★ .internal. is added to the FQDN
  "outboundIpAddresses": [
    "20.210.72.88",
    "20.210.72.103",
    "135.149.35.113",

    ... // omitted Total of 70 public IP addresses included.

  ]
}

Verifying Routing to the Application

Access from Clients Outside the Env

An HTTP request to aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io resolves to the Env's staticIp of 130.33.219.240, but it results in a 404 response.

This response is identical to the response when a non-existent App name is specified, as confirmed in Pattern ①.

404

$ curl -v https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/
*   Trying 130.33.219.240:443...
* Connected to aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io (130.33.219.240) port 443 (#0)

<omitted>

> GET / HTTP/2
> Host: aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
> user-agent: curl/7.81.0
> accept: */*
>
<!DOCTYPE html>
<html>
<head>
    <title>Azure Container App - Unavailable</title>

<omitted>

<div id="feature">
    <div id="content">
        <h1 id="unavailable">Error 404 - This Container App is stopped or does not exist.</h1>
        <p id="tryAgain">The Container App you have attempted to reach is currently stopped or does not exist.</p>
        <p id="toAdmin">If you are the Container App administrator, please visit <a href="https://portal.azure.com/">Azure Portal</a>.</p>
    </div>
</div>
</body>
</html>
* Connection #0 to host aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io left intact

aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io also results in a 404 and cannot be accessed from outside the Env.

$ curl -I https://aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io/
HTTP/2 404
content-type: text/html; charset=utf-8
content-length: 1946
date: Wed, 07 Jan 2026 08:09:00 GMT

Access from Within the Env

As before, I will test from an Nginx container.

Access via Default FQDN (without .internal.)

It resolves to a public IP and results in a 404. This is equivalent to accessing it from outside the Env.

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# nslookup aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io
Address: 130.33.219.240

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# curl -I https://aca-without-vnet.whitemoss-043fed62.japaneast.azurecontainerapps.io/
HTTP/2 404
content-type: text/html; charset=utf-8
content-length: 1946
date: Wed, 07 Jan 2026 08:17:24 GMT

Access via .internal. FQDN

It resolves to a private IP and we get a 200 response.

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# nslookup aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
;; Got recursion not available from 127.0.0.11
Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io
Address: 100.100.0.210
;; Got recursion not available from 127.0.0.11

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# curl -I https://aca-without-vnet.internal.whitemoss-043fed62.japaneast.azurecontainerapps.io/
HTTP/2 200
accept-ranges: bytes
content-length: 4332
content-type: text/html; charset=utf-8
last-modified: Mon, 13 Oct 2025 15:12:40 GMT
date: Wed, 07 Jan 2026 08:17:51 GMT

Access via <AppName>

It resolves to a private IP and we get a 200 response.

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# nslookup aca-without-vnet
;; Got recursion not available from 127.0.0.11
Server:         127.0.0.11
Address:        127.0.0.11#53

Name:   aca-without-vnet.k8se-apps.svc.cluster.local
Address: 100.100.241.104
;; Got recursion not available from 127.0.0.11

root@aca-without-vnet-2--0000002-77756d5fdc-hdcwc:/# curl -I http://aca-without-vnet
HTTP/1.1 200 OK
accept-ranges: bytes
content-length: 4332
content-type: text/html; charset=utf-8
last-modified: Mon, 13 Oct 2025 15:12:40 GMT
date: Wed, 07 Jan 2026 08:18:36 GMT

Summary

I have successfully ensured that the application deployed in aca-without-vnet cannot be accessed from the outside, just as expected.

The following sample using this configuration has been published:

Also, Module 2 of the following workshop uses a similar configuration:

In this configuration, communication between apps within the Env used curl from the FrontApp console, which is equivalent to implementing HTTP communication within the application.
In addition to direct application-to-application communication, another method is to use Dapr service-to-service invocation. I plan to verify this in another article.

Discussion