Azure Container Instances - Run Containers Without the Kubernetes Complexity Tax

Azure Container Instances (ACI) is Microsoft's attempt at serverless containers - think AWS Fargate but with more Azure-specific quirks. As of September 2025, it runs your containers in what they call \"hypervisor-level isolation\", which sounds fancy but basically means each container gets its own VM underneath.

The promise is simple: skip the Kubernetes YAML hell and VM management nightmare. Just az container create and boom - your container is supposedly running. Reality check: it works great for hello-world demos, then breaks in creative ways when you try to do anything real in production.

Here's what actually happens: You define your container, Azure spins up a VM behind the scenes, pulls your image (sometimes), starts your container (usually), and charges you per second whether your app is doing anything or just sitting there eating memory.

Why Engineers Actually Use ACI (And Why They Regret It)

Speed (When It Works): Containers supposedly start in \"seconds\" - true if your image is tiny. Got a real-world .NET image? Time to make coffee while you wait. The "image caching" is a lie - cold starts are unpredictable as hell. Sometimes quick, sometimes I question my career choices while waiting.

Simplicity (Ha!): Yes, az container create is one command. But wait until you need persistent storage, networking that doesn't suck, or logging that actually works. Suddenly you're writing ARM templates that make Kubernetes YAML look elegant.

Cost Efficiency (Your CFO Will Hate You): Per-second billing sounds great until your container gets stuck in a restart loop during your Black Friday deployment. At $0.045/vCPU-hour, a misbehaving 2-vCPU container racked us up $800 over a weekend because nobody noticed it was crash-looping every 30 seconds. And those "scale to zero" benefits? Only work if your containers actually stop instead of hanging with zombie Node.js processes that never quite die.

How ACI Actually Works Under the Hood

Microsoft's \"hypervisor-level security\" marketing speak translates to: "We spin up a VM for your container group." Each container group gets its own VM underneath, which explains the cold start times and why you can't do privileged operations.

The Good: True isolation means no noisy neighbors screwing with your performance. Your 2 vCPU container actually gets 2 vCPUs, not 2 vCPUs "best effort" like some platforms.

The Bad: VM overhead means you're paying for a hypervisor whether you need it or not. And when that VM decides to restart for "platform maintenance" (usually during your demo), your container goes down hard with no warning.

Production Reality: During our Q4 launch, our ACI containers randomly restarted at 2 AM because the underlying VM got reclaimed for "platform maintenance." No warning, no migration. Just poof - 3 hours of batch processing lost. The \"guaranteed resources\" are real, but so are the surprise reboots that wipe out your work and leave you explaining to executives why the quarterly reports are delayed.

What ACI Can (And Can't) Do in September 2025

Features That Actually Work:

• Confidential containers - if you need TEE and have money to burn
• Spot containers - 70% savings until Azure kills them during important batch jobs
• Both Linux and Windows containers - Windows support is surprisingly decent
• VNet integration - requires NAT gateways nobody tells you about

Features That Were Murdered:

• GPU support got axed July 2025 - screwed over every ML team using ACI

What's Still Missing (And Why You'll Hit These Walls):

• Service Discovery: Containers can't find each other without hard-coding IPs
• Load Balancing: You need external load balancers, adding complexity and cost
• Persistent Storage: Azure Files mounting is clunky and expensive
• Auto-scaling: Manual container groups only - no HPA or KEDA magic
• Health Checks: Basic liveness/readiness probes that barely work

When to Use ACI: Simple batch jobs, CI/CD runners, development environments where downtime doesn't matter.

When to Run Away: Microservices, anything needing service mesh, production workloads where 99.9% uptime matters. Use AKS or Container Apps instead.

Here's how ACI compares to alternatives...

When you need alternatives: Check Container Apps vs ACI comparison to see if you should switch. Use the Azure pricing calculator to calculate your actual bills before committing.

ACI's feature list looks impressive on paper, but here's what you'll actually experience when trying to use this stuff in production. Spoiler alert: some features work great, others are glorified tech demos.

Container Groups: Like Kubernetes Pods, But Simpler (And More Limited)

Container groups are ACI's version of Kubernetes pods - containers that live together, die together, and share everything. This actually works pretty well.

What works great:

• Single containers: Perfect for simple apps, batch jobs, or CI runners
• Multi-container sidecars: Logging containers, reverse proxies, monitoring agents
• Localhost communication: Containers can hit each other on localhost:port - no service discovery needed
• Shared volumes: Mount the same Azure Files share across containers

Where it breaks down:

• No health checks between containers in the group
• If one container dies, the whole group restarts (great for demos, terrible for production)
• Can't restart individual containers - it's all or nothing
• No rolling updates - you delete and recreate everything

Real-world example: Web app + Redis sidecar works fine. Web app + database + job processor? You're gonna have a bad time when one component fails and takes down the others.

Resource Limits: What You Get (And What Actually Works)

The official specs (as of September 2025):

• CPU: 0.1 to 4 vCPUs per container group
• Memory: 0.1 to 14 GB per container group
• Storage: Up to 50 GB temporary + persistent volumes

Reality check: Resource quotas vary by region. Want 4 vCPUs? Good luck in smaller Azure regions.

Production gotchas I've learned the hard way:

• Fractional vCPUs are bullshit: 0.5 vCPU performs like 0.2 vCPU when Azure is busy - learned this during the 2024 holiday traffic spike when our ML inference containers slowed to a crawl
• Memory allocation is firm: Request 2GB, get exactly 2GB. No burst capacity like EC2. Our image processing service died instantly when someone uploaded a 4K photo instead of the usual thumbnails
• Disk I/O is garbage: That 50GB temp storage has the performance of a floppy disk. Took 45 minutes to extract a Docker image that should have been a 2-minute operation
• No swap: If your app tries to use more than allocated memory, it gets OOMKilled instantly. Python's garbage collector never gets a chance to clean up

Resource planning that actually works: Always request 25% more CPU/memory than you think you need. ACI doesn't handle resource contention gracefully.

Security Features (The Good, The Bad, The Expensive)

ACI's security story is actually pretty solid, but some features cost way more than they're worth:

Confidential containers cost a fortune but work if you need that level of paranoia. Roughly 3x normal pricing for hardware-encrypted memory. Most apps don't need this.

Managed identities actually work great - no more credential expiration surprises. Your container can authenticate to Azure services automatically.

VNet networking requires NAT gateways that nobody tells you about until deployment fails. Want private networking? You'll need NAT gateway configuration that Microsoft doesn't mention upfront.

Storage That Doesn't Totally Suck

Azure Files mounting works but is clunky and expensive. Network hiccups can randomly unmount your storage, causing mysterious app failures.

Better approach: Use blob storage APIs instead of file mounts. More reliable and your app can handle connection failures gracefully.

Networking Reality Check

Public IPs: You get a random public IP unless you pay extra for static ones. DNS labels work: myapp.eastus.azurecontainer.io

Port mapping: There is no port mapping. If your app listens on port 3000, you expose port 3000. Period.

Specialized Deployment Options

ACI Spot Containers save 70% on costs but can disappear with 30 seconds notice. Great for batch jobs that can restart, terrible for anything user-facing.

That covers what ACI can do on paper. But what about the questions you'll actually ask when things inevitably go wrong?

When ACI inevitably breaks: Check the official troubleshooting guide and resource limits docs. For container optimization, Docker's best practices actually help with startup times.