Azure Well-Architected Framework: Everything You Must Know

The Cloud Adoption Framework vs the Well-Architected Framework 

Microsoft introduced two essential and complementary frameworks designed to guide organisations through their cloud adoption: the Cloud Adoption Framework and the Well-Architected Framework. Both serve different purposes. 

• On the one hand, the Cloud Adoption Framework focuses on migrating your on-premise or private data centres to Azure. It helps you assess what you can move, your team’s readiness, along possible costs. Hence, it’s widely used as a “lift-and-shift” to view whether workloads are migratable and if a company is ready for a transition to the public cloud. 
• Once you’ve made the move with CAF, the continuous improvement cycle begins, which is where the Well-Architected Framework (WAF) comes into play.  

Why is the Azure Well-Architected Framework important? 

At some point, you'll be responsible for creating, running, or operating a workload, perhaps in the cloud, maybe not (or you’re already doing this).  

If so, you’d want to know: what do I need to focus on to make sure things are reliable, secure, efficient, cost-effective, and perform well?

The Azure Well-Architected Framework is there to help you answer that question, based on its key pillars.

The way it works is that you’re constantly in a process of ensuring it remains in a well-architected state throughout its entire lifecycle. The Well-Architected framework can help you assess whether that’s true – or not, while also showing you what to pay attention to. 

What are the 6 Pillars of the Well-Architected Framework in Azure? 

The Well-Architected Framework comprises several key pillars. It started with five, but now we’ve got six. So it started with: 

1. Operational excellence 
2. Security 
3. Reliability 
4. Performance efficiency 
5. Cost optimisation 

And now we also have: sustainability (6).

Let’s get into each: 

Pillar 1: Cost Optimisation (or efficiency?)

Cost optimisation goes beyond reducing your cloud bill. This involves techniques such as:

• Right-sizing workloads
• Turning off unused resources
• Avoiding waste like always-on environments no one uses. 

It’s also iterative. And while the smaller bills are what everyone wants, the ultimate goal of cost optimisation is to increase the value of your cloud.

We could even argue that this is more about cost efficiency, rather than optimisation, as we want every penny invested in the cloud to be used as efficiently as possible, aligning with the FinOps framework.

Microsoft provides a detailed checklist to help you get started: https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/checklist 

Pillar 2: Operational Excellence 

When it comes to operational excellence, think about: do you have the processes, procedures, and know-how to run things well? 

Operational excellence refers to ensuring you have complete visibility into how your application is running and providing the best experience for your users. It’s about building processes that help you run stable, efficient systems that give you the speed and velocity of feature releases. At the centre of this pillar are DevOps practices and monitoring solutions. These define how you handle development, manage releases, and maintain observability across your systems. 

Microsoft provides a detailed checklist to help you apply Operational Excellence in Azure: https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/checklist 

Pillar 3: Performance Efficiency 

Performance efficiency is matching an application’s available resources with the demand it’s receiving. In other words, you want to ensure that what you have available works with the demand. This means you have to plan for scaling, especially for modern businesses with changing demands (think huge traffic spikes) it’s crucial. 

Also, think about the threshold you set for scaling. How fast can your Azure resources actually scale up or out? When you know traffic patterns, it makes sense to schedule scaling ahead of time so you're not reacting too late in those cases. 

Also, check your network and storage performance to ensure their levels are within acceptable limits. You don’t want excessive network latency (a slow network), so avoid unnecessary trips between Azure regions (cross-region) or waiting for roundtrips across continents (cross-continent traffic).

Where your data resides also matters. Do you really need it all in one place? Azure lets you spread data across regions, but you must design for it.

Microsoft has a solid checklist to help you plan for all this: https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/checklist. 

Pillar 4: Security 

Security is more than just protecting the data that your organisation uses, stores, and transfers. It’s about protecting all your cloud resources, assets, etc. 

Azure security evolves around defence-in-depth: managing risk across every layer of your application.

These are all important security layers that you need to consider when designing your application. All your workloads should also be built around the approach of Zero Trust.  

