What is the proper way to expose an Azure Container Instance that is inside a vnet?

Question

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.

Prandial

Answer 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.

Candlepower

Thanks for your reply. But it seems that AKS is an overkill? – Prandial

@Prandial That's just advice. AKS is heavier than ACI, but when ACI can't achieve your purpose, AKS is a good choice. – Candlepower

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! – Prandial

@Prandial So does it solve your problem or any more question about this issue? – Candlepower

No idea. I don't know how to use AKS, seems something 5 times more complicated for something that should be easy, I just want to expose my instance. So it still doesn't answer the question of how to expose an ACI publicly while inside a vnet. – Prandial

@Prandial As I said in the answer, there are no other ways to access the ACI in a VNet except the Azure Application gateway or Azure Load Balancer. Both these two ways need a static private IP, when it changes, then it will not work again. – Candlepower

So ACI are pretty much useless for real applications? They either run completely public, which is impractical if they need to access databases or other private resources, or private without any way of exposing their services on the internet as a normal web application. – Prandial

@Prandial Actually, I think ACI just useful for testing the image, not good for the production environment, and we don't have much control over it. In the end, if it's helpful please accept it. – Candlepower

That is becoming my impression too :(. It seems there might be another solution using init containers, which I will need to delve into a bit. Before accepting your answer I want to wait a bit in case someone else suggests something else. – Prandial

@Prandial Decide yourself. – Candlepower

@Prandial Is there any better answer you get? Or you still want to wait for it? – Candlepower

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. – Prandial

@Prandial There is a new service in preview that fits right in between the AKS and ACI solutions called Azure Container Apps. This gives you way more control than ACI without the complexity of AKS (It's actually AKS under the hood but simplified). It also allows for scaling to zero. Here is the product page: azure.microsoft.com/en-us/services/container-apps/#overview - It sounds like just the kind of solution you were looking for. Been waiting for something like this myself for a while as I also find AKS to be overkill for most things. – Debbiedebbra