Jeremy Wallace MVP

Microsoft MVP, MCT, and Azure Solutions Architect

[Jeremy Wallace MVP @TheAzureMVP]

If every VPN request, Teams issue, and AVD tweak still runs through you…
you’re not leading IT, you’re throttling it.
I recorded this quick breakdown on how to stop being the bottleneck and start building a team that moves without you in every ticket.

🎥 Watch this and then tell me:
What’s one task you’re going to document or delegate this week?

#ITLeadership #TechLeadership #ElevateITLeadership

[Jeremy Wallace MVP @TheAzureMVP]

Private Endpoints are powerful.

But that does not mean they are automatically the right answer every time.

A lot of Azure teams treat them like the obvious “more secure” option.

Sometimes they are.

But they also change the design.

A Private Endpoint gives the service a private IP inside your virtual network.
That is a real architectural shift, not just a firewall tweak.

And that shift brings more to think through:
DNS
routing
peering
hybrid connectivity
operational support over time

That may be exactly what you need.

But not every workload needs that level of private connectivity.

Sometimes the better move is a simpler one.

If your real goal is to restrict which subnets can reach a service, and you do not need the service mapped into your network with a private IP, Service Endpoints may solve the problem with less overhead.

If your goal is true private access, stronger isolation, and a cleaner private connectivity model across Azure and on-premises, Private Endpoints are usually the better fit.

The mistake is not choosing one over the other.

The mistake is choosing either one by default without understanding the operational tradeoff.

In Azure, the strongest design is not the one with the most features.

It is the one that matches the requirement without creating unnecessary complexity.

#Azure #MicrosoftAzure #AzureNetworking #PrivateEndpoint #ServiceEndpoints #CloudArchitecture #AzureArchitecture #CloudSecurity #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

A lot of Azure environments look governed on paper.

Policies are assigned.
Compliance dashboards are populated.
Everything appears under control.

But that does not automatically mean Azure is enforcing anything.

Azure Policy enforces based on the effect you assign.

If the effect is audit, Azure evaluates the resource and records noncompliance.
It does not stop the deployment.

If the effect is deny, Azure blocks noncompliant create or update requests before they land.

That is a huge difference.

Audit gives you visibility.
Deny changes behavior.

And this is where many Azure teams get a false sense of governance maturity.
They see policy assignments and compliance results, then assume enforcement is already in place.

Sometimes starting with audit is the right move.
It helps you understand what would break before you turn on stronger control.

But if everything stays in audit mode, your governance model is mostly reporting drift instead of preventing it.

In Azure, assigned policy does not automatically equal enforced policy.

The real question is not whether you have Azure Policy.
It is whether your policy effects are actually changing what can be deployed.

#Azure #MicrosoftAzure #AzurePolicy #CloudGovernance #AzureArchitecture #CloudSecurity #LandingZones #PlatformEngineering #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

Azure RBAC is not the same thing as Azure protection.

RBAC decides who is allowed to manage a resource.
It does not stop an authorized person from deleting or changing the wrong thing.

That is where resource locks matter.

In Azure, RBAC is your authorization layer.
Resource locks are a governance guardrail.

A CanNotDelete lock lets authorized users read and modify a resource, but not delete it.
A ReadOnly lock lets them read it, but not update or delete it.

That distinction matters more than most teams realize.

I still see environments where critical resources have well-planned role assignments but no lock strategy.
That means one valid action in the wrong moment can still take down something important.

The real lesson is this:

RBAC answers:
Who can do this?

Resource locks answer:
Should this action be allowed at all on this resource?

That is a very different question.

One more nuance matters here:
Locks apply to Azure management plane operations, not data plane operations.

So if you are protecting critical services, do not assume a lock protects everything inside them.
It protects the resource from management changes.
It does not automatically protect the underlying data path.

Good Azure governance is not just assigning the right roles.
It is deciding which resources should be hard to change, even for people who technically have access.

That is the difference between access control and operational protection.

#Azure #MicrosoftAzure #AzureRBAC #CloudGovernance #AzureArchitecture #CloudSecurity #PlatformEngineering #AzureManagement #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

