Azure Container Apps Express が Japan East / Japan West と VNET Integration に対応したので試した

Build 2026 のタイミングで Public Preview になった Azure Container Apps Express ですが、これまで利用可能なリージョンが 2 つしかなかったのと、対応している機能がかなり少なかったので検証ぐらいしかしてませんでしたが、最近のドキュメント更新で Japan East / Japan West と VNET Integration に対応したので再度試すことにしました。

ちなみに VNET Integration 以外にも Private Endpoints や Volume mount などかなり機能が増えているので、Dapr を使っていないユースケースであれば大体対応できるようになったと思います。

既に何回か話していると思いますが、Container Apps Express は ACA Sandboxes や Foundry Hosted Agent と同じ MicroVM 基盤を使っていて、Hosted Agent の対応リージョンがかなり多かったので Japan East の対応は時間の問題でした。Japan East でのキャパシティの拡充が進んだ結果と考えると嬉しい部分です。

Japan East にデプロイする

ACA Express のデプロイは containerapps.azure.com を使いますが、少し前に Japan East と Japan West へのデプロイにも対応したので簡単に確認できます。対応リージョンが増えたので UI が少しおかしい部分がありましたが、デプロイ自体は問題ありません。

Azure CLI を使うと Container Apps の Portal で対応していない機能も使えることがあるので、こちらでのデプロイ方法を知っておいて損はしないです。ドキュメントも用意されているので迷うことはないはずです。

実際に Japan East に Azure CLI を使って ACA Express をデプロイする場合は、以下の 2 つを実行するだけで済みます。ACA Express は Container Apps Environment の種類扱いなので、Environment を Express として作成するように指定します。

# Japan East を指定して Express の Environment をデプロイ
az containerapp env create --environment-mode express --name <ENVIRONMENT_NAME> --resource-group <RESOURCE_GROUP> --location japaneast --logs-destination none

# サンプルの Container App をデプロイ
az containerapp up --image docker.io/nginx --name <APP_NAME> --resource-group <RESOURCE_GROUP>

作成が終われば Container Apps の Portal から Japan East に作成されたことが確認できます。

特に難しいことはないので、Preview ですが Japan East / Japan West での ACA Express の検証が捗るはずです。例によって特に Japan East ではキャパシティの問題は出てくるかもしれませんが、Hosted Agent など多くのサービスで共有しているので、それなりに大きなキャパシティが確保されていると期待したいです。

VNET Integration を有効化してデプロイする

Japan East へのデプロイは正直おまけで、本命は VNET Integration の確認です。ACA Express がどれだけ優れたサービスであっても、VNET Integration が使えないと本番利用が難しいケースが多いので、実装を待ち望んでいた機能の一つです。

残念ながら Portal からの作成は現状行えません。Express の作成時に設定項目自体は存在しますが、以下のようにグレーアウトして無効化されている状態です。

例によって REST API や ARM Template / Bicep 経由であれば問題なく作成できるので、今回は以下のようなシンプルな Bicep を用意して VNET と VNET Integration を有効化した ACA Express を作成していきます。

重要なのは infrastructureSubnetId の指定だけです。ここに Microsoft.App/environments に委譲したサブネットの ID を指定すれば VNET Integration が有効化されます。

@description('Deployment region. Container Apps Express is currently available in Japan East.')
param location string = 'japaneast'

@description('Prefix used for resource names.')
param namePrefix string = 'aca-express-vnet'

@description('Virtual network address space.')
param vnetAddressPrefix string = '10.20.0.0/16'

@description('Dedicated subnet for the Container Apps Express environment. /27 or larger is recommended.')
param infrastructureSubnetPrefix string = '10.20.0.0/27'

@description('Container image used for the connectivity test.')
param containerImage string = 'mcr.microsoft.com/k8se/quickstart:express'

var vnetName = '${namePrefix}-vnet'
var subnetName = 'container-apps'
var environmentName = '${namePrefix}-env'
var appName = '${namePrefix}-app'

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        vnetAddressPrefix
      ]
    }
  }
}

resource infrastructureSubnet 'Microsoft.Network/virtualNetworks/subnets@2024-05-01' = {
  parent: vnet
  name: subnetName
  properties: {
    addressPrefix: infrastructureSubnetPrefix
    delegations: [
      {
        name: 'container-apps'
        properties: {
          serviceName: 'Microsoft.App/environments'
        }
      }
    ]
  }
}

resource environment 'Microsoft.App/managedEnvironments@2025-10-02-preview' = {
  name: environmentName
  location: location
  properties: {
    environmentMode: 'Express'
    appLogsConfiguration: {
      destination: null
    }
    vnetConfiguration: {
      infrastructureSubnetId: infrastructureSubnet.id
    }
  }
}

resource app 'Microsoft.App/containerApps@2026-01-01' = {
  name: appName
  location: location
  properties: {
    environmentId: environment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 80
        transport: 'auto'
      }
    }
    template: {
      containers: [
        {
          name: 'main'
          image: containerImage
          resources: {
            cpu: json('0.25')
            memory: '0.5Gi'
          }
        }
      ]
      scale: {
        minReplicas: 0
        maxReplicas: 2
      }
    }
  }
}

確認していませんが、通常の ACA と同じく作成時にのみ指定できるパラメータである可能性が高いので、実稼働向けのアプリケーションなどで VNET Integration を有効化が必要な場合には気を付けたいです。

この Bicep を使ってリソースを一通り作成すると、以下のように Custom Virtual Network が有効になった状態で作成されたことが確認できます。挙動としては Hosted Agent の Custom Virtual Network と同じだと思われます。

VNET Integration が正しく動作しているかは、Private Endpoint や Service Endpoint でアクセスを制限した Azure Storage にアクセスできるかで判断するのが簡単です。

今回は以下のように独自のアプリケーションをデプロイせずに、Container App の Console に接続して curl を使って Azure Storage にアクセスして確認しました。

問題なく応答が返ってきているので問題なく VNET Integration が動作していることも確認できました。

個人的にはこれで Container Apps Express の大きなユースケースはサポート出来たと考えているので、後は GA を待つばかりという気持ちです。HTTP ベースのアプリケーションや API であれば、コストパフォーマンスにも優れている Express は大きな選択肢になるはずです。