> cloud-solution-architect

Transform the agent into a Cloud Solution Architect following Azure Architecture Center best practices. Use when designing cloud architectures, reviewing system designs, selecting architecture styles, applying cloud design patterns, making technology choices, or conducting Well-Architected Framework reviews.

fetch
$curl "https://skillshub.wtf/microsoft/skills/cloud-solution-architect?format=md"
SKILL.mdcloud-solution-architect

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

#PrincipleKey Tactics
1Design for self-healingRetry with backoff, circuit breaker, bulkhead isolation, health endpoint monitoring, graceful degradation
2Make all things redundantEliminate single points of failure, use availability zones, deploy multi-region, replicate data
3Minimize coordinationDecouple services, use async messaging, embrace eventual consistency, use domain events
4Design to scale outHorizontal scaling, autoscaling rules, stateless services, avoid session stickiness, partition workloads
5Partition around limitsData partitioning (shard/hash/range), respect compute & network limits, use CDNs for static content
6Design for operationsStructured logging, distributed tracing, metrics & dashboards, runbook automation, infrastructure as code
7Use managed servicesPrefer PaaS over IaaS, reduce operational burden, leverage built-in HA/DR/scaling
8Use an identity serviceMicrosoft Entra ID, managed identity, RBAC, avoid storing credentials, zero-trust principles
9Design for evolutionLoose coupling, versioned APIs, backward compatibility, async messaging for integration, feature flags
10Build for business needsDefine SLAs/SLOs, establish RTO/RPO targets, domain-driven design, cost modeling, composite SLAs

Architecture Styles

StyleDescriptionWhen to UseKey Services
N-tierHorizontal layers (presentation, business, data)Traditional enterprise apps, lift-and-shiftApp Service, SQL Database, VNets
Web-Queue-WorkerWeb frontend → message queue → backend workerModerate-complexity apps with long-running tasksApp Service, Service Bus, Functions
MicroservicesSmall autonomous services, bounded contexts, independent deployComplex domains, independent team scalingAKS, Container Apps, API Management
Event-drivenPub/sub model, event producers/consumersReal-time processing, IoT, reactive systemsEvent Hubs, Event Grid, Functions
Big dataBatch + stream processing pipelineAnalytics, ML pipelines, large-scale dataSynapse, Data Factory, Databricks
Big computeHPC, parallel processingSimulations, modeling, rendering, genomicsBatch, 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

PatternSummaryPillars
Asynchronous Request-ReplyDecouple request/response with polling or callbacksR, PE
Claim CheckSplit large messages; store payload separately, pass referenceR, PE
ChoreographyServices coordinate via events without central orchestratorR, OE
Competing ConsumersMultiple consumers process messages from shared queue concurrentlyR, PE
Messaging BridgeConnect incompatible messaging systemsR, OE
Pipes and FiltersDecompose complex processing into reusable filter stagesR, OE
Priority QueuePrioritize requests so higher-priority work is processed firstR, PE
Publisher/SubscriberDecouple senders from receivers via topics/subscriptionsR, PE
Queue-Based Load LevelingBuffer requests with a queue to smooth intermittent loadsR, PE
Sequential ConvoyProcess related messages in order while allowing parallel groupsR, PE

Reliability & Resilience

PatternSummaryPillars
BulkheadIsolate resources per workload to prevent cascading failureR
Circuit BreakerStop calling a failing service; fail fast to protect resourcesR
Compensating TransactionUndo previously committed steps when a later step failsR
Health Endpoint MonitoringExpose health checks for load balancers and orchestratorsR, OE
Leader ElectionCoordinate distributed instances by electing a leaderR
RetryHandle transient faults by retrying with exponential backoffR
SagaManage data consistency across microservices with compensating transactionsR
Scheduler Agent SupervisorCoordinate distributed actions with retry and failure handlingR

Data Management

PatternSummaryPillars
Cache-AsideLoad data on demand into cache from data storePE
CQRSSeparate read and write models for independent scalingPE, R
Event SourcingStore state as append-only sequence of domain eventsR, OE
Index TableCreate indexes over frequently queried fields in data storesPE
Materialized ViewPre-compute views over data for efficient queriesPE
ShardingDistribute data across partitions for scale and performancePE, R
Static Content HostingServe static content from cloud storage/CDN directlyPE, CO
Valet KeyGrant clients limited direct access to storage resourcesS, PE

Design & Structure

PatternSummaryPillars
AmbassadorOffload cross-cutting concerns to a helper sidecar proxyOE
Anti-Corruption LayerTranslate between new and legacy system modelsOE, R
Backends for FrontendsCreate separate backends per frontend type (mobile, web, etc.)OE, PE
Compute Resource ConsolidationCombine multiple workloads into fewer compute instancesCO
External Configuration StoreExternalize configuration from deployment packagesOE
SidecarDeploy helper components alongside the main serviceOE
Strangler FigIncrementally migrate legacy systems by replacing piecesOE, R

Security & Access

PatternSummaryPillars
Federated IdentityDelegate authentication to an external identity providerS
GatekeeperProtect services using a dedicated broker that validates requestsS
QuarantineIsolate and validate external assets before allowing useS
Rate LimitingControl consumption rate of resources by consumersR, S
ThrottlingControl resource consumption to sustain SLAs under loadR, PE

Deployment & Scaling