Azure gives you multiple ways to distribute traffic.

That is useful.
It is also where a lot of Azure designs start to drift.

One of the most common mistakes is treating Azure Load Balancer and Application Gateway like interchangeable options.

They are not.

Azure Load Balancer is built for Layer 4 traffic.
It distributes TCP and UDP flows based on IP and port.
It does not understand HTTP requests, inspect URL paths, or handle TLS termination.

That makes it a strong fit for VM-based workloads, internal services, and high-performance transport-level distribution.

Application Gateway operates at Layer 7.
It understands web requests.
It can route traffic based on host names and URL paths, terminate TLS, and add web application firewall capabilities.

Load Balancer handles transport-level distribution.
Application Gateway handles application-level delivery.

This is why they should not be treated like competitors.
In many real Azure designs, they solve different parts of the traffic path and can be used together.

The mistake is not choosing one over the other.
The mistake is using the wrong one for the problem you are actually trying to solve.

#Azure #MicrosoftAzure #AzureNetworking #ApplicationGateway #AzureLoadBalancer #CloudArchitecture #AzureArchitecture #CloudDesign #WebArchitecture #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

Not every Azure VM workload should be pushed into Availability Zones.

Sometimes Availability Sets are still the better architectural choice.

That sounds backward until you look at the actual failure domain you are trying to solve.

Availability Sets help reduce correlated failures by spreading VMs across fault domains and update domains.

Availability Zones give you a higher level of resiliency because they are built around physically separate datacenter infrastructure inside a region.

Those are not the same thing.

And that is exactly why I see teams make the wrong call.

They assume the newer option is automatically the better one.

But for a lot of real-world VM workloads, especially legacy application stacks, the better question is not:
"Which feature sounds stronger?"

It is:
"What failure do we actually need to survive, and what can this workload realistically support?"

If I have a traditional app running on a small number of VMs, tight dependencies between tiers, and no real plan for cross-zone replication or failover, forcing Availability Zones can create more complexity than value.

Because once you go zonal, the design burden gets heavier.

Now you have to think through:
How traffic is routed
How data is replicated
How failover happens
How the application behaves when a zone is unavailable

That is not a checkbox decision.
That is architecture.

Availability Sets still make sense when:
You need protection from localized host, rack, power, network-switch, or maintenance-style disruptions
The workload is VM-based and not being re-architected right now
Low latency between VMs matters
The business does not need datacenter-level resiliency inside the region

Availability Zones are worth the added complexity when:
A datacenter outage in the region is in scope
The app and data tiers can actually operate across zones
You have a real load balancing, replication, and failover design
The business requirement justifies the added cost and operational overhead

Also, this is not an argument against modernization.

For many newer deployments, Microsoft recommends Virtual Machine Scale Sets with flexible orchestration for high availability with the widest range of features.

The real point is this:

Do not choose the most impressive availability feature.

Choose the right failure domain for the workload you actually have.

#Azure #MicrosoftAzure #AzureArchitecture #CloudArchitecture #AvailabilitySets #AvailabilityZones #AzureVM #HighAvailability #WellArchitected #CloudDesign

[Jeremy Wallace MVP @TheAzureMVP]

Service Endpoints and Private Endpoints are both valid in Azure.

But they are not interchangeable.

Service Endpoints are the simpler option.
You enable them on a subnet, and Azure extends that subnet’s identity to the service.
Traffic stays on the Microsoft backbone, but the service still resolves through its public endpoint.

That matters.

You are restricting access to the service, not bringing that service into your private IP space.

Private Endpoints take a different approach.
They create a private IP in your virtual network through Private Link.
That changes the architecture.

Now DNS becomes part of the design.
Peered networks matter.
On-premises resolution matters.
And if you want to remove public exposure, you also need to disable public network access where the service supports it.

Service Endpoints optimize for simplicity and speed.
Private Endpoints optimize for isolation and control.

The mistake is not choosing one over the other.
The mistake is treating them like they solve the same problem.

Because in Azure, connectivity is not just about reaching a service.
It is about deciding how that service lives inside your environment.

