12

I have an ACI that is running a REST API that needs to be exposed publicly, but needs to access resources inside a vnet.

For some reason, unlike normal VMs, if an ACI is inside a vnet, it cannot have a public IP address. If you try to give it a DNS name it fails.

The only option seems to be to use an Application Gateway as described here: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-application-gateway

And also here: Assign Static Public Address to Azure Container Instance deployment

But this approach has a fatal flaw, as indicated in the documentation itself: "If the container group is stopped, started, or restarted, the container group's private IP is subject to change. If this happens, you will need to update the application gateway configuration."

The Application Gateway has the option to select a backend pool by resource name, but this is only for normal VMs. The other option is to put in the IP address directly.

An ACI can easily get restarted without knowing. From experience, it happens relatively often that the host kills it and restarts it, possibly taking a different IP.

What is the right approach to expose a service running on an ACI instance on the internet, and at the same time have it access resources behind a vnet? The Application Gateway approach is evidently not the right approach.

I need a solution that can work easily with Azure CLI, since I am deploying my ACI through Bitbucket Pipes.

UPDATE:

Azure Container Instances are just a pile of junk. The only way to expose them from a vnet is to use an Application Gateway, which after a month running it, ends up costing more than the Container Instance itself! Moreover, Azure Container Instances are very unstable in certain regions (in West EU they keep getting killed), with support not understanding what is going on (apparently its an issue with multiple customers). So every time the instance gets restarted, it will get a different IP address, and the costly Application Gateway, which can run into over $100 per month, won't even know that the IP address changed.

Improve this question

1 Answer 1

Reset to default
1

If you only want to use the ACI, then there is no way to solve it. What you have found is the only way to access the ACI inside the VNet. But if you do not mind, maybe you can use the AKS, then enable the virtual node, then you also can run the ACI in the VNet and access it outside. Of course, you can use the AKS only, it also helps you run the application in the VNet and access outside.

Improve this answer
13
  • Thanks for your reply. But it seems that AKS is an overkill?
    – jbx
    Mar 8, 2021 at 9:50
  • @jbx That's just advice. AKS is heavier than ACI, but when ACI can't achieve your purpose, AKS is a good choice.
    – Charles Xu
    Mar 9, 2021 at 1:31
  • 1
    Thanks. What's frustrating is that for such a simple requirement that is so obvious i have to go for a complicated solution. Side rant: things in Azure always seem half baked!
    – jbx
    Mar 9, 2021 at 12:56
  • @jbx So does it solve your problem or any more question about this issue?
    – Charles Xu
    Mar 10, 2021 at 2:12
  • 1
    Marking your answer as correct just because ACI are just junk and there is no way to support this. Just discovered that on top of that, the application gateway costs more per month than the container instance it is exposing! In the end I just moved away from ACI.
    – jbx
    Apr 3, 2021 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.