Most audit, design workshops, and architecture reviews have some version of the same moment. Someone points at a diagram, taps the App Service box, and says “that’s fine, it’s got…

If you deploy Azure Application Gateway with minimum instances set to 0, don't expect the bill to come in at zero-cost. You're still paying a fixed hourly charge whether 0 or 100 instances are running. From a FinOps perspective, Application Gateway v2 (Standard_v2 and WAF_v2) has a dual-component billing model: - Component 1: Fixed hourly gateway charge. Billed 24/7 from the moment the gateway is provisioned, regardless of traffic, instance count, or autoscale settings. It's deployed with a minimum of two instances with automatic health monitoring and failover, independent of the autoscale minimum you set for capacity unit billing. - Component 2: Capacity unit (CU) hourly charge. A capacity unit is measured across three dimensions and billed on whichever is highest: 2,500 persistent connections, 2.22 Mbps throughput, or 1 compute unit. Compute unit capacity is SKU-dependent — roughly 50 TLS connections/second on Standard_v2, roughly 10 concurrent requests/second on WAF_v2. Setting minimum instances to 0 means you only pay CU costs when traffic is present. Where the real savings come from: - Minimum instances = 0: eliminates reserved CU costs. You pay CU costs only when traffic shows up. Fixed cost remains. - Minimum instances = 2: reserves 20 capacity units (2 instances × 10 CUs/instance) 24/7, billed regardless of traffic. That's significant variable cost on top of the always-on fixed cost. The recommended design: - Delete idle Application Gateways entirely. Zero traffic, 24/7 fixed charge, every hour. Redeploy from IaC when needed. - Minimum instances = 0 for non-production. You pay the fixed charge plus real traffic only. Trade-off: a spike takes 3–5 minutes to provision a new instance. - Minimum instances = 2 for production. Two warm instances, no cold start, immediate spike handling. The extra CU cost is the price of production readiness. - Pre-warm predictable spikes with Azure Automation. Application Gateway doesn't support scheduled autoscaling natively. If your traffic spikes weekday mornings and drops overnight, use an Automation runbook on a timer to raise the minimum before the spike and drop it after. The metrics to monitor: - Estimated Billed Capacity Units (what Azure is actually charging this hour) - Current Capacity Units (what traffic is actually using) - Fixed Billable Capacity Units (what your minimum instance setting reserves). If Fixed Billable Capacity Units are consistently higher than Current Capacity Units, you're paying for headroom nobody is using. #Azure #FinOps #ApplicationGateway #MVPbuzz

In the previous post on AKS Identity and Access Control, we covered authentication and authorisation, Workload Identity, secrets management, and Zero Trust principles. Your cluster is now secured! …

Azure PaaS handles 80% of the requirements I see in production environments. So why would you need AKS? AKS makes sense for genuinely demanding scenarios. Multi-cloud portability where the abstraction has real business value, not just "we might leave Azure one day." Advanced service mesh requirements that App Service or Container Apps can't deliver. A dedicated platform engineering team with the capacity to run it properly. Workloads that genuinely need fine-grained control over scheduling, networking, and runtime that PaaS abstracts away. If your environment doesn't have at least two of those, you're probably solving for an architecture you don't have. Azure PaaS is pragmatic for everything else. Standard web apps. Event-driven architectures. Small teams without a dedicated platform function. Organisations where cost predictability matters more than maximum flexibility. Container Apps, App Service, Functions, Logic Apps, Service Bus — these aren't compromise choices. For most workloads, they're the right architectural fit and the wrong reason to skip past them is "it's not cool enough." The Azure Pricing Calculator has a sample AKS workload that is a great starting point for estimating your cluster and associated workloads, what it doesn't give you is: ❌ Managing cluster upgrade cycles. ❌ Monitoring and observability setup. ❌ Security patching at the node, container image, and runtime layers. ❌ RBAC complexity. Azure RBAC, Kubernetes RBAC, namespace boundaries. ❌ A platform team of 3-5 FTEs minimum to run it properly. ❌ How this fits into your operating model. For me, the answer is simple. Start with PaaS. Graduate to AKS only when a specific workload requirement forces the upgrade AND you have the capability to support it. I spoke about this at conferences in the past and will be again this year. YouTube recording link is in the comments. If you're running AKS in production right now, can you defend the choice on workload requirements alone, or could your workloads have run on Azure PaaS services and you just wanted an AKS cluster because "it's cool"? #Azure #AKS #AzurePaaS #CloudArchitecture #PlatformEngineering #MVPbuzz