#Azure #MicrosoftAzure #AzureNetworking #PrivateEndpoint #ServiceEndpoints #CloudArchitecture #AzureArchitecture #ZeroTrust #CloudSecurity #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

Most teams treat Azure Policy like a compliance report.

That misses the bigger value.

Azure Policy is one of the few controls in Azure that can influence what gets deployed, not just report on what already exists.

That matters more than most teams realize.

When people, pipelines, or templates create or update resources, Azure Policy evaluates those resources against the rules you define. Depending on the effect, it can audit, deny, append, modify, or even deploy missing configuration.

That is not just reporting.
That is platform behavior.

This is why Azure Policy matters so much in a real landing zone.

You can require tags.
You can restrict regions.
You can enforce configuration standards.
You can automatically apply or remediate settings in the right scenarios.

Not through a standards document.
Through the platform itself.

That changes the operating model.

Without policy, governance depends on people remembering the rules.
With policy, the platform helps enforce the rules consistently.

But there is a tradeoff.

If you go too hard with deny too early, you create friction and slow teams down.
If you stay too passive with audit-only forever, nothing really changes.

Microsoft’s guidance points toward a better pattern:
start with visibility, understand the impact, then move toward stronger enforcement where it makes sense.

That is the real design decision.

Not whether Azure Policy matters.
It does.

The decision is how intentionally you use it.

Because once an Azure environment grows, retrofitting governance is a lot harder than building it in from the start.

Azure Policy is not just about compliance.

It is one of the clearest ways to turn governance standards into actual platform control.

#Azure #MicrosoftAzure #AzurePolicy #CloudGovernance #AzureArchitecture #CloudArchitecture #LandingZones #CloudSecurity #PlatformEngineering #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

One of the easiest ways to create hidden risk in Azure is to assign access too high in the hierarchy.

Azure RBAC looks simple on the surface. You assign a role, the right people get access, and work moves forward.

But the part that causes trouble later is scope inheritance.

Microsoft’s documentation is clear: if you assign a role at the management group, subscription, or resource group level, that access is inherited by the child scopes underneath it.

That means a role assigned high in the hierarchy does not just apply to one workload.
It applies to everything below that scope.

This is where convenience turns into risk.

I still see environments where Contributor gets assigned at the subscription level just to keep things moving.
It solves the short-term problem.
But over time, that same decision quietly expands access across production resources, future deployments, and systems that were never meant to be broadly managed.

Nothing has to break for this to become a problem.
The security boundary is already wider than it should be.

Microsoft’s guidance points in the right direction here:
use least privilege, and assign roles at the lowest scope that still makes sense operationally.

That does not mean higher-scope assignments are always wrong.
Sometimes they are appropriate.
But they should be intentional, limited, and understood for what they are.

Because RBAC design is not just about who can log in and do work.

It defines blast radius.

If an account is compromised, how much of the environment does that access reach?
If someone makes a mistake, how much of the platform can they affect?

A better pattern looks like this:

Keep high-scope assignments minimal.
Use the narrowest scope that fits the job.
Treat RBAC as part of your architecture, not just an admin setting.

In Azure, where you assign access matters just as much as what role you assign.

#Azure #MicrosoftAzure #AzureRBAC #CloudSecurity #CloudGovernance #LeastPrivilege #AzureArchitecture #IdentityAndAccessManagement #CloudArchitecture #MicrosoftCloud

[Jeremy Wallace MVP @TheAzureMVP]

We have Azure Monitor enabled, so we’re covered.

That sounds good until something breaks.

One of the biggest gaps I see in Azure environments is confusing monitoring with observability.

Azure Monitor is powerful.
It can collect metrics, logs, traces, and events across your environment.
You can build dashboards, queries, and alerts.

But turning on a monitoring platform is not the same as making a system understandable.

That is where many teams get stuck.

They open Log Analytics during an incident.
There is plenty of data.
But no clear story.

They can see symptoms.
They still cannot quickly find cause.

Microsoft’s Well-Architected guidance pushes observability as a capability.
The goal is to make system behavior understandable through telemetry.

That takes more than enabling diagnostics.

It takes:
Structured logs that are consistent
Telemetry that is correlated across components
Signals that map to real application flows
Alerts that reflect real user or business impact