That said, it’s also about understanding context.

• What’s the threat model for this workload?
• Where does responsibility sit?

Azure operates on a shared responsibility model: 

Microsoft’s security checklist is available here: https://learn.microsoft.com/en-us/azure/well-architected/security/checklist 

Pillar 5: Reliability 

What are the consequences if your environment goes down? How long can your business function without access to critical systems or data?  

If you're unprepared, any disaster can directly affect business revenue or even take you out of business. Therefore, we must design systems that meet the expected level of uptime and availability at the appropriate level; reliability. 

It also means understanding how SLAs work in Azure. Your own app’s reliability depends on how the underlying services perform, and those all come with their own SLAs. You need to examine them together, determine which component has the lowest SLA, and plan accordingly. 

Check out all Microsoft’s best practices for reliability: https://learn.microsoft.com/en-us/azure/well-architected/reliability/checklist 

Pillar 6: Sustainability 

Sustainability is a newer pillar that focuses on efficient resource utilisation to reduce the carbon footprint and other environmental impacts of cloud computing. It promotes energy-efficient practices, less waste, and smarter use of resources across the entire lifecycle. 

A key part of this is avoiding wasteful patterns like overprovisioning or relying too heavily on reserved instances. While reservations can lower costs, they often lead to idle infrastructure that still consumes energy. Better utilisation means fewer idle resources and a smaller environmental impact.

Architectural choices also matter. Every new feature you launch increases your carbon footprint.

Ask yourself: Is there a more efficient way to design this? Can you solve your architectural challenges in another way? 

Additional design principles to consider 

In addition to these pillars, there are several consistent design principles that you should consider throughout your architecture. 

• Enable architectural evolution: No architecture is static. Allow for the evolution of your architecture by leveraging new services, tools, and technologies as they become available. 
• Use data to make decisions: Collect data, analyse it, and use it to make decisions surrounding your architecture. From cost data to performance to user load, using data can guide you in making the right choices for your environment. 
• Educate and enable: Cloud technology evolves quickly. Educate your development, operations, and business teams to help them make informed decisions and build solutions that address business problems. Document and share configurations, decisions, and best practices within your organisation. 
• Automate: Automation of manual activities reduces operational costs, minimises error introduced by manual steps, and provides consistency between environments. 

What to consider when using the Azure Well-Architected Framework? 

You shouldn’t simply adopt the best practices from the WAF and apply them as is. If you treat it like a checklist and follow all recommendations blindly, it will break things. 

If you take a recently migrated environment and apply the best practices from the framework at infrastructure level, many applications will stop working. It’s a breaking change because they weren’t designed for that.

Let’s give you some examples: 

• Example 1: Disable public access on a storage account: If you click to disable public access on a storage account, and your application depends on that access, it’ll break. You fix the recommendation, but now your app doesn’t work.
• Example 2: Disabling TLS 1.1.: While it’s often a good best practice, it doesn’t check if you still have traffic coming over TLS 1.1. The system doesn’t verify if it’s a good idea for your specific use case. 

These examples illustrate that a quick fix can lead to a breaking change. The point is that not every recommendation fits your workload, which is why you must always look at your workloads.

Closing thoughts 

Moving just your resources to the cloud is taking advantage of only a small portion of what the cloud can bring to your organisation. The Azure Well-Architected Framework (WAF) can help guide you towards a more cloud-native setup that’s efficient, secure, and resilient. 

However, you should treat it as a set of best “possible” practices - your “conversation starters”, helping you align what's on the roadmap. 

Try to integrate as much of the Well-Architected Framework and standards as possible into your base landing zone but remember to validate: will these changes break anything? 

Doing it every three or six months helps you step out of the day-to-day chaos and assess:

• What did we build? 
• Is it still the right direction?
• Does it match our roadmap?
• Do we need to change? 

Again, you need to balance what’s important for your company and your business case. 

Remember, Well Architected Framework is a lifecycle. Maybe you score 60% today. Recheck it next month. Then again the month after. Use those insights to shape your product roadmap.