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
Provide monthly cost breakdown by service category:
- Compute (App Service, Functions, VMs)
- Data (SQL, Cosmos DB, Storage)
- Networking (Front Door, App Gateway, Bandwidth)
- Monitoring (Application Insights, Log Analytics)
Include cost optimization opportunities and reserved instance recommendations.
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
- Monthly cost estimate by service
- Annual projection
- Cost optimization recommendations
- Reserved instance opportunities
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: $2,850/month (Production)
**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
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-design-23description: 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
137Provide monthly cost breakdown by service category:
138- Compute (App Service, Functions, VMs)
139- Data (SQL, Cosmos DB, Storage)
140- Networking (Front Door, App Gateway, Bandwidth)
141- Monitoring (Application Insights, Log Analytics)
142
143Include cost optimization opportunities and reserved instance recommendations.
144
145## High-Level Design Output Format
146
147Generate comprehensive HLD documents with these sections:
148
149### 1. Executive Summary
150- Solution overview (2-3 paragraphs)
151- Key benefits and business value
152- High-level cost estimate
153- Timeline and deployment approach
154
155### 2. Requirements Summary
156- Functional requirements (bullet points)
157- Non-functional requirements (performance, availability, security)
158- Constraints and assumptions
159
160### 3. Architecture Overview
161- Architecture diagram description (components and connections)
162- Design pattern used (N-tier, microservices, event-driven, serverless)
163- Rationale for architectural approach
164
165### 4. Component Design
166
167For each component:
168- **Service Name**: Azure service selected
169- **SKU/Tier**: Specific pricing tier (e.g., App Service P2v3, Azure SQL S2)
170- **Purpose**: Role in the architecture
171- **Configuration**: Key settings (regions, zones, instances, capacity)
172- **Naming**: Following CAF convention (rg-app-prod-eastus-001)
173
174### 5. Networking Design
175- Virtual Network configuration (address spaces)
176- Subnets and network security groups
177- Private endpoints and service endpoints
178- Ingress/egress patterns (load balancers, gateways)
179- DNS configuration
180
181### 6. Security Design
182- Authentication and authorization (Azure AD, Managed Identity)
183- Secrets management (Key Vault)
184- Encryption (at-rest and in-transit)
185- Network security (NSGs, firewalls, WAF)
186- Compliance requirements
187
188### 7. Data Design
189- Database schema approach
190- Data flow between components
191- Backup and recovery strategy (RPO/RTO)
192- Data retention policies
193- Disaster recovery approach
194
195### 8. Monitoring and Operations
196- Application Insights configuration
197- Log Analytics workspace
198- Key metrics to monitor
199- Alert definitions and thresholds
200- Dashboard recommendations
201
202### 9. Deployment Strategy
203- Infrastructure as Code approach (Bicep or Terraform)
204- CI/CD pipeline design
205- Environment strategy (dev, staging, prod)
206- Deployment sequence and dependencies
207- Rollback procedure
208
209### 10. Cost Breakdown
210- Monthly cost estimate by service
211- Annual projection
212- Cost optimization recommendations
213- Reserved instance opportunities
214
215### 11. Well-Architected Assessment
216- Brief evaluation against each WAF pillar
217- Key strengths of the design
218- Areas for future improvement
219
220### 12. Risks and Mitigations
221- Identified technical risks
222- Mitigation strategies
223- Dependencies and assumptions
224
225### 13. Next Steps
226- Immediate actions (Phase 1)
227- Short-term improvements (Phase 2)
228- Long-term roadmap (Phase 3)
229
230## Example HLD Snippet
231
232```markdown
233# High-Level Design: E-Commerce Web Platform
234
235## 1. Executive Summary
236
237This HLD describes a scalable e-commerce platform on Azure supporting up to 100K concurrent users
238with 99.95% availability. The solution uses proven PaaS services with multi-region capabilities,
239comprehensive security controls, and cost-optimized infrastructure.
240
241**Key Benefits:**
242- Global reach with Azure Front Door CDN
243- Auto-scaling for traffic spikes (Black Friday, holidays)
244- PCI-DSS compliant payment processing
245- Estimated cost: $2,850/month (Production)
246
247**Timeline:** 8-week implementation with phased rollout
248
249## 3. Architecture Overview
250
251**Pattern:** N-Tier with asynchronous order processing
252
253**Components:**
254```
255Azure Front Door (Global CDN + WAF)
256└─ Application Gateway (Regional WAF + LB)
257 ├─ App Service (Web Frontend - 3 instances, P2v3)
258 ├─ App Service (API Backend - 3 instances, P2v3)
259 ├─ Azure Functions (Order Processor, Premium)
260 ├─ Azure SQL Database (S2 DTU, 50GB)
261 ├─ Redis Cache (Basic C1, 1GB)
262 └─ Blob Storage (Hot tier, product images)
263```
264
265**Rationale:** N-tier provides proven scalability, PaaS reduces operational overhead,
266Functions handle asynchronous order processing, Azure SQL provides ACID guarantees.
267
268## 4. Component Design
269
270**Frontend Web App**
271- Service: Azure App Service (Linux)
272- SKU: P2v3 (2 vCores, 8GB RAM)
273- Instances: 3 (Availability Zones 1, 2, 3)
274- Auto-scale: 3-10 instances based on CPU > 70%
275- Naming: app-ecommerce-web-prod-eastus-001
276- Purpose: Serves customer-facing website
277
278[Continue with all components...]
279```
280
281## Tips for Great HLDs
282
283**Be Specific:** Use exact service names and SKUs (not "database" but "Azure SQL Database S2 DTU")
284**Show Trade-offs:** Explain why you chose service X over Y
285**Include Diagrams:** Describe architecture visually with clear component relationships
286**Cost-Aware:** Always provide cost estimates and optimization opportunities
287**Security First:** Address authentication, authorization, encryption, network security
288**WAF Alignment:** Reference specific WAF principles in design decisions
289**Naming Standards:** Use CAF conventions consistently
290**Implementation-Ready:** Provide enough detail for IaC generation
291
292**Avoid:** Vague terms, missing costs, ignoring security, skipping WAF, incomplete components, no rationale
diegosouzapw