5 Ways to Cut Your Azure Bill Right Now

Azure Container Apps is built around running many containers with shared infrastructure: networking, ingress, autoscaling, and service-discovery all managed for you. That overhead makes sense when you're running five or ten services that need to talk to each other. It makes less sense when you're deploying a single Node or Python app on a droplet equivalent.

For a single-app workload, a B-series VM - a B1ms at under $15/month - usually costs less once you account for the Container Apps environment minimum, consumption costs, and the active/idle billing model. The VM is predictable. You pay a fixed number regardless of request volume.

Over-provisioning is the single most common cloud waste pattern. Engineers pick a size that feels safe at deployment, then never revisit it. CPU and RAM sitting at 8% utilisation are money on the table.

Look at actual metrics before picking a size. Azure Monitor gives you CPU and memory time-series for any VM. If your p95 CPU over 30 days is under 20% and you're on a D4s v3, you probably belong on a D2s v3. That's roughly half the price for the same behaviour at your actual load. Don't use a sword to cut a cake.

Pay-as-you-go pricing. Exact figures vary by region and commitment tier.

Azure's built-in health probes are blunt. They tell you whether a port is open and whether an HTTP endpoint returns a 200. They do not tell you whether your app is stuck in a restart loop, leaking memory, or hitting a dependency timeout every 30 seconds.

Hidden restarts are a real cost driver. If your app restarts four times per hour, Azure is spinning it back up on compute you're paying for - and your health probe never catches it because the port comes back fine. Add PM2 on VMs: process-level restart counts, CPU per process, and a persistent log stream. Pair with structured logging to Azure Log Analytics or an equivalent.

Each public IP in Azure has a small but real cost (~$3.65/month per static IP). The bigger problem is what accumulates when you assign multiple IPs or create extra tunnels per VM - NAT gateway processing, egress charges across peered VNets, and routing complexity you pay for on every traffic crossing.

Cleaner architecture: one VNet per VM (or small cluster), single public IP, internal DNS via private DNS zones, traffic staying within the VNet wherever possible. Inter-VNet peering is cheap. Extra NAT gateways and extra public endpoints are not.

Nginx as a reverse proxy is a default many teams never revisit: one VM, Nginx on 443, routing to multiple apps on internal ports, each needing its own SSL certificate. CPU overhead creeps up as TLS termination runs on every request, on your compute, on your bill.

Cloudflare Tunnel flips this. Install cloudflared on your VM, it opens an outbound tunnel to Cloudflare's edge, and Cloudflare handles all TLS - one wildcard cert, managed for free. Your VM never exposes port 443. Nginx, if you keep it, does plain HTTP on localhost - far cheaper on CPU. On a small VM with moderate HTTPS traffic, TLS offload can shift your CPU baseline 10–25%.