Traffic splitting in Azure Container Apps

By default, when ingress is enabled, all traffic is routed to the latest deployed revision. When you enable multiple revision mode in your container app, you can split incoming traffic between active revisions.

Traffic splitting is useful for testing updates to your container app. You can use traffic splitting to gradually phase in a new revision in blue-green deployments or in A/B testing.

Traffic splitting is based on the weight (percentage) of traffic that is routed to each revision. The combined weight of all traffic split rules must equal 100%. You can specify revision by revision name or revision label.

This article shows you how to configure traffic splitting rules for your container app. To run the following examples, you need a container app with multiple revisions.

Configure traffic splitting

Configure traffic splitting between revisions using the az containerapp ingress traffic set command. You can specify the revisions by name with the --revision-weight parameter or by revision label with the --label-weight parameter.

The following command sets the traffic weight for each revision to 50%:

az containerapp ingress traffic set \
    --name <APP_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --revision-weight <REVISION_1>=50 <REVISION_2>=50

Make sure to replace the placeholder values surrounded by <> with your own values.

This command sets the traffic weight for revision <LABEL_1> to 80% and revision <LABEL_2> to 20%:

az containerapp ingress traffic set \
    --name <APP_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --label-weight <LABEL_1>=80 <LABEL_2>=20

1. Go to your container app in the Azure portal.
2. Select Revision management from the left side menu.
3. If the revision mode is Single, set the mode to multiple.
   1. Select Choose revision mode.
   2. Select Multiple: Several revisions active simultaneously.
   3. Select Apply.
   4. Wait for the Revision Mode to update to Multiple.
4. Select Show inactive revisions.
5. If you don't have multiple revisions, you can create a new revision.
   1. Select Create new revision.
   2. You can use the default settings or customize the revision.
   3. Enter a Name/Suffix for the revision.
   4. Select Create.
   5. Wait for the revision to deploy.
6. Select Active for the revisions you want to route traffic to.
7. Enter the percentage of traffic you want to route to each revision in the Traffic column. The combined percentage of all traffic must equal 100%.
8. Select Save.

Enable traffic splitting by adding the configuration.ingress.traffic properties to the ingress section of your container app template. You can specify the revisions by name with the revisionName property or by revision label with the label property.

The following example sets 100% of traffic to the latest deployed revision:

{
  ...
  "configuration": {
    "ingress": {
      "external": true,
      "targetPort": 80,
      "allowInsecure": false,
      "traffic": [
        {
          "latestRevision": true,
          "weight": 100
        }
      ]
    },
  },

The following example shows traffic splitting between two revisions by name:

{
  ...
  "configuration": {
    "ingress": {
      "external": true,
      "targetPort": 80,
      "allowInsecure": false,
      "traffic": [
          {
              "revisionName": "my-example-app--5g3ty20",
              "weight": 50
          },
          {
              "revisionName": "my-example-app--qcfkbsv",
              "weight": 50
            }
        ],
    },
  },

The following example shows traffic splitting between two revisions by label:

{
  ...
  "configuration": {
    "ingress": {
      "external": true,
      "targetPort": 80,
      "allowInsecure": false,
      "traffic": [
          {
              "weight": 50,
              "label": "v-2"
          },
          {
              "weight": 50,
              "label": "v-1"
          }
        ],
    },
  },

Use cases

The following scenarios describe configuration settings for common use cases. The examples are shown in JSON format, but you can also use the Azure portal or Azure CLI to configure traffic splitting.

Rapid iteration

In situations where you're frequently iterating development of your container app, you can set traffic rules to always shift all traffic to the latest deployed revision.

The following example template routes all traffic to the latest deployed revision:

"ingress": { 
  "traffic": [
    {
      "latestRevision": true,
      "weight": 100
    }
  ]
}

Once you're satisfied with the latest revision, you can lock traffic to that revision by updating the ingress settings to:

"ingress": { 
  "traffic": [
    {
      "latestRevision": false, // optional
      "revisionName": "myapp--knowngoodrevision",
      "weight": 100
    }
  ]
}

Update existing revision

Consider a situation where you have a known good revision that's serving 100% of your traffic, but you want to issue an update to your app. You can deploy and test new revisions using their direct endpoints without affecting the main revision serving the app.

Once you're satisfied with the updated revision, you can shift a portion of traffic to the new revision for testing and verification.

The following template moves 20% of traffic over to the updated revision:

"ingress": {
  "traffic": [
    {
      "revisionName": "myapp--knowngoodrevision",
      "weight": 80
    },
    {
      "revisionName": "myapp--newerrevision",
      "weight": 20
    }
  ]
}

Staging microservices

When building microservices, you might want to maintain production and staging endpoints for the same app. Use labels to ensure that traffic doesn't switch between different revisions.

The following example template applies labels to different revisions.

"ingress": { 
  "traffic": [
    {
      "revisionName": "myapp--knowngoodrevision",
      "weight": 100
    },
    {
      "revisionName": "myapp--98fdgt",
      "weight": 0,
      "label": "staging"
    }
  ]
}

Next steps

Blue-green deployment