PatternSummaryPillars
Deployment StampsDeploy multiple independent copies of application componentsR, PE
Edge Workload ConfigurationConfigure workloads differently across diverse edge devicesOE
Gateway AggregationAggregate multiple backend calls into a single client requestPE
Gateway OffloadingOffload shared functionality (SSL, auth) to a gatewayOE, S
Gateway RoutingRoute requests to multiple backends using a single endpointOE
GeodeDeploy backends to multiple regions for active-active servingR, PE

See Design Patterns Reference for detailed implementation guidance.


Technology Choices

Decision Framework

For each technology area, evaluate: requirements → constraints → tradeoffs → select.

AreaKey OptionsSelection Criteria
ComputeApp Service, Functions, Container Apps, AKS, VMs, BatchHosting model, scaling, cost, team skills
StorageBlob Storage, Data Lake, Files, Disks, Managed LustreAccess patterns, throughput, cost tier
Data storesSQL Database, Cosmos DB, PostgreSQL, Redis, Table StorageConsistency model, query patterns, scale
MessagingService Bus, Event Hubs, Event Grid, Queue StorageOrdering, throughput, pub/sub vs queue
NetworkingFront Door, Application Gateway, Load Balancer, Traffic ManagerGlobal vs regional, L4 vs L7, WAF
AI servicesAzure OpenAI, AI Search, AI Foundry, Document IntelligenceModel needs, data grounding, orchestration
ContainersContainer Apps, AKS, Container InstancesOperational control vs simplicity

See Technology Choices Reference for detailed decision trees.


Best Practices

PracticeKey Guidance
API designRESTful conventions, resource-oriented URIs, HATEOAS, versioning via URL path or header
API implementationAsync operations, pagination, idempotent PUT/DELETE, content negotiation, ETag caching
AutoscalingScale on metrics (CPU, queue depth, custom), cool-down periods, predictive scaling, scale-in protection
Background jobsUse queues or scheduled triggers, idempotent processing, poison message handling, graceful shutdown
CachingCache-aside pattern, TTL policies, cache invalidation strategies, distributed cache for multi-instance
CDNStatic asset offloading, cache-busting with versioned URLs, geo-distribution, HTTPS enforcement
Data partitioningHorizontal (sharding), vertical, functional partitioning; partition key selection for even distribution
Partitioning strategiesHash-based, range-based, directory-based; rebalancing approach, cross-partition query avoidance
Host name preservationPreserve original host header through proxies/gateways for cookies, redirects, auth flows
Message encodingSchema evolution (Avro/Protobuf), backward/forward compatibility, schema registry
Monitoring & diagnosticsStructured logging, distributed tracing (W3C Trace Context), metrics, alerts, dashboards
Transient fault handlingRetry 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:

AntipatternProblemFix
Busy DatabaseOffloading too much processing to the databaseMove logic to application tier, use caching
Busy Front EndResource-intensive work on frontend request threadsOffload to background workers/queues
Chatty I/OMany small I/O requests instead of fewer large onesBatch requests, use bulk APIs, buffer writes
Extraneous FetchingRetrieving more data than neededProject only required fields, paginate, filter server-side
Improper InstantiationRecreating expensive objects per requestUse singletons, connection pooling, HttpClientFactory
Monolithic PersistenceSingle data store for all data typesPolyglot persistence — right store for each workload
No CachingRepeatedly fetching unchanged dataCache-aside pattern, CDN, output caching, Redis
Noisy NeighborOne tenant consuming all shared resourcesBulkhead isolation, per-tenant quotas, throttling
Retry StormAggressive retries overwhelming a recovering serviceExponential backoff + jitter, circuit breaker, retry budgets
Synchronous I/OBlocking threads on I/O operationsAsync/await, non-blocking I/O, reactive streams

Mission-Critical Design

For workloads targeting 99.99%+ SLO, address these design areas:

Design AreaKey Considerations
Application platformMulti-region active-active, availability zones, Container Apps or AKS with zone redundancy
Application designStateless services, idempotent operations, graceful degradation, bulkhead isolation
NetworkingAzure Front Door (global LB), DDoS Protection, private endpoints, redundant connectivity
Data platformMulti-region Cosmos DB, zone-redundant SQL, async replication, conflict resolution
Deployment & testingBlue-green deployments, canary releases, chaos engineering, automated rollback
Health modelingComposite health scores, dependency health tracking, automated remediation, SLI dashboards
SecurityZero-trust, managed identity everywhere, key rotation, WAF policies, threat modeling
Operational proceduresAutomated 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:

PillarFocusKey Questions
ReliabilityResiliency, availability, disaster recoveryWhat is the RTO/RPO? How does it handle failures? Is there redundancy?
SecurityThreat protection, identity, data protectionIs identity managed? Is data encrypted? Are there network controls?
Cost OptimizationCost management, efficiency, right-sizingIs compute right-sized? Are there reserved instances? Is there waste?
Operational ExcellenceMonitoring, deployment, automationIs deployment automated? Is there observability? Are there runbooks?
Performance EfficiencyScaling, load testing, performance targetsCan 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 constraints

Step 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


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.

┌ stats

installs/wk0
░░░░░░░░░░
github stars1.8K
██████████
first seenMar 17, 2026
└────────────

┌ repo

microsoft/skills
by microsoft
└────────────

┌ tags

└────────────