Azure Solutions Architecture · AZ-305 · Architecture Foundations · by Raushan Ranjan, MCT
Azure Global Infrastructure – “The City You’re Moving Into”
Think of Azure as a giant city where companies can rent offices, factories, and kitchens instead of building everything themselves.
- Region → A city in the cloud (East US, UAE North).
- Availability Zone (AZ) → Neighborhoods in that city, separated for reliability.
- Region Pair → Twin city in another location for disaster recovery.
Tip: Always place your critical workloads across AZs and region pairs for high availability.
Azure Resource Hierarchy – “Company Structure”
Imagine your company HQ and how it’s organized:
- Tenant → Company HQ (Azure AD)
- Management Groups (MGs) → Departments (Finance, Sales, IT)
- Subscriptions → Bank accounts for projects
- Resource Groups (RGs) → Filing cabinets per project
- Resources → Individual files, servers, or applications inside the cabinet
Key Idea: Governance and cost control trickle down from the top (MG) to each resource.
The Azure Solution Architect Role – “The Architect, Not the Builder”
Your client isn’t expected to code, he’s the strategist:
- Decide what fits best: VM, App Service, Functions?
- Balance cost, performance, security, reliability, operations (CROPS pillars).
- Make designs repeatable, scalable, and governed.
Analogy: The difference between a chef (DevOps Engineer) and a restaurant designer (Solution Architect).
Microsoft Cloud Adoption Framework (CAF) – “How to Move HQ Smoothly”
CAF is like a moving guide for your company:
- Strategy → Why move to cloud? (Cost, speed, agility)
- Plan → Which departments/projects move first
- Ready → Prepare office floors, furniture, security (Landing Zones!)
- Adopt → Move teams & equipment
- Govern → Rules, budgets, compliance (Policy + RBAC + Tags)
- Manage → Daily maintenance & operations
Note: CAF governance phase is critical — it’s what keeps your HQ organized and your resources under control.
Governance & Management Topics – “City Council Rules”
Before you build anything, you need rules and guardrails.
- Design for Governance → Set policies, compliance, cost rules
- Analogy: City council setting building codes and electricity rules
- Management Groups (MGs) → Departments
- Organize subscriptions and inherit rules
- Subscriptions → Bank accounts
- Separate costs and boundaries per department/project
- Resource Groups → Filing cabinets
- Logical container for resources, helps with lifecycle management
- Resource Tagging → Labels on invoices/files
- Cost center, owner, environment → makes reporting & automation easy
- Azure Policy → Enforce rules
- Example: Only allow certain VM sizes in a region
- Analogy: Building permits and zoning rules
- RBAC → Who can do what
- Analogy: Keycards for different floors/rooms
- Landing Zones → Pre-built office floors ready to move in
- Governance, network, identity, subscriptions ready from day one
Tip: Governance first → if you don’t set rules, chaos spreads as the environment grows.
Compute Services – “Where Your Work Happens”
Think of compute as where your applications “live and work”. Different types for different needs:
| Service | Analogy | Use Case |
|---|---|---|
| VMs | Own kitchen | Full control, legacy apps, full OS access |
| Azure Batch | Factory assembly line | Large-scale jobs like simulations or renderings |
| App Service | Restaurant with chef & waiters | Web apps/APIs, managed scaling, minimal infra management |
| Azure Container Instances (ACI) | Food truck | Short-lived, bursty workloads, quick deployment |
| Azure Kubernetes Service (AKS) | Fleet of food trucks | Microservices, scalable container orchestration |
| Azure Functions | Vending machine | Event-driven, serverless, pay-per-use |
| Logic Apps | Universal remote | Automate and integrate workflows across services |
Compare & Contrast Quick Memory Aid:
- VMs → full control, ops heavy
- App Service → managed, less ops, web-focused
- Functions/Logic Apps → event-driven, serverless, pay per execution
- ACI/AKS → containerized, scalable, modern workloads