Azure FinOps Essentials

In partnership with

Hi there, and welcome to this week’s edition of Azure FinOps Essentials!

This week, I’m exploring the cost side of Azure PaaS. Services like App Service, Functions, Logic Apps, and Cosmos DB promise simplicity and speed, but they often come with hidden costs if you’re not paying close attention.

PaaS can absolutely support a cost-efficient cloud strategy, but only if you understand how these services are billed, when to scale them, and what to avoid. I’ll walk through common traps, smart design choices, and when it still makes sense to pay for convenience.

If your team uses Azure PaaS or is considering it, this edition will help you make better-informed decisions and avoid unnecessary surprises.

Let’s get into it.

Cheers, Michiel

The hidden cost of PaaS convenience

When Azure PaaS first arrived on the scene, I loved it.

No more VM patching. No more fiddling with hosting. Just deploy and go. For developers, it felt like magic.

But over time, that magic started to fade.

I began seeing bills with strange patterns. Services that barely received any traffic were costing hundreds per month. Logic Apps were running like clockwork, even when they weren’t needed. App Services were deployed on premium plans, even for internal tools with three users.

And it wasn’t just me. In nearly every project I’ve joined in the past few years, I’ve seen the same pattern. Teams default to PaaS for speed, but never revisit their choices, and that’s when cost creeps in.

It’s not that Azure PaaS is bad. Quite the opposite. But if you don’t understand how these services are priced, or how to right-size them for your actual needs, you end up paying for a level of performance or convenience you don’t even use.

In this edition, I’ll walk through the most common PaaS cost traps I’ve seen, and how to get the most out of these services without blowing your budget.

Let’s start by looking at where things tend to go wrong.

Why PaaS isn’t always cheaper

Platform as a Service is often positioned as a cost-effective way to build and run applications. It takes infrastructure concerns off your plate and lets your team move faster. No patching, no VMs, no OS tuning, just deploy and go.

But underneath that simplicity lies a problem: you still pay for the platform, even when you don’t use it.

Most PaaS services in Azure are priced around provisioned capacity, execution volume, or tier-based bundles. These models are easy to misinterpret or misuse, especially when convenience takes priority over optimization. Here’s what I keep seeing in real-world Azure environments.

Azure App Service Plans

Every App Service is hosted in a plan, and that plan defines the resources you’re paying for. Even if the app is idle, the cost continues. What often happens: a team spins up a new App Service and selects a Premium V3 plan for better performance or custom domains.

Then nothing happens. The app receives almost no traffic, but the plan keeps running, billing €200 or more per month. In some environments, I’ve seen five or more small apps each on their own Premium plan, none of them breaking 10 percent CPU. Consolidation would have cut costs by half or more.

Azure Functions (Premium Plan)

Function Apps are often seen as the most cost-effective way to run backend workloads. That holds true on the Consumption Plan. But the moment you move to the Premium Plan to get features like VNET support, custom domains, or improved cold start, the pricing changes completely. Now you’re paying for pre-warmed instances, even if your functions are idle. One project had a single Function App on Premium with three always-on instances running 24/7. Monthly cost: around €150. Actual usage? Less than 10 minutes of compute per hour.

Logic Apps

Logic Apps are billed per execution step. Each action costs a fraction of a cent, until you run hundreds of them every few minutes. I’ve seen environments where Logic Apps were used for monitoring storage queues, checking Blob storage, and routing status updates. These flows ran every 5 minutes, 24 hours a day, even when there was nothing to process. The team never expected them to cost more than a few euros, but together they exceeded €400 per month.

Cosmos DB

Cosmos DB is powerful, but easily over-provisioned. Teams often set high RU/s throughput to handle potential spikes, then leave it unchanged for months. In one case, a team had provisioned 20,000 RU/s for a service that processed a few hundred items per hour. With no autoscale and no alerts, the cost kept accumulating quietly.

Event Hubs and friends

Some Azure services, like Event Hubs, promise elastic scaling but only in one direction. Event Hubs Standard tier does not scale down automatically. If your load spikes, it can add throughput units. But unless you manually remove them, you’re paying for that capacity even after traffic returns to normal. It’s easy to think you’re covered because the word autoscaling is mentioned in the docs. But in practice, many of these services scale up by default and leave scale-down as a manual step.

PaaS is still a great option for many workloads, especially when delivery speed or operational simplicity matters. But when it comes to cost, most services assume always-on usage and conservative provisioning. To keep things efficient, you have to look closer and adjust more often than you think.

Common PaaS cost traps and how to avoid them

You don’t need to stop using PaaS to control costs. But you do need to be more intentional about how you use it. Most cost issues with PaaS don’t come from extreme usage, but from defaults that were never reviewed or resources that were never revisited.

Here are some common traps and how to avoid them.

Overprovisioned plans

Many App Services or Functions run on plans that are far too large for what they need. The most common reason is fear of future load or simply copying what someone else did. Start with the lowest tier that supports your requirements and scale up only if real usage demands it. And if the workload is seasonal or irregular, consider scaling manually or consolidating with other apps on the same plan.

