CLOUDY MUSINGS

This topic comes up constantly. Sometimes it's at the start of a discovery conversation before we get into modernization, governance, platform engineering strategy, security, or cost optimization. Sometimes it's during a migration discussion where the existing documentation is incomplete or just plain wrong in the way only cloud infrastructure documentation can be. And sometimes it's simpler than any of that: someone just needs to know what's actually running in Azure across

As with previous posts, all source code and a corresponding GitHub repository can be found here! This is one of those questions that seems like it should have a straightforward answer, but it doesn't because what good fun would that be if there were a straightforward answer? I'm sure you've been here before: someone spots an enterprise application in Microsoft Entra ID, notices it has permissions or credentials attached, and naturally asks: who created this thing? If you star

This keeps coming up in real conversations, and it usually surfaces right when decisions start to matter. Someone says they are "in GCC," and from there the assumption creeps in that Azure Government is somehow already in the picture. That leap feels small in the moment, but know it is not. The reference and assumption snowballs into bad architecture, wrong scoping, and uncomfortable conversations when compliance teams start asking harder questions. People are not being carel

There's a very specific moment in almost every Azure File Sync conversation where things go from "this is going great" to "wait, what do you mean we can't do that?" P.S. That happened this week and it took me back, hence the blog post. This usually happens right after the POC looks successful. You've synced a few hundred gigs from the D: drive of an on-premises file server, cloud tiering is working, ACLs look intact, and everyone feels good. Then someone asks how you expose

Let me tell you about a moment that happens to almost everyone working with Azure networking. You're designing a network, you discover service endpoints, and you think "Great! This keeps my traffic on Microsoft's backbone instead of the public internet." You enable them for Storage, SQL, maybe Key Vault. Everything makes sense. Then you stumble across service endpoint policies and think "Oh cool, I can add more control to all these services!" You start setting them up for SQ

So you're looking at Azure Data Box, and it seems pretty straightforward. Microsoft sends you a physical box, you load it up with data, ship it back, and boom: your data's in Azure. Simple, right? Then you actually start planning the migration. You open the portal, dive into the docs, and suddenly you're reading the same paragraph about "regions" for the third time, still not entirely sure what it means. Here's the question I've been asked from time to time: If I create my Da

Note, the companion code and corresponding full GitHub repository is located here . Azure costs are tricky enough without licensing contracts adding another layer of confusion on top. One of my long-running jokes from my time working at Microsoft was that you needed an advanced degree just to understand Azure billing, and then a second one to understand how that billing intersects with real-world consumption in Azure. What tends to catch teams off guard is that the agreement

When I wrote Azure Savings Plans, Finally Explained with Math That Actually Makes Sense , I was very focused on solving one specific problem. People were looking at Savings Plans and feeling like they were missing something obvious. They saw the hourly commitment. Then they saw their bill. They did not see a discount. And that disconnect was driving a lot of unnecessary anxiety. Once that post went live, I started finalizing this post as I knew there would be immediate follow

Math IS hard and mathing isn't my strong suit. I am writing this blog because I STILL get tripped up at times with Savings Plans. You guessed it...this becomes a cheat sheet for ME in the future, too! Azure Savings Plans are one of those topics that routinely make smart people feel like they missed a prerequisite class. I see it in customer meetings, I see it in internal chats, and I definitely see it in the way people react to Azure Advisor recommendations. The issue is not

Like all my previous blogs, code to accompany this post exists here . If you have ever tried to answer the question “what kind of Azure subscription is this?” using automation, you probably assumed there was a clean, authoritative answer somewhere. An API call. A property. A single source of truth. And if you have spent any real time with Azure billing or FinOps work, you already know how quickly that assumption falls apart. Most people eventually land on Offer ID. The Azure

a.k.a. How to migrate file data without breaking apps, users, or your weekends! All code for this blog can be found here ! In my time of supporting customers embracing a "digital transformation", every file migration starts the same way: “We just need to move our file shares to the cloud.” That sentence hides an enormous amount of complexity. Files are not just bytes on disk (I wish they were...life would be easier!). They encode how people collaborate, how applications behav

There has been a lot of noise lately about Microsoft “changing support” for Azure Pay As You Go subscriptions. Depending upon who you ask, this has turned into everything from “PAYG is being deprecated” to “Microsoft is forcing everyone into CSP.” None of that is actually happening. Microsoft doesn't always make this straightforward in messaging, so my hope is to help you out a bit! This is what I want to land clearly with you all and will repeat it a few times: Microsoft is

The companion code for this blog can be found here . One thing you may have noticed is that I have been in PowerShell a bit more frequently as of late. The back story is I had a machine that all of a sudden didn't respond well with PowerShell and I spent quite a bit of time cleaning everything up. Whenever plagued with PowerShell issues, I run through an extensive list of troubleshooting every time a machine doesn't play nice and figured it might be a good time to share some

All sample PowerShell companion code for this blog can be found here . Azure has plenty of tools that do one thing really well, and Azure Resource Mover fits right into that category. If you need to move supported resources across regions without rebuilding from scratch, this is your tool. The trick is knowing what it was built for, what it refuses to touch, and how to use it without creating a surprise outage. This guide walks through what Resource Mover is good at, what it

The code referenced in this blog can be found here ! There are still moments when Azure catches me by surprise. Back when I first moved away from traditional on-prem environments, I was convinced the Contributor role was almost identical to Owner , just without the ability to manage access or view billing. Simple, right? Turns out that was completely wrong, and what I learned since then keeps saving me headaches every time I spin up a new environment. My goal of this post is

Tis the season! Customers always ask the most interesting questions about cloud capabilities. This one isn't documented well and you have to sort of piece it together by "reading the tea leaves" (my least favorite). A customer asked me a question that sounded simple enough: “Can we stand up Azure Migrate in our brownfield tenant, run dependency mapping there, and then use Azure Migrate to migrate workloads into our new greenfield tenant?” If you’ve ever led a large-scale migr

a.k.a. Here's Your Full Guide to Understanding Azure Cloud Governance Without Losing Your Mind or Sanity Cloud governance is one of those topics that sounds straightforward until you start hearing people use the same five words to describe completely different things. You walk into a meeting and someone says, “We should solve this with Azure Policy,” and someone else responds, “We need a Blueprint,” and a third person chimes in with, “This belongs in our Service Group model.”

Cloud engineering looks complicated from the outside. But when you peel back some layers, it doesn't seem so daunting. I believe in breaking down tricky concepts so that even a six-year-old could understand. We don’t need to make everything so complicated that no one gets it. To me, that's the quickest way to lose the hearts and minds of your esteemed colleagues, customers, and peers. The Complexity of Cloud Engineering What I've found is that folks often imagine giant Terraf

In my last post , I talked about what’s changing with Azure’s Pay-As-You-Go (PAYG) APIs and why the old Usage Details endpoint is being retired. Now it’s time to roll up our sleeves! If your FinOps automations rely on Microsoft.Commerce/UsageAggregates, you’ll need to migrate those scripts to use the Exports API or Cost Details API. This post covers the exact code changes you need to make in PowerShell and Python (typically what I see most often with my customers and what I t

If you pull cost data from Azure’s Pay-As-You-Go (PAYG) subscriptions, you might have noticed something new in Microsoft’s documentation lately: the legacy “Get Usage Details” API is being deprecated. That’s right. The familiar Consumption API that so many FinOps teams built automations around is heading for retirement. Before you start rewriting every script you own, take a breath. This change is not a disaster. It is an upgrade. Let’s talk about what is happening, why Micro