In most Azure projects, the default position for logs is to create a Log Analytics Workspace and turn everything on. This has a huge impact on the cost profile of your solution and can stick out like a sore thumb when it comes to FinOps optimization reviews. Lets say your workspace was ingesting 50GB of data per day - thats a high number but not unheard of in Enterprise environments where you may have multiple VMs, multiple AKS or Azure PaaS based workloads with the full network security stack running. With that figure, you're spending around €4,000/month on logs. That's around €50,000 per year on logs that you may not really need. The likely breakdown is: 👉 AzureDiagnostics: ingesting verbose logs from all services. 👉 ContainerLog: using the old ContainerLog table (not ContainerLogV2).  👉 AzureActivity: every write operation, across all environments including dev/test, shipped to the same workspace. There are ways to get this reduced: ✅ Migrate to resource-specific tables (away from the default AzureDiagnostics), typically 40–60% volume reduction for the same diagnostic data. ✅ Switch to ContainerLogV2, 50% reduction in container log volume, same signal ✅ Run a query to show the highest used tables. Then run another query to show if these have been queried in the last 30 days. ✅ Move infrequently queried tables to Basic tier. 20GB per day of Analytics data costs approx. €1500. 20GB per day of Basic data costs approx. €300. Now, there's a slight caveat - if you have created Dashboards for observability based on KQL Queries, then this counts as a query against a table. You'll need to work out if those specific tables are needed for longer than the 8 days retention offered by Basic Tier. What are your top 3 Log Analytics tables by ingestion volume — and when were they last queried? https://lnkd.in/diCXCwWs #Azure #AzureMonitor #LogAnalytics #FinOps #Observability #MVPbuzz

Your AKS Cluster Autoscaler scaled from 10 nodes to 4 overnight.   You expected a 60% compute cost reduction, and you got it! But your Azure bill only dropped by 27%. Here's a realistic AKS cost breakdown for a 10-node Standard_D4s_v3 cluster (in North Europe with RI's applied): 👉 VMs (10 × D4s_v3 @ €110/month): €1,100/month  👉 Managed OS disks (10 × 128GB Premium SSD @ €17/month): €170/month 👉 Application Gateway for Containers (Standard): €250/month  👉 Azure Load Balancer (Standard): €25/month  👉 Azure Container Registry (Premium, 500GB): €170/month 👉 Log Analytics / Container Insights (est. 8GB/day): €650/month 👉 Misc (Public IPs, Bandwidth, etc.): €50/month Total: €2,400/month When Cluster Autoscaler removes 6 nodes, it only reduces the €660 in VM costs. That’s around 27% of the total bill, not the 60% you were expecting. The autoscaler is doing its job, but there are other ongoing costs that don’t get touched: ❌ Persistent Volume costs ❌ Log Analytics ingestion you never tuned ❌ ACR tier costs ❌ AGC / Load Balancer / network charges ❌ Retained or orphaned disks nobody cleaned up The real FinOps gains with AKS come from looking beyond autoscaling: ✅ Use Ephemeral OS disks for your nodes ✅ Cut Container Insights ingestion with ContainerLogV2 for better collection settings and support for Basic tier log storage ✅ Scale AGC Capacity Units down when traffic is low ✅ Audit orphaned disks regularly ✅ Check what % of spend is compute before assuming autoscaling fixes the bill On a €2,400/month setup, applying these changes can lower your bill to around €1,400/month. Thats now a saving of 42% that autoscaling alone can’t deliver. Cost savings isn't just about scaling and compute. Understanding the breakdown between compute and the other costs can really shift your cost optimisation approach. #AKS #Kubernetes #Azure #FinOps #MVPbuzz