Without that, Azure Monitor becomes a place you store data instead of a system that helps you explain what actually happened.

And during an outage, that difference shows up fast.

Most environments do not have a tooling problem.

They have an observability design problem.

#Azure #MicrosoftAzure #AzureMonitor #Observability #CloudOperations #SRE #CloudArchitecture #OperationalExcellence #CloudEngineering #mvpbuzz

[Jeremy Wallace MVP @TheAzureMVP]

“we deployed it across Availability Zones, so we’re highly available.”

I hear that a lot.

And it is only true if the architecture actually uses them correctly.

Availability Zones give you something very important:
physical separation inside an Azure region.

Different datacenter infrastructure.
Different power.
Different cooling.
Different failure domains.

That is a strong foundation.

But it is still only a foundation.

What I see in real environments is this:

A single VM is pinned to one zone.
A service supports zones, but zone redundancy was never enabled.
The app tier is spread out, but the data tier is not.
Traffic routing and failover were never properly designed or tested.

Technically, Availability Zones are involved.

Practically, the workload can still go down.

That is the misunderstanding.

High availability does not come from placement alone.
It comes from redundancy, distribution, health-aware traffic handling, data protection, and failover behavior that has actually been designed into the workload.

Availability Zones can be one of the most powerful resilience features in Azure.

But “uses zones” is not the same thing as “survives a zone failure.”

If your workload cannot lose a zone without manual intervention or meaningful downtime, it is not highly available.

It is just zone-aware.

#Azure #MicrosoftAzure #CloudArchitecture #HighAvailability #AzureDesign #WellArchitected #CloudResilience #AzureInfrastructure #CloudEngineering #mvpbuzz

[Jeremy Wallace MVP @TheAzureMVP]

Azure Backup Is Not Disaster Recovery

“We have backups, so we’re covered.”

That sounds reassuring until the outage is real.

One of the most common gaps I see in Azure environments is treating backup like disaster recovery.

They are not the same thing.

Azure Backup is essential for data protection and recovery. If something is deleted, corrupted, or lost, you need a way to restore it.

But restoring data is not the same as restoring service availability.

That is the part many teams miss.

A backup helps you recover what was lost.

A disaster recovery strategy helps you restore service within the timeframe the business expects.

That is where RPO and RTO actually matter.

If the business can tolerate a longer recovery window, backup may be enough.

If the business expects systems to stay available or come back quickly after an outage, the design needs more than backup alone.

The real issue is not whether you have backups.

It is whether your recovery design matches your business expectations.

Because recovery and failover are not the same thing.

#Azure #MicrosoftAzure #CloudArchitecture #DisasterRecovery #AzureBackup #AzureSiteRecovery #CloudResilience #BCDR #CloudEngineering

[Jeremy Wallace MVP @TheAzureMVP]

Azure RBAC vs Microsoft Entra roles and why confusing them creates security gaps

One of the fastest ways to create hidden security risk in Azure is to confuse two things that sound almost identical:

Azure RBAC
Microsoft Entra roles

They are not interchangeable.

Azure RBAC is about access to Azure resources.

Can you start a VM
Can you modify a storage account
Can you deploy infrastructure
Can you manage a resource group or subscription

It operates at the Azure resource layer.

Microsoft Entra roles are about access to Microsoft Entra resources and tenant administration.

Can you create users
Can you reset passwords
Can you manage groups
Can you manage applications, authentication settings, or directory roles

That operates at the directory layer.

The mistake I see often is using a broader Microsoft Entra role when Azure RBAC was the right tool.

Someone needs access to manage a resource. Instead of assigning a scoped RBAC role at the right level, they get a broader directory role. The request gets solved, but now they may have permissions that extend far beyond the original need.

Microsoft’s model is actually very clean when you follow it:

Use Azure RBAC for resource access.
Use Microsoft Entra roles for directory and identity administration.

When those boundaries blur, access starts to expand in ways that are harder to justify, harder to audit, and easier to overlook.

If you are reviewing an Azure environment and something feels off about access, this is one of the first places worth checking.

Not just who has access.

But which permission system gave it to them.

