Azure Container Instance - Failed to Create

Question

Azure Container Instance - Failed to Create

Brian Bento 0

I am using a PS script to create ACI instances and I have used this script before with no issue at a previous company. However, now when I run it with the updated info I get the following error:

The DNS name label 'alludio-platform-tenants-api-prod' in container group 'alludio-platform-tenants-api-prod' is invalid. It can contain only lowercase letters, numbers and hyphens. The first character must be a letter. The last character must be a letter or number. The value must be between 5 and 63 characters long.

It is quite obvious nothing in the label violates any of the explanations outlined and I even was able to create the container through the web console with the exact same info I provide to the script and it created just fine.

I have updated my Az PS version as well to the latest thinking maybe there was a mismatch on the api on the backend. I don't understand how it can give me this error when its clearly not an issue.

Anonymous

2026-03-31T18:29:59.32+00:00
Hello Brain,

Thank you for sharing the details regarding the issue with creating your Azure Container Instance (ACI).

Although the DNS label alludio-platform-tenants-api-prod is valid on its own, the error you’re seeing occurs because Azure silently appends a hash suffix to the DNS label to enforce uniqueness across tenants. For example, Azure actually attempts to register a name like:

alludio-platform-tenants-api-prod-<hash>.<region>.azurecontainer.io

If the combined length exceeds 63 characters, it triggers the “invalid DNS name label” error—even though your input label itself meets all requirements. This also explains why it worked in your previous company (different tenant → different hash) and why the portal succeeds (the portal handles the hash automatically).

Recommended Solutions

Shorten the DNS label so that even with the hash appended it stays under 63 characters. -DnsNameLabel "alludio-tenants-api-prod"

Use the Unsecure reuse policy to prevent hash generation if your security requirements allow: New-AzContainerGroup ` -ResourceGroupName "your-rg" ` -Name "alludio-platform-tenants-api-prod" ` -DnsNameLabel "alludio-platform-tenants-api-prod" ` -DnsNameLabelReusePolicy "Unsecure" ` ... # other parameters

Use the noReuse policy for a unique hash every time, which allows reuse but results in an unpredictable FQDN: -DnsNameLabelReusePolicy "noReuse"

Reference:

Troubleshoot common issues in Azure Container Instances

Deploy an Azure Container Instances (ACI) container group with DNS name reuse policy (preview)

Deploy a container instance in Azure using Azure PowerShell
Hope this helps! Please let me know if you have any queries.

2 answers

Your answer

Anonymous

2026-03-31T18:29:59.32+00:00

Hello Brain,

Thank you for sharing the details regarding the issue with creating your Azure Container Instance (ACI).

Although the DNS label alludio-platform-tenants-api-prod is valid on its own, the error you’re seeing occurs because Azure silently appends a hash suffix to the DNS label to enforce uniqueness across tenants. For example, Azure actually attempts to register a name like:

alludio-platform-tenants-api-prod-<hash>.<region>.azurecontainer.io

If the combined length exceeds 63 characters, it triggers the “invalid DNS name label” error—even though your input label itself meets all requirements. This also explains why it worked in your previous company (different tenant → different hash) and why the portal succeeds (the portal handles the hash automatically).

Recommended Solutions

Shorten the DNS label so that even with the hash appended it stays under 63 characters. -DnsNameLabel "alludio-tenants-api-prod"

Use the Unsecure reuse policy to prevent hash generation if your security requirements allow: New-AzContainerGroup ` -ResourceGroupName "your-rg" ` -Name "alludio-platform-tenants-api-prod" ` -DnsNameLabel "alludio-platform-tenants-api-prod" ` -DnsNameLabelReusePolicy "Unsecure" ` ... # other parameters

Use the noReuse policy for a unique hash every time, which allows reuse but results in an unpredictable FQDN: -DnsNameLabelReusePolicy "noReuse"

Reference:

Troubleshoot common issues in Azure Container Instances

Deploy an Azure Container Instances (ACI) container group with DNS name reuse policy (preview)

Deploy a container instance in Azure using Azure PowerShell
Hope this helps! Please let me know if you have any queries.

Answer 1

The error is raised because Azure is validating the DNS name label, not the container group name, and the DNS label must follow stricter rules than the container group name. In PowerShell, the -IPAddressDnsNameLabel parameter on New-AzContainerGroup / New-AzContainerInstanceContainerGroupProfile is what sets this value.

Key points from the DNS name label rules for Azure Container Instances:

Allowed characters: lowercase letters, numbers, and hyphens (-).
First character: must be a letter.
Last character: must be a letter or number (cannot be a hyphen).
Length: 5–63 characters.

The error message shows that the DNS name label is alludio-platform-tenants-api-prod. Even though this string appears valid, the issue is typically one of the following in the script:

A different value is actually being passed to -IPAddressDnsNameLabel than expected (for example, including a trailing hyphen, whitespace, or an empty/short value after variable expansion).
The DNS label is being set from a variable that contains uppercase characters or invalid characters once concatenated.
The container group name and DNS name label are being confused; the portal may auto-generate a valid DNS label even if the group name is longer or slightly different, while the script explicitly sets an invalid DNS label.

To resolve:

Explicitly set a valid DNS label in the script:
- Ensure the value is all lowercase, 5–63 characters, starts with a letter, and does not end with -.
- Example: -IPAddressDnsNameLabel "alludio-platform-tenants-api-prod".
Log or output the exact value passed to -IPAddressDnsNameLabel before calling New-AzContainerGroup to verify there are no trailing spaces or unexpected characters.
Confirm that the container group name itself also follows its own naming rules (lowercase letters, numbers, hyphens; cannot start or end with a hyphen; no consecutive hyphens; length 1–63) because some tooling can conflate the two when building the request.

If the same values work in the portal, compare the portal-generated DNS label with what the script sends and align the script’s -IPAddressDnsNameLabel to that format.

References:

Answer 2

Brian Bento 0

It turns out the issue was that i was concatenating two strings in line $service-$environment and for some reason it works everything else but not for this dns label - instead I had to do "${service}-${environment}" which makes no sense but it works. I even had tried hardcoding it but that didn't work either so not sure what is going on there.

0 comments