Subscribe to Microsoft Azure today for service updates, all in one place. Check out the new Cloud Platform roadmap to see our latest product plans.

Most organisations running Microsoft 365 E3 or E5 are paying for Azure capabilities they've never provisioned. Not edge features. Core infrastructure: virtual desktops, identity management, threat detection, SIEM log ingestion. The Azure budget conversation is harder than it needs to be because nobody has checked what's already in the M365 agreement. Here's what an M365 E3/E5 agreement typically includes that most organisations have never activated: ✅ Azure Virtual Desktop access rights — E3 and above includes per-user access rights for AVD. This removes the per-user licensing fee that kills VDI business cases before they reach architecture. If your VDI project has stalled on cost, check the M365 agreement before requesting new budget. ✅ Microsoft Entra ID P1/P2 — included in E3/E5. Conditional Access, Identity Protection, Application Proxy. This is the toolkit that replaces legacy VPN for remote access — and the licence is already paid for. Most organisations buy Entra separately and never claim the entitlement already in their agreement. ✅ Microsoft Defender and Sentinel — E5 Security includes unified threat protection, and E5 customers typically receive a data grant for Sentinel covering M365 log ingestion. If your security operations team is paying separately for SIEM ingestion of Microsoft 365 logs, they may be paying twice. The project approval conversation changes completely when "we need budget for Azure" becomes "we already own the licences — we need budget for implementation." Has your organisation done a full M365-to-Azure entitlement mapping? The AVD access rights one is the most consistently missed — and the most likely to unlock a project that's been stuck for 12 months. #Azure #Microsoft365 #FinOps #AVD #MVPbuzz

AI is making the PoC-to-production pipeline problem significantly faster... and worse. I built a Copilot Agent in 20 minutes this week. It connects to AKS, scans the Azure Updates site, and emails me relevant updates. It works. It's useful. I'm not supporting it. For a personal project: fine. That's the point. Worryingly, the statement "I built this in 20 minutes" is now the statement I'm hearing more and more in customer meetings, closely followed by a quick demo showing "it does exactly what we need it to do" and then "we should ship it." And this is now running in production with: ❌ No operational documentation ❌ No error handling or retry logic ❌ No observability ❌ No secrets management On-call at 2am isn't fun when the codebase is a vibe-coded prototype nobody owns. AI tooling has removed the friction that used to create natural checkpoints. The time between "I wonder if I could build this" and "it's running in production" used to involve enough effort that someone with experience usually intervened. Now it doesn't. The Agent I built is a genuine example of what's possible in 20 minutes: Copilot interface → AKS backend → Azure Updates scraper → email delivery. The gap in AI-accelerated development is both a technical skills problem AND a governance problem. Most organisations don't have a clear line between "this is an experiment" and "this is a production system" — and AI tooling is making that line harder to see, not easier. If nobody on the team can explain how to fix it at 2am, it's not production-ready - it's just a demo with uptime. #Azure #AI #Engineering #CloudArchitecture #MVPbuzz

"Just one more year of ESUs. Then we'll migrate." Support for Windows Server 2012 ended October 2023. The ESU bills are escalating. The security exposure is compounding. The migration still hasn't started. And on October 13th (6 months time), the ESUs run out. We've been here before. WannaCry in 2017 caused billions in damages. The organisations hit hardest weren't running XP because they didn't know the risk. They were running it because migration felt harder than "one more year." Windows Server 2012 is the same conversation, and the threat landscape is significantly worse than it was in 2017. The difference now is that the tools have caught up with the problem: ✅ Azure Migrate automates discovery and dependency mapping (including File Servers) — the part of migration planning that used to take months of manual spreadsheet work. The inventory excuse is gone. ✅ Azure Arc delivers ESUs to on-premises servers securely while migration planning is underway. It's not a permanent strategy, but it closes the exposure gap while you build the exit plan properly instead of reactively. ✅ Azure Virtual Desktop is the path for organisations whose real blocker isn't the OS — it's the legacy applications running on it. AVD keeps those apps accessible without having to migrate the underlying infrastructure first. Most Server 2012 migrations aren't stalled because the technical path is unclear. The tools and roadmap exists. The blocker is usually a conversation that hasn't happened yet. Oh by the way - once you get past October 13th, you're on the run-in to Windows Server 2016 EOL on January 11th 2027. And don't forget SQL is also within this timeline as well. Are you going to sign up for another cycle of ESUs? https://lnkd.in/d33_3-a5 #Azure #HybridCloud #Migration #Security #MVPbuzz