#Azure #MicrosoftAzure #AzureSecurity #IdentityAndAccess #AzureRBAC #EntraID #CloudSecurity #CloudArchitecture #ZeroTrust

[Jeremy Wallace MVP @TheAzureMVP]

A lot of Azure connectivity issues start showing up when Private Endpoints are introduced.

Not because Private Endpoints are inherently complicated.

But because they quietly change how your network architecture has to work.

On the surface, the idea is simple. A PaaS service like Storage or SQL gets a private IP inside your virtual network. Traffic to that service can stay on the Microsoft backbone instead of going over the public internet.

That sounds like a clean security win.

But the real design change is not the IP address.

It is DNS.

When you enable a Private Endpoint, clients that should reach that service privately need the service FQDN to resolve to the private endpoint IP instead of the public IP. That means your full name resolution path has to be designed for it.

If DNS is not designed correctly, you start seeing issues that feel random:

• Applications that cannot connect even though the network path looks correct
• Hybrid environments where on-premises resolves differently than Azure
• Multiple VNets behaving inconsistently depending on DNS design

Microsoft’s documentation is clear that Private Endpoints depend on correct DNS configuration. That makes DNS a core part of the architecture, not just a background service.

This is where many designs fall short.

Private Endpoints get deployed.
DNS is only partially configured.
Connectivity becomes inconsistent.

The answer is often not another network rule.

It is treating DNS as a first-class design component.

Private Endpoints are not just a security feature.

They are a network architecture decision.

#Azure #MicrosoftAzure #AzureNetworking #PrivateEndpoint #CloudArchitecture #AzureArchitecture #CloudSecurity #AzureDNS #CloudEngineering #mvpbuzz

[Jeremy Wallace MVP @TheAzureMVP]

Network Security Groups are one of the first security controls most people learn in Azure.

And for good reason.

They are simple, powerful, and built into Azure networking. A few rules can quickly restrict traffic between subnets or help protect a VM from unwanted access.

But over time, I see many Azure environments drift into a pattern where NSGs become the entire network security strategy.

That is where things start to break down.

NSGs are fundamentally stateful traffic filtering rules. They allow or deny traffic based on source, destination, port, and protocol. They are extremely useful for segmentation and basic traffic control.

What they are not designed to do is become the only security layer in a growing Azure environment.

As environments scale, teams often start stacking hundreds of NSG rules across subnets and network interfaces. Troubleshooting gets harder. Security intent becomes less clear. Small changes can create unexpected consequences.

Microsoft’s architecture guidance points toward layered controls instead.

NSGs help with segmentation.

Private Endpoints provide private access to supported platform services and reduce public exposure.

Azure Firewall or other network security appliances provide centralized inspection and control.

Service firewalls and service-specific access controls enforce security closer to the service itself.

Each layer has a different job.

NSGs are still a core part of Azure networking. But when they become the only control mechanism in the architecture, they usually collect complexity faster than most teams expect.

The real question for many Azure environments is not whether NSGs are configured.

It is whether they are doing the job they were actually designed for.

#Azure #MicrosoftAzure #AzureNetworking #CloudArchitecture #AzureArchitecture #CloudSecurity #NetworkSecurity #AzureFirewall #CloudEngineering

[Jeremy Wallace MVP @TheAzureMVP]

You can build a highly available VM architecture in Azure and still have it fail in production.

One small detail often decides whether your load-balanced design actually works.

Health probes.

Azure Load Balancer does not inherently know whether your application is healthy. It relies on health probes to determine backend endpoint status and which backend instances should receive new connections.

If the probe succeeds, the backend instance stays available for new traffic.
If the probe fails, Azure Load Balancer stops sending new connections to that unhealthy instance.

That sounds simple, but the real issue is what the probe is actually checking.

Many deployments point the probe at a basic port or a minimal endpoint. The probe passes, and Azure keeps sending traffic.

Meanwhile, the application may still be degraded in a way that the probe does not detect.

Microsoft’s documentation is clear that probe configuration and probe responses determine which backend pool instances receive new connections. That means the probe endpoint is part of your reliability design.