Always-on instances

Services like Azure Functions (Premium), Azure Container Apps, and Azure App Service Plans with autoscaling still reserve capacity even when nothing is running. That means you pay whether the workload is active or not. Review your scaling rules and instance minimums. For low-traffic or background jobs, serverless options might still be a better fit.

Forgotten test environments

Test and staging environments often get the same SKUs as production but are used only during working hours. Without scheduled scale-down or auto-stop policies, they quietly burn through budget outside office hours. Implement scheduled shutdowns, or better yet, let developers deploy to shared environments when needed and tear them down after.

Premium tiers by default

It’s easy to click on a higher tier when setting up a new service, especially if it promises better performance, private networking, or more features. But once those premium features are no longer needed, the plan usually stays. If you’re not using what you’re paying for, downgrade. Many workloads do not need Premium V3, Elastic Premium, or DTU-based SQL tiers.

Overactive workflows

Logic Apps and Functions with time-based triggers can rack up unexpected costs. If your workflow runs every 5 minutes, ask if it really needs to. Add early exit conditions when no work is needed. Review telemetry to see how many runs actually resulted in useful outcomes.

No tagging or grouping

If you can’t attribute costs to specific teams, projects, or environments, you can’t manage them effectively. Make sure all PaaS resources are tagged correctly. Use Azure Policy to enforce tag presence and alert when tags are missing. This helps identify unused or orphaned services.

Being proactive with these patterns can easily reduce your PaaS bill by 20 to 40 percent without changing your architecture. The trick is not to avoid PaaS, but to avoid running it on autopilot.

When PaaS is still worth it

Not every workload needs to be cost-optimized down to the cent. Sometimes, the speed, simplicity, or built-in features of Azure PaaS are exactly what a team needs — even if it costs more than a DIY setup.

Here are some scenarios where paying for convenience makes sense.

When platform features replace operational overhead

Running your own service with VMs or containers might be cheaper on paper, but you’ll need to manage updates, scaling, certificates, networking, backups, monitoring, and more. If a PaaS service handles all of that and lets your team focus on delivering value, the tradeoff can be worth it. I’ve seen teams regain multiple hours per week simply by not having to manage TLS, deployment scripts, or log plumbing.

When consistency across teams is more valuable than fine-tuned savings

In large organizations or fast-moving environments, having a consistent approach matters. If everyone uses the same deployment model, logging setup, and scaling rules, you save time in onboarding, maintenance, and troubleshooting. PaaS gives you those common patterns out of the box. The cost might be slightly higher, but the coordination overhead drops significantly.

When scaling requirements are hard to predict

For unpredictable workloads, for example, bursty APIs, marketing campaigns, or mobile traffic spikes, PaaS can give you a buffer. Services like Azure Functions, Event Grid, and Cosmos DB (with autoscale) handle sudden spikes better than a self-hosted service. In these situations, paying a bit more for elasticity can prevent outages or slowdowns that impact your users.

When your team prioritizes speed over infrastructure control

Startups, internal tool teams, or early-phase projects often don’t have the time or skillset to build scalable infrastructure from scratch. If PaaS allows a team to ship features faster and validate ideas, it’s doing its job. The real cost would be delaying delivery to save a few euros on infra.

When the cost is understood and accepted

In mature teams, spending more isn’t the problem. Lack of visibility is. If a team understands the cost of a PaaS service, tracks its usage, and can justify it, there’s no issue. It only becomes waste when the bill shows up and nobody knows where it came from.

PaaS doesn’t need to be the cheapest option. It needs to be the right one, with eyes open and tradeoffs made consciously.

Wrapping up

Azure PaaS is not the problem. Running it without insight is.

If you understand how a service is billed, what you actually need, and where the waste lives, PaaS becomes a powerful tool. But without that awareness, it’s easy to pay for speed while losing control over cost.

FinOps is not about avoiding spend. It is about making informed decisions that balance performance, velocity, and business value.

PaaS can absolutely support that goal, as long as you are intentional about how you use it.

You can (easily) launch a newsletter too

This newsletter you couldn’t wait to open? It runs on beehiiv — the absolute best platform for email newsletters.

Our editor makes your content look like Picasso in the inbox. Your website? Beautiful and ready to capture subscribers on day one.

And when it’s time to monetize, you don’t need to duct-tape a dozen tools together. Paid subscriptions, referrals, and a (super easy-to-use) global ad network — it’s all built in.

beehiiv isn’t just the best choice. It’s the only choice that makes sense.

Start free today. No credit card required.

Please help me by visiting my sponsor. And interested in sponsoring yourself, then visit the sponsor page.

Thanks for reading this week’s edition. Share with your colleagues and make sure to subscribe to receive more weekly tips. See you next time!

Want more FinOps news, then have a look at FinOps Weekly by Victor Garcia