Cloud Solution Architect
MicrosoftOfficialPublished by Microsoft
- Skill
- Guidelines
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill configures an AI agent to act as a Cloud Solution Architect, providing structured guidance based on the Azure Architecture Center. It enables the agent to assist with designing production-grade cloud systems, selecting appropriate architecture styles, applying proven design patterns, and conducting systematic reviews against the Well-Architected Framework (WAF). The agent is equipped with knowledge of 10 core design principles, 44 cloud design patterns, and decision frameworks for technology selection, ensuring that architectural decisions are well-reasoned and aligned with industry-standard best practices.
What it does
- Provides guidance on selecting architecture styles like N-tier, Microservices, and Event-driven.
- Maps 44 cloud design patterns to WAF pillars for reliability, security, and performance.
- Offers a decision framework for choosing compute, storage, data, and messaging technologies.
- Conducts systematic architecture reviews using the Well-Architected Framework.
- Identifies performance antipatterns and suggests remediation strategies.
- Supports the creation of Architecture Decision Records (ADRs) for project documentation.
When to use it
- When designing a new cloud-based application or system architecture.
- When reviewing an existing system design for potential improvements or bottlenecks.
- When evaluating technology choices for compute, data, or messaging services.
- When performing a Well-Architected Framework review to ensure system quality.
- When troubleshooting performance issues caused by common cloud antipatterns.
Advantages
- Ensures architectural consistency by following official Azure best practices.
- Facilitates informed decision-making through structured tradeoff analysis.
- Promotes the use of resilient, scalable, and cost-effective design patterns.
- Standardizes the documentation of architectural decisions via ADR templates.
- Helps align technical choices with specific business requirements and SLAs.
Usage examples
- “I am designing a high-traffic e-commerce platform. Which architecture style should I choose?”
- The agent will compare styles like Microservices versus N-tier based on your team's autonomy, domain complexity, and scaling needs, recommending the best fit.
- “Our application is experiencing performance issues under load. Can you help me identify potential antipatterns?”
- The agent will review your current design against known performance antipatterns like 'Busy Database' or 'Chatty I/O' and suggest specific fixes.
- “Help me conduct a Well-Architected Framework review for my current Azure deployment.”
- The agent will guide you through a systematic assessment of your architecture across the five WAF pillars, identifying risks and improvement opportunities.
- “We need to choose a messaging service for our event-driven system. What are the options?”
- The agent will present a decision framework comparing Service Bus, Event Hubs, and Event Grid based on your specific throughput and ordering requirements.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/cloud-solution-architect/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip cloud-solution-architect.zip -d .agents/skills
Documentation by Microsoft
Cloud Solution Architect
Overview
Design well-architected, production-grade cloud systems following Azure Architecture Center best practices. This skill provides:
10 design principles for Azure applications
6 architecture styles with selection guidance
44 cloud design patterns mapped to WAF pillars
Technology choice frameworks for compute, storage, data, messaging
Performance antipatterns to avoid
Architecture review workflow for systematic design validation
Ten Design Principles for Azure Applications
| # | Principle | Key Tactics |
|---|---|---|
| 1 | Design for self-healing | Retry with backoff, circuit breaker, bulkhead isolation, health endpoint monitoring, graceful degradation |
| 2 | Make all things redundant | Eliminate single points of failure, use availability zones, deploy multi-region, replicate data |
| 3 | Minimize coordination | Decouple services, use async messaging, embrace eventual consistency, use domain events |
| 4 | Design to scale out | Horizontal scaling, autoscaling rules, stateless services, avoid session stickiness, partition workloads |
| 5 | Partition around limits | Data partitioning (shard/hash/range), respect compute & network limits, use CDNs for static content |
| 6 | Design for operations | Structured logging, distributed tracing, metrics & dashboards, runbook automation, infrastructure as code |
| 7 | Use managed services | Prefer PaaS over IaaS, reduce operational burden, leverage built-in HA/DR/scaling |
| 8 | Use an identity service | Microsoft Entra ID, managed identity, RBAC, avoid storing credentials, zero-trust principles |
| 9 | Design for evolution | Loose coupling, versioned APIs, backward compatibility, async messaging for integration, feature flags |
| 10 | Build for business needs | Define SLAs/SLOs, establish RTO/RPO targets, domain-driven design, cost modeling, composite SLAs |
Architecture Styles
| Style | Description | When to Use | Key Services |
|---|---|---|---|
| N-tier | Horizontal layers (presentation, business, data) | Traditional enterprise apps, lift-and-shift | App Service, SQL Database, VNets |
| Web-Queue-Worker | Web frontend → message queue → backend worker | Moderate-complexity apps with long-running tasks | App Service, Service Bus, Functions |
| Microservices | Small autonomous services, bounded contexts, independent deploy | Complex domains, independent team scaling | AKS, Container Apps, API Management |
| Event-driven | Pub/sub model, event producers/consumers | Real-time processing, IoT, reactive systems | Event Hubs, Event Grid, Functions |
| Big data | Batch + stream processing pipeline | Analytics, ML pipelines, large-scale data | Synapse, Data Factory, Databricks |
| Big compute | HPC, parallel processing | Simulations, modeling, rendering, genomics | Batch, CycleCloud, HPC VMs |
Selection Criteria
Domain complexity → Microservices (high), N-tier (low-medium)
Team autonomy → Microservices (independent teams), N-tier (single team)
Data volume → Big data (TB+), others (GB)
Latency requirements → Event-driven (real-time), Web-Queue-Worker (tolerant)
Cloud Design Patterns
44 patterns organized by primary concern. WAF pillar mapping: R=Reliability, S=Security, CO=Cost Optimization, OE=Operational Excellence, PE=Performance Efficiency.
Messaging & Communication
| Pattern | Summary | Pillars |
|---|---|---|
| Asynchronous Request-Reply | Decouple request/response with polling or callbacks | R, PE |
| Claim Check | Split large messages; store payload separately, pass reference | R, PE |
| Choreography | Services coordinate via events without central orchestrator | R, OE |
| Competing Consumers | Multiple consumers process messages from shared queue concurrently | R, PE |
| Messaging Bridge | Connect incompatible messaging systems | R, OE |
| Pipes and Filters | Decompose complex processing into reusable filter stages | R, OE |
| Priority Queue | Prioritize requests so higher-priority work is processed first | R, PE |
| Publisher/Subscriber | Decouple senders from receivers via topics/subscriptions | R, PE |
| Queue-Based Load Leveling | Buffer requests with a queue to smooth intermittent loads | R, PE |
| Sequential Convoy | Process related messages in order while allowing parallel groups | R, PE |
Reliability & Resilience
| Pattern | Summary | Pillars |
|---|---|---|
| Bulkhead | Isolate resources per workload to prevent cascading failure | R |
| Circuit Breaker | Stop calling a failing service; fail fast to protect resources | R |
| Compensating Transaction | Undo previously committed steps when a later step fails | R |
| Health Endpoint Monitoring | Expose health checks for load balancers and orchestrators | R, OE |
| Leader Election | Coordinate distributed instances by electing a leader | R |
| Retry | Handle transient faults by retrying with exponential backoff | R |
| Saga | Manage data consistency across microservices with compensating transactions | R |
| Scheduler Agent Supervisor | Coordinate distributed actions with retry and failure handling | R |
Data Management
| Pattern | Summary | Pillars |
|---|---|---|
| Cache-Aside | Load data on demand into cache from data store | PE |
| CQRS | Separate read and write models for independent scaling | PE, R |
| Event Sourcing | Store state as append-only sequence of domain events | R, OE |
| Index Table | Create indexes over frequently queried fields in data stores | PE |
| Materialized View | Pre-compute views over data for efficient queries | PE |
| Sharding | Distribute data across partitions for scale and performance | PE, R |
| Static Content Hosting | Serve static content from cloud storage/CDN directly | PE, CO |
| Valet Key | Grant clients limited direct access to storage resources | S, PE |
Design & Structure
| Pattern | Summary | Pillars |
|---|---|---|
| Ambassador | Offload cross-cutting concerns to a helper sidecar proxy | OE |
| Anti-Corruption Layer | Translate between new and legacy system models | OE, R |
| Backends for Frontends | Create separate backends per frontend type (mobile, web, etc.) | OE, PE |
| Compute Resource Consolidation | Combine multiple workloads into fewer compute instances | CO |
| External Configuration Store | Externalize configuration from deployment packages | OE |
| Sidecar | Deploy helper components alongside the main service | OE |
| Strangler Fig | Incrementally migrate legacy systems by replacing pieces | OE, R |
Security & Access
| Pattern | Summary | Pillars |
|---|---|---|
| Federated Identity | Delegate authentication to an external identity provider | S |
| Gatekeeper | Protect services using a dedicated broker that validates requests | S |
| Quarantine | Isolate and validate external assets before allowing use | S |
| Rate Limiting | Control consumption rate of resources by consumers | R, S |
| Throttling | Control resource consumption to sustain SLAs under load | R, PE |
Deployment & Scaling
| Pattern | Summary | Pillars |
|---|---|---|
| Deployment Stamps | Deploy multiple independent copies of application components | R, PE |
| Edge Workload Configuration | Configure workloads differently across diverse edge devices | OE |
| Gateway Aggregation | Aggregate multiple backend calls into a single client request | PE |
| Gateway Offloading | Offload shared functionality (SSL, auth) to a gateway | OE, S |
| Gateway Routing | Route requests to multiple backends using a single endpoint | OE |
| Geode | Deploy backends to multiple regions for active-active serving | R, PE |
See Design Patterns Reference for detailed implementation guidance.
Technology Choices
Decision Framework
For each technology area, evaluate: requirements → constraints → tradeoffs → select.
| Area | Key Options | Selection Criteria |
|---|---|---|
| Compute | App Service, Functions, Container Apps, AKS, VMs, Batch | Hosting model, scaling, cost, team skills |
| Storage | Blob Storage, Data Lake, Files, Disks, Managed Lustre | Access patterns, throughput, cost tier |
| Data stores | SQL Database, Cosmos DB, PostgreSQL, Redis, Table Storage | Consistency model, query patterns, scale |
| Messaging | Service Bus, Event Hubs, Event Grid, Queue Storage | Ordering, throughput, pub/sub vs queue |
| Networking | Front Door, Application Gateway, Load Balancer, Traffic Manager | Global vs regional, L4 vs L7, WAF |
| AI services | Azure OpenAI, AI Search, AI Foundry, Document Intelligence | Model needs, data grounding, orchestration |
| Containers | Container Apps, AKS, Container Instances | Operational control vs simplicity |
See Technology Choices Reference for detailed decision trees.
Best Practices
| Practice | Key Guidance |
|---|---|
| API design | RESTful conventions, resource-oriented URIs, HATEOAS, versioning via URL path or header |
| API implementation | Async operations, pagination, idempotent PUT/DELETE, content negotiation, ETag caching |
| Autoscaling | Scale on metrics (CPU, queue depth, custom), cool-down periods, predictive scaling, scale-in protection |
| Background jobs | Use queues or scheduled triggers, idempotent processing, poison message handling, graceful shutdown |
| Caching | Cache-aside pattern, TTL policies, cache invalidation strategies, distributed cache for multi-instance |
| CDN | Static asset offloading, cache-busting with versioned URLs, geo-distribution, HTTPS enforcement |
| Data partitioning | Horizontal (sharding), vertical, functional partitioning; partition key selection for even distribution |
| Partitioning strategies | Hash-based, range-based, directory-based; rebalancing approach, cross-partition query avoidance |
| Host name preservation | Preserve original host header through proxies/gateways for cookies, redirects, auth flows |
| Message encoding | Schema evolution (Avro/Protobuf), backward/forward compatibility, schema registry |
| Monitoring & diagnostics | Structured logging, distributed tracing (W3C Trace Context), metrics, alerts, dashboards |
| Transient fault handling | Retry with exponential backoff + jitter, circuit breaker, idempotency keys, timeout budgets |
See Best Practices Reference for implementation details.
Performance Antipatterns
Avoid these common patterns that degrade performance under load:
| Antipattern | Problem | Fix |
|---|---|---|
| Busy Database | Offloading too much processing to the database | Move logic to application tier, use caching |
| Busy Front End | Resource-intensive work on frontend request threads | Offload to background workers/queues |
| Chatty I/O | Many small I/O requests instead of fewer large ones | Batch requests, use bulk APIs, buffer writes |
| Extraneous Fetching | Retrieving more data than needed | Project only required fields, paginate, filter server-side |
| Improper Instantiation | Recreating expensive objects per request | Use singletons, connection pooling, HttpClientFactory |
| Monolithic Persistence | Single data store for all data types | Polyglot persistence — right store for each workload |
| No Caching | Repeatedly fetching unchanged data | Cache-aside pattern, CDN, output caching, Redis |
| Noisy Neighbor | One tenant consuming all shared resources | Bulkhead isolation, per-tenant quotas, throttling |
| Retry Storm | Aggressive retries overwhelming a recovering service | Exponential backoff + jitter, circuit breaker, retry budgets |
| Synchronous I/O | Blocking threads on I/O operations | Async/await, non-blocking I/O, reactive streams |
Mission-Critical Design
For workloads targeting 99.99%+ SLO, address these design areas:
| Design Area | Key Considerations |
|---|---|
| Application platform | Multi-region active-active, availability zones, Container Apps or AKS with zone redundancy |
| Application design | Stateless services, idempotent operations, graceful degradation, bulkhead isolation |
| Networking | Azure Front Door (global LB), DDoS Protection, private endpoints, redundant connectivity |
| Data platform | Multi-region Cosmos DB, zone-redundant SQL, async replication, conflict resolution |
| Deployment & testing | Blue-green deployments, canary releases, chaos engineering, automated rollback |
| Health modeling | Composite health scores, dependency health tracking, automated remediation, SLI dashboards |
| Security | Zero-trust, managed identity everywhere, key rotation, WAF policies, threat modeling |
| Operational procedures | Automated runbooks, incident response playbooks, game days, postmortems |
See Mission-Critical Reference for detailed guidance.
Well-Architected Framework (WAF) Pillars
Every architecture decision should be evaluated against all five pillars:
| Pillar | Focus | Key Questions |
|---|---|---|
| Reliability | Resiliency, availability, disaster recovery | What is the RTO/RPO? How does it handle failures? Is there redundancy? |
| Security | Threat protection, identity, data protection | Is identity managed? Is data encrypted? Are there network controls? |
| Cost Optimization | Cost management, efficiency, right-sizing | Is compute right-sized? Are there reserved instances? Is there waste? |
| Operational Excellence | Monitoring, deployment, automation | Is deployment automated? Is there observability? Are there runbooks? |
| Performance Efficiency | Scaling, load testing, performance targets | Can it scale horizontally? Are there performance baselines? Is caching used? |
WAF Tradeoff Matrix
| Optimizing for... | May impact... |
|---|---|
| Reliability (redundancy) | Cost (more resources) |
| Security (isolation) | Performance (added latency) |
| Cost (consolidation) | Reliability (shared failure domains) |
| Performance (caching) | Cost (cache infrastructure), Reliability (stale data) |
Architecture Review Workflow
When reviewing or designing a system, follow this structured approach:
Step 1: Identify Requirements
Functional: What must the system do?
Non-functional:
- Availability target (e.g., 99.9%, 99.99%)
- Latency requirements (p50, p95, p99)
- Throughput (requests/sec, messages/sec)
- Data residency and compliance
- Recovery targets (RTO, RPO)
- Cost constraintsStep 2: Select Architecture Style
Match requirements to architecture style using the selection criteria table above.
Step 3: Choose Technology Stack
Use the technology choices decision framework. Prefer managed services (PaaS) over IaaS.
Step 4: Apply Design Patterns
Select relevant patterns from the 44 cloud design patterns based on identified concerns.
Step 5: Address Cross-Cutting Concerns
Identity & access — Microsoft Entra ID, managed identity, RBAC
Monitoring — Application Insights, Azure Monitor, Log Analytics
Security — Network segmentation, encryption at rest/in transit, Key Vault
CI/CD — GitHub Actions, Azure DevOps Pipelines, infrastructure as code
Step 6: Validate Against WAF Pillars
Review each pillar systematically. Document tradeoffs explicitly.
Step 7: Document Decisions
Use Architecture Decision Records (ADRs):
# ADR-NNN: [Decision Title]
## Status: [Proposed | Accepted | Deprecated]
## Context
[What is the issue we're addressing?]
## Decision
[What did we decide and why?]
## Consequences
[What are the positive and negative impacts?]References
Design Patterns Reference — Detailed pattern implementations
Technology Choices Reference — Decision trees for Azure services
Best Practices Reference — Implementation guidance
Mission-Critical Reference — High-availability design
Source
Content derived from the Azure Architecture Center — Microsoft's official guidance for cloud solution architecture on Azure. Covers design principles, architecture styles, cloud design patterns, technology choices, best practices, performance antipatterns, mission-critical design, and the Well-Architected Framework.
Files
- ATTRIBUTION.mdAdded by AutoGineer879 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md17.1 KiB
- references/architecture-styles.md15.0 KiB
- references/best-practices.md11.5 KiB
- references/design-patterns.md37.9 KiB
- references/design-principles.md16.5 KiB
- references/mission-critical.md14.7 KiB
- references/performance-antipatterns.md7.6 KiB
- references/technology-choices.md7.6 KiB
references/best-practices.md
Cloud Application Best Practices
Twelve best practices from the Azure Architecture Center for designing, building, and operating cloud applications.
1. API Design
Design RESTful web APIs that promote platform independence and loose coupling between clients and services.
Key Recommendations
Organize APIs around resources using nouns, not verbs, in URIs
Use standard HTTP methods (GET, POST, PUT, PATCH, DELETE) with correct semantics
Use plural nouns for collection endpoints (e.g.,
/orders,/customers)Support HATEOAS to enable client navigation of the API without prior knowledge
Design coarse-grained operations to avoid chatty request patterns
Do not expose internal database structure through the API surface
Version APIs to manage breaking changes without disrupting existing clients
Return appropriate HTTP status codes and consistent error response bodies
WAF Pillar Alignment
Performance Efficiency · Operational Excellence
Common Mistakes
Using verbs in URIs (e.g.,
/getOrders) instead of resource-based pathsExposing database schema directly through API contracts
Creating chatty APIs that require multiple round-trips for a single logical operation
2. API Implementation
Implement web APIs to be efficient, responsive, scalable, and available for consuming clients.
Key Recommendations
Make actions idempotent so retries are safe (especially PUT and DELETE)
Support content negotiation via
AcceptandContent-TypeheadersFollow the HTTP specification for status codes, methods, and headers
Handle exceptions gracefully and return meaningful error responses
Support resource discovery through links and metadata
Limit and paginate large result sets to minimize network traffic
Handle large requests asynchronously using
202 Acceptedwith status pollingCompress responses where appropriate to reduce payload size
WAF Pillar Alignment
Operational Excellence
Common Mistakes
Not handling large requests asynchronously, causing timeouts
Not minimizing network traffic through pagination, filtering, or compression
3. Autoscaling
Dynamically allocate and deallocate resources to match performance requirements while optimizing cost.
Key Recommendations
Use Azure Monitor autoscale and built-in platform autoscaling features
Scale based on metrics that directly correlate with load (CPU, queue length, request rate)
Combine schedule-based and metric-based scaling for predictable traffic patterns
Set appropriate minimum, maximum, and default instance counts
Configure scale-in rules as carefully as scale-out rules
Use cooldown periods to prevent oscillation (flapping)
Plan for the delay between triggering a scale event and resources becoming available
WAF Pillar Alignment
Performance Efficiency · Cost Optimization
Common Mistakes
Not setting appropriate minimum and maximum limits for scaling
Not considering scale-in behavior, leading to premature resource removal
Using metrics that do not accurately reflect application load
4. Background Jobs
Implement batch processing, long-running tasks, and workflows as background jobs decoupled from the user interface.
Key Recommendations
Use Azure platform services such as Functions, WebJobs, and Batch for hosting
Trigger background jobs with events, schedules, or message queues
Return results to calling tasks through queues, events, or shared storage
Design jobs to be independently deployable, scalable, and versioned
Handle partial failures and support safe restarts with checkpointing
Monitor job health with logging, metrics, and alerting
Implement graceful shutdown to allow in-progress work to complete
WAF Pillar Alignment
Operational Excellence
Common Mistakes
Not handling failures or partial completion within long-running jobs
Not monitoring background job health, missing silent failures
5. Caching
Copy frequently read, rarely modified data to fast storage close to the application to improve performance.
Key Recommendations
Cache data that is read often but changes infrequently
Use Azure Cache for Redis for distributed, high-throughput caching
Set appropriate expiration policies (TTL) to balance freshness and hit rates
Handle cache misses gracefully with a cache-aside pattern
Address concurrency issues when multiple processes update the same cached data
Implement cache invalidation strategies aligned with data change patterns
Pre-populate caches for known hot data during application startup
WAF Pillar Alignment
Performance Efficiency
Common Mistakes
Caching highly volatile data that expires before it can be served
Not handling cache invalidation, serving stale data to users
Cache stampede — many concurrent requests regenerating the same expired entry
6. CDN (Content Delivery Network)
Use CDNs to deliver static and dynamic web content efficiently to users from edge locations worldwide.
Key Recommendations
Offload static assets (images, scripts, stylesheets) to the CDN to reduce origin load
Configure appropriate cache-control headers for each content type
Version static content via file names or query strings for reliable cache busting
Use HTTPS and enforce TLS for secure delivery
Plan for CDN fallback so the application degrades gracefully if the CDN is unavailable
Handle deployment and versioning so users receive updated content promptly
WAF Pillar Alignment
Performance Efficiency
Common Mistakes
Not versioning content, causing users to receive stale cached assets after deployments
Setting improper cache headers, resulting in under-caching or over-caching
7. Data Partitioning
Divide data stores into partitions to improve scalability, availability, and performance while reducing contention and storage costs.
Key Recommendations
Choose partition keys that distribute data and load evenly across partitions
Use horizontal (sharding), vertical, or functional partitioning based on access patterns
Minimize cross-partition queries to avoid performance degradation
Design partitions to match the most common query patterns
Plan for rebalancing as data volume and access patterns evolve
Consider partition limits and throughput caps of the target data store
Reduce contention and storage costs by separating hot and cold data
WAF Pillar Alignment
Performance Efficiency · Cost Optimization
Common Mistakes
Creating hotspots by selecting a partition key with skewed distribution
Not considering the cost and latency of cross-partition queries
8. Data Partitioning Strategies (by Service)
Apply service-specific partitioning strategies across Azure SQL Database, Azure Table Storage, Azure Blob Storage, and other data services.
Key Recommendations
Shard Azure SQL Database to distribute data for horizontal scaling
Design Azure Table Storage partition keys around query access patterns
Organize Azure Blob Storage using virtual directories and naming conventions
Align partition boundaries with the most frequent query predicates
Reduce latency by co-locating related data within the same partition
Monitor partition metrics and rebalance when skew is detected
WAF Pillar Alignment
Performance Efficiency · Cost Optimization
Common Mistakes
Not aligning the partition strategy with actual query patterns, causing full scans
Ignoring service-specific partition limits and throttling thresholds
9. Host Name Preservation
Preserve the original HTTP host name between reverse proxies and backend web applications to avoid issues with cookies, redirects, and CORS.
Key Recommendations
Forward the original
Hostheader from the reverse proxy to the backendConfigure Azure Front Door, Application Gateway, and API Management for host preservation
Ensure cookies are set with the correct domain matching the original host name
Verify redirect URLs reference the external host name, not the internal backend address
Test CORS configurations end-to-end with the preserved host name
Document host name flow across all network hops in the architecture
WAF Pillar Alignment
Reliability
Common Mistakes
Not preserving host headers, causing redirect loops or incorrect absolute URLs
Breaking session cookies because the cookie domain does not match the forwarded host
10. Message Encoding
Choose the right payload structure, encoding format, and serialization library for asynchronous messages exchanged between distributed components.
Key Recommendations
Evaluate JSON, Avro, Protobuf, and MessagePack based on performance and interoperability needs
Use schema registries to enforce and version message contracts
Validate incoming messages against their schemas before processing
Prefer compact binary formats (Protobuf, Avro) for high-throughput, latency-sensitive paths
Use JSON for human-readable messages and broad ecosystem compatibility
Consider backward and forward compatibility when evolving message schemas
WAF Pillar Alignment
Security
Common Mistakes
Using an inefficient encoding format for high-volume message streams
Not validating message schemas, allowing malformed data into the processing pipeline
11. Monitoring and Diagnostics
Track system health, usage, and performance through a comprehensive monitoring pipeline that turns raw data into alerts, reports, and automated triggers.
Key Recommendations
Instrument applications with structured logging, metrics, and distributed tracing
Use Azure Monitor, Application Insights, and Log Analytics as the monitoring backbone
Define actionable alerts with clear thresholds, severity levels, and response procedures
Detect and correct issues before they affect users by monitoring leading indicators
Correlate telemetry across services using distributed trace context (e.g., correlation IDs)
Establish performance baselines and track deviations over time
Build dashboards for operational visibility across all tiers of the architecture
Review and tune alert rules regularly to reduce noise
WAF Pillar Alignment
Operational Excellence
Common Mistakes
Insufficient logging, making incident root-cause analysis slow or impossible
Not using distributed tracing in microservice or multi-tier architectures
Alert fatigue from poorly tuned thresholds that generate excessive false positives
12. Transient Fault Handling
Detect and handle transient faults caused by momentary loss of network connectivity, temporary service unavailability, or resource throttling.
Key Recommendations
Implement retry logic with exponential backoff and jitter for transient failures
Use a circuit breaker pattern to stop retrying when failures are persistent
Distinguish transient faults (e.g., HTTP 429, 503) from permanent errors (e.g., 400, 404)
Leverage built-in retry policies in Azure SDKs before adding custom retry logic
Avoid duplicating retry layers across middleware and application code
Log every retry attempt for post-incident analysis
Set a maximum retry count and total timeout to bound retry duration
WAF Pillar Alignment
Reliability
Common Mistakes
Retrying non-transient faults (e.g., authentication failures, bad requests)
Not using exponential backoff, overwhelming a recovering service with constant retries
Retry storms caused by multiple layers retrying simultaneously without coordination
Source: Azure Architecture Center
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Microsoft
- Publisher
- Microsoft (Official)
- Source
- microsoft/skills · .github/skills/cloud-solution-architect · commit 0696600
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download cloud-solution-architect.zip