The best production architectures treat the probe like a meaningful health signal.

Instead of checking only whether the server is reachable, the probe should reflect whether the application is actually ready to serve requests.

If your load balancer only knows the instance is reachable, it cannot protect you from every kind of application failure.

#Azure #MicrosoftAzure #CloudArchitecture #AzureArchitecture #LoadBalancing #AzureVM #CloudReliability #WellArchitected #CloudEngineering #mvpbuzz

[Jeremy Wallace MVP @TheAzureMVP]

Still typing on Android? Fix that. Join the Flow waitlist. Win stuff 🚀‍https://t.co/NvGDBRdgqH

[Jeremy Wallace MVP @TheAzureMVP]

Most architecture conversations start in the wrong place.

They start with technology.

They should start with the business.

Architecture design is always driven by business goals. That means ROI, financial constraints, and measurable outcomes must guide every technical decision.

Before you design anything, ask:

• Does the allocated budget actually enable us to meet our goals?
• Where does the application really spend money across build and operations?
• What are the true priority areas?
• How do we maximize investment — better utilization or smart reduction?

Here’s the hard truth:

A cost-optimized workload is not the same thing as a low-cost workload.

There are real tradeoffs.

Tactical cost cutting is reactive. It might lower spend this quarter.
It rarely builds long-term financial responsibility.

Sustainable optimization requires:

• Clear prioritization
• Continuous monitoring
• Repeatable processes
• Alignment between business intent and technical execution

Start with recommended design principles.
Justify every architectural decision against business requirements.
Then operationalize it using a Cost Optimization checklist.

And expect change.

As business priorities shift, cost allocation will shift.
Optimizing cost often creates tension with security, scalability, resilience, and operability.

If those tradeoffs are not handled intentionally, teams often choose the cheaper option instead of the right option.

That decision may save money today.
It can cost reputation tomorrow.

Optimize with intent.
Design for the business.

#CloudArchitecture #Azure #WellArchitected #CostOptimization #CloudStrategy #Leadership

[Jeremy Wallace MVP @TheAzureMVP]

Azure Well Architected Framework (WAF) is the fastest way I know to turn “cloud debates” into real decisions.

Here are the 4 lines I keep coming back to:
• WAF turns opinions into decisions.
• You don’t improve “the cloud.” You improve workloads.
• Most outages aren’t surprises. They’re unpaid design debt.
• Trade-offs aren’t mistakes. Unstated trade-offs are.

Practical next step (15–30 min): Pick your most important workload, run the Azure Well-Architected Review, and build a backlog of your top 10 improvements. Then pick the first 1–2 you can ship this month.

If you want, comment WAF and tell me which pillar is your biggest pain right now: Reliability, Security, Cost Optimization, Operational Excellence, or Performance Efficiency.

#Azure #MicrosoftAzure #AzureWellArchitectedFramework #WellArchitected #CloudArchitecture #CloudStrategy #CloudGovernance #CloudSecurity #ReliabilityEngineering #CostOptimization #OperationalExcellence #PerformanceEfficiency #SiteReliabilityEngineering #DevOps

[Jeremy Wallace MVP @TheAzureMVP]

Watch is now on YouTube: https://t.co/LHbpbNHeMV

[Jeremy Wallace MVP @TheAzureMVP]

Just published a new YouTube video on the Azure Well-Architected Framework (WAF) and I’m genuinely pumped about this one.

WAF is one of the best tools Microsoft has given us for making cloud architecture decisions with intention, not vibes.

In the video I break down:
• What WAF is (and what it is not)
• The 5 pillars: Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency
• How to run the Well-Architected Review and turn the output into a real improvement backlog
• How to use it as an ongoing system, not a one-time project

If you’re building on Azure, this framework is a cheat code for reducing outages, tightening security, and controlling spend without guesswork.

Question for you: which pillar is your biggest pain right now?
Reliability, Security, Cost, Ops, or Performance?

Check it out: https://t.co/O1ejHMpFTj

#Azure #MicrosoftAzure #CloudArchitecture #AzureWellArchitectedFramework #WellArchitected #AzureAdvisor #FinOps #CloudSecurity #AzureArchitecture