If you have spent any meaningful time provisioning resources in Azure, you have almost certainly hit a quota limit at least once. Maybe a Virtual Machine deployment failed because the vCPU limit fo…

Learn how to create an Azure Files assessment in Azure Migrate to evaluate readiness, cost, and migration options for on-premises file shares.

Learn how Azure Network Security Perimeter secures PaaS resources with logical network boundaries. Control public access, prevent data exfiltration, and manage access rules for Storage, Azure AI Search, and Key Vault.

Azure networking documentation covers a lot of ground. What it is less good at is surfacing the assumptions embedded in common configurations — the things that appear safe on paper but create real …

In the previous post on AKS Networking, we defined how traffic flows into, through, and out of an AKS cluster. We designed ingress entry points, internal service communication patterns, and control…

I’ve been working with a customer who wants to migrate from Azure SQL Server to Azure SQL Managed Instance. It was the right choice for them – they want to manage multiple databases, so…

A Landing Zone is never the first thought when a project starts. When the pressure is on to deliver something fast in Azure (or any other cloud environment, the simplest path looks like this: Creat…

In the previous post on AKS Networking, we explored the different networking models available in AKS and how IP strategy, node pool scaling, and control plane connectivity shape a production-ready …

Image Credit: Microsoft Microsoft have just announced the General Availability of Disconnected Operations for Azure Local, M365 Local and Foundry Local. Reading between the lines of the announcemen…

In the previous post, we broke down AKS Architecture Fundamentals — control plane vs data plane, node pools, availability zones, and early production guardrails. Now we move into one of the most co…

If there's one thing that busines leaders and architects agree on, its this: hybrid isn't a temporary layover on the way to the cloud. For most enterprises, it's a 5 to 10+ year destination. The speed at which Cloud and AI advancements have evolved leads to pressure on business leaders and CTOs to go "all in" on cloud. The way these services are now bundled into licensing for the likes of Entra, Microsoft 365, Azure and Security offerings can lead to "FOMO" fears, as well as license-wastage worries. But that doesn’t always acknowledge real-world business factors. Many workloads remain on-premises for very good reasons: ✅ Data sovereignty and strict regulatory rules.   ✅ Ultra-low latency requirements for industrial or edge scenarios.   ✅ Legacy vendor applications tied to specific hardware.   ✅ Cost optimization for stable, predictable workloads. Recognising this reality reflects practical architecture, not a lack of innovation. The goal is to manage your entire estate consistently, wherever it runs. That's where tools like Azure Arc come in, extending the Azure control plane (think Policy, Monitor, and Defender) right to your on-premises servers. For VMware shops, Azure VMware Solution (AVS) provides a cloud bridge while keeping the operational model familiar. And of course, proactive FinOps remains critical. It’s not just about continuously optimising costs and avoiding surprises like orphaned or oversized resources that often lead to cloud repatriation, its also about ensuring that the licenses and SKU's you have purchased are providing maximum benefit. The best strategy is one that matches your business realities—not forcing your organisation into a cloud-only box. Thinking about your environment, which workloads do you see as likely to stay on-premises long term? #Azure #HybridCloud #AzureArc #MVPbuzz

In the previous post From Containers to Kubernetes Architecture, we walked through the evolution from client/server to containers, and from Docker to Kubernetes. We looked at how orchestration beca…

Solution Architects can design a technically solid cloud infrastructure that is secure, compliant and resilient. Presenting to business stakeholders and budget approvers in a language they understand and is relevant to their business requirements is another matter. It's easier to connect the solution to the problem we are trying to solve if we lead with the "how" before explaining the "why." In the boardroom, it’s less about:   ✖️ The specific tools you're using   ✖️ Intricate technical implementations   ✖️ The latest security frameworks by name   ✖️ All the acronyms  What truly resonates with them is the business impact, including:   ✅ Business risk   ✅ Financial impact   ✅ Competitive advantage   ✅ Regulatory compliance   ✅ Customer trust  Shifting from a hands-on engineer mindset to becoming a trusted advisor means framing our architecture as the solution to real business challenges—not just ticking technical boxes. That’s how we move from useful diagrams to strategic projects with funding and impact. #Azure #TechLeadership #Architecture #MVPBuzz 

Subscribe to Microsoft Azure today for service updates, all in one place. Check out the new Cloud Platform roadmap to see our latest product plans.

Learn how Windows is moving toward an NTLM-independent future with enhanced auditing, Kerberos enhancements, and a phased roadmap.

Learn how Azure savings plans help you save money by committing an hourly spend for one-year or three-year plan for Azure compute resources.

In the previous post, What Is Azure Kubernetes Service (AKS) and Why Should You Care?, we got an intro to AKS, compared it to Azure PaaS services in terms of asking when is the right choice, and fi…

In every cloud native architecture discussion you have had over the last few years or are going to have in the coming years, you can be guaranteed that someone has or will introduce Kubernetes as a…

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

Centralize orphan resources in Azure environments. Contribute to dolevshor/azure-orphan-resources development by creating an account on GitHub.

RIP to the traditional Virtual Machine. Everyone wants serverless these days. PaaS-this. Cloud Native-that. You can see why though - PaaS services will always win when it comes to cost control, resilience, scalability, and most importantly agility for Development and Operations teams to create solu

2025 was a great year for me from a community speaking perspective. I had the opportunity to speak in-person at conferences like South Coast Summit, Nordic Integration Summit, and Global Azure and …

My feed is full of "Here's what you need to learn in 2026" posts. If you're trying to follow every single recommendation, you’ll likely end up overwhelmed and not gaining much at all. I've seen it lead to burnout, and I've felt it myself. My advice is always to learn at your own pace, with an achievable goal that build's on top of a skillset you already have. 👉 For the experienced Cloud Engineer with strong networking skills: Build on that foundation by diving into Kubernetes and AKS. Your knowledge of the “plumbing” is a huge advantage for container orchestration. (Check out Microsoft Docs on AKS here: https://lnkd.in/dwY88E2n) 👉 For the Security Specialist: Mastered identity? Your next move is exploring Microsoft Sentinel to extend your skills into proactive cloud security. (Here’s a great starting point: https://lnkd.in/deBdypa4) 👉 For the End-User Computing Admin: Coming from RDS or Citrix? Focus on Azure Virtual Desktop. You’re leveraging familiar concepts but with cloud scalability. (Official docs: https://lnkd.in/dEFviS5d) 👉 For the Developer: Comfortable in your IDE? Layer on Azure Container Apps or look at how Agentic AI can be integrated into your applications. (Azure Container Apps info: https://lnkd.in/dTAGvg5U; For Agentic AI training path, see https://lnkd.in/dzVn_A67) Real growth comes from building depth, not just ticking boxes. It’s about making your learning manageable and tying it to your day-to-day work. What’s the next skill you’re planning to build that fits with where you’re at right now? #Azure #AKS #Security #AVD #AgenticAI #2026Goals

Its Christmas time, and that means its time for another month of the always fantastic Festive Tech Calendar. This was one of the first events that I participated in when I was trying to break …

Microsoft has announced that Azure Lab Services will be retired on June 28, 2027. New customer sign-ups have already been disabled as of July 2025, which means the clock is officially ticking for a…

ALT: a picture of a man with blood on his face and the words we 'll get together have a few laughs