Architecture Design Skill
Design comprehensive Azure architectures and produce HLD documentation following Well-Architected Framework and Cloud Adoption Framework best practices.
When to Use
- Design new Azure solutions from requirements
- Create High-Level Design (HLD) documentation
- Select Azure services and architectural patterns
- Plan cloud migrations or modernization
- Produce architecture decision records
Design Process
1. Gather Requirements
Ask clarifying questions about:
- Workload type: Web app, API, data processing, IoT, AI/ML
- Scale: User count, data volume, geographic distribution
- Performance: Response time, throughput, latency SLAs
- Availability: Uptime requirements (e.g., 99.9%, 99.99%)
- Security: Data classification, compliance (HIPAA, GDPR, PCI-DSS)
- Budget: Monthly/annual cost constraints
- Timeline: Deployment deadlines, phasing needs
2. Select Azure Services
Service Selection Priority: PaaS > Containers > IaaS
Refer to references.md for detailed guidance on:
- Compute options (App Service, Functions, AKS, Container Apps, VMs)
- Data storage (Azure SQL, Cosmos DB, PostgreSQL, Blob Storage)
- Messaging (Service Bus, Event Hubs, Event Grid, Storage Queues)
- Networking (Front Door, Application Gateway, Load Balancer)
Key Decision Criteria:
- Match service capabilities to requirements
- Consider team expertise and operational overhead
- Evaluate cost vs. feature trade-offs
- Prioritize managed services to reduce operations
3. Design Architecture
Apply patterns based on requirements:
N-Tier (Traditional):
- When: Standard web apps, proven patterns, team familiarity
- Structure: Frontend → Load Balancer → App Tier → Database
- Services: App Service, Azure SQL, Application Gateway, Redis Cache
Microservices:
- When: Loosely coupled services, independent scaling, polyglot needs
- Structure: API Gateway → Services → Message Bus → Databases
- Services: API Management, AKS/Container Apps, Service Bus, Cosmos DB
Event-Driven:
- When: Asynchronous processing, reactive systems, decoupled components
- Structure: Event Sources → Event Hub/Grid → Functions/Logic Apps → Storage
- Services: Event Hubs, Azure Functions, Cosmos DB, Service Bus
Serverless:
- When: Sporadic workloads, event processing, cost-sensitive scenarios
- Structure: HTTP/Timer/Queue Triggers → Functions → Storage/Database
- Services: Azure Functions, Logic Apps, Cosmos DB, Blob Storage
4. Apply Well-Architected Framework
Address all five pillars (detailed checklists in waf-assessment skill):
Reliability:
- Availability Zones for production
- Multi-region for mission-critical (99.99%+)
- Health checks and auto-healing
- Backup strategy with RPO/RTO defined
Security:
- Managed identities (no credentials in code)
- Private endpoints for PaaS services
- HTTPS only with TLS 1.2+
- Network security groups (least privilege)
- Azure Key Vault for secrets
- Azure AD authentication and RBAC
Cost Optimization:
- Right-size resources (start small, scale up)
- Auto-scaling policies
- Reserved instances for predictable workloads
- Storage tiers (Hot/Cool/Archive)
- Cost monitoring and alerts
Operational Excellence:
- Infrastructure as Code (Bicep or Terraform)
- CI/CD pipelines
- Application Insights + Log Analytics
- Alerts for critical scenarios
- Automated deployment and rollback
Performance Efficiency:
- CDN for static content
- Caching strategy (Redis, CDN)
- Asynchronous processing
- Appropriate compute SKUs
- Auto-scaling rules
5. Create Naming Convention
Follow Cloud Adoption Framework:
{resource-type}-{workload}-{environment}-{region}-{instance}
Examples:
- rg-ecommerce-prod-eastus-001
- app-ecommerce-prod-eastus-001
- sql-ecommerce-prod-eastus-001
- kv-ecommerce-prod-eastus
- func-orderproc-prod-eastus-001
Standard Tags:
Environment: Production | Staging | Development | Test
Owner: teamname@company.com
CostCenter: IT-12345
Project: ProjectName
BusinessUnit: Sales | Marketing | Engineering
Criticality: Critical | High | Medium | Low
DataClassification: Public | Internal | Confidential | Restricted
6. Estimate Costs
Invoke the azure-pricing skill to retrieve live retail pricing. Never estimate costs from memory.
The azure-pricing skill will:
- Call
azure-mcp/pricing (pricing_get) per billable resource SKU and region
- Return a three-column table: Pay-as-you-go | 1-year Reserved | 3-year Reserved
- Identify top reserved instance / savings plan candidates
Confirm all service SKUs in step 3 before requesting pricing — the tool requires a specific SKU or service name.
Structure the cost output by category:
- Compute (App Service, Functions, VMs, AKS nodes)
- Data (SQL, Cosmos DB, Storage)
- Networking (Front Door, App Gateway, Firewall, Bandwidth)
- Monitoring (Application Insights, Log Analytics)
High-Level Design Output Format
Generate comprehensive HLD documents with these sections:
1. Executive Summary
- Solution overview (2-3 paragraphs)
- Key benefits and business value
- High-level cost estimate
- Timeline and deployment approach
2. Requirements Summary
- Functional requirements (bullet points)
- Non-functional requirements (performance, availability, security)
- Constraints and assumptions
3. Architecture Overview
- Architecture diagram description (components and connections)
- Design pattern used (N-tier, microservices, event-driven, serverless)
- Rationale for architectural approach
4. Component Design
For each component:
- Service Name: Azure service selected
- SKU/Tier: Specific pricing tier (e.g., App Service P2v3, Azure SQL S2)
- Purpose: Role in the architecture
- Configuration: Key settings (regions, zones, instances, capacity)
- Naming: Following CAF convention (rg-app-prod-eastus-001)
5. Networking Design
- Virtual Network configuration (address spaces)
- Subnets and network security groups
- Private endpoints and service endpoints
- Ingress/egress patterns (load balancers, gateways)
- DNS configuration
6. Security Design
- Authentication and authorization (Azure AD, Managed Identity)
- Secrets management (Key Vault)
- Encryption (at-rest and in-transit)
- Network security (NSGs, firewalls, WAF)
- Compliance requirements
7. Data Design
- Database schema approach
- Data flow between components
- Backup and recovery strategy (RPO/RTO)
- Data retention policies
- Disaster recovery approach
8. Monitoring and Operations
- Application Insights configuration
- Log Analytics workspace
- Key metrics to monitor
- Alert definitions and thresholds
- Dashboard recommendations
9. Deployment Strategy
- Infrastructure as Code approach (Bicep or Terraform)
- CI/CD pipeline design
- Environment strategy (dev, staging, prod)
- Deployment sequence and dependencies
- Rollback procedure
10. Cost Breakdown
- Invoke the
azure-pricing skill to retrieve live retail prices per service SKU and target region
- Monthly cost per service and annual projection
- Side-by-side table: Pay-as-you-go | 1-year Reserved | 3-year Reserved
- Cost optimization recommendations (right-sizing, spot/preemptible nodes, storage tiers)
- Top reserved instance / savings plan candidates with estimated monthly saving
11. Well-Architected Assessment
- Brief evaluation against each WAF pillar
- Key strengths of the design
- Areas for future improvement
12. Risks and Mitigations
- Identified technical risks
- Mitigation strategies
- Dependencies and assumptions
13. Next Steps
- Immediate actions (Phase 1)
- Short-term improvements (Phase 2)
- Long-term roadmap (Phase 3)
Example HLD Snippet
# High-Level Design: E-Commerce Web Platform
## 1. Executive Summary
This HLD describes a scalable e-commerce platform on Azure supporting up to 100K concurrent users
with 99.95% availability. The solution uses proven PaaS services with multi-region capabilities,
comprehensive security controls, and cost-optimized infrastructure.
**Key Benefits:**
- Global reach with Azure Front Door CDN
- Auto-scaling for traffic spikes (Black Friday, holidays)
- PCI-DSS compliant payment processing
- **Estimated cost**: see Section 10 — priced live via the `azure-pricing` skill per SKU and target region
**Timeline:** 8-week implementation with phased rollout
## 3. Architecture Overview
**Pattern:** N-Tier with asynchronous order processing
**Components:**
Azure Front Door (Global CDN + WAF)
└─ Application Gateway (Regional WAF + LB)
├─ App Service (Web Frontend - 3 instances, P2v3)
├─ App Service (API Backend - 3 instances, P2v3)
├─ Azure Functions (Order Processor, Premium)
├─ Azure SQL Database (S2 DTU, 50GB)
├─ Redis Cache (Basic C1, 1GB)
└─ Blob Storage (Hot tier, product images)
**Rationale:** N-tier provides proven scalability, PaaS reduces operational overhead,
Functions handle asynchronous order processing, Azure SQL provides ACID guarantees.
## 4. Component Design
**Frontend Web App**
- Service: Azure App Service (Linux)
- SKU: P2v3 (2 vCores, 8GB RAM)
- Instances: 3 (Availability Zones 1, 2, 3)
- Auto-scale: 3-10 instances based on CPU > 70%
- Naming: app-ecommerce-web-prod-eastus-001
- Purpose: Serves customer-facing website
[Continue with all components...]
Tips for Great HLDs
Be Specific: Use exact service names and SKUs (not "database" but "Azure SQL Database S2 DTU")
Show Trade-offs: Explain why you chose service X over Y
Include Diagrams: Describe architecture visually with clear component relationships
Live Pricing: Invoke the azure-pricing skill for every cost section — never guess prices from memory; always pass the target region and currency (e.g. GBP for UK workloads)
Cost-Aware: Always provide cost estimates and optimization opportunities
Security First: Address authentication, authorization, encryption, network security
WAF Alignment: Reference specific WAF principles in design decisions
Naming Standards: Use CAF conventions consistently
Implementation-Ready: Provide enough detail for IaC generation
Avoid: Vague terms, missing costs, ignoring security, skipping WAF, incomplete components, no rationale
1---2name: architecture-design3description: Design Azure cloud architectures from requirements and generate High-Level Design (HLD) documentation with service selection, patterns, cost estimates, and WAF alignment. Use this when asked to design or architect Azure solutions.4---5
6# Architecture Design Skill
7
8Design comprehensive Azure architectures and produce HLD documentation following Well-Architected Framework and Cloud Adoption Framework best practices.
9
10## When to Use
11
12- Design new Azure solutions from requirements
13- Create High-Level Design (HLD) documentation
14- Select Azure services and architectural patterns
15- Plan cloud migrations or modernization
16- Produce architecture decision records
17
18## Design Process
19
20### 1. Gather Requirements
21
22Ask clarifying questions about:
23- **Workload type**: Web app, API, data processing, IoT, AI/ML
24- **Scale**: User count, data volume, geographic distribution
25- **Performance**: Response time, throughput, latency SLAs
26- **Availability**: Uptime requirements (e.g., 99.9%, 99.99%)
27- **Security**: Data classification, compliance (HIPAA, GDPR, PCI-DSS)
28- **Budget**: Monthly/annual cost constraints
29- **Timeline**: Deployment deadlines, phasing needs
30
31### 2. Select Azure Services
32
33**Service Selection Priority:** PaaS > Containers > IaaS
34
35Refer to [references.md](./references.md) for detailed guidance on:
36- Compute options (App Service, Functions, AKS, Container Apps, VMs)
37- Data storage (Azure SQL, Cosmos DB, PostgreSQL, Blob Storage)
38- Messaging (Service Bus, Event Hubs, Event Grid, Storage Queues)
39- Networking (Front Door, Application Gateway, Load Balancer)
40
41**Key Decision Criteria:**
42- Match service capabilities to requirements
43- Consider team expertise and operational overhead
44- Evaluate cost vs. feature trade-offs
45- Prioritize managed services to reduce operations
46
47### 3. Design Architecture
48
49Apply patterns based on requirements:
50
51**N-Tier (Traditional):**
52- **When**: Standard web apps, proven patterns, team familiarity
53- **Structure**: Frontend → Load Balancer → App Tier → Database
54- **Services**: App Service, Azure SQL, Application Gateway, Redis Cache
55
56**Microservices:**
57- **When**: Loosely coupled services, independent scaling, polyglot needs
58- **Structure**: API Gateway → Services → Message Bus → Databases
59- **Services**: API Management, AKS/Container Apps, Service Bus, Cosmos DB
60
61**Event-Driven:**
62- **When**: Asynchronous processing, reactive systems, decoupled components
63- **Structure**: Event Sources → Event Hub/Grid → Functions/Logic Apps → Storage
64- **Services**: Event Hubs, Azure Functions, Cosmos DB, Service Bus
65
66**Serverless:**
67- **When**: Sporadic workloads, event processing, cost-sensitive scenarios
68- **Structure**: HTTP/Timer/Queue Triggers → Functions → Storage/Database
69- **Services**: Azure Functions, Logic Apps, Cosmos DB, Blob Storage
70
71### 4. Apply Well-Architected Framework
72
73Address all five pillars (detailed checklists in [waf-assessment skill](../waf-assessment/)):
74
75**Reliability:**
76- Availability Zones for production
77- Multi-region for mission-critical (99.99%+)
78- Health checks and auto-healing
79- Backup strategy with RPO/RTO defined
80
81**Security:**
82- Managed identities (no credentials in code)
83- Private endpoints for PaaS services
84- HTTPS only with TLS 1.2+
85- Network security groups (least privilege)
86- Azure Key Vault for secrets
87- Azure AD authentication and RBAC
88
89**Cost Optimization:**
90- Right-size resources (start small, scale up)
91- Auto-scaling policies
92- Reserved instances for predictable workloads
93- Storage tiers (Hot/Cool/Archive)
94- Cost monitoring and alerts
95
96**Operational Excellence:**
97- Infrastructure as Code (Bicep or Terraform)
98- CI/CD pipelines
99- Application Insights + Log Analytics
100- Alerts for critical scenarios
101- Automated deployment and rollback
102
103**Performance Efficiency:**
104- CDN for static content
105- Caching strategy (Redis, CDN)
106- Asynchronous processing
107- Appropriate compute SKUs
108- Auto-scaling rules
109
110### 5. Create Naming Convention
111
112Follow Cloud Adoption Framework:
113```
114{resource-type}-{workload}-{environment}-{region}-{instance}
115
116Examples:
117- rg-ecommerce-prod-eastus-001
118- app-ecommerce-prod-eastus-001
119- sql-ecommerce-prod-eastus-001
120- kv-ecommerce-prod-eastus
121- func-orderproc-prod-eastus-001
122```
123
124**Standard Tags:**
125```
126Environment: Production | Staging | Development | Test
127Owner: teamname@company.com
128CostCenter: IT-12345
129Project: ProjectName
130BusinessUnit: Sales | Marketing | Engineering
131Criticality: Critical | High | Medium | Low
132DataClassification: Public | Internal | Confidential | Restricted
133```
134
135### 6. Estimate Costs
136
137**Invoke the `azure-pricing` skill** to retrieve live retail pricing. Never estimate costs from memory.
138
139The `azure-pricing` skill will:
140- Call `azure-mcp/pricing` (`pricing_get`) per billable resource SKU and region
141- Return a three-column table: Pay-as-you-go | 1-year Reserved | 3-year Reserved
142- Identify top reserved instance / savings plan candidates
143
144> Confirm all service SKUs in step 3 before requesting pricing — the tool requires a specific SKU or service name.
145
146Structure the cost output by category:
147- Compute (App Service, Functions, VMs, AKS nodes)
148- Data (SQL, Cosmos DB, Storage)
149- Networking (Front Door, App Gateway, Firewall, Bandwidth)
150- Monitoring (Application Insights, Log Analytics)
151
152## High-Level Design Output Format
153
154Generate comprehensive HLD documents with these sections:
155
156### 1. Executive Summary
157- Solution overview (2-3 paragraphs)
158- Key benefits and business value
159- High-level cost estimate
160- Timeline and deployment approach
161
162### 2. Requirements Summary
163- Functional requirements (bullet points)
164- Non-functional requirements (performance, availability, security)
165- Constraints and assumptions
166
167### 3. Architecture Overview
168- Architecture diagram description (components and connections)
169- Design pattern used (N-tier, microservices, event-driven, serverless)
170- Rationale for architectural approach
171
172### 4. Component Design
173
174For each component:
175- **Service Name**: Azure service selected
176- **SKU/Tier**: Specific pricing tier (e.g., App Service P2v3, Azure SQL S2)
177- **Purpose**: Role in the architecture
178- **Configuration**: Key settings (regions, zones, instances, capacity)
179- **Naming**: Following CAF convention (rg-app-prod-eastus-001)
180
181### 5. Networking Design
182- Virtual Network configuration (address spaces)
183- Subnets and network security groups
184- Private endpoints and service endpoints
185- Ingress/egress patterns (load balancers, gateways)
186- DNS configuration
187
188### 6. Security Design
189- Authentication and authorization (Azure AD, Managed Identity)
190- Secrets management (Key Vault)
191- Encryption (at-rest and in-transit)
192- Network security (NSGs, firewalls, WAF)
193- Compliance requirements
194
195### 7. Data Design
196- Database schema approach
197- Data flow between components
198- Backup and recovery strategy (RPO/RTO)
199- Data retention policies
200- Disaster recovery approach
201
202### 8. Monitoring and Operations
203- Application Insights configuration
204- Log Analytics workspace
205- Key metrics to monitor
206- Alert definitions and thresholds
207- Dashboard recommendations
208
209### 9. Deployment Strategy
210- Infrastructure as Code approach (Bicep or Terraform)
211- CI/CD pipeline design
212- Environment strategy (dev, staging, prod)
213- Deployment sequence and dependencies
214- Rollback procedure
215
216### 10. Cost Breakdown
217- **Invoke the `azure-pricing` skill** to retrieve live retail prices per service SKU and target region
218- Monthly cost per service and annual projection
219- Side-by-side table: Pay-as-you-go | 1-year Reserved | 3-year Reserved
220- Cost optimization recommendations (right-sizing, spot/preemptible nodes, storage tiers)
221- Top reserved instance / savings plan candidates with estimated monthly saving
222
223### 11. Well-Architected Assessment
224- Brief evaluation against each WAF pillar
225- Key strengths of the design
226- Areas for future improvement
227
228### 12. Risks and Mitigations
229- Identified technical risks
230- Mitigation strategies
231- Dependencies and assumptions
232
233### 13. Next Steps
234- Immediate actions (Phase 1)
235- Short-term improvements (Phase 2)
236- Long-term roadmap (Phase 3)
237
238## Example HLD Snippet
239
240```markdown
241# High-Level Design: E-Commerce Web Platform
242
243## 1. Executive Summary
244
245This HLD describes a scalable e-commerce platform on Azure supporting up to 100K concurrent users
246with 99.95% availability. The solution uses proven PaaS services with multi-region capabilities,
247comprehensive security controls, and cost-optimized infrastructure.
248
249**Key Benefits:**
250- Global reach with Azure Front Door CDN
251- Auto-scaling for traffic spikes (Black Friday, holidays)
252- PCI-DSS compliant payment processing
253- **Estimated cost**: see Section 10 — priced live via the `azure-pricing` skill per SKU and target region
254
255**Timeline:** 8-week implementation with phased rollout
256
257## 3. Architecture Overview
258
259**Pattern:** N-Tier with asynchronous order processing
260
261**Components:**
262```
263Azure Front Door (Global CDN + WAF)
264└─ Application Gateway (Regional WAF + LB)
265 ├─ App Service (Web Frontend - 3 instances, P2v3)
266 ├─ App Service (API Backend - 3 instances, P2v3)
267 ├─ Azure Functions (Order Processor, Premium)
268 ├─ Azure SQL Database (S2 DTU, 50GB)
269 ├─ Redis Cache (Basic C1, 1GB)
270 └─ Blob Storage (Hot tier, product images)
271```
272
273**Rationale:** N-tier provides proven scalability, PaaS reduces operational overhead,
274Functions handle asynchronous order processing, Azure SQL provides ACID guarantees.
275
276## 4. Component Design
277
278**Frontend Web App**
279- Service: Azure App Service (Linux)
280- SKU: P2v3 (2 vCores, 8GB RAM)
281- Instances: 3 (Availability Zones 1, 2, 3)
282- Auto-scale: 3-10 instances based on CPU > 70%
283- Naming: app-ecommerce-web-prod-eastus-001
284- Purpose: Serves customer-facing website
285
286[Continue with all components...]
287```
288
289## Tips for Great HLDs
290
291**Be Specific:** Use exact service names and SKUs (not "database" but "Azure SQL Database S2 DTU")
292**Show Trade-offs:** Explain why you chose service X over Y
293**Include Diagrams:** Describe architecture visually with clear component relationships
294**Live Pricing:** Invoke the **`azure-pricing` skill** for every cost section — never guess prices from memory; always pass the target `region` and `currency` (e.g. `GBP` for UK workloads)
295**Cost-Aware:** Always provide cost estimates and optimization opportunities
296**Security First:** Address authentication, authorization, encryption, network security
297**WAF Alignment:** Reference specific WAF principles in design decisions
298**Naming Standards:** Use CAF conventions consistently
299**Implementation-Ready:** Provide enough detail for IaC generation
300
301**Avoid:** Vague terms, missing costs, ignoring security, skipping WAF, incomplete components, no rationale
gabrielmoreira